英国政府が「デザイン原則（Design Principles）」というものを提示しています。
https://www.gov.uk/guidance/government-design-principles
英国政府公式サイト（GOV.UK）の指標を示したものであり、あくまでも政府による政府のための指標です。ゆえに、公共性を強く意識した指標であることを認識した上で読む必要がありますが、WEB制作をはじめとする、あらゆるデジタルコンテンツ制作に生かすことができると思います。
筆者自身も、ここ10年ほど中心的な指標にしており、時折読み返すようにしています。とくに、制作後に「ま、これくらいでいいかな」と思ったときなどは、必ず再読するようにしています。
「デジタル・デザインの指標」と言いつつも、言い回しから根底の思想まで、実に英国らしさ全開とも言える内容であり、読み込むほどおもしろいです。
なお、訳文はすべて当記事の筆者（竹谷）によるものです。英国政府が公式提供するものではありません。
【目次 / Contents】
- Start with user 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 （ウェブサイトをつくるのではなく、デジタルサービスをつくる）
- Be consistent, not uniform（画一的ではなく、一貫性を持たせる）
- Make things open: it makes things better（物事をオープンにすること：それは物事をより良くする）
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.
サービスデザインは、ユーザーニーズの把握から始まります。ユーザーのニーズが分からなければ、適切なものを作ることはできません。リサーチ、データ分析、ユーザーとの対話を行いましょう。思い込みは禁物です。ユーザーに共感しつつも、ユーザーが求めているものが必ずしも必要なものではないことを忘れてはいけません。
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など）を提供し、他の人の仕事にリンクすることを意味します。私たちは、還元不可能な核（コア）となる部分に集中すべきです。
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.
多くの場合、既存のサービスがどのように利用されているかを見ることで、現実の行動から学ぶことができます。勘や当てずっぽうなやり方ではなく、データに基づいて意思決定を行ってみるとよいでしょう。サービスを開始した後も、ユーザーと一緒にプロトタイプを作成してテストし、それに応じて反復していきましょう。アナリティクスは内蔵され、常に表示され、読みやすいものでなければなりません。アナリティクスは必要不可欠なツールです。
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.
何かをシンプルに見せるのは簡単です。しかし、使いやすいものを作ることははるかに難しく、特に基本的なシステムが複雑な場合はなおさらです。「昔からこうだった」という言葉を鵜呑みにしてはいけません。物事をシンプルにすることは、たいてい、より多くの困難な作業を伴いますが、それは正しいことなのです。
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.
良いサービスを作るには、小さく始めて激しく繰り返すのが一番です。最小限の実行可能なプロダクトを早期にリリースし、実際のユーザーでテストし、アルファ版、ベータ版、本番版と、機能を追加したり、機能しないものを削除したり、フィードバックに基づいて改良を加えていきます。反復することは、リスクを減らすことにつながります。大きな失敗をすることなく、小さな失敗を教訓に変えることができます。プロトタイプがうまくいかない場合は、恐れずに破棄してやり直しましょう。
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.
利用しやすいデザインは、すなわち良いデザインです。私たちが作るものはすべて、可能な限り包括的で読みやすく、可読性の高いものでなければなりません。エレガントさを犠牲にしなければならないとしても、それはそれでいいのです。私たちは観客のためではなく、ニーズのために建築しています。ウェブに慣れている人たちだけでなく、国全体のためにデザインしているのです。私たちのサービスを最も必要としている人たちは、往々にして最も使いにくいと感じているものです。最初からその人たちのことを考えましょう。
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?
私たちはスクリーンのためにデザインしているのではなく、人間のためにデザインしているのです。私たちは、利用者がどのような状況で私たちのサービスを利用しているのかをよく考える必要があります。利用者は図書館にいるのでしょうか？携帯電話を使っているのでしょうか？フェイスブックしか知らないのでしょうか？今までウェブを使ったことがないのでしょうか？
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.
サービスとは、人が何かをするときに役立つものです。私たちの仕事は、ユーザーのニーズを掘り起こし、そのニーズに合ったサービスを構築することです。もちろん、その多くはウェブ上のページになりますが、私たちはウェブサイトを作るのが仕事ではありません。デジタルの世界は現実の世界とつながっていなければならないので、サービスのあらゆる側面を考え、それらが組み合わさってユーザーのニーズを満たすものになるようにしなければなりません。
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.
私たちは、自分がやっていることを可能な限り共有すべきです。同僚と、ユーザーと、そして、世界と。コードの共有、デザインの共有、アイデアの共有、意図の共有、失敗の共有。より多くの人がサービスを見れば見るほど、サービスはより良くなります。「ハウリング」が発見され、より良い代替案が指摘され、ハードルが上がります。
私たちがやっていることの多くは、オープンソースコードとウェブデザインコミュニティの寛大さによって可能になっています。私たちはその恩返しをしなければなりません。
引用に関する表記: References in this article
この記事内における引用箇所は、英国政府が掲げるオープンガバメントライセンスに基づき引用しています。This article is quoted under the UK Government’s Open Government Licence.
Thumbnail Photo by Kate Krivanec on Unsplash Thank you.
