About the Government Digital ServiceWe're a centre of excellence in digital, technology and data, collaborating with departments to help them with their own transformation. We work with them to build platforms, standards, and digital services.If you have comments or questions, please get in touch. You can send an email to gds-comms@digital.cabinet-office.gov.uk, and we're on Twitter @gdsteam.Government Digital ServiceUKGDS_ddb0a580-05db-11e6-8f6e-3108f26a1bf3The Government Digital Service (GDS) is part of the Cabinet Office.UK DepartmentsMatt HancockWe believe in working openly, because making things open makes them better. In the words of our Minister, Matt Hancock, our work is about "transforming the relationship between citizens and the state."_ddb0a6d4-05db-11e6-8f6e-3108f26a1bf3To lead the digital transformation of government._ddb0a756-05db-11e6-8f6e-3108f26a1bf3User NeedsWe always start with user needs.AgilityWe are agile.Design PrinciplesWe work to a set of Design Principles that guide us in everything we do. Listed below are our design principles and examples of how we've used them so far. These build on, and add to, our original 7 digital principles. 1 Start with needs* 2 Do less 3 Design with data 4 Do the hard work to make it simple 5 Iterate. Then iterate again. 6 This is for everyone 7 Understand context 8 Build digital services, not websites 9 Be consistent, not uniform 10 Make things open: it makes things betterNeedsStart with needs* *user needs not government needs Service design starts with identifying user needs. If you don't know what the user needs are, you won't build the right thing. Do research, analyse data, talk to users. Don't make assumptions. Have empathy for users, and should remember that what they ask for isn't always what they need.EmpathyLessDo less -- Government should only do what only government can do. If we’ve found a way of doing something that works, we should make it reusable and shareable instead of reinventing the wheel every time. This means building platforms and registers others can build upon, providing resources (like APIs) that others can use, and linking to the work of others. We should concentrate on the irreducible core.ReusabilityDataDesign with data -- In most cases, we can learn from real world behaviour by looking at how existing services are used. Let data drive decision-making, not hunches or guesswork.BehaviourPrototypingKeep doing that after taking your service live, prototyping and testing with users then iterating in response.TestingAnalysisAnalytics should be built-in, always on and easy to read. They're an essential tool.SimplicityDo the hard work to make it simple -- Making something look simple is easy. Making something simple to use is much harder -- especially when the underlying systems are complex -- but that's what we should be doing. Don't take "It’s always been that way" for an answer. It's usually more and harder work to make things simple, but it's the right thing to do.Hard WorkIterationIterate. Then iterate again. -- The best way to build good services is to start small and iterate wildly. Release Minimum Viable Products early, test them with actual users, move from Alpha to Beta to Live adding features, deleting things that don't work and making refinements based on feedback. Iteration reduces risk. It makes big failures unlikely and turns small failures into lessons. If a prototype isn't working, don't be afraid to scrap it and start again.InclusionThis is for everyone -- Accessible design is good design. Everything we build should be as inclusive, legible and readable as possible. If we have to sacrifice elegance -- so be it. We're building for needs, not audiences. We're designing for the whole country, not just the ones who are used to using the web. The people who most need our services are often the people who find them hardest to use. Let's think about those people from the start.LegibilityReadabilityContextUnderstand context -- We're not designing for a screen, we're designing for people. We need to think hard about the context in which they're using our services. Are they in a library? Are they on a phone? Are they only really familiar with Facebook? Have they never used the web before?UnderstandingServiceBuild digital services, not websites -- A service is something that helps people to do something. Our job is to uncover user needs, and build the service that meets those needs. Of course much of that will be pages on the web, but we're not here to build websites. The digital world has to connect to the real world, so we have to think about all aspects of a service, and make sure they add up to something that meets user needs.ConsistencyBe consistent, not uniform -- We should use the same language and the same design patterns wherever possible. This helps people get familiar with our services, but when this isn’t possible we should make sure our approach is consistent. This isn't a straitjacket or a rule book. Every circumstance is different. When we find patterns that work we should share them, and talk about why we use them. But that shouldn’t stop us from improving or changing them in the future when we find better ways of doing things or the needs of users change.OpennessMake things open: it makes things better ...SharingWe should share what we're doing whenever we can. With colleagues, with users, with the world. Share code, share designs, share ideas, share intentions, share failures. The more eyes there are on a service the better it gets -- howlers are spotted, better alternatives are pointed out, the bar is raised. Much of what we’re doing is only possible because of open source code and the generosity of the web design community. We should pay that back.DesignsIdeasIntentionsFailureLeadershipWe've won design awards, and are recognised world leaders in public sector digital innovation. Digital government teams in the US, Australia and New Zealand were established on the same model, and follow very similar principles.InnovationThinking Out LoudWe use this blog to think out loud, and let the world know what we're doing.GOV.UKEnable discovery of government services and information._ddb0a896-05db-11e6-8f6e-3108f26a1bf31We run GOV.UK, the best place to find government services and information. It began as an alpha, built in just 10 weeks, and has grown to become part of our national digital infrastructure. It's always being improved in response to user research and user feedback. Our work is not just about websites. Among many other things, we also:_ddb0a94a-05db-11e6-8f6e-3108f26a1bf3Public ServicesWork with the rest of government to make public services simpler and better_ddb0aa08-05db-11e6-8f6e-3108f26a1bf32_ddb0aad0-05db-11e6-8f6e-3108f26a1bf3PlatformsBuild platforms like GOV.UK Verify -- a way to confirm users are who they say they are_ddb0ab84-05db-11e6-8f6e-3108f26a1bf33_ddb0ac60-05db-11e6-8f6e-3108f26a1bf3DataWork to ensure government data is good data, more usable for all_ddb0ad1e-05db-11e6-8f6e-3108f26a1bf34_ddb0ade6-05db-11e6-8f6e-3108f26a1bf3TechnologyHelp departments make better-informed decisions when they need to buy technology_ddb0ae9a-05db-11e6-8f6e-3108f26a1bf35_ddb0af6c-05db-11e6-8f6e-3108f26a1bf3ToolsHelp departments provide their staff with better value technology that's more of a tool and less of a barrier_ddb0b03e-05db-11e6-8f6e-3108f26a1bf36_ddb0b12e-05db-11e6-8f6e-3108f26a1bf32016-04-18https://gds.blog.gov.uk/about/OwenAmburOwen.Ambur@verizon.net