Some members of our team recently attended a panel discussion about the value of design systems. One of the topics that came up got me thinking about buttons.
First thing first – let’s be clear: we don’t hate buttons. But we do have an issue with how some components, including buttons, are implemented across digital interactions. Let me explain…
We have a very busy content design team, spread thin across multiple projects, services and products. When members of our community make requests for web pages, often with very little explanation about what they are trying to achieve and who their users are, this can be incredibly challenging for the team.
Aside from that, we’ve been having many conversations about consistency of experience, content standards and what would help speed up the design process. We’ve also been discussing one critical pain point in how we, as a digital team, interpret stakeholders’ suggestions and whether to implement them.
This blog post reflects some of these conversations, conclusions and decisions we’ve come to as a team, as well as what we’re doing about them.
Linking back to University strategic goals
Millions of people from around the world interact with our website and other digital services each year. The University is lucky because it has a dedicated team that is truly committed to delivering the best experience possible for its large and diverse audiences.
To maintain consistency, we work from a design system, which is effectively a library of guidance, examples, and repeatable design patterns that focus on key digital interactions. It allows us to move at pace and provide effective digital experiences that support the University’s strategy and its goals, such as equality, diversity and inclusivity – a critical mission to deliver on its ambition.
But there is more to it.
Having a library of design components can sometimes give the impression that all the design work has been completed… Although patterns do help teams build things in shorter amounts of time, it is how and why a group of patterns and components are stitched together that results in great design.
It’s all about context
Turning a content design eye on your own design system helps keep products consistent and scalable. It also helps keep designers sane.
They have to understand this collection of components, patterns and tools, but more importantly the right contexts in which to use (or not use) them.
Without this you can easily lose the benefits that those components were designed to provide, such as greater accessibility for users who rely on assistive technology to browse websites.
When we talk about content design in the context of design systems, we are not necessarily talking about style guides. We are referring to how we create repeatable design patterns, backed by research and agree upon their correct use as a team. Having a clear understanding of the solution to a problem allows it to be reapplied when the same problem comes up somewhere else – and at scale.
For example, we spent a bit of time looking at research groups and the important need for the contact panel, in terms of discoverability and consistency of experience. The design system is an especially valuable tool in the case of the contact panel.
In our content management system, there’s a lot of flexibility with the component itself. Here’s an example from the Coherent X-ray Science group:
Although many of our content designers have been using the template since it was launched, checking in with the design system helped remind them of best practice. The design system also helps them progress work more quickly by removing the need to rely on other members of the team for this information.
So what about buttons?
We have nothing against buttons. We’re only using them as an example of when choosing a component to build a product or service means making a content design decision for that interaction.
When a component has context, you can make the right decision by default.
Our design system contains information about buttons and what they communicate. It gives explanations and showcases our different button types.
All of this is great because it’s flexible, but it can’t always tell you when to make that content decision of including a button or not.
When you add the context and the content choice to the system, the designer knows the right button to choose for each content type.
At this point, we probably want to stop thinking about buttons in isolation – more in a sense of journeys and the next steps a potential user group may choose to take, if at all. And that’s what we’re hoping to move towards.
For example, our new Postgraduate Research topic pages include Drupal fields where primary buttons can be applied using simple HTML code. These are present in the design system, but used sparingly by content designers despite the technical flexibility to use them more liberally.
Here’s our design system page for this product, including the guidance for ‘How to apply’ which uses primary buttons.
Then cross referenced with the component guidance, it’s easy to understand that the primary buttons are for important tasks.
Journeys can be broken if there is not enough understanding of:
- when to use and more importantly not to use a button,
- what button type is most appropriate,
- where to place a button on a page
Throw in the human need to want to please people (such as by doing exactly what they’ve requested on a ticket) and things can go really wrong.
This is where training comes in to support individuals – to help them question any request we get in terms of the real value it will deliver for our users. After all, we’re here to represent them.
The need for good design choices
So to clarify our position, this is about how a design system, made up of well-chosen components and patterns, does not replace the need for good design decisions.
There are a million ways to make bad choices using good components and patterns – in the same way a piece of text can follow a style guide but still not read well or give users what they need.
The precedent for this in government is interesting. The design system and prototyping toolkit are both incredibly solid and allow for very little variety – you can only prototype in code so there’s very limited potential to deviate all the way through from sketching to development. Even with all that, there’s still the need for hefty and sophisticated design reviews and assessments to make sure teams are making good decisions. This is because there’s still a lot of room for poor usage.
I’m being reminded (thanks Kate!) of this old Morecambe and Wise sketch – playing all the right notes, not necessarily in the right order so you get a completely different piece of music as a result. Not necessarily what you expected when you bought your concert ticket!
Question everything everywhere all at once
Getting the whole team on the same page is really important, especially around the purpose of the system and how to use it. We’d spent many meetings in the past going back and forth about whether we needed more guidance for our team or for the disciplines we collaborate with. We wanted to make sure we were crystal clear about this as a group so we have plans to create more training and simple guidance to ensure the wider team understands how to design for specific goals and journeys.
Question everything, everywhere and all at once to get out of your comfort zone to ensure that the people who are interacting with our services get the best experience when that happens. Being comfortable with awkward conversations is important, and it gets easier as you become more familiar with the work, design principles and flows.
We’d also love to do more on how to introduce content patterns and more robust design crits and 2i (our quality checks) so nothing falls between the cracks.
There’s always room for improvements, including how we accept the work and suggestions from the community vs the time it takes to evaluate and understand what solutions may work. This includes when we need to involve other disciplines such as performance analytics, SEO or user research.
We’re iterating as we go along. We’re not over buttons as yet. They have a role to play, just not in every single page, or journey…
Did we say we’re recruiting?
We are always looking for new talent.
If you are interested in being part of our team, naturally curious human-being who feel that trying to solve content problems is your thing, please get in touch. You can read more about our team and its ethos in our recruitment pages.
My sincere thanks to Claire, Jonny and Kate for their contribution and suggestions.