Fear of flying

Public sector digital services in the UK have a specific set of design patterns that were originally developed by GDS for gov.uk. When gov.uk was initially being created, there wasn’t a standard way that government digital services worked across the world. To a large degree, GDS had to define how public sector digital services should be designed from scratch. Over the last 14 years, teams across the public sector, including the NHS, have elaborated on this approach. Today, public sector design systems are a robust toolset that teams rely on everyday. While many of them remain under constant development, together they represent a holistically-considered way of designing services that is internally consistent. They are their own design paradigm and have provided a massive benefit to teams across the sector. Last week, in a blogpost about work being done to reinvigorate the NHS design system, Tero Väänänen articulated why these tools are so important:

Design systems help delivery teams create consistent user experiences that feel familiar, behave predictably, and, when done well, are accessible.

They do this by offering a set of reusable design components and patterns that can be trusted and used ‘off the shelf’ by multiple teams, saving them time and effort.

The current, live NHS App makes use of the NHS design system, however this toolset was made for services on the web. We do our best to adhere to the system, but there are places where we need to diverge or invent something new to fit our context. It kinda works and it kinda doesn’t, with the resulting app feeling best when viewed as a mobile website because, well, it is a mobile website. What else might we do?

In our current work, we are testing the assumption that by relying on stock components and patterns from iOS and Android, we can increase the trust users have in the app and reduce the amount of effort it takes to complete tasks. This includes what things look like and how they work. The theory is that patterns of use will be more familiar to users if we make our app work like most of the other apps they use every day (i.e. Jakob’s Law). Here we reach an interesting moment of conflict. Given that iOS and Android do things differently than public sector services (at least at the level of interaction design), which set of conventions is the correct one to use as our foundation? My hunch is that we should do everything we can to avoid deviating from the tools that Apple and Google provide, but this introduces the risk that we deviate from patterns that users trust. Tero hints at what we’re worried about breaking:

If something looks and behaves like an NHS website, people are more likely to trust it. But, if a legitimate NHS digital product doesn’t look authentic, people may avoid using it. At best, that wastes public money. At worst it causes harm to people.

Indeed, but we’re not making a website, so which stylistic paradigm should we index on? We intend to find out.

We’ve been building prototypes to explore an approach that relies heavily on the mobile OS design systems and last week we took them out into the world to get feedback from users for the first time. Over the course of an afternoon spent in the lobby of a community centre in London, we were able to put our prototypes into users’ hands and start gauging how people react to a newly rebuilt app. What we observed was fascinating, if also predictable.

The most interesting aspect of the research was not what people told us verbally, but was watching how their hands moved. We spoke with people ranging in age from approximately 25 to 80 who had a mixture of access needs. The way they moved in our prototypes was remarkably more fluid than what I’ve witnessed in research sessions on the current, live app. When attempting to perform a given task, people didn’t hesitate in how they engaged with the interface. Instead, they moved confidently and directly. To quote Anna (the researcher I joined for the outing), “People were flying.”

Right now, the prototypes aren’t hooked up to any APIs, so they aren’t slowed down waiting for patient data to be returned from a server. That makes the experience much snappier, but so does the basic nature of a mobile app, where all of the front-end code is already on the user’s device. That said, using mock data deflates our early findings a bit because our tests aren’t entirely realistic. We’ll need to get the prototypes connected to real data sources and run the research again in a few weeks.

These early findings are both surprising and not. It was what we have been hoping for, but to see it working in real life was something else. It is an encouraging start (but it is also just a start that we shouldn’t draw too many conclusions from yet). The next question will be whether we can blend platform conventions for visual design and navigation controls with public sector conventions for service journeys.

Some links:

• Design is not coming to save you, by Alexandra Deschamps-Sonsino. This should have had a subtitle that reads “What you think of as design is really the tail end of late-stage capitalism and what we should really be focussing on is a more assertive socialist politics.” (And I agree.)
• Mapping is thinking, by Martin Wright. Yes.
• Thank you for being annoying, by Adam Mastroianni (via Paul Pod). When I say that design is fun, this is what I mean. I love what I do, there is pleasure in it, but I also just want to straighten all the picture frames.
• Ira Glass on Storytelling (via Russell Davies). This chimes nicely with a thing I talk about in management settings, specifically that my job as a manager is not to help people improve in some pre-formed, cookie cutter way. Rather, it is to help each person become more themself.
• Game design is simple, actually, by Raph Koster. This is ostensibly about game design, but you can apply most of what is here to digital services, including approaches to shaping emotional responses to complex tasks. Plus, it begins by defining “fun”, which is S-tier design nerd stuff.