I’ve talked before about various aspects of how we build software at GDS, and especially for GOV.UK, but I’d like to take a step back and about one of our early design rules: “tools over content”.
Many of the needs we’re addressing are complicated. If the team building a website only have a generalised ‘content management system’ it can become very difficult to provide people with exactly the information relevant to their situation. As an expectant parent you’re likely to want to know exactly what your eligibility is for leave and benefits. The full details of your entitlements can be very complex depending on due dates, when you started your current job, your employer’s policies and so on. Most users don’t want to consume and interpret all that information themselves, but if the content management tools only allow us to publish text then that’s what users will end up reading.
In building GOV.UK (and establishing GDS) we knew we had to do better than that. We had to do the hard work to make it simple. What is complex as a piece of prose can often be simplified. Asking a few questions can take someone to a very specific and tailored answer. It can also take them directly into the transaction they need to complete. By asking the right questions we can take you straight to what you need to do rather than making you wade through hundreds of words to determine exactly what content applies to you. Even where the answer involves a fair amount of reading we can give people tools to penetrate, navigate and apply all that content. An example of this is our maternity leave planner which will only require most people to enter a couple of dates to find out what leave they can take.
Greater than the sum of our parts
The secret is to have a cross-functional (or cross-disciplinary) team. You need people who understand the needs, the users, the available tools and the creative possibilities. Those people need to be able to challenge one another and collectively refine the solution. If they can do that they will usually come up with something much better than any of them could have achieved alone. That’s been a big part of what we’ve been looking for when we’ve been hiring.
Each of the “formats” we’ve used to shape GOV.UK have emerged out of that cross-disciplinary process. A first iteration of any format or tool is specific to a single need. Future iterations and newly understood needs may identify that format only suits one need, or that there’s scope to clarify and develop it to serve many more needs.
As formats have become more clearly defined we’ve found that content designers drive the formats that are most clearly prose, business analysts drive the smart answers, developers wrangle the more awkward data-driven content and so on. In each and every case, however, it takes a mix of skills to identify what format best solves a need, how we continually refine the formats and when exactly we need to build specific tools.
Filed under: GDS, Innovation
