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