G’day, I’m Tim, a designer on NHS.UK Alpha. I’ve recently joined the team and started looking at our design approach and process. We need to be able to solve increasingly complex design problems quickly and with as little overhead as possible. We can do this using a modular design approach, relying on reusable elements and patterns.
Systems not screens
Our design work aims to generate elements and patterns rather than designing complete screens (static representations of what a service or product may look like). Screens, although really useful, are not the end design goal. They are a design artefact created to test elements in context.
Screens often suffer from being representations of the thing you’re trying to design rather than the thing itself. A design process that focuses on only producing screens tends to avoid thinking about reusable elements. It favours bespoke solutions to problems that each screen is trying to solve.
From the outset, our aim is to create a system where basic elements or blocks can be combined to create more complex patterns and systems. Starting with the most basic elements, our ambition is to create an ever-evolving library of elements that can be shared and used across teams.
Build and iterate
Initially, our aim is to create just enough elements to tackle any new design challenges. We will then develop these elements further as we iterate through build and test loops.
We can also take a systematic approach to measure the effectiveness of any element or pattern we create. We can take one element, designed in one specific context and then see how it works and test it in a variety of other contexts. If testing results in changes to an element, those changes can easily be made across all contexts.
We drew a lot from the thinking of Brad Frost, Dan Mall, and others who work in this area, around how we could layer complexity through the arrangement of elements. Start small with the fundamentals and then build up from there.
Emerging patterns and elements
By looking at systems rather than screens, we are starting to see that in the work we are doing, any design is made up of three interconnected design tasks: content design (what the product says), interface design (how it says it), and context design (where it’s saying it).
Dan Mall recently wrote a great post about content display patterns and development patterns being ‘the design’. This is something that resonated with us here. Most pattern work focuses on the presentation layer – basically how the thing looks. However, we’re finding that patterns can be found in both the content and the build.
With the work we’ve done on diabetes for example, we understand that, by and large, most people’s experience of alpha.nhs.uk to date has been through content.
The content is the actual interface.
So it makes sense to explore any content display patterns so we can start creating efficiencies in the content creation process.
Furthermore, as we start to develop prototyping kits, we’re seeing the need for development patterns that are closely related to their content and display pattern counterparts.
These three layers reflect the interdisciplinary nature of the work we’re doing. As a team, we’re all across the design, from content to display to the front end build. Just as user research is a team sport, so is design.
We started small, looking at the grid and fundamental elements around typography and then started building out from there.
Ways of working
Getting these systems up and working will take a fair chunk of time, discipline and focus. Initially, it’s easy to be overwhelmed by the scope and scale of it all. However, to overcome some of these fears, we’ve come up with a number of approaches:
- Just enough design – we’re not trying to design the whole thing up front here. We’re only looking at basic elements and then seeing what patterns evolve, whilst always considering user needs, presentation, content and context.
- Avoid inertia by making mistakes – we know we need to make decisions, but we also need to be prepared to change any decisions we make almost immediately.
- Focus on the big and the small at the same time – what we must do is look at the really small elements and then traverse out to the larger context. We need to regularly step back from the canvas to understand the bigger picture.
- Research vigorously – take every opportunity to put things in front of users.
- Know which problems to park – some problems will take a long time to fix, do just enough to keep moving forward, and work on solving the big problem.
Are you working in this area? We’d love to hear from you: firstname.lastname@example.org
I’ve mentioned a few links within the actual post. Here are some others that continue to inform our research: