本記事は以下記事の翻訳です。
記事の著者の一人である Mike Bracken は、「UK Government Digital Service（英国政府デジタルサービス）」の創設者の一人であるが、この記事での「Government」は議会や行政府だけでなく、国民にデジタル･サービスを提供する公的機関全体を指しており、公共サービスがより良く、より低コストで提供されるようにすることを目的としている。これらの原則は政府や公的機関が提供するデジタル･サービスだけにとどまらず、営利･非営利問わず様々な組織が提供するサービスの設計原則に当てはまる部分も多い。
特に明記されていない限り、すべてのコンテンツは「オープン政府ライセンス v3.0」の下で利用可能である。
Government Digital Service Design Principles
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.
これらは、我々の当初の「7つのデジタル原則」を基盤とし補完するものである。
上記「7 digital principles」はリンク切れのようである
- Start with needs
要求から始める - Do less
より小さく行う - Design with data
データによる設計 - Do the hard work to make it simple
単純にすることに尽力する - Iterate. Then iterate again.
反復する。そしてまた反復する - This is for everyone
すべての人々のために - Understand context
コンテキストの理解 - Build digital services, not websites
Webサイトではなくデジタル･サービスを構築する - Be consistent, not uniform
画一的ではなく、一貫性を保つ - Make things open: it makes things better
オープンにせよ。それが物事をより良くする
1. Start 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.
サービスの設計はユーザーの要求を識別することから始めよう。ユーザーの要求をわかっていない場合、正しいものを構築できない。調査し、分析し、ユーザーと話をしよう。勝手な思い込みをやめよう。
- 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.
政府は政府にしかできないことだけを行うべきだ。効果的な手法を見出したなら、毎回車輪を再発明するのではなく、再利用可能かつ共有可能な形にすべきである。これは、他者が構築できる基盤や登録簿を整備し、他者が利用できるリソース（APIなど）を提供し、他者の成果と連携することを意味する。我々は本質的な中核業務に集中すべきである。
- 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.
アクセスが容易な設計は優れた設計である。我々が構築するものはすべて、可能な限り包括的で、読みやすく、理解しやすいものであるべきだ。洗練さを犠牲にせざるを得ないなら、そうしよう。我々は観客のためではなく、必要性のために構築している。Webの利用に慣れた人だけでなく、国全体のために設計しているのだ。我々のサービスを最も必要とする人々は、往々にしてその利用が最も困難だと感じる人々である。最初からそうした人々のことを考えよう。
- Building for inclusion, by Léonie Watson
- What are we doing about accessibility? by Joshua Marshall
- Here’s what we mean by “building for inclusion”, by Mike Bracken
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?
我々は画面のために設計しているのではなく、人のために設計している。ユーザーがサービスを利用する状況を深く考える必要がある。図書館にいるのか？ スマートフォンを使っているのか？ Facebookしか知らないのか？ Webを一度も使ったことがないのか？などを。
- 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
Webサイトではなくデジタル･サービスを構築する
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.
サービスとは、人々が何かを行うのを助けるものである。我々の仕事は、ユーザーのニーズを明らかにし、それらのニーズを満たすサービスを構築することである。もちろんその多くはWeb上のページになるが、我々はWebサイトを作るためにここにいるのではない。デジタル世界は現実世界と繋がっていなければならない。そのため、サービスのあらゆる側面を考え、それらが総合されてユーザーのニーズを満たすものになるよう保証する必要がある。
- 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.
（ただし）これは拘束衣でも規則集でもない。状況はそれぞれ異なる。効果的な手法を見つけたら共有し、その理由を話し合うべきである。しかし、より良い方法が見つかったり、ユーザーのニーズが変わったりした時には、将来的にそれらを改善したり変更したりすることを妨げるものであってはならない。
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.
我々の取り組みの多くは、オープンソース･コードとWebデザイン･コミュニティの寛大さによって初めて可能となっている。その恩恵に報いるべきだ。
- GDS, USDS, and sharing expertise, by Mike Bracken
- How sharing helps us improve digital services, by Mike Bracken