Part 03. Design System Assets Evolved
Your design system business case will detail the costs required for an investment to realise the value of your benefits case. These costs can vary greatly pending on the scale of your organisation or the ambitions of your design system. In this article, we will explore some of these domains to inform your design system business case, likely procurement, capital-intensive, and operational investments and costs.
This is part one of a five-part series dedicated to building a Design System business case
Feel free to visit any of the series:
Let’s look at some of the Design System domains
Design systems consist of assets and guidelines, created and leveraged by a community, controlled by guidelines and governance to enable fantastic user experiences and business objectives at scale, efficiently, and effectively. We can define these areas into four domains.
01. Assets & guidelines
02. Communities
03. Control
04. Performance & Objectives
01. Assets & Guidelines
The building blocks of a design system are the assets and supporting guidelines. If your ambition for your design system is to help the entire stack of the business, then this is where semantics become really important. What does a ‘component’ mean to you? What is a pattern or a template, or a token? One of the most well-known early thought leaders in this space being Brad Frost, Atomic Design. My issue with the Atomic Design framework has always been how prescriptive the categorisation is. I suggest approaching your semantics and information architecture like you would any other human-centred information architecture initiative.
Information Architecture Activities
Audience: Who is your audience utilising or contributing to the Design System? Get ambitious, information architect structures should be sustainable models to serve the future.
Research Competition: Get inspired by other design systems. But appreciate different audiences, scales, and maturities of organisations and their design systems into different information architecture. What is critical is validating the information architecture that is appropriate for your organisation.
Jobs to be done: What are the top jobs your audience undertakes? Consider the use-cases of each of your audiences the Design System serves.
Content inventory: What current content exists or is required by each audience segment?
Card Sorting: Begin appreciating your macro domains that have a hierarchical affinity to one another.
Tree-testing: Invite your audience and test trees of hypothetical menu hierarchies, ensuring your audiences' intuitive findability of content.
The user experience of your design system has a direct correlation to the adoption of your design system by intended audiences. The adoption is critical to continues success realised as you scale your design system(s).
Card sorting is a UX research technique in which users organise topics into groups. Use it to create an IA that suits your users' expectations.
Follow these tips to effectively evaluate a site’s navigation hierarchy and to avoid common design mistakes.
Information Architecture Asset Examples
Design Tokens
Everything starts here. Tokens are the rudimentary beginnings of design system assets. Platform agnostic definitions are the fundamentals of your design system assets. Think colour, type, spacing, time, etc. Consider a single colour; the brand will likely call that colour an abstract name (e.g. pigeon grey), designers may call it a hex value (e.g. #b9b9b9), a developer may call it a sass variable. We want a single definition that builds connectivity and a standard definition through those utilising it. An excellent example is Salesforce - Lightning Design System, Design Tokens.
Components
The most recognisable parts of a Design System Components. These are the building blocks utilising design tokens to render a fundamental element (e.g. radio, checkbox, button, input, etc.). Components will present variations of the fundamental element. Consider how many buttons variations exist in your experience. What's essential is you build continuity between the category of your component and its related variations so that you don't branch unnecessary bespoke components.
Patterns
Patterns consist of a reusable collection of components that can be defined by their respective interactions when solving a design problem. These need to be adopted and documented as use-cases (e.g. your 'login' experience may utilise components including a title, some labels, inputs, a checkbox, a button supported by a suite of design tokens).
Content Modelling
Structured content is content that is planned, developed, and connected outside of an interface, so it's ready for any interface. It treats content as data, so it makes sense to people and computers. A necessary enabler for content at scale ambitions (e.g. Distributed Authoring, Personalisation Models, Internal Search Maturity, Create Once Publish Everywhere)
Content Type translated to Component design
Design Systems have similar elements "What does your design system contain?"
95%
Color system
89%
Typography system
89%
Form components
74% Usage guidelines
74% Navigation components
73% Spacing system
71% Design files
70% CSS code
69% Framework-specific
65% Accessibility guidelines
64% Grid system
64% Layout system
36% Voice & tone guidelines
61% HTML code
60% Brand guidelines
57% JavaScript code
50% Example page templates
46% Content blocks
21% Animation system
6% Other
Reference: Sparkbox Design System Survey 2021
02. Communities
Building your design system community is building a culture. Previously in series article Part 02. Design Systems Market Landscape I discuss Digital Makers, Collaborators, Sponsors, Stakeholders, and the end Customer. 'Adoption' is a design system's most significant barrier to success. We cannot underestimate the change management required to promote, nurture and support the design system community. We will add dedicated change management to the resource profile as part of our design system business case.
What are communities of practice? In brief, they’re groups of people informally bound together by shared expertise and passion for a joint enterprise.
How being open and inclusive will improve your design system and your design culture.
A Guild is a collection of people (from across business areas and often different roles) with a shared interest.
03. Control
Whether those responsible for your design system are operating in a centralised or federated model, the workflows and controls to utilise and contribute to the system requirements define workflows and controls to guide and govern your communities. The agile manifesto states, “Individuals and interactions over processes and tools“, it’s not wrong. Procuring a suite of tools without consideration to your design system communities is redundant. But your choices of tools are critical to enabling integrated workflows at scale. Software is exciting and maturing at a rapid rate! After much research POCs and enterprise procurement efforts, I can confidently suggest a suite.
Figma has outsized feature development of any nearest competitor, truly understanding digital makers and empowering them to collaborate, architect and design at scale.
It’s important to delineate between your design sandpit, enabling new ways to solve problems and frozen states of your design system versions. If Figma is your sandpit, then Zeplin is your frozen state.
Component development in isolation of having a complementary 1:1 relationship between design files and engineers assets. Similarly to Figma, it too is supported by a community of powerful plugins.
Many build their own bespoke interface to render their design system. Zeroheight both integrates with Figma, Zeplin & Storybook. Whilst providing a codeless CMS experience to ensure all can contribute.
There are probably millions of plugins and add-ons relating to design systems. Whilst you should be careful of relying on open-source plugins for large teams, these four deserve mention.
Model your content and update any connected Figma files from a single source of truth with your whole team.
Export Figma styles and custom tokens to a style dictionary ready JSON.
A build system that allows you to define styles once, in a way for any platform or language to consume.
This Storybook addon can be helpful to make your UI components more accessible.
Your design system is a way of working, and its assets should be living. If your assets become static and unmaintained, then your design system is dead. This way of working requires a level of governance that doesn’t bottleneck or impede delivery whilst holding true to quality standards, accountabilities, and definition of done. Governance comprises the processes that control decision-making, contribution, enhancements, success measures, and design system workflows. I suggest approaching with a service designer’s mindset. e.g. consider the three P’s of service design as well as front-stage and backstage environments.
People. This component includes anyone who creates or uses the service and individuals who may be indirectly affected by the service.
Props. This component refers to the physical or digital artefacts (including products) needed to perform the service successfully.
Processes. These are any workflows, procedures, or rituals performed by either the employee or the user throughout a service.
There are some critical stages of the design system to model.
Onboarding & adoption - if adoption is critical to design system value realisation, concentrating on the onboarding experience becomes a priority. What do your different audiences need on their first-time experience utilising the design system? How can you facilitate seamless adoption?
Contribution & communications - you need a mechanism to govern decisions for new, variation, bespoke, or identifying redundant development that is democratised and empowers all related audiences, especially the marginalised or introverted. As your assets continue to evolve, are all audiences aware of the current state (e.g. new version patch notes)?
Feedback & Support - Is there a bug with a component? Do the how-to instructions not provide enough guidance? Have we learnt something from some recent in-market experimentation activities? Or perhaps there is an update of workflow, software or industry? Providing channels and a cadence to enable fast feedback loops will nurture your communities health.
Success Measures - We're building a business case to seed your design system ambitions. We will forecast and hypothesise benefits, and these need to be measured to validate our hypothesis and inform our success targets. This requires all related parties, whether it's designer cycle-time, scrum team velocity or platform maintenance reductions, to have a 'control' benchmark of the pre-design system. Measured against new design system contribution and existing design system adoption as delta's to inform your team targets.
From being imagined in someone’s head to being added to the design system and ready for use by everyone
While many understand the benefits of a design system—creating a structure built for scalability—some worry that they’ll lose flexibility.
If a design system user can’t get done what they’re trying to get done, the whole system risks obsolescence.
04. Performance & Objectives
Measuring your design system success is contingent on your tooling choices, hence another reason for suggesting the suite above. In ‘Part 01 - Design System Problem Space’, I mentioned some hard and soft data points to start collating. Let’s define those further and model them into OKRs (Objective Key Results). We will use these in your business case to inform how we will measure the benefits modelling in your business case. Here’s an example of some hard metric:
Business Problem
Requiring to build more scope for less time and cost
Objective
Realise velocity improvements across all digital makers
Key Result
5% velocity gain by scrum teams adopting design tokens
10% velocity gain by scrum teams adopting web components & patterns
Future Maintenance & Cost Avoidance
Increase standardisation of components
Degree of contribution (# of assets added)
Degree of reuse (# of assets adopted across platforms)
Hampering efforts to scale digital delivery
Scale digital delivery utilising offshore options and external partners
Offshore confidence (# of digital resources via offshore partners utilising design system)
Junior (time to mature contribution & efficiency)
Don’t discount the insights of longitudinal sentiment analysis.
For example, a well-designed survey is an opportunity to gather insight. Send it quarterly to the design system audiences can also be valuable for informing some of the soft metrics with more definition and identifying other qualitative themes to provide direction and framing for future design system optimisations.
If you want to learn more about building a survey
If you want to learn more about OKR’s I suggest reading:
Inform your Design & Research Ops health
Building a survey to inform your design & research ops with longitudinal trends & insight
Google often uses “Objectives and Key Results” (OKRs) to set ambitious goals and track progress.
We have an idea of the objectives and scope in front of us to inform a roadmap and possible future horizons.
In the following article, 'Part 04. Design System Roadmap & Horizons' will explore some barriers to entry, hypothetical sequencing, likely dependencies, prioritisation models, and future ambitions. Before we deep dive into the business case generation and secure funding to seed or scale your design system, our last items are required.
Continue reading the design system series: