Designers working on large software products often have a difficult and counterintuitive lesson to learn. They need to learn to let go of some control in order to design at scale.
Left to their own devices, designers will try to control every pixel of a product, and have rationale for every piece of UI and its relationship with other components, and states, etc. They will design each individual screen, considering its relationship to all the other screens.
This detail-focused screen design can work wonders – on smaller products. But for larger products it is an operational bottleneck, and does not scale.
We have a large product. Our Race Dashboard alone has well over 300 distinct screens, with variable states. We have 9 other dashboard types. Our Website Builder product has its own set of screens and states.
As I was told when I joined RunSignup: “We have a lot of stuff.”
Our company is small, but we have many, many projects going on all at once. Ideally, we would have a designer involved in every project, but that is just not practical.
Our design system allows our designers to have influence, even when we are not actively working on a project.
What is a Design System?
I think this quote sums it up nicely:
“A design system is a collection of reusable components, guided by clear standards, that can be assembled together to build any number of applications.”InVision Design Systems Handbook
In addition to a component library, a mature design system should include other concepts like typography, color, dimensions, workflows, and even tone and voice.
There are so many examples of fantastic design systems that we take inspiration from, like SalesForce Lightning, Google Material Design, IBM Carbon, and Mailchimp.
Just a quick look at those examples will give you a sense of the depth and consideration that goes into those systems.
Our design system aspires to have that level of documentation and detail. We currently have over 100 components available for our developers. We have been building our design system up over the past two years, and we will continue to improve it over time.
How our design system has helped us so far at RunSignup
UI Consistency
In a large system, consistency is important but also difficult to maintain. By establishing simple guidelines like “This is how we do tabs”, we gain consistency across unrelated projects. Software products with consistent UI patterns are higher quality and easier to use.
Because of this UI consistency, our users are made to be more efficient. When they see familiar components, like tabs, they already know how to use them. We reduce the amount of learning our users have to do to use our products. Familiarity creates efficiency.
Faster Development
The design system allows our developers to quickly develop new UI without having to get approval from the UX team. They can easily pick from a pre-approved list of components from the design system, and copy and paste component code directly into their projects. Prior to this, they would have to search through or code base to find the piece of UI they wanted, and then pull the code over. Sometimes this would result in duplicate code, slightly modified duplicate code, etc.
This copy and paste approach has sped up our UI development considerably.
Having our design system act as the “single source of truth” for UI code, also speeds up our code review process.
We pride ourselves on releasing more than 2,000 software updates a year. A big part of each release is our code review process, in which every line of code is peer reviewed prior to release, to ensure quality.
When our components are used in a new project, we know they have already been reviewed and tested. During code review we don’t have to review the component code again, so it saves us some time.
Accessibility
When our UI components are initially created, they are built to be accessible. Accessibility testing is done in our review process. When components are used in our projects, we benefit from having a certain level of accessibility built in, without our developers needing to think about it too much.
Lessons for the UX Team
Most of the learning for the design team so far comes in the form of witnessing how our developers use the components we’ve created. The components often get used in unexpected ways:
This isn’t a knock on devs. It’s actually a knock on the quality of the design system.
If the design system doesn’t provide good examples and rationale of when to use a component, you get unexpected and sometimes deficient results. You get a pile of cats. Over time, we untangle the cats, and streamline things.
When we see new UI that is configured in unexpected ways, we know we need to provide stronger guidelines. We need better flow patterns. We need to provide better resources for our developers.
Instead of trying to control and design each screen, we are designing the system. We are letting go of control, and when things don’t come out the way we expect, we know we need to improve our design system.
We are working to improve our design system and its components and documentation every week. We know it will make things better for our users, better for our developers, and better for our products.
