IAS13 - Revolutionising GOV.UK

This is part of a series of notes from the Information Architecture Summit from 2013. All posts will be tagged IAS13. This talk was presented by Paul Annett.

  • Before:
    • hundreds of government department websites make it hard to find stuff, have to know how gov works to know where to look
    • 1 in 5 phone calls to help lines were for failed digital transactions; web transaction costs 1 penny, phone call costs 6 pounds
    • locked into contracts, can cost 75,000 dollars to change a line of code
  • starting to replace everything with single gov.uk
    • created Government Digital Services (GDS) cabinet office with control of all user experience across all digital channels
    • fix publishing
    • fix transactions
    • open API
  • citizen needs information (next public holiday, do I apply for X) and services (taxes, renew passport)
    • most digital services can't be done online, working on digitizing and improving
      • some services can be prioritized based on frequent use (register to vote vs apply for burial at sea)--created metrics of transactions for each department of each service, all publicly browsable
      • started with 25 of the most important services that will set the bar for all the others
  • private sector ecommerce has design patterns, but government transactions are obligated, complicated, infrequent ("grudge transactions")
    • users don't compare to other governments, compare to google and twitter, need to measure up
    • want people to prefer online to phone or face to face
  • proof of concept in 2011 to start conversations
    • just a taste of what could be done without bureaucracy overhead, use to convice polititions that this was the right way to go
    • public, invited feedback, have continued to iterate design
    • initial prototype didn't worry about scalability, main focus was feedback
  • design principles (published, want to change how government organizations think and work, explain process, evolve over time)
    • start with needs (user needs, not departments or stakeholders)--if you don't give people what they want in private sector, they go to a competitor; in public sector, competitor is the more expensive channels like phone
      • analyzed search terms on old sites, used to prioritize content on new site and uncover user needs
    • do less, focus efforts on what needs to be done: government should only do what only government can do--cut out things like tips on keeping bees, reduced number of pages and closed things that other non-gov sites could do better
    • design with data: user testing on prototypes, analytics
    • share information, e.g. with call centers, who have rich information on exactly what the problems are with digital services, create shared responsibility for keeping things running smoothly
    • do the hard work to make it simple--online services are on top of complex processes and legislation--hard to simplify something when specific procedures are enshrined in law
      • don't over-simplify, people can feel sped through without being given time to think on forms that are too short and simple; people have trouble trusting government services that are too simple, "can't possibly work that way"
    • iterate! don't treat websites like rockets, they're services so you can refine them over time
    • build for inclusion
      • the people who use gov services the most are the people who are most vulnerable and hardest to reach--need to allow people to register to vote without email or computer; accessibility is not just checkboxes, needs to account for real use
      • people who haven't used a computer don't scroll--the fold is back! don't have to avoid scrolling, but consider it, especially on things more likely to be seen by people who haven't used computer before
    • understand context and environment (job center, home, hospital bed)
      • government transactions are often related to stress and suffering, being asked to make very serious decisionts--slow people down, give them the time to make those decisions wisely, consider emotional context
    • build digital services, not websites
      • many services have elements that aren't digital, design for those--some can be digital, but some won't
        • e.g. may have alternatives to signing using webcam, try to make people's lives easier
    • be consistent, not uniform: not every pattern works in all situations, agencies have guidance on how to design services but also freedom to experiment and work out what works best as they go along
    • make things open, share with colleauges, users, etc.--why they have alpha, github, etc., allows feedback, lets people to contribute better code, enable world to build services that are bigger and better on their data
      • also paying back open source community
      • the public paid for it, they own it