How to embed confidence at the core: testing and communication in design systems teams
Dan Donald
What do we mean by confidence?
There’s a lot of thinking that can go into our design systems before we’ve designed or coded anything. One concept that’s always resonated with me is what confidence in the system might mean to different specialisms or teams and what we can put in place to embody that. Having faith in the system, the workflows around it and the people working on a design system is an integral part in it’s successes. When I think about the word confidence and break it down, it suggests that the system being reliable and trusted so let’s explore how we might exemplify that.
In many ways, we could assert that being reliable will foster trust and in part, it will. As a developer, being able to in some way consume a component from the design system and it works and looks as expected and matches the designs they may’ve been given to work with is key. From that, knowing how any additional requirements could be discussed and potentially added to the components, or to in some way extend the appearance or behaviour of these components matters. Having an opinionated system is fine, so long as feedback is encouraged and can be responded to in a timely manner so these needs aren’t met with a bottleneck.
Decisions, documentation and testing
At every step in the workflow, we can ask ourselves what gives us and others confidence. As the design stage, do we understand the decisions that have been made? Do we have a clear intent behind the component? As we document it are we clear on use cases and any caveats? Have we factored in any technical concerns?
As a component finds its way to developers, is the same taxonomy and so language used (so a button is called a button in a design tool as it is in code)? If not, is it clear why? When it comes to consuming a component is it predictable how to consume them in some way (perhaps from an NPM repo)? When working with the component are the props or attributes consistent across them so there’s some cohesion in the developer experience?
Stages of automated testing bring in a degree of confidence too – that unintentional changes will be caught, preventing them from appearing on the live site or app. One simple method of doing this is using visual regression testing (VRT) using a tool like Backstop.js. This stores a snapshot image of the component so subsequent changes would be compared against it. It allows you to set different-sized viewport sizes to be compared and a threshold of how subtle the changes are that you want to detect. Along with testing functionality with something like Jest and Puppeteer (as with many things in web tech YMMV). If you have some kind of build process on a CI/CD server, unintentional or potentially breaking changes should be caught.
Different specialisms with the same goal
What we’re aspiring to do across disciplines from product, design, development and testing/QA is to embed different kinds of confidence in what we’re creating across this design system. Each with a view of how their kind of input plays into the others to create a cohesive whole.
A further kind of confidence is in how we deal with and diagnose mistakes or errors. Again, across this end-to-end workflow that will mean many things; knowing how something can be flagged or reported and roughly what the process is instilling that sense that it’s not an immutable object. It can and should change over time and if the worst happens and a bad change is made, there’s a process for managing that quickly and transparently. If a designer uses a component from a library and they see something awry or can suggest improvements, how we can empower them to do that? If a developer or tester spots a bug, how can that be dealt with; if an improvement can be made, how can there be a process to empower them, which makes the whole system better? Often cited as a good example, gov.uk’s design system homepage has clear sections for ‘community’ (creating or improving components) and ‘support’ with how to contact the team and some content that might aid your use of the system.
It’s all about people
A key part of any design system is governance; that in itself leans towards communication and workflows. Digging into the latter, at its most basic the design system workflow should enable us to go from the problem we want to solve through to a solution actually used by our audience(s) as quickly as possible. Through that process we want to have clarity; from the problem space to execution in design through to how we should build it, then how it’s deployed to the live environment. That end-to-end view is really important for everyone to be aware of to some degree so there’s less hand-over and a greater appreciation of how everything works. A designer might never fully understand the pipelines as a platform engineer might never totally understand UX or visual design but understanding can encourage empathy, which in turn helps build trust.
As workflows and some kind of governance is formed, ensuring it’s freely available and talked about with others in your organisation is key; working as openly as you are able to can help to be seen to want to take people on the journey of the design system. Even at an early stage, building in feedback loops; encouraging colleagues to voice their opinions or concerns and see how that’s responded to.
You might have opportunities to do forms of presentation for people not directly related to the system itself where the higher-level pitch needs to not just explain what it is but how it makes things better and why they should have confidence in it, without necessarily needing to communicate the detail for those audiences. Take the time to understand what different audiences might need or want from your sessions. Try things, don’t be afraid to fail, listen and improve. Spending time with individuals can be really important from the earliest stages to understand how they might use it and their experiences as they start to engage with it. Whatever the specialism they have, it’s the end-to-end journey of a component (which is a solution to a user or business problem) that’s really key. How it goes from conception to the live website or app.
Revisiting my first paragraph around confidence in this context being composed of reliability and trust, we’ve touched upon how important transparency and communication are, which along with workflows form a sense of governance. Feedback loops and responding to change can help with trust. Where we can use tools to provide some sense of reliability gives us another angle.
What does confidence in your design system mean to you? How do you bake that into your design system?