じぶんのUIデザイン原則
デザイン原則とは
最近、多くの企業やプロダクト・サービスが「デザイン原則」を公開するようになってきました。
「自分たちが良いと考えているデザイン」を明文化したものですが、たとえば“Cheerful, Fresh, Speedy”（適当です）のような数個のワードに集約して並べたような、企業やブランドの「理念」や「行動指針」により近いような抽象的なものをよく見かけます。
それだけ“デザイン”が担うものが拡大し、“デザイン経営”の考えかたや価値観が浸透してきているあらわれなのかもしれません。
何にどう役立てようとするかで、必要な抽象度が変わってくるとも言えそうです。“デザイン”が持ち合わせている戦略性の理解が進み、ビジネスの根幹に組み込まれていくことが広まっているのを考えればそれも当たり前といえます。
またそれとは別に、「デザイン原則」で検索してみると、「近接／整列／対比／反復」といった、効果的な伝達のためのレイアウトやタイポグラフィなどの基本的なデザイン理論やテクニックについて解説したものも見つかります。
ちょっと目線の高さや粒度がまちまちなので混乱しますが、この記事ではソフトウェアやアプリケーションのUIのデザイン実務の現場でよりどころとなる実用的な経験則という意味合いで扱おうと思います。
わざわざ決める必要があるソフトウェアのUIのデザイン
ソフトウェアのUIのデザインは、リアルな物体としての道具のデザインがその材質の特性やサイズや質量といった物理的な制約を受けるのにくらべ、そもそも意図的にデザインする比重が大きいと言えます。
例えば大工道具の金槌（ハンマー）をデザインするとしたら、釘を打ち込む部分、持ち手となる部分、てこの原理を活かしてつたえる力を最大にするための適切なバランスなど、物理法則からおのずと導き出されてくる部分が大きいです。そしてその物理法則に裏打ちされた“見た目”も「ここを持つんだな」「こう振り下ろすんだろうな」「ここを釘に当てるんだな」と自然に感じ取ることができます。
対して、ソフトウェアのUIのデザインは、ボタン一つとっても「押せそう」な感じを出すために、さまざまなことをわざわざ決めてあげる必要があります。そしてそれは、止まってそこにあるときの見た目の話だけではありません。
Lee&Morayによる信頼の4つの次元
1. 基礎： 自然界を支配する法則や社会の秩序に合致している
2. 能力： 終始一貫して安定的かつ望ましい行動や性能が期待できる
3. 方法： 行動を実現するための方法、アルゴリズム、ルールが理解できる
4. 目的： 上記の背後にある意図、動機が納得できる
釘が撃ち込まれていく感触を、跳ね返る力を、身体的に直接感じ取ることができる金槌とは違い、スクリーンのボタンは、押すとき、押している間、押したあと、そのアクションの最中のすべてにおいて、操作の実感をどう与えるかをいちいち決めなくてはいけないのです。（じつは「押す」という言葉も、ホントに物理的に押し込んでいるわけではないのに、操作の実感を補完するために概念的に利用していると言えます）
でも、もともとなんの制約もなくどうとでもできてしまう世界。どのようにすれば違和感なく「こうさわったらこう動くはずだろう」という期待に応え、アクションがきちんと受け付けられたと感じ、安心して使えるUIとなるのでしょうか。さらには、金槌のようなシンプルな道具ではなく、立体的・重層的な構造を持ち、複数の目的に応えるもののデザインとして、どうしたらいいのでしょうか。
そういった特性を背景に、先人たちがマン・マシーンインターフェースを研究してきた歴史があります。そして、それをもとに合目的性の高いデザインを実現するための経験則としていろいろなデザイン原則（design principles）を残してくれています。人の認知的身体的特性に適応させることや、標準化されて一般に学習が進んでいる方式を踏襲することが重要とされます。
いくつか代表的なものを紹介したいと思います。
代表的なデザイン原則
Shneidermanの「8つの黄金律」
対話型システムのインタラクションに関する原則
1. 一貫性を保つように努める （Strive for consistency.）
2. ヘビーユーザーが操作をショートカットできる手段を用意しておく （Enable frequent users to use shortcuts. ）
3. 有用なフィードバックを提供する （Offer informative feedback.）
4. 完了感を与えるために、対話をデザインする （Design dialog to yield closure.）
5. 簡単にエラーに対応できるしくみを提供する （Offer simple error handling.）
6. 簡単にやり直しできるようにする （Permit easy reversal of actions.）
7. 内部の動きが把握できるようにする （Support internal locus of control.）
8.人間の短期記憶の負担を減らす （Reduce short-term memory load.）
Ben Shneiderman氏（1947年8月21日生まれ）は、アメリカのコンピュータ科学者、メリーランド大学 Human-Computer Interaction Lab.の教授。
オリジナルのリストは1986年に発表。CUIの対話型システムのインタラクションデザインに関する原則です。
Normanの「ユーザー中心設計の7原則」
マンマシンインターフェース全般に対する設計の原則
1. 外界にある知識と頭の中にある知識の両者を利用する （Use knowledge in the real world and in the head）
2. 作業の構造を単純化する （Simplify the structure of tasks）
3. 対象を目に見えるようにして、どのようにタスクが実行され、どのような結果になるのかを評価できるようにする （Make things visible）
4. 対応づけを正しくする （Get the mappings right）
5. 自然の制約や人工的な制約などの制約の力を活用する （Exploit the power of constraints）
6. エラーに備えたデザインをする （Design for error）
以上のすべてがうまくいかないときには標準化をする （When all else fails, standardize）
1988年「誰のためのデザイン？―認知科学者のデザイン原論」にて紹介。GUIにとどまらず、マン・マシーン・インターフェースに適用できるルールとして、初版から25年経った現在も多くの人に参照されています。
Nielsenの「10のヒューリスティック評価」
特定のシステムを対象としたユーザビリティ原則によらない普遍的な経験則
1. システム状態の視認性を高める （Visibility of system status）
2. 実環境に合ったシステムを構築する （Match between system and the real world）
3. ユーザーにコントロールの主導権と自由度を与える （User control and freedom）
4. 一貫性と標準化を保持する （Consistency and standards）
5. エラーの発生を事前に防止する （Error prevention）
6. 記憶しなくても、見ればわかるようなデザインを行う （Recognition rather than recall）
7. 柔軟性と効率性を持たせる （Flexibility and efficiency of use）
8. 最小限で美しいデザインを施す （Aesthetic and minimalist design）
9. ユーザーがエラーを認識、診断、回復することをサポートする （Help users recognize, diagnose, and recover from errors）
10. ヘルプとマニュアルを用意する （Help and documentation）
Webが誕生した直後のころ1994年に、特定のシステムを対象としたユーザビリティ原則によらない、普遍的な経験則としてまとめられました。
アストロラボのUIデザイン原則
このように有名なデザイン原則はいくつもありますが、自社の事業内容によってより重視するもの、そんなに気にする必要のないものもあったりするので、自分たち用に整理したUIデザイン原則を作ってみるといいのでは、ということで、アストロラボでは紹介したようなデザイン原則もふまえて自社のUIデザイン原則をつくりました。
UIをデザインする際に参照できるよう、自社のUIデザインライブラリーの中のガイドラインドキュメントに以下のUIデザイン原則を掲載しています。
1. シンプルに
2. 移動距離は常に短く
3. 記憶に頼らない
4. 寛容性を持つ
5. 適切なフィードバック
6. 一貫性を保つ
7. よい見た目にする
8. 実際のコンテンツを使う
1. シンプルに
「つねにシンプルに。小難しくするな」
人間がいちどに認識し処理できる情報量には限界があります。
無駄な情報に埋もれてしまえば、視界の中で必要な情報を探し拾うのが難しくなるでしょう。
ユーザーに必要な情報のみ必要なタイミングで触れるように段階的な表示を制御したり、ユーザーの概念モデルや共通認識を利用して標準化・自動化したりすることで、表示と操作を単純化します。
シンプルであることは、認知的な負荷を減らし、快適な操作体験とシステムへの理解をもたらします。
シンプルな設計のロシアのソユーズロケットが比較的信頼性が高く、1960年代から現在にいたるまで使われつづけているのに対し、「（250万個もの部品を使い）人類がこれまでに製造した中で最も複雑な機械」などと言われている米国のスペースシャトルが信頼性が比較的低く、事故を何度も起こし、死者も多数出し、5機中2機を失い、保守費用が巨大化し、2011年に廃止になってしまったという話は、シンプルさの重要性について示唆的です。
2. 移動距離は常に短く
ユーザーの行動についてもシンプルに。無駄なく効率的なものとなるようにアクションの順序や経路を設計します。
最初から必ずしも必要でない情報の入力はいちどに求めず、必要となった時点で追加できるようにして、まずは気軽にフローを開始してもらう
いったん先まで進ませておいてからあとで何かが足りないと出発地点まで連れ戻すような事態にならないようきちんと分岐と条件を整理しておく、必要なものや制限を予告しておく
フローの中断がユーザーに深刻な被害をもたらさない限りはいつでも途中で離脱できるように（たくさんのデータを取り扱う業務システムでは一度に完了せず、一時保存なども）
そもそもフローの開始前にユーザーを適切なスタート地点に連れていくことも大切。大多数のユーザーにとって開始時の動作が決まっているのなら、スクロール位置や表示の状態、登録済の値の保持や初期値、初めに入力するコントロールへのフォーカスなど、ユーザーがすぐに取り掛かれる状態で画面がロードされるように。ひとつのフローを終えた後の次の動作も同様で、前のフローの完了後、次のフローに最もとりかかりやすい状態に自動で遷移するようにする
3. 記憶に頼らない
人の記憶には量の面でも精密さの面でも限界があります。
ユーザーに何かを正確に思い出してもらうことを期待するよりも、認識可能な要素を示すほうが高いユーザビリティとスムーズな操作体験を実現できると言えます。
ユーザーの持つ記憶や知識を頼りに、正確な入力や段取りを求めるようなことをしない
システムの利用中にもユーザーの短期記憶を試すような負担をかけない例）「前の画面で表示されていたコードを入力してください」
駅にある切符の券売機。最近は特に観光客向けに路線図マップからタッチパネルで行き先を選んで購入できるものも登場していますが、以前からあるものは券売機では金額を選択するようになっていました。頭上に掲示された大きな路線図で行き先の駅のところに書かれた金額を確認して記憶してから券売機のUIの前に臨むことになります。
あるいは店舗の名前。例えば、存在しないが複数の似たような名前がある「大手町タワースクウェア店」と入力されたとしたら、どの店舗のことをさすつもりだったのかわかるでしょうか。
4. 寛容性を持つ
たまにこのような入力を見かけることがあります。
郵便番号はハイフンなしの半角
住所内の英数字は全角
電話番号はハイフンありの半角
システム側が規定した形式や順序に合わせることを求めるのではなく、可能な限りユーザーの通常ありうる自然な行動や入力を受け付けます。システム側で適切に変換するようにして、ユーザーに考えさせたり不要な負荷をかけないようにします。
こうしたユーザーの人間らしい行動に寛容性を持つことは、エラーの発生やCVR（コンバージョンレート）にも大きく関係します。
5. 適切なフィードバック
操作の直前に操作を助ける情報と、ユーザーの操作の結果起きたこと、現在の状態についての情報の提示がフィードバックです。
ユーザーが意識しているアクションの単位だけでなく、ロールオーバーやフォーカス、クリック、ドラッグ、ドロップなど細かな分解されたひとつひとつの操作についての反応もまた次の操作のためのフィードバックとしてはたらき、ひとつの大きな操作のためのフィードバックを構成しています。
フィードバックが、音や見た目の変化、アニメーションやメッセージなどにより適切なタイミングで逐一伝えられることで、ユーザーはシステムとの対話に安心感、システムを信頼して満足度が高くなります。
また、適切なフィードバックは操作ミスを減らすことにもつながります。
例えば、ボタンの連打が起こりやすいとしたら、1度目のボタンクリック後にボタンを無効（disable）化、受付して処理中であることをローダーやメッセージで表示することで、「自分のアクションはシステムに受け付けられているのだろうか」という不安を解消し、連打を防止することができます。（そもそも裏側のつくりとして連打でのアクション実行を受け付けないのももちろんです）
6. 一貫性を保つ
同じ意味や機能を持つものは同じように、配色、形状、配置、ふるまいなどに一貫したルールを適用します。
システム内での一貫性だけでなく、対象ユーザーが慣れ親しんでいる他の一般的なシステムや社会的な慣習などとも一貫性を持たせるようにします。
システム外の外部知識や共通認識を利用できるため、説明を省きシンプルにできるとともに、よりユーザーの自然な期待に応え、予測や学習を助けることができます。
たとえば配色、UIのカラーシステムなども、一般的な共通認識と揃えたほうがよいものです。
赤は普遍的に警告色として危険を表します。おそらく人間の血液が赤いためでしょう。信号も赤は「とまれ」です。UIではエラーや、破壊的なアクションの実行前の警告を示すシステム機能色のひとつとして扱われることが多いです。
余談ですが、中国でかつて「信号の赤を“進め”にしよう」という運動があったそうです。1960～70年代にかけて起こった文化大革命のなかで「”紅”衛兵（こうえいへい）」が提唱しました。
「赤は革命の色。停止ではなく、前進にこそふさわしい」という理由だとか。実際には実施されなかったとのことです。
ただ、日本企業も赤をコーポレートカラーに赤を採用しているところも多いので、地味に笑えないケースも。システムのUIにもコーポレートカラーを反映したいと考えたときに、システム機能色とは区別して考え、バランスが取れるようにする必要があるでしょう。
7. よい見た目にする
動きや間も（あるいは音も）含めたふるまいとして、ここちよく美しく感じられる“見た目”は、審美的なことだけにとどまるものではありません。
単に肯定的な感情を持って作業を遂行するほうがパフォーマンスが高い、という観点においても、よい見た目であるということは重要な意味があります。（対してネガティブな感情の時は広がりよりも深さ—ささいな粗探しに注意が向くといわれています）
UIは、人々がそれを喜んでつかうとき、実際に一段と便利になるということです。ユーザーの体験を支える高い「利用品質」は、当然ながらよい見た目なしに実現できるものではないといえます。
8.デザインには実際のコンテンツを使う
すこし他のものと毛色が違いますが、とくに業務システムのUIデザインで大事なのがこちらです。
実際に使用されるデータとはほど遠い仮のテキストや画像ではなく、実データまたは実データから要秘匿部分を調整したデータをデザイン過程でも流し込んで、設計時の判断の材料としていくことがけっこう重要です。
最大／最小情報量のときの表示領域の整合性やサイズ設計
妥当なUIコントロールパーツの選択
情報の性質に合わせた順序・関連性・重要性の情報デザイン
情報の形式に合わせた適切な制限の設定
ユーザーの文脈に合わせた開示の制御
見た目のバランス など
UIの使い勝手は、実際のものに限りなく近いデータが入っていてこそ判断が可能なものも多いです。また、開発時においても、いいかげんなダミーデータのせいでデータベースからの参照のバグに気づかないといったケースもあったりします。
以上です。こうしたUIデザイン原則を決めておくことで、デザイナーだけでなくプロジェクトやプロダクトのマネージャー、開発担当者と目線を揃えておくのに役立つのではないでしょうか。
この記事が気に入ったらサポートをしてみませんか？