Does your teeny-tiny team need a design system?
Solo designers and small teams can benefit from implementing even partial systems
Over the years, I’ve seen how the benefits of design systems at any level of implementation align with the requirements of small, nimble teams. While all teams now face restricted time and resources, tiny teams often find themselves also facing a design-hostile culture.
The structure and reusability design systems provide can service these teams well, providing the team more time to improve the design culture of their organization, giving them reference points when communicating with developers, and providing consistency for users.
In this series
- Does your teeny-tiny team need a design system? (You are here)
- The elements of design systems for teeny-tiny teams
- Building your teeny-tiny team’s design system
- Implementing your teeny-tiny team’s design system
What challenges is your organization facing?
Design systems take money and/or time to implement. This reality means we should understand how our teams will see a return on this investment.
Understanding what the organization is trying to achieve will help you understand if it’s the right time to invest in standardizing your design components and processes.
Has your organization discovered its place in the market?
If your organization isn’t sure of its market fit, it may need to quickly pivot to new approaches. This constant shifting is a poor fit for the rigidity of a full-fledged design system, but it may benefit from using a lightly-styled library of design components which are flexible enough to be applied in many circumstances.
Do the demands on your organization require constant visual shifts to maintain the attention of its audience, customers, and/or users?
Organizations in events, entertainment, marketing, etc., which require chasing trends or unique visual approaches have a lot of overhead in creative ideation alone. While some structure may help your processes, tiny teams may find it easier to forego the overhead of a design system and focus primarily on ideation and high-level execution of short-lived concepts.
Does your organization have a strong brand or multiple strong brands which require visual consistency to maintain market recognition?
Branding is an important visual practice, especially in crowded markets. If your organization has strong brand requirements, a full design system can help separate a brand from its competitors, unite several brands under a single parent, and provide physical and digital experiences that are tailored to individual brand identities.
Do your users require familiarity to effectively achieve goals in your organization’s products?
In some circumstances, where design functions were missing in early stages of a product’s or brand’s development, experiences can become riddled with inconsistent approaches to similar user flows. This can be confusing and frustrating for users. A design system of some form is almost a requirement to solve this issue.
Is your organization prioritizing increasing product release velocity over the long term?
Once built and adopted, design systems are a useful method for increasing velocity by decreasing the amount of parsing required by developers in the design-to-development handoff process. If there’s a code component to the system, that can also allow developers to simply plug in pre-built components, further speeding development. Systems can also increase velocity for designers, by providing an easy starting place for ideation and UI structure.
What structural realities do you need to consider?
In addition to company goals, it’s important to understand what challenges you may face when attempting to implement a design system. If there are many hurdles, it might be better to resolve those issues before attempting to build any system at all.
Is your tech stack conducive to reusable designs?
Teams of all sizes use component-based libraries like Angular, React, etc. If your developers are using a tech stack focused on reusing code, it provides an excellent opportunity to communicate the value of reusing design components as well.
Some teams may already be reusing design code by utilizing a design component library which they restyle to match the designs provided by the design team. This approach has benefits and drawbacks, which can be covered in a future article.
Do your developers need extra guidance to achieve desired results?
Let’s face it: not all development teams are created equal. Skills and personal investment in the work can vary company-to-company, team-to-team. Design systems can help smooth over teams which just can’t — or won’t — create good user experiences. Depending on the implementation, they do this by creating shortcuts and removing decision-making in the development process.
Do you need tight control over micro interactions?
Design systems can be as simple as button states or as complex as controlling loading, animations, user flows, and more. They may be a great way for a design team to more directly control how the details are implemented.
Does your team have the capacity to build and apply the design system?
Ultimately, someone has to do the work to design all the components and variables of a design system and translate them into your marketing, products, and processes. This is a significant amount of work. For teams which are just scraping by, a design system may be a pipe dream until the organization is willing to invest more in its design function.
Does your organization’s leadership see design as a cost-center?
Design-hostile organizations view design as a necessary evil, rather than a means of strategic advantage and differentiation. Design systems require resources and a change of processes, so if your tiny team faces this type of culture, it may be an uphill battle to sell implementing any design system elements.
What won’t a design system fix?
Design systems are powerful tools, but they’re ultimately just tools. Understanding what you shouldn’t expect can be just as useful as understanding the benefits.
Design systems don’t make designers design better.
If you or your team lacks design experience, a design system will not replace that experience or decision making. It may give designers more time to focus on the larger user experience, but poor user experiences can be — and are — built from excellent design systems.
Design systems won’t implement themselves.
Work will be required to encourage adoption and refactoring of the existing codebase (as necessary). The implementation process will represent extra work for designers and developers, and will require extensive communication. Changes to the design system can have breaking changes, which needs to be understood and communicated. Selling the potential development benefits of a design system to developers can be an excellent way to improve communication between design and development teams.
Design systems won’t improve the user experience on their own.
Design systems can improve consistency of experiences across an app, but it won’t directly solve core user experience problems. Sometimes, the solutions for those problems might lie outside of what exists in the design system. It can’t replace innovation or user research. If applied too rigidly, systems can work against implementing the best outcome for users.
The person maintaining the design system will not have more time.
Design systems can reduce overhead and increase velocity across an organization overall, but the person or people creating and maintaining the design system will find that the best-case scenario is having the same amount of time they did before by saving time in the design process, but spending more time maintaining and communicating the design system.
There are infinite considerations.
Design systems can be tailored to any circumstance. The end question is ultimately this: Will layers of structure in our design process further my organization’s goals?
If the answer is yes, then the next step is to understand the elements of design systems and how each can stand alone or weave together to help your tiny team.
