Poster_DesignPrinciples-ja

KO | EN

gitlite — search

#hacktoberfest #react #ai #android #deep-learning #docker #nodejs #windows #awesome #awesome-list #security #mcp #openai #open-source

Poster_DesignPrinciples-ja

(★ 8)

イギリス政府のデジタルサービスにおけるデザイン原則。Japanese version of GOV.UK Design Principle Poster

Poster_DesignPrinciples-ja 최신버젼 다운로드

최종 버전 다운로드 (.zip)

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

# Poster_DesignPrinciples-ja
Japanese version of GOV.UK Design Principle Poster

# 1. ニーズからはじめる
サービスデザインはユーザーニーズの特定からはじまります。ユーザーが誰なのか分からなければ、正しくつくることはできません。リサーチをし、データを分析し、ユーザーと話をしましょう。推測はしない。ユーザーに共感を持ち、彼らが「欲しいと言もの」と「実際に必要とするもの」は違うとことも注意しましょう。

# 2. より少なく
政府は政府でしかできないことだけをするべきです。何かできることがわかったら、再利用できるよう、共有できるようにするべきです。毎回「車輪の再発明」は必要ありません。つまり、プラットフォームを作ること、APIなど外部の組織や個人が使えるものを提供することです。私たちはこれ以上減らすことができないコアに集中すべきです。

# 3. データからデザインする
多くの場合、私たちは実際のユーザーがどのように既存システムを利用しているか見ることで学ぶことができます。人の感や推測ではなく、データに判断をさせましょう。サービスがライブになってから、プロトタイピング、ユーザーテストの後も継続的にデータを取りましょう。そうすることでイタレーション（反復）することができます。分析は組み込まれている必要があります。常にデータが取れ、簡単である必要があります。必須ツールです。

# 4. シンプルにするためにハードワークをする
見た目をシンプルにするのは簡単です。シンプルに使えるようにするのはもっと難しいです、特にそれを実現するシステムが複雑な場合は。しかし、それが政府としてやらなければいけないことです。「これまでそうだった」を質問の答えとして受け入れないように。シンプルにするのはハードワークが必要ですが、それが正しいことなのです。

# 5. 反復、そして反復
良いサービスを作る最良の方法は小さく作ってワイルドに反復して改善することです。初期からMVPをリリースして実際のユーザーとテストしましょう。アルファ、ベータ、ライブに移行するごとに機能を追加したり動かない機能を削除します。これはフィードバックからの改善によるものです。反復はリスクを削減します。大失敗を回避することを助け、小さな失敗を学びとします。プロトタイプがうまくいかない場合、それを捨てて新しくスタートすることを恐れないように。

# 6. 全ての人のために
誰でも使えるデザインはよいデザインです。私たちが作る全ては包含的、わかりやすく、読みやすくなければいけません。もしそのためにエレガンスを捨てなければいけないのであれば、捨てましょう。私たちはニーズを満たすサービスを作っています。私たちは国全体のために作っています、Webを使い慣れた人だけではなく。そのサービスを最も必要とする人は最もWebから離れた人なのかもしれません。そういう人たちを最初から考慮に入れましょう。

# 7. コンテキストを理解する
私たちはスクリーンのためにデザインをしているのではなく、人のためにデザインをしています。その人たちが私たちのサービスを利用する背景をよく理解しなければいけません。彼らは図書館にいるのでしょうか？電話を使ってるのでしょうか？Facebookしか使わないのでしょうか？そもそもWebを使ったことがあるのでしょうか？

# 8. Webサイトではなくデジタルサービスを作る
サービスとは誰かが何かをする助けとなるものです。私たちの仕事はユーザーのニーズを表面化し、そのニーズを満たすものを作ることです。もちろん、その多くはWebページかもしれません。しかし私たちはWebサイトを作っているのではありません。デジタルの世界はリアルな世界と繋がらなければいけません。ユーザーニーズを満たすために私たちはサービスの全ての側面について考えないといけません。

# 9. 統一性ではなく一貫性
私は同じデザイン言語と同じデザインパターンをできる限り使うわなければいけません。これにより人とサービスとの距離を近づけます。もしそれが難しい場合は少なくともそのアプローチに一貫性があることを持たせなければいけません。

これは拘束衣やルールブックではありません。様々な状況が考えられます。良いパターンがあれば共有すべきで、なぜそれを使うべきか議論すべきです。しかし、それが将来の改善の妨げになるようにしてはいけません。

# 10. オープンにする。ベターにつながる。
私たちのしていることを可能な限り共有しなければいけません。同僚と、ユーザーと、そして世界と。コード、デザイン、アイデア、意図、そして失敗を。サービスにより多くの目が向けられるほど、そのサービスは改善されます。叫んでいる人を見つけ、より良い代替案が指摘され、水準が上がります。

私たちのしている多くはオープンソースやデザインコミュニティーの善意がなければなし得ないものです。そこに参加して私たちも貢献しなければいけません。

# 日本語訳について
デザイン原則について一つだけ注意点。デザイン原則はプロジェクトごとに作られるべきです。GOV.UKのデザイン原則は公共サービスのコンテキストをもとに作られています。このデザイン原則を自分たちがそのまま採用しても意味がありません。そのような意図でこの日本語版は作られていません。

クルマの自動運転にはクルマの自動運転のデザイン原則が必要ですし、公共交通機関にはそのコンテキストにあったデザイン原則が必要です。それでも、このGOV.UKは基本的なデザイン原則が多く含まれているため、自分たちのデザイン原則と比べてると色々な発見があるかもしれません。日本語版の作成意図はそんなところにあります。

デザイン原則の作り方はアメリカ政府機関の18Fが作成した”18F Method Cards”でも紹介されています。[18Fメソッドカード日本語版](https://github.com/and-design/f18-method-cards "18Fメソッドカード日本語版")はこちら。

Poster_DesignPrinciples-ja

Poster_DesignPrinciples-ja 최신버젼 다운로드

오늘의 추천 프로젝트

Was this content helpful?

Recent Feedback

Poster_DesignPrinciples-ja

Poster_DesignPrinciples-ja 최신버젼 다운로드

오늘의 추천 프로젝트

Was this content helpful?

Recent Feedback

Download README