Các nguyên tắc thiết kế dịch vụ số của Chính phủ

Government Digital Service Design Principles

Theo: https://www.gov.uk/design-principles

Được liệt kê bên dưới là các nguyên tắc thiết kế của chúng tôi và các ví dụ cách chúng đôi đã sử dụng chúng cho tới nay.

1. Bắt đầu với các nhu cầu của những người sử dụng

Thiết kế dịch vụ bắt đầu bằng việc nhận diện các nhu cầu của người sử dụng. Nếu bạn không biết người sử dụng cần gì, bạn sẽ không xây dựng được điều đúng. Hãy nghiên cứu, phân tích dữ liệu, nói chuyện với những người sử dụng. Đừng giả thiết. Có sự cảm thông đối với những người sử dụng, và hãy nhớ rằng những gì họ hỏi không phải lúc nào cũng là những gì họ cần.

• Chúng ta ngụ ý gì khi chúng ta nói “biến đổi dịch vụ”, của Mike Bracken
• Hầu hết của chính phủ là hầu hết thiết kế dịch vụ hầu hết thời gian, của Matt Edgar
• Lửa trại thẳng đứng: các bức tường nghiên cứu của người sử dụng của chúng tôi, của Kate Towsey

2. Hãy làm ít đi

Chính phủ chỉ nên làm những gì chỉ chính phủ có thể làm. Nếu chúng ta đã thấy cách làm thứ gì đó được việc, thì chúng ta nên làm cho nó sử dụng lại được và chia sẻ được thay vì lúc nào cũng phát minh lại chiếc bánh xe. Điều này ngụ ý việc xây dựng các nền tảng và đăng ký cho những người khác có thể xây trên nó, cung cấp các tài nguyên (như các API) mà những người khác có thể sử dụng, và liên kết tới công việc của những người khác. Chúng ta nên tập trung vào cốt lõi không thể nhỏ hơn được.

• Xây dựng hạ tầng dân sự số từ nền lên, của Mike Bracken
• Những gì chúng ta đã học được về mở rộng phạm vi lanh lẹ, của Jamie Arnold

3. Thiết kế với dữ liệu

Trong hầu hết các trường hợp, chúng ta có thể học được từ hành xử của thế giới thực bằng việc xem xét cách các dịch vụ đang tồn tại được sử dụng. Hãy để dữ liệu dẫn dắt việc ra quyết định, không linh cảm hay phỏng đoán. Hãy tiếp tục làm điều đó sau khi làm cho dịch vụ của bạn sống, làm mẫu và kiểm thử với những người sử dụng rồi lặp đi lặp lại để trả lời. Phân tích nên có, luôn tiếp tục và dễ đọc. Chúng là công cụ cơ bản.

• Dữ liệu thực thi cho các dịch vụ của chính phủ
• Bỏ đi các biểu tượng của chúng ta, của Guy Moorhouse
• Kết hợp nghiên cứu và phân tích của người sử dụng để cải thiện kinh nghiệm của người sử dụng, của Lana Gibson và Charlotte Clancy

4. Làm cật lực để làm cho nó đơn giản

Làm thứ gì đó trông đơn giản và dễ dàng. Làm thứ gì đó đơn giản để sử dụng là khố hơn nhiều - đặc biệt khi các hệ thống nằm bên dưới là phức tạp - nhưng đó là những gì chúng ta nên làm. Đừng nói “Nó luôn là như vậy” cho câu trả lời. Công việc thường nhiều hơn và cật lực hơn để làm cho mọi điều đơn giản, nhưng đấy là điều đúng đắn phải làm.

• Làm việc cật lực để làm cho mọi điều đơn giản, của Mike Bracken
• Tôi đấu tranh với luật và những người sử dụng đã chiến thắng, của Pete Herlihy
• Đây là những gì chúng ta ngụ ý khi chúng ta nói “biến đổi dịch vụ”, của Mike Bracken

5. Lặp lại. Lặp đi lặp lại lần nữa

Cách tốt nhất để xây dựng các dịch vụ tốt là bắt đầu nhỏ và lặp đi lặp lại nhiều lần. Hãy phát hành tối thiểu các sản phẩm trụ vững được sớm, kiểm thử chúng với những người sử dụng thực sự, chuyển từ Alpha sang Beta

• Phát hiện các phát hiện, của Sarah Prag
• 6 trường hợp điển hình sử dụng nghiên cứu và dữ liệu để cải thiện một dịch vụ sống động, của Ben Holliday
• Các bản mẫu làm ra các ví dụ của bản thân chúng, của Mike Bracken

6. Đây là cho tất cả mọi người

Thiết kế truy cập được là thiết kế tốt. Mọi điều chúng ta xây dựng nên là toàn diện, hợp pháp và có khả năng đọc được có thể. Nếu chúng ta phải hy sinh sự thanh lịch - hãy làm thế. Chúng ta đang xây dựng vì các nhu cầu, không vì các khán thính phòng. Chúng ta đang thiết kế cho cả nước, không chỉ cho những ai quen sử dụng web. Những người cần nhất các dịch vụ của chúng ta thường là những người thấy chúng khó nhất để sử dụng. Hãy nghĩ về họ từ đầu.

• Chúng ta ngụ ý gì khi chúng ta nói về khả năng truy cập, của Alistair Duggin
• Cân nhắc dãy những người sẽ sử dụng sản phẩm hoặc dịch vụ của bạn, của Alistair Duggin
• Hy vọng, truyền cảm hứng và tham gia toàn diện, của Steven Mark
• Xây dựng vì sự tham gia toàn diện, của Léonie Watson

7. Hiểu ngữ cảnh

Chúng ta không thiết kế cho màn hình chúng ta đang thiết kế cho mọi người. Chúng ta cần nghĩ cật lực về ngữ cảnh ở đó họ đang sử dụng các dịch vụ của chúng ta. Họ ở trong một thư viện ư? Họ làm việc với điện thoại ư? Họ thực sự chỉ quen với Facebook ư? Họ chưa từng sử dụng web trước đó ư?

• Chúng ta đã tuyển người như thế nào với các kỹ năng thấp/không phải số về Phân bổ sự Chăm sóc, của Simon Hurst
• Đúng chỗ để làm nghiên cứu về nông thôn, của Emily Ball

8. Xây dựng các dịch vụ số, chứ không phải các website

Một dịch vụ đôi khi giúp được mọi người làm thứ gì đó. Công việc của chúng ta là phát hiện ra các nhu cầu của người sử dụng, và xây dựng dịch vụ đáp ứng được các nhu cầu đó. Tất nhiên nhiều dịch vụ đó sẽ là các trang trên web, nhưng chúng ta không ở đây để xây dựng các website. Thế giới số phải kết nối với thế giới thực, nên chúng ta phải nghĩ về tất cả các khía cạnh của dịch vụ, và chắc chắn chúng bổ sung thêm thứ gì đó đáp ứng được các nhu cầu của người sử dụng.

• Lãnh đạo số, của Kit Collingwood-Richardson
• Hé lộ phía ẩn dấu của sự biến đổi, của Mike Bracken
• Không phải HMRC cũ , của Mike Bracken

9. Hãy nhất quán, chứ không phải đồng nhất

Chúng ta nên sử dụng ngôn ngữ y hệt và mẫu thiết kế y hệt bất kỳ khi nào có thể. Điều này giúp cho mọi người quen thuộc được với các dịch vụ của chúng ta, nhưng khi điều này là không thể thì chúng ta nên chắc chắn tiếp cận của chúng ta là nhất quán.

Đây không phải là sự trói tay trói chân hay sách quy định. Từng hoàn cảnh là khác nhau. Khi chúng ta thấy các mẫu làm việc được thì chúng ta nên chia sẻ chúng, và nói về việc vì sao chúng ta sử dụng chúng. Nhưng điều đó không dừng được chúng ta khỏi việc cải thiện hoặc thay đổi chúng trong tương lai khi chúng ta thấy các cách làm tốt hơn hoặc các nhu cầu của những người sử dụng thay đổi.

• Tấm vọc các mẫu thiết kế của GOV.UK
• Đâu là quy trình thiết kế ở GDS? của Ben Terrett

10. Hãy làm cho mọi điều là mở: Nó làm cho mọi điều tốt hơn

Chúng ta nên chia sẻ những gì chúng ta đang làm bất cứ khi nào chúng ta có thể. Với các đồng nghiệp, với những người sử dụng, với thế giới. Hãy chia sẻ mã, chia sẻ các thiết kế, chia sẻ các ý tưởng, chia sẻ các ý định, chia sẻ sự thất bại. Càng nhiều con mắt ở đó xem một dịch vụ thì nó sẽ càng tốt hơn - các lỗi sẽ được nắm bắt, các lựa chọn thay thế tốt hơn được chỉ ra, tiêu chuẩn được nâng cao.

Nhiều những gì chúng ta đang làm chỉ có khả năng vì mã nguồn mở và sự hào phóng của cộng đồng thiết kế web. Chúng ta nên trả lại.

• GDS, USDS, và chia sẻ sự tinh thông, của Mike Bracken
• Sự chia sẻ giúp chúng ta cải thiện các dịch vụ số như thế nào, của Mike Bracken

Listed below are our design principles and examples of how we’ve used them so far.

1. Start with user 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 remember that what they ask for isn’t always what they need.
   • What we mean when we say “service transformation”, by Mike Bracken
   • Most of government is mostly service design most of the time, by Matt Edgar
   • Vertical campfires: our user research walls, by Kate Towsey
2. Do 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.
   • Building digital civic infrastructure from the ground up, by Mike Bracken
   • What we’ve learned about scaling agile, by Jamie Arnold
3. Design 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. Keep doing that after taking your service live, prototyping and testing with users then iterating in response. Analytics should be built-in, always on and easy to read. They’re an essential tool.
   • Performance data for government services
   • Retiring our icons, by Guy Moorhouse
   • Combining user research and analytics to improve the user experience, by Lana Gibson and Charlotte Clancy
4. Do 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.
   • Doing the hard work to make things simple, by Mike Bracken
   • I fought the law and the users won, by Pete Herlihy
   • This is what we mean when we say “service transformation”, by Mike Bracken
5. Iterate. 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.
   • Discovering discovery, by Sarah Prag
   • 6 case studies using research and data to improve a live service, by Ben Holliday
   • Exemplars making examples of themselves, by Mike Bracken
6. This 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.
   • What we mean when we talk about accessibility, by Alistair Duggin
   • Consider the range of people that will use your product or service, by Alistair Duggin
   • Hope, inspiration and inclusion, by Steven Mark
   • Building for inclusion, by Léonie Watson
7. Understand 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?
   • How we recruited people with low/no digital skills on Carer's Allowance, by Simon Hurst
   • The right place to do rural research, by Emily Ball
8. Build 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.
   • Digital leadership, by Kit Collingwood-Richardson
   • Revealing the hidden side of transformation, by Mike Bracken
   • Not the HMRC of old, by Mike Bracken
9. Be 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.
   • The GOV.UK Design Patterns Hackpad
   • What’s the design process at GDS? by Ben Terrett
10. Make things open: it makes things better
    We 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.
    • GDS, USDS, and sharing expertise, by Mike Bracken
    • How sharing helps us improve digital services, by Mike Bracken

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com