所属している開発組織の中で、ここ1~2年でチームの人数が増えたこともありデザインガイドラインの重要性が増してきた。
それのメモ。思考の吐き出し。
ここでいうデザインガイドラインは、material designでいう「Introduction」みたいな、思想や方針を示しているもの。TypographyやColorやコンポーネントとかのシステムは含まない。

課題

プロダクトデザインの方向性、方針、軸となるものが不明瞭な現状。
体験やその優先度などの一貫性が失われないように、チームとして意識していきたい。
かといって決裁フローなどが増えてスピード感を落としたくはない。

打ち手

デザインガイドラインの普及により、みんなでデザインの方針をインストールしていきたい。

どんな方針？
作ってるデザインガイドラインの原則のごく一部をメモメモ。↓↓↓

カスタマイズよりもパーソナライズ

ユーザーが作業(カスタマイズ、選択)せずとも、最適な状態になっていることを理想とする。

洗練された課題解決
「ユーザーの作業を減らす」という方針があれば、より一貫性のある明確な課題解決ができる。
仮に「ユーザーに選ばせようorユーザーに好きなように設定してもらおう」という方針になると、サービスの価値の大部分をユーザーに委ねることになってしまうのでは？という。それでも全然アリだとは思うが、ウチに関していうと、サービスとして提供する価値がブレやすくなると思っている。
この方針は、サービス開発の努力の方向性を明確にする。
課題や要望に対してユーザーの手間をかけずに解決させるのは難易度が高いが、難易度が高い理想形を一度考えて、それからブレークダウンして現実的な解決策を練る方がいいのではないか？的な。

例外的なカスタマイズの価値
ただし、ユーザーが作業(カスタマイズ、選択)すること自体に価値がある場合も存在する。ちゃんと見極めないといけない。
なんでもかんでも見た目上シンプルにしてタップ数を減らすことが正義ではない。決して、ない。

迷ったらシンプルに

ユーザーに提供する機能や情報は最低限必要なモノに絞る。
参考：あるとよい機能はない方がよい
一度提供した機能を削除するのは容易ではない。また、既にある機能の価値を守りながら新機能や新施策を開発するのは難易度が上がる。
つまり、機能が増えれば増えるほどプロダクトは肥大化し、スピードが遅くなり、提供したい価値が曖昧になる。

認知コスト
選択肢が多いと認知コストが高くなり、選択自体を諦めてしまう可能性すらある。ただし、選択肢を少なくすること自体を目的にしてはいけない。
参考：ジャムの法則
つまり、選択肢は少なければ少ないほどいいということではなく、最適な選択肢の数を設定することが大切。その「最適さ」は少ない方がよろしいケースの方が多そう、というだけのこと。
5つかもしれないし、1つかもしれない。
1つの場合、それはもはやシステムが自動処理するはず。

ブランディング
中長期的に「ごちゃごちゃしていて見づらいサービス」という印象を与えたくはない。
サービスに対する印象は目に見えて数値化されにくいが、だからこそ印象を育む努力を怠ってはいけない。

うむ。

これらをもう少し説得力と納得感のあるものに仕上げなければ。

チームのみんなにとって共感性が高くないと意味がない。
多くのチームメンバーがこのガイドラインを読んで、それぞれがガイドラインから生まれた議論や思考や解釈をして開発が行われる状態にしたい。そしてガイドラインのアップデートもチームによって行われるようにしたい。

ただ、ガイドラインからはみ出たアイデアや意見を除外するのは気持ちいい感じはしないので、そこも課題となりそう。むしろここのマインドもガイドラインにしてしまうかw