A Design System to build products for any brand, on any digital platform, web or mobile

The Challenge

How might we build a design system we can use for any future product, with support for web, iOS and Android?

research

Design Systems start with research

I started the project by digging deep into the problem and taking inventory of previous design systems to learn what went wrong. I also ran a comparative analysis with the top multi-product design systems, such as IBM Carbon and Adobe Spectrum. Finally, I interviewed the users: my fellow designers and engineers.

Here are some of the insights from the conversations with team members, and research done on previous design systems:

building the system

Start small, and evolve from there

Given that we were trying to build a design system to solve any problem, it would have been easy to fall into the trap of building a very complex problem from the start. Being the systems thinking nut that I am, I knew this approach would not work. So I decided to heed Gall's Law's advice, which states that "to build a complex system that works, you must build a simpler system first, and then evolve it over time."

A top-down approach

So I started with the bare essentials: the principles to drive the system, a foundational set of styles, a minimal component library, and the procedures to update and keep the system alive.

By following this top-down approach, I was avoiding past mistakes, where we focused on the "What of the system" and instead allowing the Design Principles to drive growth of the system.

A system driven by principles

The one thing all top-tier systems have in common is that principles drive them. It is the principles that define the purpose of the system.

Principles are like a guiding compass if you will. They empower individuals to contribute, ensuring that updates align with the system's purpose. But they must be actionable and measurable to be effective.

After some iteration, I landed on a set of principles that were adequate to benefit the system and any product built with it.

Practices keep the system alive

After the principles, the second cornerstone of the system are the practices. Practices are the procedures we put in place to ensure that the system stays alive and relevant. I came up with four core practices to fulfill this very purpose:

‍

1. Document everything

By documenting everything we removed any uncertainty and mitigated any of the trust issues contributors brought up during the interviews.

Therefore, we must make the documentation appealing by ensuring it is highly visual, easy to digest, and full of interactive examples. No one wants to read a wall of text for every component.

2. Everything must be findable

For the system to be useful, we must ensure contributors can find the information they are looking for.

We accomplished this by keeping the system as lean as possible, linking everything to their sources, and organizing the content intuitively (informed by card sorting exercises with designers and engineers).

‍

3. Get feedback often

Feedback is often underrated, but as the system evolves, we must constantly assess what is working and what isn't. To do this, I established biweekly meetings to reflect on the current status and decide the next steps.

One of the things we learned during these status meetings was that contributors didn't know when to create components, so I documented a decision diagram to help them troubleshoot on their own.

‍

4. Always be preaching

Building and documenting the system is not enough. For the system to be effective, the team has to use it. And to get people to use it, you must get it in front of them. Adoption is key!

It took a lot of preaching to get it done, from one-on-one meetings, design reviews, and video tutorials, to adding a changelog to post the latest updates. It was not a once-done-and-forget job but a continuous ongoing process.

Component library

The Foundation

Foundation, also known as design styles or tokens, refers to the lowest level design decision that define the look and feel of the UI. For StartupJS, our foundation refers to: Typography, Color, Spacing, Radius, Motion, Elevation, Iconography, and Imagery.

‍

A limited number of choices

To keep the system lean, I chose to limit the number of presets for all foundational styles. For example: for typography, I used 7 presets + their bold BEM variants. While for colors, 9 styles with 4–5 steps were more than enough. Despite how limited this may seem, I never felt the need to add additional variables.

‍

Styles can be generated systematically

By adhering to a typographic scale and a color-generating algorithm, I ensured that any designer in the team could generate typography and colors that work by default.

An adaptable system that works for any brand

We built StartupJS to be flexible enough to accommodate any brand style.

How do we achieve this? At the start of a project, we work with clients to establish the visual direction of their product. To expedite this process, I built several style-sample templates I can use to show clients a glimpse of the final look of their app early in the process. This way, there are no surprises, and we can focus on solving the real challenges.

This is one of the style templates showcasing the StartupJS default styles and other example business cases.

Picking these values is is a lot like picking ingredients to cook a meal. When you rush the process and pick ingredients that don’t work well together, you end up with something nasty. But if you take the time to pick the best ingredients you’ll get delicious results.

Component library

Atomic components

I followed Brad Frost's Atomic design principles to build our component library, starting on the simplest components first, and building up to the most complex patterns.

‍

Components

In the design system, these are the simplest UI components we can build using a few elements, these include buttons, labels, links, badges, tooltips, etc...

Patterns

Complex components are assembled using simple components. Some examples are cards, time/calendar pickers, drop-downs, form inputs, etc.

‍

‍

Iterating on patterns: Tables

Sticking to a single design system allowed us to improve components and offer component variations to clients. See how table filters evolved to meet the demands of the different product use cases.

‍

‍

Iteration on mobile table patterns

Mobile tables also went through extensive iteration, as displayed below.

‍

evolving the system

Pre-building User Flow Patterns

As I was working on pattern components, I realized that some user flows rarely change, or just require minor tweaks. By pre-building these user patterns upfront, we would be able to deliver a working experience for new projects out of the box. These Patterns include things such as account creation, recovery, login, cart checkout etc...

Admin Panels

As the system matured, we found that it would be beneficial in the long term to add CMS-like features, such as admin panels, as an out-of-the-box features included with any new project.

Even though end users rarely experience these behind-the-scenes panels, admin panels are great time savers for designers and engineers, who can now test features faster. Additionally, they allow clients to manage their digital product transactions, mailing, and user base.

‍

business impact

The Outcomes

Since we started building StartupJS, we’ve built 19 cross-platform products. These products serve brands in a wide range of sectors such as: hospitality, education, finance, logistics, technology, human resources, SaaS B2B, and retail.

‍

19 products built with StartupJS so far

THANKS FOR READING!

Want to see more work? Check this out!

‍