For many Product Owners or product team leaders, design systems still seem like a nice-to-have, rather than a must-have. Companies may have a design system implemented up to the point of a design kit (which aligns the work of designers within their own teams, but does little to support cross-functional work), or have multiple, mostly independent design systems that cover each of their products, which aren't helping with speed and scale for the overall business.
What many business stakeholders fail to realize is that the connection and collaboration that a full design system facilitates is where the real ROI comes into play. A "design system" that's just for designers (ie: a design kit, without a full component library, developer sandbox, documentation and governance model) leaves quality, product and development teams in the dark.
Translating a design kit into components can largely be a guessing game on the engineering side. As developers, we know that working with a loose assortment of components committed independently soon becomes a challenge — it's almost impossible to make any major changes to large systems. Not only that, but even when we use some of these components, the usages range widely and the implementations are very inconsistent. Changes to single components or pages often mean that another, seemingly unrelated, component has changed as well, and it becomes hard to have clear visibility on the status of the system.
We believe in the amazing outcomes that teams can gain from adopting design systems. But many enterprises with multiple teams already in motion can't afford to stop and build one, or align the many existing versions. And so, these teams keep tripping over the problems that a design system could help to fix.
Let’s explore how to enable teams to resolve these problems without stopping their progress toward the end goal.
Drive understanding with visibility
To absolutely everyone on a product team except for developers, components and their capabilities are completely opaque. Design and product management can only see where these components are used, not the variants or details of what they can do. During each sprint, you need everyone on the team to be able to evaluate if the pieces being used to build the app make sense for your product.
Storybook is an industry standard UI documentation tool that helps highlight UI pages, components, tokens, and rules. Each variation of inputs that controls a configuration helps the user explore how a component is used or how a page works. Aided by community-driven plugins, teams can use Storybook to help organize the testing of component’s visual consistency, interactivity, and accessibility all within a reliable and fast environment.
Once Storybook is implemented, teams have an environment where they can test changes and explore how components are configured. When changes are made, all team members have visibility into which other components are impacted and can use this to structure meaningful changes to how components are set up.
Define business and design rules for consistency
If a component doesn't have a focus, how do we know if a new feature should be added? Without rules, we can see the result, but we have no insight into what's going on behind the scenes. Because of this, we have no idea how much effort it's will take to change the component when new use cases arise. Creating better alignment within and across product teams with the right tooling can reduce the "black box" of development, break down silos and open up insights.
Design tools like Figma help to foster a culture of collaboration, and more closely match the development process. Version control, tokens and components are all part of the design vocabulary of the tool. There is even an auto-layout feature that very closely resembles flex-box rules (justify-content and align-items).
Product teams can work together to create shared conventions and guidelines that both design and development can share. Once these rules are established, they can help drive consistency. Developers can easily pull important implementation rules from the design files, and designers can get a better business context when prototyping new experiences. When assessing the quality of what has been built, Storybook and Figma help to drive analysis with integrations and visual testing tools like Percy.
Figma has built-in prototype features that allow teams to experience the app before it's created, and thereby allow a better understanding of the customer experience. Prototypes are powerful because they aid behavioral testing for developers and product managers. Project kickoff, user journey session and team activities can be done using FigJam, a new product that can help to reduce the clutter of tools product teams typically use.
Because each component is displayed individually in Storybook, automation and manual testing is easier. Automated visual testing can be done with Chromatic, automated interactivity testing with Testing Library, and unit testing with Jest, to name a few examples. For manual visual testing, Storybook’s popularity has led to open-source packages that allow Figma design files to be added to the Storybook canvas so that the team can view live updates and use the inspector tool. This makes comparative visual testing between Figma files and components built in Storybook easier for the quality, design and development teams to review in Storybook.
How structure can enable change
Creating consistent rules for new components and improving their visibility across the product team is essential for delivering great customer experiences in an agile way. However, turning rules and clarity into well-defined components is essential to implementing the components throughout your application (and across applications as your design system scales). Without good definitions and clear use cases, even a simple change can mean rolling out dozens of small manual fixes and adjustments across the application as other components are impacted.
With the right tools, however, components can be properly structured in both design and development. Inside of Figma, designers can use components and their rules to adapt pages and layouts accordingly. Any changes made to the components will apply across all designs. Similarly, if developers organize components with clear and intentional interfaces, we can easily change their behavior. The value this brings is clear: Teams need to be unafraid to make changes, and can't be overly attached to an implementation, but rather champions of the value the feature brings. When fear of change is present even in this small way, it leads to team conflict, delays, rework, and potential loss of ROI.
Components will inevitably have to change after the product is released to users. But the use cases and interfaces for components must be strict in order to enable any neccessary global changes without risk. Changing a button in one place, for example, shouldn't require a major refactor across all buttons. Similarly, developers should avoid over-architecting for change that never materializes. To head off this problem, product management and design must partner closely to understand the post-launch product roadmap.
Build, measure, learn
Bringing visibility, consistency, and structure in product workflow together, design and development teams can apply these principles to pivot as the needs of the product change. When your components, rules and variations are clearly defined in documentation and tooling, your team has a source of truth that can inform future changes to meet the needs of the business. This allows you to adopt a build, measure, learn cycle of product creation, releasing digital applications to the market quickly, gaining insights from users, and acting on their feedback to improve the product quickly.
With a foundational component process in place, your team can be well on the way to implementing a design system, without spending time away from the goal of launching your product as quickly as possible. The visibility, consistency and structure informs your next step for your design system: building a governance process. The improved collaboration and faster time to market will more than justify the need to continue building a full design system.