Building my first design system, for a fintech company

🔬 Discovery

I shadowed and interviewed engineers to understand their processes when turning designs to code. We discovered that consistency is not only a visual problem but also a problem in code, and that it creates more problem dragging the team overall performance.

Look-alike buttons with same functionality, but coded twice

After that, I started doing my research and stumbled upon design systems, it's benefits (for me and the team) and its differences between UI libraries and frameworks such as Bootsrap. The only thing that's not clear is how to build one.

🔎 Key findings

• Components look similar but CSS classes was barely reused due to lack of component library and documentations.
• Inconsistencies visually and in code across products, multiplies tech and design debt, slowing down the team velocity.
• App performance suffers due to bloat code.
• Turning design to code consumes up to 50% of engineers time in their 2-week sprints.

💡 Strategy & ideation

After going through articles and pages about design system, talking to engineers and stakeholders, I managed to convince our CTO for us to create our own design system. I proposed a strategy on how I'll implement it while working on constant demand of design and without disrupting or creating chaos for engineers.

🛠 Methods and tools

• Use Atomic Design Methodology.
• Use BEM methodology for the CSS classes.
• Mobile-first approach as we saw in data (Google Analytics and FullStory) that more than half of our users / visitors uses a mobile device.
• Set-up a staging environment that constantly mirrors the production code for easier implementation.
• Coda for auditing components, creating an inventory, project management and reporting tool.
• Catalog for documentation guidelines.
• Coding tools: Prepros for processing files, PugJS / Jade for HTML, Stylus for CSS. A local setup of a dedicated staging environment for design in ReactJS.

Project phases

• Phase 1: Audit all pages and screens. Compare all used components in all pages. The goal is to create a backlog of what needs to be fixed, replaced, repurposed, merged and archived.
• Phase 2: Building the component library and documenting every single component with its use cases, when and how.
• Phase 3: Implementing and replacing all old components in every pages to be rolled-out slowly per sprint.

🚀 Execution & implementation

No matter how fancy and straightforward the strategy is, execution is always the tricky part, but all-in-all, with the collaboration of the whole team and buy-ins from our CTO, I was able to pull it off.

😣 Challenges

• First time to build a robust library from scratch
• I had to manage my time carefully, so that I can still deliver design while building the design system.
• It was comfortable to just copy, but eventually had to refactor and archive components and code, because when building a design system, you have to be intentional.
• Writing down design principles & documentation of usage guidelines.
• Designing and coding components, mobile-first. This means that while I'm conceptualizing how the element should look like, I will also need to plan and consider how it will look like in tablets or desktops. Full-width elements may not always look good full-width in tablets and desktops (eg. Buttons, input fields and textareas)

📆 Timeline: 8 months

• First 2 months (4 sprints) to audit, create a component inventory, and do the rest of discovery work.
• Month 3 was used to plan how to develop the base components (used 90% of the time / page like buttons)
• Month 4, Using the backlog, I started rolling out the completed components and continue working on the rest. For example, for week 1, I'll be updating form components such as buttons and text fields.
• Month 5-8, Once I got the momentum, I just rinsed and repeated my process while reporting the progress with the whole team.

Business outcomes

Upon completing, implementing and usage of the stable, "1.0.0" build, we started benefitting from the perks of having one.

• Completing and using our design system, sped-up design production by 40-60%, removed 99.9% of UI implementation (CSS) work for engineers which also made them happier. Enabling me to serve 3 product teams with ease.
• Single source of truth in design and code.
• Achieved a 99.9% consistency, for our end-to-end customer facing screens, which is usable for phones, tablets and laptops.
• Happier engineers as they have more time focusing on developing functions instead of spending 20%-50% of their time translating design to code.
• Leaner and DRY(Stylus/CSS) code reducing 99.9% of bloat code and speeding up loading speed by 15-20%.
• Rapid prototyping are done by adding a few lines of codes.
  • UX flows are quickly visualized.
  • Prototyping and testing ideas are done in brainstorming and ideation sessions.
  • Product Owners can also use it as a sandbox by playing with a little HTML
• Faster onboarding for new engineers as the documentation exists.

Learnings and takeaways

Completing the design system had tremendously made our lives easier. The caveat here though is that maintenance, like any product is as important as building it. As your product evolve, so will your design system, and without proper maintenance, it will grow to the point that it will start working against your team. With that, here are some of my key takeaways building one:

• Naming convention is hard. Specially if you want it to be reusable.
• To remain lean and intentional, every design tokens and components should have their purpose why it exists.
• The documentation should answer how, when and why a component should be used, especially if there are variants or it will just be a component library and not a design system.
• The design system is for the whole organization and not only for designers, so strategize and evangelize the importance and benefits of having one or it will not be adapted.
• Inconsistencies are byproducts of lack of documentations, communication and proper system such as doing regular audits and reviews.
• Again, maintaining and scaling a design system is as if not more crucial than building one, And for it to be maintained, you will have to look for another designer or a design engineer to help/replace you.