Users-first

How government development teams put the user at the heart of what they do

Transcript

2. Who’s this bozo? • Mark Ford - @fordie • Founder of WorthingDigital • Front End Web Developer • Contractor My name, you’ll find me as fordie on most of the social networks Won’t bore you with the whole story, but Worthing Tweetup 8 or nine years ago, WorthingDigital 6 Years ago Front end dev for 18 years, contractor half that time
3. Users First How the government does it and you can too This is going to be a very high level overview
4. A bit of history In 2010 Martha Lane-Fox, one of the founders of the founders of lastminute.com was invited to carry out a review of direct gov. 
 It was fairly clear that things could be a lot better. She wrote Francis Maude outlining her proposals
5. – Martha Lane-Fox “There has been a reinvention of the Internet and the behaviour of users in the last few years. Digital services are now more agile, open and cheaper. To take advantage of these changes, government needs to move to a 'service culture', putting the needs of citizens ahead of those of departments” in October that year and in November GDS was born.
 They assembled a team and in March the following year they started work on an Alpha version of gov.uk. 
 The plan was to come up with a single domain to represent all government departments in the same way.
6. In March 2012 Ben Terrett did this at GDS HQ, Aviation house.
 “Someone had put some persona posters up and I got angry, saying that the whole country were our users, not some neat persona. I ripped a hole in that piece of paper and stuck it in the window.” In April the design standards were published. These went on to form part of the Service Manual, which we’ll come on to in a moment. 
 In 2013 GDS started collaborating with other government departments, in November of that year the digital strategy was published.
7. • All departments will ensure that they have appropriate digital capability in-house, including specialist skills • From April 2014, all new or redesigned transactional services will meet the Digital by Default Service Standard Jump forward to today and most (if not all) central government departments, The NHS & local authorities have an in-house version of GDS all following a standard way of working based on the service manual. Teams must deliver services which meet the Service Standard which is defined in the service manual.
8. https://www.gov.uk/service-manual The service is assessed against the 18 points in the Service Standard. Out of the 18 points I think there are only a handful that you probably wouldn’t want to apply to your own projects
9. A quick look a project phases From Discovery to Live Projects in government go through 4 phases, starting in discovery the pass through Alpha beta and eventually go live. In order to be considered “live” a service has to pass three assessments, these are carried out at the end of discovery, alpha and beta. We’re going to have a quick look a what happens during Discovery, Alpha, Beta & Live
 There is a fifth phase, which I’m not going to cover, retirement. You can probably imagine what that means. We’ll just whizz through this and then I’ll get on to the parts of the government process that I think make the biggest difference to user experience
10. Discovery • Who are your users? • What are your users needs? • How would you start developing a service to meet those needs? • Are there any technical constraints from legacy systems? • What should you call your service? Find Out
11. Discovery • Carry out user research • Analyse business needs • Ultimately, decide whether to proceed with the project What to do Discovery typically takes place over a sprint or two (2 - 4 weeks)
12. Alpha In the alpha phase you need to: • build prototypes of your service • test your prototypes with users • demonstrate that the service you want to build is technically possible You should use your experience building prototypes in the alpha to: • find the problems with the design of your service and decide how you’ll solve them • make some estimates about how much your service will cost • identify the biggest risks for the beta stage, as early as possible
13. Beta • The objective of the beta phase is to build a working version of the service based on your alpha prototypes. • The version you build must be able to handle real transactions and work at scale. • You also need to keep improving your service and replace existing services or integrate with them.
14. Beta • Once you have a functioning version of your service you can go into Private Beta. This is usually password protected and only open to invited users • Once you’re happy that you’re private beta is stable you can open your service up to the general public. • Keep iterating
15. Once you’re in public beta you’re effectively live as the service is publicly accessible. For a government service to remove it’s beta banner it has to pass its live assessment.
16. Live The live phase is the time to keep improving your service based on: • user feedback • analytics • your ongoing user research There are a number of other points that need to be met in order to remove the beta banner. These are mainly technical around analytics, security and reporting.
17. So that is a very quick run through of the process
18. Hang on fordie, you said this was about users…
19. The key to putting users at the heart of your service starts in Discovery
20. Before you start building
21. Point 1 of the Service Manual “Understand user needs Research to develop a deep knowledge of who the service users are and what that means for the design of the service.”
22. Understand user needs • Speak to your users, what do they want? • In plain English break their needs down into “user stories”
23. “As a < type of user >, I want < some goal > so that < some reason >.”
24. “As a user I want to find the right widget so that I can buy it”
25. Build a prototype Think about your user stories as you build your prototype and use them as your definition of success
26. In government we’re lucky to have the prototype kit. This is a node app which allows you to quickly build an HTML prototype of a service that looks and behaves a lot like a real site, only there’s nothing transactional going on behind the scenes. It can be used to create pages without gov.uk branding, but there are probably better tools out there.
27. There are a number of tools available on line that will allow you to create prototypes, some create clickable images, some will create a basic HTML site. You can even use a site builder like Wix or square space. If you’re more technically minded there are node apps. Ideally you should use html prototypes there’s much more value in having something that behaves more like a real site.
28. At this stage don’t get too hung up on the design. You really just want a very vanilla experience. Focus on the interactions, not the pretty
29. A quick aside… Why do we use prototypes?
30. Why Prototype • Rapidly achieve a live-like experience, making it easier for research participants to believe that the design they’re seeing is real. • Quick and inexpensive changes • Handy for service managers • Version Control • The prototype is the design
31. Test You don’t have to wait until you’ve built an end to end prototype before you start testing. In government we test part of a service every couple of sprints. Prototype a user story and then go through it with some users. The sooner you can start testing with users the better.
32. What is user testing? • Asking “real people” to carry out a task on your service • Ideally face to face, but can be done over skype etc. • If possible record the sessions • You don’t need to test with a lot of people By real people I mean someone that could really be a user. Ideally not your mum, or anyone that works in your organisatio n.
33. –Nielsen Norman Group “zero users give zero insights”
34. Nielson Norman Group

35. Where can I find users? In government we use specialist recruiters, you probably won’t want to do that. You can ask for volunteers among people you know. But for a better representative sample, why not take your laptop to a coffee shop and ask people there to let you buy them a coffee in exchange for five minutes of their time?
36. Before you start ask your user a bit about themselves: where do they work? How much do they do on line? Have they used any of your competitors services, what do they think of them? Then get down to business
 Give the user a task, then ask them questions as they try to complete it.
37. “What do you think will happen next?”
38. “Why did you choose that option?”
39. “How does that make you feel?”
40. Make a note of what the users say, and anything they do that is unexpected. Make some changes and test again.
41. – Paul Boag “Present your prototypes as discussion pieces. The first iteration of a prototype should never be what you build, but instead be a vision of what is possible.”
42. After a few rounds of testing you’ll have covered all of the main user stories. In other words if the prototype was your real service users would be able to get whatever they’re expecting to do done. You’re ready to start your Beta Remember, this does not need to be your finished product, you’re building your MVP
43. Build your working site making it as close as possible to your prototype. When it’s ready you may want to carry out a Private Beta, in other words only allow selected users to access it. You can do this by password protecting the site. During private beta ensure that users are able to achieve their goals on the service, then unleash it on the world!
44. Analyse Once you are in Public Beta, look at your google analytics, are people getting through the user journeys? If not, what’s stopping them? You may want to do some more testing. If you find a problem, prototype your solution test it and once your happy apply the redesign to the beta version of the site.
45. Now you’re live • If you want to add features prototype and test them first • Speak to, and test with users frequently • Keep tweaking
46. Find out more • Read the GDS blog (HMRC & MoJ Digital blog a lot too) • Check out The Service Manual • Read Don’t make me think for a more in depth introduction to user testing
47. Thank you