Months ago, I started my journey here at Humi as the only designer at a rapidly scaling startup. Task number one seemed pretty straight forward; start building a design system. I had worked with design systems before during production work and helped to contribute to them, but never had the task of building one from the ground up. I was excited yet nervous as I knew how big of a beast design systems are, and how difficult it is for large teams to tackle, let alone by a single designer.
After months of hard work, I'm super excited to introduce the world to Lingo. It's been one hell of a ride, and I couldn't be more proud of everyone involved in the creation of Humi's first design system. Fortunately, this all lined up with our new branding, and it's exciting to see design at Humi catapult in such a short amount of time. I'll take you through the five stages that went into bringing Lingo to life.
1. Why are we doing this?
As with any project with design thinking applied, priority number one is to identify what the current problems were. Not having a design system has a slew of disadvantages as we all know, and one thing that needed to be determined right off the bat was the business advantages to building one. For us that meant:
Eliminate inefficiencies, inconsistencies & clarify problems that are regularly encountered.
Not having a source of truth with clear rules creates confusion and uncertainty when building UIs. Having a strong design system reduces design debt as the product scales.
Well-structured & consistent design output will improve code reusability
Developers will be large supporters of the Design System project by helping to build the code library. Rather than having to recreate one-off elements and maintain multiple versions of each element, they'll use an up-to-date library.
More time spent on problem-solving
Shifting design focus from creating custom and nuanced elements, to creating great customer experiences.
Meet standards for accessibility
Ensuring the product follows web standards and works efficiently for all customers.
Creating/maintaining a standard
Continuously contributing and iterating on elements to maintain quality and ensure scalability.
After observing and consulting with the product and engineering team, I discovered that building front-end was no easy task having no clear rules and guidelines. This reflected in our product with many inconsistencies in affordance, UI elements, spacing, the list goes on.
I conducted an audit that captured major areas and their specific flaws: icons, typography, use of dialogs, use of colour, every single kind of component, spacing/grids, and accessibility. The results were overwhelming and put into perspective how broken things were, and how fast things will continue to deteriorate if we continued down the same path.
We also had a look into component usage through our tracking on FullStory and Pendo. This helped us to gain insight into essential features to retain.
2. How Are We Going to Do This?
After identifying core problems and conducting a thorough audit, it was time to layout astrategy. Design systems are living things and are a constant work in progress. To treat it as such, we put together a core team that would be dedicated to the creation and maintenance. The goal was to treat this as a squad with engineering, product, and design working in harmony as we do with any other project.
After taking the results from the audit, we laid out what was necessary to retain, items that were redundant or obsolete, and what was missing. Using atomic principles as our guide, we set out our roadmap to plan work around releasing areas of the design system. Things that were taken into account include engineering/design bandwidth, level of effort, other product releases, and branding timelines. As I mentioned in the beginning, the marketing department was simultaneously working on building out our new branding which was a perfect opportunity for our UI to get some TLC.
Another important part of this step was the setting of what KPIs we were going to be tracking. To define what success will look like, we listed metrics that we will continuously monitor to determine what's going well and what might need some work.
3. Building for Scale
We can all agree there are hundreds of design systems out there, some gigantic and comprehensive and some lean and nimble. The critical thing to note is that there isn't a one size fits all approach to creating one. It has to tailor to your specific company's needs, though it is highly beneficial to check out what others are doing to get a sense of standards.
I looked at several different types of design systems and found that most were also following the atomic principals, which validated our approach. I started tackling the "atoms" which involved seeking out a new font, color palette, iconography, and use of spacing. Since these elements are shared with branding, I included our brand designer Simon on the explorations and decision making to ensure cohesion between brand and product. Together we searched, tested, and ultimately decided on the elements above and created rules on usage. From there, I began fleshing out the next steps including the molecules, organisms, and templates.
I also met with Mike, the engineer, on my team, weekly to scope out work on the engineering side. Since we were changing from Semantic to Angular Material, we had to accommodate setting up our new front-end infrastructure.
4. Iterate, Test and Iterate Some More
It's super important to take your design system out for a few test drives before entering the big race. We knew that we'd need to put it to use to hone in on areas that needed work. We also needed to validate that what we built would serve as useful for our product, and put our theories into practice. We set up a staging environment and used it as our playground to test components, visual elements, and accessibility.
Some interesting findings arose when we shared the environment internally. Many didn't like the accent colours we picked as it didn't feel connected to the new branding. We also received feedback on contrast and use of imagery. After going back to the drawing board, I created some new concepts and sent out a survey to see what peoples thought were. This helped to gain consensus on personal preference and accessibility as some folks had perceived contrast differently, even though everything was WCAG compliant. I had set up one-on-ones to dive into qualitative feedback and the nuances.
5. Sweat the details
In the final stage, we dedicated our time to finely tuning every single pixel in the development environment. Now is the time to ensure that everything is pixel perfect and behaves as we intended it to. A design system's major goal is to make designing and building UIs easier with a high standard of quality. To stay true to the goals we set, we needed to ensure that the hard work that went into all stages of the project was reflected in the first ship. Here at Humi we always give time to honing into details, which is why we had separate QA sessions for different major areas such as Atomic changes (colour, icons, typography, spacing), Icons, Illustrations, and form components.
I'd like to thank everyone who helped to bring this into reality. It couldn't have been done without everyone's care and effort. I'm extremely proud to work with such talented and driven individuals.
I also want to give a shout out to Figma. This opportunity finally helped me to make the jump from sketch, and I have no regrets. I highly recommend Figma for housing your design system due to its effortless maintenance, easy setup, and all-around great support.
Bonus learnings
Design systems are not UI kits
There are so many moving parts that make up a design system, a UI kit is only one aspect.
Documentation is everything
You'll thank yourself later. Record every win, failure, and finding throughout the way.
Things can change, and they should
Nothing has to be set in stone. Since it takes months at a minimum to build, things will change in the team, company, and ultimately needs of the design system.
Usability testing is just as important as with any project
The last thing you want is to work long and hard at something only to get it wrong. Show early and often, and take what you build on test runs.
It takes a village
Design is a collaborative sport, and none of this would have been possible without the help of product, marketing, engineering, and everyone who had a hand in helping.
.jpg){kind=avatar}