Design Systems as vehicle for leadership
I first did at-scale design systems work a decade ago whilst leading a team of 200 designers in an organisation of 20000 people1 and quickly came to see the output of this work as both:
Infrastructure to create scalable high-quality user experiences, and
The recasting of the role of design and designers in the organisation.
Today, I want to talk a little about that second part, because I think it is under-appreciated both by design practitioners, and by leaders who are commissioning this work and asking organisations to attribute value to it almost always on the basis of the first part.
I would posit that the large majority of the overall impact of Design Systems work is actually not about consistency, speed of delivery, quality of experience, or ease of “handover”, but it is in fact about unleashing the potential of design to operate across businesses as thought partners, as proposition designers, as facilitators of user-centric thinking and of technical partners with peer technical disciplines. That is what Design Systems done well do in design mature organisations, and we need to be more bullish in that assertion, and less unambitiously myopic in how we measure the success of these investments.
Stop measuring output, start measuring impact
A typical early-stage approach to measuring the return on design systems investments is to take superficial measurements of outputs and to use those to show that building infrastructure for design scales better than designing stuff over and over again. Teams will often build dashboards which look at the raw count of components live in a product, they might even go as far as to calculate the percentage of a product surface area which is built using componentry rather than adhoc code. This is useful as a measure of progress, but in reducing the value of these investments to such narrow aspects obscures the wider impact we are making in freeing up time for more generative design and research work. Whilst many organisations are always going to require some sort of output measure, we should also be bold enough to talk about impact of our work in the whole.
So instead of saying “45% of the product page is now made up of design systems components”, we should say “45% of the product page is now built with design systems components, this has reduced our time-to-market by 20% and with the capacity we have gained in leveraging these components we have begun to tackle some of the work for next quarter to the point where we are now ready to start building new features 2 months earlier than would have been the case previously. This in turn has allowed us to conduct pre-launch research which has significantly reduced the risk of these features failing to meet both user and internal needs”.
This speaks to what the business cares about, and not to the fears of the design organisation in keeping hold of the progress we have made to work in ways which scale and are sensible.
Celebrate design work that happens without design
Design systems done (and crucially, documented) well create the possibility for good design work to happen without a designer ever having seen it. That is an uncomfortable position to put ourselves in, but we also have to acknowledge that there are almost no businesses where every feature and every product gets the attention it needs from a design perspective. HR tooling, finance tooling and partner tooling are all regular examples of where software is being built without dedicated design investment. If - in building high quality reusable architecture for design - we allow these teams to deliver better stuff, we should celebrate that and not shy away from it for fear that we have designed ourselves out of a job we were never going to do in the first place. This decentralised leveraging of design builds advocacy in places which may previously have felt resentful that they were not deemed important enough to deserve well made software.
Design Systems need not be simply a set of reusable parts
When we talk about Design Systems, we are generally talking about technical infrastructure, but our definition should be wider than this. If design systems are about the systemification of design, then we should avoid making design simply about the interface in the way we as an industry like to complain is done to us by every one else. What is the design system for workshop facilitation? What is the design system for technical documentation? What is the design system for proposition design work? What is the design system for multi-disciplinary collaboration? This stuff is what we all know design to be - and so we should be thinking of how we formalise, scale and operationalise all of these things, not just the rounded rectangles which come out of the end of that lengthy process.
The last decade has seen design become a much more mature and integrated part of how software gets made in evolved organisations. We should recognise that progress, stop being bashful about it and ask for it to be measured in ways which recognises that scale of change, and scale of ambition.
Stuart.
Buy me a several drinks and let me tell you how hard that was at some point, I think I’m still carrying the trauma of that process around with me!