Design patterns in government 2016
Download as PPTX, PDF7 likes2,233 views
This document discusses the Government Digital Service's (GDS) use of design patterns over the past year. It explains that GDS has created design principles, style guides, templates, and patterns to help scale design across government. It also discusses strategies for making patterns accessible to all users, including those with low digital skills, and for getting designers to adopt patterns, such as through research, co-creation, enforcement, and design tools. The document provides examples of improved patterns around form structures and dropdown menus.
Design patterns in government 2016
- 1. #gdsteam@timpaul @cjforms Design patterns in government One year on What we learned What we changed #gdsteam
- 2. Caroline Jarrett Forms specialist Government Digital Service @cjforms Tim Paul Head of Design Patterns Government Digital Service @timpaul
- 3. #gdsteam@timpaul @cjforms #gdsteam Image credit: photo by Caroline Jarrett of historic cartoon. Not yet successful in tracing the source; please tell us if you know it
- 4. #gdsteam@timpaul @cjforms We’re going to talk about how to: - do design at scale - make design patterns for everyone - get designers to use design patterns
- 5. #gdsteam@timpaul @cjforms How to do design at scale #gdsteam
- 7. #gdsteam@timpaul @cjforms Cross Government Design Meeting, Leeds, 2014
- 10. #gdsteam@timpaul @cjforms The advantages of small teams Collective ownership and shared vision It’s easy to share or steal good ideas A consistent style emerges naturally You’re able to respond quickly
- 11. #gdsteam@timpaul @cjforms Some of the things we’ve done Design principles Style guides Page templates Design patterns Design training Design tools Events Wikis, blogs etc.
- 13. #gdsteam@timpaul @cjforms How to make design patterns for everyone #gdsteam
- 14. #gdsteam@timpaul @cjforms We must design for people with low digital skills and confidence Low High Digital skills and confidence Users GOV.UK Average
- 15. #gdsteam@timpaul @cjforms Activity Think of groups of people who might have low digital skills or confidence
- 17. Idea: Naintara Land image: http://www.memorylossonline.com/glossary/images/amygdala.jpg We must design for people who are stressed
- 19. #gdsteam@timpaul @cjforms Avoid dropdowns if at all possible - they’re not intuitive - they hide choices - they’re hard to use
- 21. We showed two videos • a woman in her 30s struggling to complete a date- of-birth dropdown • a man with low vision unable to use a select box because the browser failed to enlarge it. #gdsteam@timpaul @cjforms
- 23. #gdsteam@timpaul @cjforms Alternatives to drop-down lists - radio buttons - free text - type ahead
- 25. #gdsteam@timpaul @cjforms Example 2 Form structure
- 26. #gdsteam@timpaul @cjforms Form structure 1. Know why you’re asking every question 2. Design for the most common scenarios first 3. Start with one thing per page
- 28. #gdsteam@timpaul @cjforms Let’s apply the form structure pattern to a page on GOV.UK #gdsteam
- 29. 29
- 30. #gdsteam@timpaul @cjforms www.gov.uk/burial-at-sea 1. Make a list of all the things 2. Design for the most common scenarios first 3. Start with one thing per page
- 31. #gdsteam@timpaul @cjforms ‘Things’ could be: - information - evidence - decisions - money - physical objects - times and places - actions
- 32. #gdsteam@timpaul @cjforms Search for ‘service manual form structure’
- 33. #gdsteam@timpaul @cjforms How to get designers to use design patterns #gdsteam
- 34. #gdsteam@timpaul @cjforms We’ve tried 4 methods: 1. Research 2. Co-creation 3. Enforcement 4. Design tools
- 36. #gdsteam@timpaul @cjforms Test your guidance as well as your patterns
- 42. #gdsteam@timpaul @cjforms Example 1 Gender and sex
- 44. #gdsteam@timpaul @cjforms Example 2 Fixing the Apple Effect
- 51. #gdsteam@timpaul @cjforms 13 “Build a service consistent with the user experience of the rest of GOV.UK including using the design patterns and style guide”
- 53. #gdsteam@timpaul @cjforms We worked with the Verify team to make account management patterns
- 57. #gdsteam@timpaul @cjforms 1. Research 2. Co-creation 3. Enforcement 4. Design tools
- 58. #gdsteam@timpaul @cjforms Make it easier to do it right than to do it wrong
Editor's Notes
- #3: Intros
- #4: Caroline We work on GOV.UK
- #5: Caroline How to design at scale How to make design patterns for everyone How to get designers to use patterns
- #6: Tim We’re going to start by talking a bit about this. Show of hands: who’s experienced this challenge? who’s worked on a thing that has more than 10 designers on it?
- #7: From this…
- #8: To this…
- #9: There are (far) more designers working on GOV.UK outside GDS than there are within GDS
- #10: This is our design team. We’re distributed around the country. Departments are hiring more and more designers. Last year, our online patterns community had about 350 members. Today it has over 800.
- #12: Here are some of the things we’ve done to try and keep the benefits of a small team. Principles 10 of them. eg. “Do the hard work to make it simple” Not just slogans - we still use them in discussions. Help create a shared vision and sense of ownership Style guides, templates and patterns The raw materials. Ingredients and recipes. Embodied in code wherever possible. We work collectively on them via a wiki called Hackpad. This is how we maintain consistency. Training We’ve started doing 3 day training courses. Clara and Caroline - but we all contribute. A chance to meet other designers and learn something. Understand context - origins of GOV.UK War stories and case studies We teach people to code using our prototype kit Tools Prototype kit Contains our styles, templates and patterns. Events X-Gov meet ups Ad hoc workshops
- #13: This is how it all hangs together. We learn from and engage with the design community in various ways: - Face to face - Through mailing lists and other informal resources - By publishing advice in the service manual - By checking whether services are following the advice in service assessments
- #14: Caroline The main thing that informs our design patterns are our users. Because we provide government services, our users are ANYONE who is entitled to and needs that service. We can’t leave anyone behind. 1st time internet users. 1st time computer users. This means we have to try extra hard to reach people who might be unfamiliar with digital technologies.
- #15: Imagine the bell curve of your users and how skilled or confident they are at using computers. The GOV.UK curve extends much further to the left than the average - these are the users we need to reach.
- #17: Excerpt from blog post by Katy Arnold, https://assisteddigital.blog.gov.uk/2015/02/13/tales-of-the-unexpected-visas-assisted-digital-research/ A reality check It’s easy to assume that skilled people will all be IT literate, but what we found was that some skilled visa applicants (for example chefs, oil rig workers, small business retailers and church workers) lacked the skills, confidence or ability to get online.
- #19: Tim We’ll give two examples of what happens when you make patterns that work for everyone.
- #23: This is an example of what we now recommend. Yes, you need validation on the fields. But remember - ‘Do the hard work to make it simple’.
- #25: Caveats around type-ahead Don’t assume that the user is looking at the screen whilst they type
- #26: Caroline
- #27: The pattern actually has three steps, but for some reason people only remember the last one…
- #29: Caroline
- #32: Things
- #33: Google ‘service manual form structure’ This pattern explains how to structure forms for GOV.UK services. We’re going to concentrate on section 3: ‘Start with one thing per page’ - Time and effort are subjective - Good because: - works well on small screens - breaks complex tasks into simple chunks - easier to recover from errors - easier to do things like save progress
- #34: Tim It’s not enough to just churn out a bunch of patterns. Anyone who’s worked on a large website will know what can happen. They can quickly go stale, unused by most people. The tumbleweed effect.
- #35: We’re going to discuss 4 methods we’ve tried in the last year. We’ll give a few examples of each method and talk about how successful we think they’ve been.
- #36: Caroline Obviously, all patterns should be grounded in research. But as well as that, the guidance itself should be researched.
- #37: Service teams are users of patterns too. They won’t use them if they can’t find them or they’re not useful. Here are some things we’ve learned testing patterns with service teams.
- #38: Then we overlay higher level patterns. This is one that we launched recently: it’s about how to show error messages. We’ve learned that we have to put hints to designers rather than example content to make sure it gets designed.
- #39: We’ve discovered that for high level service patterns it’s important to give real-life examples. Abstract guidance isn’t enough. This an early prototype for a licensing pattern.
- #40: We discovered that some patterns are more like ingredients, whereas some are more like recipes.
- #41: Excerpt from Progress indicators Help people understand where they are in a transaction and give them the confidence to continue. On this page: Start without a progress indicator If you do use one, keep it simple Avoid complex progress indicators 1. Start without a progress indicator Test your service first without any progress indicators at all. It may be simple enough that you don’t need them. If it isn’t, then at least you’ll discover the point at which people start to struggle. It’s often the order, type or number of questions that causes issues, so try improving these first.
- #42: Tim Smart people don’t like being told what to do. Also - the value of patterns is as much in their creation as in their use. So you want to include as many people in their creation as you can. By working on patterns with the people who will be using them, you get the benefit of their experience and their buy-in. I’m going to give 2 examples of where this method has benefitted us.
- #43: So, governments have a habit of asking people personal questions when they don’t need to. Historically, we’ve had a very black and white attitude to things like gender and sex.
- #44: So, this long and interesting discussion on Hackpad enabled us to write a pattern for gender and sex. We were able to take a potentially controversial topic and invite people to collaborate on it before it made it’s way into formal guidance. This is basically open policy making. We had input from international forms experts (Jessica Enders) and from people from the transgender community. This made the pattern better.
- #46: Our form fields used to look like this
- #47: On 5 October Simon Hurst is a researcher from DWP, on Personal Independence Payment. He used our mailing list to raise an issue he’d seen with some participants not being able to see the borders on our text fields. On participant referred to this as ‘The Apple Effect’ He got responses from Companies House saying they’d found similar issues. Other parts of government chimed in with they experience. We established that it was the thickness, not just the colour that was an issue. We used the list to ask the design and research communities to try out some thicker, darker borders next time they were testing with users with low vision.
- #48: Within a couple of weeks we were able to: Verify that the issue exists in more than one service Agree collectively on a design change Test the design change in research on more than one service Implement the change to our global styles
- #49: Our form fields used to look like this
- #50: Now they look like this Seems like a relatively minor change, but it will have had a huge effect for lots of our users. We were only able to identify the issue and co-ordinate the change because of the community tools we had in place.
- #51: Caroline Another approach is to try to compel people to follow our advice. We’ve got two ways we’ve tried to do this - one for the public sector, one for the private sector.
- #52: The Service Standard is the thing that GDS and departments use to assess the quality of the services we make. Services are assessed at least twice during development, and can’t go properly live unless they pass. Item 13 explicitly tells people to use our design patterns. This gives us the leverage we need if a service is being developed that is wilfully ignoring our design patterns. However, we try to make it very clear that service teams can iterate a pattern if they can demonstrate that this better meets the needs of their users.
- #55: Tim Embed your patterns into the tools that designers use. Make it easier to use those patterns than do something else.
- #56: Prototype kit We’ve made this specifically for designers. It lets you make interactive prototypes of GOV.UK services. It’s a great intro to coding - we offer training too. It contains a growing number of our patterns.
- #57: We added page templates for Start pages Question pages Check your answers pages Confirmation pages Put them together and you’ve got a basic transaction. In our training we teach people how to make a simple transaction using these pages. They learn how to re-use data across pages and to route users to different questions. We’re trying to make it easier to use our patterns than to not use them. Did it work? The kit is very popular (sometimes too popular) Feedback from training is very positive It’s given us a place to put coded patterns
- #58: Caroline