GDS Design Principles – Improved

GDS Design Principles – Improved

I like the UK Government Digital Service Design Principles. For a government organisation, GDS show some progressive thinking and their design principles come close to principles to which I could subscribe. Close, but no cigar.

Here’s my suggestions for principles which I could wholeheartedly embrace:

1. Attend to folks’ needs.
   This improvement seems close to “start with needs”. But why just start? Sounds a bit waterfall-ish to me.

   “Before we begin any project we spend a long time working out what the user needs are.”

   Do people have needs just at the outset of an endeavour? Maybe they mean “Always give priority to (users’) needs.” If so, why not make it clear?

   Why only users’ needs? That seems like missing the fundamental opportunity to build an environment in which (GDS) folks can choose to give of their best.

   And “start with needs” seems to imply design is a linear process, rather than – as I see it – one of evolution, emergence, and continual learning/discovery.

2. Do what’s needed – more more, no less.
   Sometimes, less is more. Sometimes it’s not. If we do what’s needed, and no more, then we’ve done the minimum. Focussing on “doing what’s needed” – taking into account all constituencies and needs – seems better than “doing the most good” (whose good?). And let’s not get hung up on the minutiae of “minimal” page design (see their example) when “minimal” effective services are the aim?
3. Continually Evolve The Service with Quick Feedback and Iterations.
   OK with this one – excepting the wording “Design with Data” which may only serve to confuse, and to cut folks off from relevant pools of existing know-how, such as Lean Startup. See also my (additional) principle 11.
4. Make It Optional.
   One of the things that really gets my goat with “Digital by Default” is that it so often means “Digital only”. I won’t go into the folly of believing that digital aka online Government Services are cheaper to provide or meet folks’ needs better, by default. Better, I suggest, to make the digital option truly optional, and follow the data to learn if the digital option is the most popular option. Let folks vote with their feet!
5. Flow.
   “Iterate” is a bit of a duplicate of 3. This principle seems more about highlighting the idea of continual flow of value. I.E. No service has a beginning or end, but just a continual flow of ever-improving delivery of “meeting people’s needs”. “Launch” happens every day. Maybe dozens of times per day.
6. Build for Inclusion.
   Great principle. Hard to do when Digital By Default – “The people who most need our services are often the people who find them hardest to use” (and those who least want to use a computer to access them?). Is this issue even discussable?
7. Understand Context.
   Ditto with 6.
8. Build Services, not Digital Services.
   Granted this is not within the purview of the Digital Teams themselves, whose raison d’etre is to build Digital Services. But I believe this can change, given the will.
9. Derive Consistency From Needs.
   If needs are understood, and the trade-offs of consistency also understood, than it’s possible to decide when consistency is beneficial, and when it’s a drag.
10. Make Things Open.
    Including dissent, discussion and debate – and those topics that remain undiscussable. 😉
11. Build Improvement Into the Way the Work Works.
    Some of the original list of UK Government Digital Service Design Principles speak to improving government (digital) services as experienced by users. But I see no explicit mention of improving the way the work works. I’m sure all the smart folks in GDS are pursuing improvements to how they work, so why not recognise and honour that with its own principle? Moreover, make explicit the principle of in-band continuous improvement – to help avoid the dysfunctional anathema of e.g. change programmes, improvement teams, and so on.

– Bob

Further Reading

Sketching User Experiences: Getting the Design Right and the Right Design ~ Bill Buxton