Digital design principles

I'm quite impressed with the work of the Government Digital Service, set up by Martha Lane Fox as a team in the Cabinet Office to transform government digital services. I've heard a couple of their key people speak at various conferences, so will have blogged about some of their principles before, especially their tagline  -  Digital by Design.

Today I've been having a look at their  principles for designing digital services - and they are excellent. We certainly adopt some of them to a greater or lesser extent when developing services,  but I think we could do with having a close look at all of them. The website is extremely well set out - very concise descriptions of the principles, and for each one a drop down set of examples of how they've put the principle into practice. In summary they are:

1 Start with needs
  - start by identifying and thinking about real user needs and design around those — not around the way the ‘official process’ is at the moment

2 Do less
 - only do what you can do. If someone else is doing it — link to it.

3 Design with data
 -  learn from real world behaviour and continue this into the build and development process — prototyping and testing with real users on the live web.

4 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 we should be doing.

5 Iterate. Then iterate again.
 -  start small and iterate. Release Minimum Viable Products early, test them with real users, move from Alpha to Beta to Launch adding features and refinements based on feedback from real users.

6 Build for inclusion
 -  build a product that’s as inclusive, legible and readable as possible.

7 Understand context
 - don't design for a screen but for people. Think  about the context in which services are used. Are they on a phone? Are they only really familiar with Facebook?

8 Build digital services, not websites
 - services don’t begin and end at websites. Might start with a search engine and end somewhere physical.

9 Be consistent, not uniform
 - wherever possible  use the same language and  design patterns — this helps people be familiar with  services. But, when this isn’t possible,  make sure the underlying approach is consistent.

10 Make things open: it makes things better
 - share code, designs, ideas, intentions, failures,  with colleagues, with users, with the world.  The more eyes there are on a service the better it gets — howlers get spotted, better alternatives get pointed out.