実践UI Flows - UI制作のはじまり

UI Flowsは、37signalsというアメリカのウェブアプリケーション開発会社が生み出した、画面遷移図の上位互換的なUI制作ノウハウです。

チームで行う最初のUI制作フロー

UXデザインやエンジニアリングに比べ、UIデザインをチーム全体で進めるノウハウは意外なほど浸透していません。

これは、遷移図やワイヤーフレーム作りをディレクターと意思決定者間で行い、その後のUI制作はデザイナー個人に任せるという、職能で分断された制作フローが原因と思われます。

これは分業として大いにアリなのですが、何度も打ち合わせたり問題や考慮漏れの発見が遅れたりと、意思決定の速度と精度を下げます。

UI Flowsはこの壁を打ち破る、チームで行うUI制作の第一歩です。

画面遷移図は情報が少なすぎて非効率

画面遷移図は、みなさんご存知の通り画面名をマインドマップのように繋げていく手法です。

一覧性が高く作るのが容易なので、採用する現場がとても多いのですが、画面遷移図からワイヤーフレームを作るとなると、ユーザーがそのページで行うことの情報がありません。

そのため前後の関係から導かれる分岐や要素の見逃しが非常に多くなります。

この結果、デザインや実装の段階になってから足りない要素・画面や要素間・ページ間の遷移が不明確な点が大量に発見され、再打ち合わせを行う羽目になります。

なぜユーザーがとるべき行動やあるべき要素について予め議論されていないのでしょう？とても非効率です。

UI Flowsの書き方

UI Flowsの書き方はとてもシンプル。主な要素は「ユーザーが見るもの」と「ユーザーがやること」の2つ。それを矢印でつないでいくだけです

1つの画面に対してアクションは1つとは限らないので、2つ以上ある時は下に重ね、枝分かれさせていきましょう。

UI Flowsの使い方：プロトタイピング前と、開発前

UI Flowsはあくまで中途生成物です。常に最新の状態に保たなければいけないわけではありません。

使うタイミングは、低精度のプロトタイピング前と、実際の開発前の2つです。

はじめに作ったUI Flowsを使ってワイヤーフレームやプロトタイプを作り、ユーザビリティテスト等のテスト・評価を経て修正が行われ、Hi-FiなUIデザインに仕上げます。

その後、テストで修正された遷移や要素の変更をUI Flows上でも修正し、実装へと移ります。

シンプルで議論しやすいので、関わる人が増えるタイミングで使うのがよさそうです。

もちろん、実際にはUI Flowsやプロトタイピングでもエンジニアと協同し、ユーザビリティだけでなくフィジビリティまで検証した上でUIデザインを行うのが理想的です。

できればワークショップで実践しよう

用意するのはペンと3色の付箋、それを貼れる壁ないしボード、そして主要なチームメンバーです。

3色の付箋にはそれぞれ、ユーザーが見るもの・ユーザーがやること・画面名を書きます。

UI Flowsワークショップの様子

本来画面名を書く必要は無いのですが、付箋の面積が不足したり議論中に画面の呼び名がバラバラになるのを防ぐため、画面名用の付箋は用意した方がいいでしょう。

この点は、画面遷移図のいいとこ取りですね。

チーム全員で「手で気づく」

UI Flowsは画面遷移図とは異なり具体的な要素について議論しながら行う、擬似的なプロトタイピングです。

デザイナーが作業中に「あ、ここにこれも必要になるな」とか「この遷移はこう変えた方がいいな」と気づく、いわゆる手で気づく感覚をチーム全体で得られます。

そのワークに意思決定者が同席していれば、その場であるべきフローへの修正を意思決定することもできます。

一人で作った場合でも、後からレビューしやすい

画面遷移図よりは要素が多いですが、構造が単純です。Standardさんのブログなどにも書かれていますが、誰かが一人で作った場合やワークショップの参加者以外でも、すばやく読み解くことができます。

これはユーザーの行動を表すほかの手法(ユーザーストーリーやカスタマージャーニーマップ、ブループリント、プロトタイプなど)と比べて大きなメリットですね。

画面遷移図よりも作るのに時間がかかる？

UI Flowsは画面遷移図よりも作成に時間がかかること・必ずしも一人で作業が完結しないことから、採用が難しいチームがあるかもしれません。

しかしよく考えてみると、1.5〜2時間ほどのワーク1回で擬似的なプロトタイピングと共通認識の生成が済みます。

これは、誰かが作った遷移図を全員が読み取る・全員の認識を合わせる・遷移図から作ったワイヤーフレームやデザインから発見された問題を修正するといった、慢性的に積み重なる作業や打ち合わせに比べると明らかに省コストです。

（UI Flowsを実践したプロジェクトでは、ほかに遷移やユーザーの動きについて2回以上打ち合わせをしたことがありません。）

まとめ:まずは画面遷移図をUI Flowsに置き換えてみよう

UI Flowsは、既に画面数が膨大なプロジェクトや、状態・要素の変化に乏しいサイト、テンプレートな構成のサイト等には不向きです。いたずらに時間を浪費することになるでしょう。

しかし、例えばユーザーが登録して使うようなアプリケーションには最適です。その改善や新規立ち上げなどの際は、画面遷移図をUI Flowsに置き換えてみてはいかがでしょうか？

きっと無駄な議論や打ち合わせが減り、代わりにクリエイティブな議論をする時間を得られ、クオリティにこだわったプロダクト開発が出来るはずです。

ニュースレターへ移行のお知らせ

当ブログは別媒体へ移設・移行されました。新たにニュースレターとして運営いたしております。フォロワーの皆さまにおかれましては、下記から無料購読くださいますと、引き続き情報を入手できます。
移設先のメディア：https://uxman2020.substack.com/