Justin Stach
Design Systems, brand and identity (part three)
Previously I’ve outlined why we needed to create a more systemic approach to building our digital UI and described how brand and identity play a role in this, in this final part I’ll talk about the design system that we built, which we called Tesco’s Digital Design Language and of course immediately gave the three letter acronym of DDL.
We created the DDL as a visual design system to address the challenge of our look and feel being utterly inconsistent across our digital estate, in fact we were often inconsistent within a product. The DDL is an initiative that was initally proposed to answer the question: how should our digital estate look to our customers? By getting the many design teams and stakeholders together we would create a specification for our most common user interface elements. By having standardised versions of these elements we created the ability to optimise and improve them for everyone, rather than at a local isolated instance - in effect, we created a feedback mechanism for our look and feel.
The second thing design systems like the DDL create is the ability to stop endless low-value debates about things such as, ‘should a button be red, orange, blue, rainbow sparkles’, ‘should a carousel have a stop button’, ‘how big are our headlines meant to be’, ‘how should we set up images to work responsively’ and so on. By having a standard, default specification, we allow our teams to focus on high-value problem solving and meeting customer needs.
Design systems like the DDL are a hot topic right now - businesses are recognising them as a way to consolidate and rationalise their digital channels, and using them to drive down operational costs, time to decision making, time to delivery and of course improving customer perception and trust. Indeed, some of the more pioneering businesses are open sourcing their design systems so that they get used, tested and improved by as many people as possible. Remember that Bootstrap was Twitter’s design system long before it became the web’s default UI.
These initiatives parallel similar system-wide approaches in engineering: shared architectural practices, code libraries and code standards. They all share the same idea of setting a common set of practices to allow greater autonomy and distributed decision-making within teams by trusting that they work from shared standards and removing gatekeeping.
Which brings us to the last piece of the naming puzzle - where visual design systems become UI design systems or libraries. We started the DDL as a system for designers, we avoided code other than where it was helpful to document how a particular interaction worked. But the thing we heard time and time again was from people wanting the code that the created the DDL elements so they could build with it. Engineers and developers are generally pretty sensible folks who like nothing more than a quick starting point. ‘Can you make a DDL version of Bootstrap?’ became something I had to regularly answer.
Late in 2017 we started work with the Technolgy function to extend the design system of the DDL into a library of UI components that are agnostic of the products they get used in. Technology leadership decided that they needed to build a set of core UI components that would enable distributed, autonomous teams to reuse, extend and contribute improvements to. Our collaboration with them created the foundations of a library, a distributed way of working centred around Github and the start of a workflow that ensures that everyone can participate and improve the library.
The power of having a living design system like this is that it allows us to very quickly build in a consistent way. Here’s an example of pulling together a set of off-the-shelf components to create a prototype of something like a new brand expression compliant Delivery Saver website.
Note that’s using production-ready code pulled from the Github repo. The editor you see around it isn’t ready for everyone to use, but you can easily imagine this being the starting point for a lot of our teams to experiment with different layouts and see how they respond across viewports. Tools and design standards like these mean that the domain experts in marketing or comms can solve their own problems and take a design all the way through to a viable solution that is potentially shippable.
This leaves our specialist design and engineering teams free to focus on the higher-value, higher-order problems. Design systems like the DDL won’t ever tell us how best to handle some of our unique experience problems like how we present delivery or fulfilment options, but they will free us up to stay focussed on that rather than redesigning yet another button.
design systems design language design strategy brand inclusivity scale