Part 01. Design System Problem Space
Design Systems have been around since the dawn of software development in varying levels of maturity. However, today we are seeing design systems connect and enable through the entire stack of the business. Companies everywhere understand the strategic use of design systems to achieve outsized business results, grow faster, and have higher margins than their competitors. Yet, we still see 60% of design systems as unsuccessful.
Design Systems typically are born grassroots, built by teams with the best of intentions. But these grassroots initiatives are neither a) dedicated capacity b) capitally funded or c) gains measured or d) endorsed through the full-stack of the organisation. These are critical gaps to be resolved to scale a design system, shifting the consideration of assets and inciting new ways of working that realise your business ambitions efficiently and effectively. This is part one of a five-part series dedicated to building a Design System business case and ensure your design system is amongst the 40% that are successful.
Feel free to visit any of the series:
Design Systems are not a library of assets. They are a system of people, culture, assets, workflows, governance and measures.
Suppose you don’t have a truly adopted and endorsed Design System. In that case, chances are you have several style guides and libraries generated and supported by different teams or business units. But they aren’t all throw away. We don’t want to go and add yet another library to the existing suite. Instead, we want to codify our existing libraries to more than the sum of their parts by inciting new ways of working that realises our business ambitions and seamless customer experiences at scale efficiently and effectively.
40% of Design Systems are considered successful
76% of design systems have existing for for three or fewer years
The Design System Problem Space
Design Systems are not a library of assets, they are a system
Design Systems are not a library of assets. They are a system. If you don’t have a truly adopted and endorsed Design System, chances are you have several style guides and libraries generated and supported by different teams or business units. But they aren’t all throw away. We don’t want to go and add yet another library to the existing suite. Instead, we want to codify our existing libraries to more than the sum of their parts by inciting new ways of working that realises our business ambitions and seamless customer experiences at scale efficiently and effectively. Each organisation has different levels of maturities, but when it comes to a design system, we all share common problems we’re trying to solve.
Duplicated effort as we scale our digital delivery
We waste time and capacity to redesign, develop and test inconsistent design system assets across teams and platforms.
Take note of the duplicate assets your teams build. Consider how much one button costs. Once we designer's design it, a BA writes the related user story, a developer builds it, a tester tests it, and we need to maintain it. Assuming you run the usual scrum team of 5-7 at an average of $1000p/d, that one button could cost you $120,000 without exaggeration. Why would we duplicate that asset?
Increased asset maintenance and duplicated build effort
Typically, variations are necessary for an asset that can quickly become its own standalone asset rather than a considered variation of a parent asset. This is about all the variations that could exist in a date-picking interaction. Now consider all the variations a single asset has.
Typical interactions consist of multiple states to be designed (hover, click, active, focus, etc.)
We have multiple browsers that render slightly differently that need to be tested (chrome, safari, firefox, internet explorer, etc.)
We have multiple viewports and devices to consider pending your breakpoint and/or grid strategy.
And if you cater for accessible audiences, you have WCAG criteria to validate across a range of disabilities (visual, audio, cognitive, mobility, etc.)
A component has 64 different states at minimum
Now that’s only stock standard considerations. But again, if we take our example of a button, just 1 state of that button actually has x 64 different states of being tested for and maintained! That button is starting to cost even more than we thought…
Long onboarding time for the team & limited offshore delivery confidence
We work in a market that typically has a mixed contingent workforce, high attrition as specialists move from one company or project to the next, and offshore reliance scaling delivery. It takes time for even the most adept of workers to become efficient in working and gain company context. There is nothing to provide guidance or accountability for delivery standards without a defined workflow and governance model, supported by design system assets adopted by the digital maker and contributor community. Meaning there is an excellent opportunity to optimise onboarding experiences and leverage offshore partners efficiently and effectively.
These problems have continued lasting effects
Inconsistencies in our experiences
Experiences today are truly multifaceted experiences by various channels, whether it is your traditional website experience, a native (iOS/Android) app experience, email, voice experience, watch experience, and even AR or VR. Whether design tokens, component assets, content or modelling, a design system can confidently support consistency across the spectrum of experiences at scale. Resulting in a consistent customer experience.
Unnecessary code loading to render
Legacy platforms mean legacy code and assets. Constant engineering on top of engineering without appropriate time to refactor or align to a design system results in unnecessary code, which results in excessive loading, which results in slower response times for your users. Gain performance benefits through the faster rendering of and an optimised user experience at scale.
Shared knowledge and usage of our guidelines
Software takes time to develop and mature, resulting in a lot of IP gained over time. You want to avoid single points of failure or relying on individuals rather than a system. Design Systems provides workflows, governance, and assets to apply guidelines and refer to for future makers to contribute to or utilise the design system. Minimising the risk of IP lost during times of change and attrition.
Start collating the hard & soft metrics to support your business case modelling later
We need to start capturing our measures to inform the value of the design system. We will detail the IRR (internal rate of return) over five years by the end of this series. For example:
Hard metrics
% Increasing velocity
Maintenance capacity reduction
New hire productivity
Leverage offshore
Multi-brand enablement
Soft metrics
Improving EVP
Distributing knowledge share
Improving Customer Experience
Continue reading the design system series: