An Unarticulated Principle of User Interface Design

A few month’s ago I renewed my British driver’s licence while sitting at my computer in São Paulo. As a British resident, all I needed to have with me to be able to renew online were the following:

  • a valid UK passport
  • a fee of £14 payable by MasterCard, Visa, Electron, Maestro or Delta debit or credit card
  • the addresses of where I have lived over the last 3 years
  • my current driving licence
  • my National Insurance number

The whole process took around ten minutes, and within a week my new license had arrived at my parent’s house in the UK. The system does not always run this smoothly however. The complexity of the DVLA computer system in the UK which people access for information and services relating to their licenses and road tax is huge, and in 2014 a new version of the site crashed following the phasing out of tax discs, while another new version of the site crashed in 2015 following the abolition of the paper counterpart to licenses.

The integration of two disparate computer systems, especially two as huge as the DVLA system and the passport system, is a vastly complicated project, one which clearly run the risk of being delivered late and over budget. What made this project possible was not just the project methodology and the quality of the people in the teams taking part, but the ten principles listed below which have been developed over time by the Government Digital Services team. These are:

Start with needs*
Do less
Design with data
Do the hard work to make it simple
Iterate. Then iterate again.
This is for everyone
Understand context
Build digital services, not websites
Be consistent, not uniform
Make things open: it makes things better

The gov.uk website explains the thinking behind these principles and also provides examples of how they have used them so far:

Start with user needs*
*user needs not government needs
Service design starts with identifying user needs. If you don’t know what the user needs are, you won’t build the right thing. Do research, analyse data, talk to users. Don’t make assumptions. Have empathy for users, and remember that what they ask for isn’t always what they need.

Do less
Government should only do what only government can do. If we’ve found a way of doing something that works, we should make it reusable and shareable instead of reinventing the wheel every time. This means building platforms and registers others can build upon, providing resources (like APIs) that others can use, and linking to the work of others. We should concentrate on the irreducible core.

Design with data
In most cases, we can learn from real world behaviour by looking at how existing services are used. Let data drive decision-making, not hunches or guesswork. Keep doing that after taking your service live, prototyping and testing with users then iterating in response. Analytics should be built-in, always on and easy to read. They’re an essential tool.

Do the hard work to make it simple
Making something look simple is easy. Making something simple to use is much harder — especially when the underlying systems are complex — but that’s what designers should be doing. Don’t take “It’s always been that way” for an answer. It’s usually more and harder work to make things simple, but it’s the right thing to do.

Iterate. Then iterate again
The best way to build good services is to start small and iterate wildly. Release Minimum Viable Products early, test them with actual users, move from Alpha to Beta to Live adding features, deleting things that don’t work and making refinements based on feedback. Iteration reduces risk. It makes big failures unlikely and turns small failures into lessons. If a prototype isn’t working, don’t be afraid to scrap it and start again.

This is for everyone
Accessible design is good design. Everything we build should be as inclusive, legible and readable as possible. If we have to sacrifice elegance — so be it. We’re building for needs, not audiences. We’re designing for the whole country, not just the ones who are used to using the web. The people who most need our services are often the people who find them hardest to use. Let’s think about those people from the start.

Understand context
We’re not designing for a screen, we’re designing for people. We need to think hard about the context in which they’re using our services. Are they in a library? Are they on a phone? Are they only really familiar with Facebook? Have they never used the web before?

Build digital services, not websites
A service is something that helps people to do something. Our job is to uncover user needs, and build the service that meets those needs. Of course much of that will be pages on the web, but we’re not here to build websites. The digital world has to connect to the real world, so we have to think about all aspects of a service, and make sure they add up to something that meets user needs.

Be consistent, not uniform
We should use the same language and the same design patterns wherever possible. This helps people get familiar with our services, but when this isn’t possible we should make sure our approach is consistent. This isn’t a straitjacket or a rule book. Every circumstance is different. When we find patterns that work we should share them, and talk about why we use them. But that shouldn’t stop us from improving or changing them in the future when we find better ways of doing things or the needs of users change.

Make things open: it makes things better
We should share what we’re doing whenever we can. With colleagues, with users, with the world. Share code, share designs, share ideas, share intentions, share failures. The more eyes there are on a service the better it gets — howlers are spotted, better alternatives are pointed out, the bar is raised. Much of what we’re doing is only possible because of open source code and the generosity of the web design community. We should pay that back.

These are really excellent guidelines which if followed will result in well-designed and usable digital services. There is one principle though which has not been articulated but which is the inspiration behind all the others, and that is the principle of one human being valuing the life of another. We can start to build products and services out of a desire to earn income and become wealthy, or we can start from a desire to make other lives better in some way. Even though a government web service may be clean, simple and functional, there can still be an underlying sense of soul in the essence of its conception.

References

Government Digital Service Design Principles

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s