The Design Principles have been in Alpha since April 2012. It’s probably about time they went into Beta. But every time we start doing that we ask ourselves ‘Are the principles right?’
We’re genuinely split on that.
Mostly, the design principles work
Between releasing GOV.UK, starting the transformation of 25 of government’s biggest services, and growing from a hundred people in Holborn to more than six hundred people working in eight departments, it’s fair to say we’ve had a busy couple of years.
The design principles have been at the heart of that work. They’ve been presented to ministers and foreign governments, been picked up by other teams and companies and they’re on posters above digital teams up and down the country.
We’ll always start with user needs, we’ll always design with data, we’ll always believe that making things open will help us make those things better.
So there’s a strong argument for keeping them stable. Updating the evidence that underpins each principle is a bit of a no-brainer, we’re doing that and we need to make the page much more accessible than the current design. But the principles themselves pretty much work.
But they aren’t perfect
Thing is, some of them don’t quite hit the spot.
Build for inclusion isn’t as strong a statement as it could be. We’re huge fans of Tim Berner’s Lee’s tweet from the 2012 opening ceremony... This is for everyone is a huge reminder that a service like GOV.UK isn’t for any particular audience or particular ‘type’ of user. It’s for the whole of the UK (and a lot more besides).
Build digital services, not websites sort of works... but it gets wrapped up in questions about making APIs which, yes, is part of the point. But also it’s about knowing GOV.UK and its services are going to be delivered in a lot of different ways, whether that’s device type, people using our APIs or assisted digital support. Build things people can build on has been doing the rounds here in a its place a fair bit.
Understand context has always been problematic. We expect makers of digital services to have empathy for the people using the things they build, but the context of that use is something you should be drawing from data and research. At the moment the principle implies there’s a ‘context phase’ where you work out if it’ll look good on an iPad, which wasn’t what we intended.
Finally, we aren’t explicit about one of the most important reasons for the success of our projects; the teams working on them. Multidisciplinary teams that evolve and grow (and often shrink again) over the course of a service’s development are critical. And we don’t mention those.
We can solve those problems by explaining the principles better, or we can change the principles themselves. And on any given day we’re pretty much 50/50 on that.
So, we should start with users
And you’re the users, or some of them, so we’d love to know how and if you use them, for example:
- how do the design principles appear in your team’s work? (Or maybe they don’t...)
- how do you explain them to new starters?
- do they play a role in the things you build?
- if we just deleted them all and wrote USER NEEDS NOT GOVERNMENT NEEDS on the page on 100pt comic sans, would anyone notice?
We’re after stories (and photos, ideally) of how you use the principles and what changing them might mean for you. Facts, not reckons.