UK Government digital design principles examined for mobile

by Geoff Dennis

Martha Lane-Fox

In an earlier article (‘GoMo examines UK gov design principles for mobile’) here, we noted that the UK  government has come up with design guidelines for digital services.  These are based on Dame Martha Lane-Fox’ guidelines for the [UK] Government Digital Service (GDS). We promised that we would investigate how effective these are for mobile (rather than desktop) users. So we have now taken each of the ten principles and examined its relevance to mobile. Read on …

P1. Start with needs: (we) must start with ..real user needs. We should design around those .. and we should remember that what users ask for is not always what they need.

Stated generally, as a mobile user I want to be able to use my mobile device to carry out a task that I need to conduct with a public body.

An example would be renewing my car tax. Implicit additional goals are to be able to conduct this via an interface that is readily usable on a portable device, reliably to its conclusion, and at an acceptable speed for someone who is on the move.

We can only determine whether this principle has been applied by testing whether a service works, which we shall be doing over the coming weeks.

P 2. Do less: .. do what only government can do. …concentrate on the irreducible core.

In other words outsource or refer users to existing services that could meet their needs.

A good principle, in that it should also ensure services are implemented rapidly and are readily expandable. Not specific to mobile solutions.

P 3. Design with data: learn from real world behaviour… (use) prototyping and testing with real users on the live web

Most government services exist and are being re-worked for use over the internet. Some might not, though.

Caring about user feedback, and piloting, are important. This principle recognises that statistics and analytical data can be used to refine a service.

Again, not specific to mobile, but applicable to the multitude of devices there are to cater for.

P 4. Do the hard work to keep it simple. Making something look simple is easy; making something simple to use is much harder — especially when the underlying systems are complex

The proof of this will be the proportion of transactions completed on portable devices.

It might have been useful to see a target number for the maximum number of steps here.

How many one-click government services will we ever see?

P 5.Iterate then iterate again. The best way to build effective services is to start small and iterate wildly. Release Minimum Viable Products …

If you are providing a service you can always provide it better, and the best way to find out how is to run a test then iterate.

Giving early exposure to a solution also reduces risk. This, and building core functionality first (minimum viable product) follows the currently accepted software best practice advocated in Agile development.

P 6. Build for inclusion. Accessible design is good design: ..build a product that’s as inclusive, legible and readable as possible. ..sacrifice elegance (where necessary).

Again, software design best practice dictates that you consider all needs at the outset, and user interfaces generally provide features that support accessibility.

It also keeps costs down not to tack on features for additional classes of user.

P 7. 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 on a phone?

Are they only really familiar with Facebook? Have they never used the web before?

Our context is mobile so, yes, they need to think about it. And don’t assume anything about user behaviour – check how people use the service.

P 8. Build digital services not web sites. Our service doesn’t begin and end at our website. It might start with a search engine and end at the post office (and) we need to design for that.

It sort of says it all about past public sector solutions that they need to include this.

And it also means don’t jump on the latest app bandwagon for the sake of it. We’d advocate keeping away from OS-specific solutions too.

P 9. Be consistent, uniform. Use the same language and the same design patterns .. so (that) users will have a reasonable chance of guessing what they’re supposed to do.

A hard one to ensure across a multitude of government departments. Who’s going to police this? The Cabinet Office, who came up with these guidelines?

P10. Make things open: it makes things better. We should share what we’re doing whenever we can.

A good principle for standardising practice. Interestingly, the examples mention several things but not data, which is still contentious in many areas.

Something that really caught my attention in Stig Larsson’s ‘The Girl ..’ trilogy was the journalist’s ability to look up the owner of a vehicle from it’s registration number. In Sweden, maybe, but not in the UK.

In conclusion then, laudable principles, many of which apply whether for mobile devices or not.

Some, such as following user needs, context, and keeping it simple, could pay big dividends for mobile users if followed.

See also the original guidelines and an interesting assessment of whether they are relevant in another design context:  - the London Underground.

About Geoff Dennis

Geoff Dennis is a director with Insight Manufacturing and IT project manager, and has a background in software development and methodologies in office and telecommunications software.
This article was published in Mobile Web, mobile developers and tagged , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>