シンプルなUIを実現するためにできること


僕は、シンプルで使いやすいデザインが好きだ。
多くのデザイナーも同じ考えだと思うけど、積み上げられた意見を反映した結果、シンプルとかけ離れたデザインになる事も多い。

デザインやディレクションを仕事にしていると、例えば

  • チームメンバー、同僚デザイナーからのインプットが多く、絞り込めず納得感を持たせるためにやむをえず盛ってしまう
  • 終盤で仕様漏れが発覚し、初期設計からズレるが時間が無く暫定対応になる
  • 偉い人の指摘で抜本見直しが必要だがスケジュールは変わらず中途半端になる

一度くらいこんな経験をしたことがあると思う。

後出しで要件が追加されると2歩後退してやり直すか、時間の猶予が無いと暫定的な突貫対応になるため本来の実力が出せず不本意な結果になる事も多い。
そのため、僕の場合は、予め情報を集める事に力を注ぎ、後々破綻しないディレクションをするように心がけている。

必要な情報をできるだけ早く集めきる

 

1. 競合調査、ステークホルダーの確認

新しくデザインする時、まずグラフィックツールを開くのではなく、情報収集から始める事が多い。

ステークホルダーと目的合意、競合サイトの調査、必要機能の要件洗い出しは当たり前のようにやるとして、関連部署から受けるであろう制約も同時に確認して、要件の抜け漏れを防止するようにしている。

例えば、ロゴ作成時は図形商標の取得プロセス、スケジュール感を把握するための部門と相談し、アプリUIの設計時は、利用規約の表示方法から個人情報の取扱い・コミュニケーション機能提供時の制約などを確認してUIに反映する。

その時、制約を越えてこだわるべき箇所は、『弊社の法務は厳しいからこのUIしょうがないんだよねー』と言う状況を起こさないように説得材料集めのタスクを積んでいく。

意思決定者も関連部門のポリシーを正確に把握していない事も多く、ITや法務、インフラ部門との調整が杜撰だと後々ボディブローのように効いて後退する事になるので、必ずミーティングに参加する or 自分で調整するようにしている。

終盤のステージング環境でツッコミを受けて突貫工事するのは何としても避けたいからだ。

 

2. 画面を見ながら要件をあぶり出す

一通りヒヤリングして要件が見えたら、数パターンデザイン案を作ってチームから意見を募る。この時、重要なのは荒い状態でもいいから早く相談する事、密室でやらずに全員にシェアする事。

一人で要件を洗い出したつもりでも、実際の画面を見て会話する事で抜け漏れや改善案が見えてくる事が多い。

若い時は指摘を受けるのが嫌で、最初から完璧な仕事を目指す抱え込むスタイルだったけど、早い段階で周りを巻き込んで設計した方が質が高くなる事に気づいてからは、Twitter感覚で、SlackにUI案をつぶやきながら作るようにしている。

作ったUI案をSlackに投下したら、エンジニアが数時間でプロトタイプを作ってくれた事があるんだけど、頭で考えるのと、形にして手で触って感じることのギャップは大きいので、設計段階でその感覚をキャッチボールできる環境は最高だと思う。

この前「とにかく雑に作れ」と言う記事を見たけど、まさにこんな感じで、雑っぴんぐする事で、答えが浮かび上がってくる事が多い。

中には抱え込み癖がついている人も居るので、Slackの分報という仕組みを採用して雑にシェアするカルチャーを醸成するのも一つの方法だと思う。

日報の弱点を補える「分報」とは
課題解決へのアクションが遅れてしまうという日報の弱点を克服するために、僕のチームでは「分報」という独自の取り組みをしている。分報ではSlackなどの社内チャットツールを使い、「今やっていること」や「困っていること」をつぶやく。課題をリアルタイムに共有できるのが特徴だ。日報が社内mixi日記だとすると、分報は社内Twitterにあたる。

 

3. ユーザーレビュー、ニーズ引き出し

「2」と並行して、ユーザーニーズを集める作業も実施していく。
この時点では、MVPとして製品評価の実施ではなく、情報収集を目的としたオープンなインタビューを行う事が重要だと思う。

  • デザイン案をみてもらい本質的なニーズを引き出す
  • 自分の感覚とユーザー感覚とのズレが無いか確認
  • オープンクエスチョンでアイディアを募る

テクニックの一つとして、複雑になりがちな入会遷移やフォーム周りのストレスチェックを実施して、関連部門との交渉材料もここで集めるようにしている。

例えば、ユーザー属性は取り敢えず取っておきたいマーケチーム向けに『ミスタップや入力項目が多いストレスで離脱ユーザーがこれだけ増える可能性ありますが、本当にこの属性全部必要ですか? ギリギリまで絞りません?』 と動画データをみせつつ交渉する事で項目を絞っていく事もできる。

 

4. 情報量の頂点

要件、制約、ユーザーニーズを出し切ったら、不必要な要素を排除し、本質的な情報に絞る引き算のデザインを始めていく。

僕は必要なければ、この時点までオリジナルのグラフィックは作らずに「UI8」「Sketch App Sources」「Shutterstock」などの素材を使って情報集めに徹する事が多い。

ここまでで大事なこと

  • チーム内外を巻き込んで意見を出し切っておく
  • 制約を把握する事で、後の設計破綻を防ぐ
  • グラフィックやアニメーションで悩まずに情報集めに徹する

 

5. 本番環境同等のプロトタイプレビューで最終チェック

テストは必ずユーザーが使うであろう同等の環境でチェックする事で、環境違いによる誤評価を防ぐようにしている。

利用想定が電車の中であれば、同じように電車の中で触り心地をチェックするし、Push通知がトリガーになるコンテンツの場合は、通知文言も最適化させた状態でチェックしていく。通信環境など実際ユーザーが触る環境でテストするともう一段階位改善する余地がでてくる事が多い。

例えば、スマートフォンAPPをPCのiOSシュミレータで評価することなどはしてはいけない。

 

6. デザインブラッシュアップ

ここまで来たらゴールはもうすぐ。
細かいアイコンやカラー調整などグラフィックを仕上げていく。

 

7. リリース & ガイドライン/デザインデータ整備

無事にリリースできた後は結果が出るのを待ちつつ、デザインガイドライン作りとデータ整備をしておく。
Twitterでエゴサーチをすると予想通りの反応が出ると嬉しくなるし、改善点も見えてくるので、チームにシェアしつつUIの改善案をだしてまだSlackに投下していく。

 

まとめ

これデザイナーの仕事?って思う人が多いかもしれないけど、シンプルで良質なUIデザインを実現したい場合、グラフィックよりもっと前の段階を調整する事で実現できることが多いのだけど、やり方がわからない人向けに書いてみました。良ければ参考になればと思います。

 

デザインの伝え方
デザインの伝え方

posted with amazlet at 17.02.28
Tom Greever
オライリージャパン
売り上げランキング: 30,094