Seed stage design system
I leveraged a lean design system that quickly brought cohesion to a financial services platform and the EPD team that built it. This project became the company’s foundation for more strategic (and less expensive) product development.
I came to Wingspan, a finance app for contract workers and freelancers, as the founding designer. When I arrived, the state of the product, like many early stage ideas, was a disjointed proof of concept that had secured a seed funding round, but was not yet finding product-market-fit. With the funding runway set, I was tasked with imparting a strategic, user-centered approach to bring Wingspan to the status of “all-in-one platform”. The main measure of success was to support the business’s goal of user growth.
I led design and project management and we had one engineering lead, and two developers.
Initial socialization to business: May 2020
Begin focused design process: January 2021
Migrate existing components: April 2021
- Products at various stages of incompleteness. Priorities were hard to confidently define and pieces were tackled partially and inefficiently.
- Not yet all-in-one. There wasn’t a feeling of unification across the products, so Wingspan’s value proposition was not yet coming across to users.
- No product culture. The engineering culture was unharmonious and inexperienced regarding an iterative, user-centered approach.
I audited the app and evaluated the full feature set from a systems perspective. My hypothesis was that introducing a lean design system would:
- Focus designs to reach feature completeness. Constraints would guide us to graceful and consistent polish across the entire platform.
- Obviate time spent on usability issues and bugs. Both user experience and engineering output and morale would significantly improve in quality.
- Define a better product development culture. This was the first project that required communication and collaboration between engineering, product, and design. I used it as a tool for learning how we could work together happily and efficiently.
How might we use a design system (instead of feature development) to unify multiple products into an all-in-one platform experience?
Prioritizing a design system over feature development
My goal was for a component library to be built in-step with the design system right from the beginning. My resolve was strong to break free of the common early stage pattern of building out a design system only for it to rot in Figma as engineering prioritized more “direct” and “immediate” goals. I advocated my vision to the team.
Long term perspective
Make feature development less expensive. By virtue of implementing it, applying the design system to the platform would improve usability, raising the overall quality of user experience across the board. With that generic improvement clearing a lot of UX noise, the lowest performing product could be more clearly assessed from a feature deficiency perspective. Development priorities would be more confident and strategic, wasted work would be mitigated.
Bundling within a project
Get the ball rolling with a quick win. I had had success in the past first applying a design system to a small contained project and I did it again here. Bounding the design system within a less overwhelming space allures engineers with a quick win. The feature got built, the design system kinks got worked out, then migration to the rest of the product becomes more exciting for all.
Planning the design system
Auditing for a baseline
I took stock of existing usability issues with my own heuristic evaluation and feedback from users and user-facing teammates. A newly discovered trend was that our users were defaulting to mobile, even for long sessions of administrative tasks. Addressing visual inconsistencies from feature to feature was the lowest hanging fruit to quicken adoption and improve repeat session experience.
Establishing lean priorities
I created a scope for the very initial design system that struck a good balance. It was simple enough to create a sense of uniformity and expected convention across all major user flows.
The lean design system had only the following foundations and components:
- Layout (navigation, page header)
Introducing a review process
This was a brand new approach for leadership, so there were many stages of review for everyone to feel confident in pursuing this strategy. Design critiques, technical engineering evaluation, pre-launch usability testing, and in-prod usage evaluation were all techniques employed to make shipment a success.
Implementation and migration
Failed first attempt
The engineering team had no prior familiarity with design systems or component libraries and the “bundling within a project” hypothesis failed to yield a component library. As the founding and only designer, I moved onto a different project post hand-off and my secondary contribution was insufficient for meeting the design system goal. My disappointment aside, this attempt served to solidify team buy-in for a more dedicated second attempt.
A new engineering team was tasked with focusing on the design system without the noise of any additional goals. My review process within engineering implementation became much heavier and helped yield the outcomes I had initially set.
The biggest challenge was that once we hit our groove, there was a push for me to design “all the components we will ever need”. It took extra effort to explain that without a defined understanding of the future use cases, this was a futile act. We were able to stop that scope creep before burdening engineering.
I created an interface inventory with annotated screenshots so that 100% of upgradable components were handled. With this artifact, necessary rework to base components and new component instances was straightforward. The resulting consistency was an immediate happiness boost vocalized by users and the team. The rest of the engineers felt a new level of pride in their work - we had reached a point where the backend had connected harmoniously with the frontend. This satisfaction promoted greater care and quicker resolution of usability issues moving forward.
My biggest takeaway from this project was to not hesitate to lead, even if technical areas are usually led by engineering. General engineering leadership does not smoothly translate to good execution if there is a lack of experience. My expertise, if pushed stronger from the beginning, would have gotten us to our destination sooner.
I also deepened my understanding of the lack of understanding of design systems in startup culture. The disconnect between a design system and its use in Figma with coded componentization is more profound than I had realized. I can now provide a more thorough initial education for inexperienced parties.
Planning and execution was much more streamlined since we had come to a shared understanding of how to talk about components within a system. A few lingering complex custom flows could be reimagined and simplified to fit into our new design system. It also set us up for feature development required for our pivot from B2C to B2B2C.
The biggest business impact was simply that this project connected our product to the story we were trying to tell via marketing. Upon login and at first glance on each module of the platform, the value proposition and potential of Wingspan was now clear. B2C acquisition and adoption was much more hands-free. We were powerfully poised for fundraising.