UIデザイン道・その2「UX Flow(画面遷移図)の重要性」
シリコンバレーのUXデザイン
以前モバイルOSの開発に携わったことがあり、シリコンバレーのUXデザインを体験する機会があった。
Spec Sheet(機能仕様書)、UX Flow(画面遷移図)、UI Component Sheet(ビジュアル要素定義書)の3つで、一つのプロダクトの設計図となる。ただ３つもドキュメントがあると、アップデートが大変である。
仕様が固まっていく、あるいはBug Fixしていく中でそれぞれのドキュメントを更新しなくてはいけないが、いずれかが追いつかなくなる。結果的にUX Flowがその全てを補完する存在となった。
UX Flowとは何か？
UX Flowを設計フェイズに用いた仕事の進め方を様々なクライアント業務の中で実施しているが、非常に分かり易いと言われる。
下記のような、ウェブやゲーム開発の現場で描きがちな画面レイアウト図。
画面の構成要素は分かるが、条件による状態変化がもの凄い小さいフォントで大量のテキストとして表記されている。
また、その画面で必要な機能をパズルのように詰め込んだ画面レイアウトとなることが多い。
端的に設計者の意図を読み取るのが難しく、コミュニケーションロスが大きい。
何故なら画面レイアウト図には、時間の流れが存在しないためだ。
それに対し、下記のUX Flow(画面遷移図)には文字通り”Flow(流れ)”が存在する。
画面内にあるリストやボタンを選択した際、どの機能が呼び出されるのか？どの画面へ遷移するのか？遷移先の画面からどうやって元の画面に戻ってくるのか？来ないのか？どの条件によって画面状態や遷移が変化するのか？
全ての流れを追えるように描く。
UX Flowは機能仕様も加味しないと描けないので、当然先のSpec Sheetの要件も満たす。UX Flowは画面レイアウトを考慮の上で描くので、UI Compoの洗い出しも出来る。
加えてUX Flowは操作の流れを描くため、ユーザの行動や心理を想像し、機器やサービスを使うストーリーを描くことが出来る。
エラーケースやダイアログ文言の条件出しにも使えるので、設計書としての性格も強い。
UX Flowをもとに、QAテストのシナリオを作ったりもする。
初めてUX Flowを描く際に、画面レイアウト図(画面内のパーツの配置)との差を理解するまでに多少なりとも時間がかかる。それだけ、クライアントやユーザの行動、心理を想像し、UX Flowに書き起こすと言う作業は、奥が深いのかも知れない。
