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.
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.
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
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
Chúng ta ngụ ý gì khi chúng ta nói “biến đổi dịch vụ”, của Mike Bracken
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.
Những gì chúng ta đã học được về mở rộng phạm vi lanh lẹ, của Jamie Arnold
Xây dựng hạ tầng dân sự số từ nền lên, của Mike Bracken
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.
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
Bỏ đi các biểu tượng của chúng ta, của Guy Moorhouse
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.
Đâ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
Tôi đấu tranh với luật và những người sử dụng đã chiến thắng, của Pete Herlihy
Làm việc cật lực để làm cho mọi điều đơn giản, của Mike Bracken
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
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 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
Phát hiện các phát hiện, của Sarah Prag
Đâ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.
Xây dựng vì sự tham gia toàn diện, của Léonie Watson
Hy vọng, truyền cảm hứng và tham gia toàn diện, của Steven Mark
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
Chúng ta ngụ ý gì khi chúng ta nói về khả năng truy cập, của Alistair Duggin
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 đó ư?
Đúng chỗ để làm nghiên cứu về nông thôn, của Emily Ball
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
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.
Không phải HMRC cũ , của Mike Bracken
Hé lộ phía ẩn dấu của sự biến đổi, của Mike Bracken
Lãnh đạo số, của Kit Collingwood-Richardson
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.
Đâu là quy trình thiết kế ở GDS? của Ben Terrett
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.
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
GDS, USDS, và chia sẻ sự tinh thông, của Mike Bracken
Listed below are our design principles and examples of how we’ve used them so far.
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
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
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.
Retiring our icons, by Guy Moorhouse
Combining user research and analytics to improve the user experience, by Lana Gibson and Charlotte Clancy
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
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
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
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
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
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.
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
Ý kiến bạn đọc
Những tin mới hơn
Những tin cũ hơn
Blog này được chuyển đổi từ http://blog.yahoo.com/letrungnghia trên Yahoo Blog sang sử dụng NukeViet sau khi Yahoo Blog đóng cửa tại Việt Nam ngày 17/01/2013.Kể từ ngày 07/02/2013, thông tin trên Blog được cập nhật tiếp tục trở lại với sự hỗ trợ kỹ thuật và đặt chỗ hosting của nhóm phát triển...