画面遷移に疑問を感じたあなたにオススメするUI Flowsというツール

クライアントやディレクターから渡された画面遷移図を元にワイヤーフレームを作ってみると、後から足りない画面が次々に発見された、または画面内の情報がどこに繋がるのか分からないといった経験はありませんか？
この画面遷移図というものは本来は制作範囲の全体像と構造を明確にし、必要な画面というものを洗い出したりするものです。通常のWebサイトであれば、従来のような画面遷移図でも問題ないかもしれませんが、多くのインタラクションが発生するサービスの設計では複雑化しやすく、何度も情報を行き来して確認することになるため時間がかかります。

原因のひとつとして、画面遷移図では画面名のみを記載して繋げていくことになるため、必要な情報が不足していることが挙げられます。その結果、本来であれば条件によって変化する画面、例えばデータがない場合やエラーなどの想定ができず、開発の後まで発見されないといった問題に繋がります。
こういった問題を解決するために、今回はSTANDARDで導入しているUI Flowsという可視化手法について紹介します。

この記事は以前の、アプリUI勉強会 in ネットイヤーグループの中で紹介していたUI Flowsというツールについてのフォローアップ記事になります。

UI Flowsとは

元は37Signalsの記事で紹介されていたものです。従来の画面遷移図のように矢印で情報同士を繋げていくものですが、画面内でユーザーが見るものとユーザーがすることに分解して情報の関係を記述していくため、画面遷移図よりも詳細で、利用の流れも把握しやすいという特徴があります。
STANDARDでは利用中の流れを定義したシナリオを元に、このUI Flowsの形に落とし込んでいき、そこからワイヤーフレームを作成します。
最低限の要素のみでプロトタイピングまで進むことができるため、MVPの作成時などには特に有効です。シナリオが複数ある場合には、シナリオごとにUI Flowsをいくつかのパターンに分けて作成した後にマージ、ナビゲーション構造の検討などをした後にプロトタイピングを行います。

参考： A shorthand for designing UI flows – (37signals)
UIデザインを共有するためのシンプルな記法とは？（37signalsの場合） – IDEA*IDEA

UI Flowsの書き方1

UI Flowsの基本的な書き方としては、まず「ユーザーが見るもの」を書き、そこに一本の線を引き、その下に「ユーザーがすること」という形で書いていきます。
そして、「ユーザーがすること」の次には「次にユーザーが見るもの」「次にユーザーがすること」という流れで繋がっていきます。見るものというのは、同じ見るものであっても、ラベルなどまで書いてしまうと一気に複雑化してしまうため、基本的なアクションのトリガー（ボタンやフォームなど）を記述していくようにしましょう。
これによりアクション→フィードバック→アクション→フィードバック…という簡単なインタラクションが繋がっていく様を可視化することができます。

例えばSNSなどのログインフローなどであれば、すごく簡易的ですがログインIDとパスワードを入力し、ログインボタンを押してログインを完了させるという流れになります。
これを元にUI Flowsと書いていくと次のようになります。

1. ログインID用の入力フォームを見る
2. ログインIDを入力する
3. パスワード用の入力フォームを見る
4. パスワードを入力する
5. ログインボタンを見る
6. ログインする
7. ログイン後の画面を見る

UI Flowsの書き方2

続いてユーザーがすることが複数ある場合です。先ほどの流れと同じですが、「ユーザーがすること①」の下に点線を引き、2つめの「ユーザーがすること②」を書きます。
この「ユーザーがすること②」も当然アクションをするからにはフィードバックが必要になるため、「ユーザーが見るもの②」に繋がります。

同じように先ほどのログインについて考えていきましょう。
ユーザーはパスワードを勘違いしているなどの理由で、間違った情報を入力してしまうことがあります。
その場合には下記のような流れになります。
（ログインIDも間違っているケースは複雑化回避のため、この例では一旦置いておきます）

1. ①ログインIDの入力フォームを見る
2. ②ログインIDを入力する
3. ③パスワード用の入力フォームを見る
4. ④-①パスワードを入力する
5. ④-②間違ったパスワードを入力する
6. ⑤ログインボタンを見る
7. ⑥ログインする
8. ⑦−①ログイン後の画面を見る
9. ⑦−②パスワードが異なる警告を見る

UI Flowsの粒度

UI Flowsを作成する上で実は重要なのがこの粒度かもしれません。
今までの基本の書き方で紹介した粒度はかなり細かく、画面内のユーザーが操作するコンポーネントが想像できるほどの粒度です。ここまで細かく分解されていれば、ワイヤーフレームの作成時には情報を配置するだけで最低限のプロトタイプは作れます。しかし、多くの機能がある場合などには情報が大規模化しやすく、一覧性が低くなります。
今までの書き方では、作成時などの小規模な場合や、細かな粒度にすることでミスを減らしたい場合などに有効です。
次に、もっと荒い粒度の書き方を紹介します。

こちらは先ほどまでの書き方に比べ、かなりざっくりと情報を記述している例です。
線の上の「ユーザーが見るもの」がほぼ画面名のような粒度であり、「ユーザーがすること」も省略して分けられているものです。細かな粒度の時のようにコンポーネントなどまでは記述されていませんが、「ユーザーがすること」から情報を読み取れる人同士であればこの程度でも問題なく確認することができるでしょう。

UI Flowsのメリット

画面遷移よりも情報の関係性、詳細が確認しやすい

画面名だけが書かれている遷移よりも、そこでユーザーがするべきことが明確になっているため、ワイヤーフレーム作成までスムーズに進むことができます。細かなラベルまではUI Flowsに記載はされませんが、MVPを作成するための最低限の情報は網羅することができます。

余計な機能の増加を防止

これは正直確実とは言えませんが、制作時に必ずUI Flowsの前にシナリオを作成するということを徹底していると、コンテキストを明確にする必要があるため、便利そうだったりやちょっとした思いつきによる余計な機能の追加を防ぐ抑止力になることがあります（後ほど紹介しますがあまり厳密にやりすぎるとスピードダウンの要因にもなります）。

デザイナー以外も参加できる

UI Flowsでは単純なアクティビティにまで情報を分解しているため、デザイナー以外のメンバーとも一緒に作成することができます。むしろエンジニアも参加したほうが、エラー時の挙動などについて漏れなく記述することができるようになるため、後工程からの余計な手戻りを減らすことができるでしょう。

UI Flowsのデメリット

スピード感が低下する

先ほどの余計な機能の追加を防止することの裏になりますが、当然画面遷移図よりも多くの情報を記述することになるため時間がかかります。このデメリットを解消するための方法としては、コアシナリオのみはUI Flowsを作成し、ほかはプロトタイピング中にマージするといったことや、UI Flowsの粒度を荒くすることで対応できるかと思います。

簡単にですが、画面遷移の代替手段となるUI Flowsについて紹介しました。
今年の4月くらいから何度か実際の案件でも使用していますが、画面遷移のみの場合に比べ情報の流れを意識できるようになり、ワイヤーフレームの作成時にも何が必要なのか…と考えることがなくなりました。
何度か作成しているとインタラクションについての理解も深まるため粒度は荒くなりますが、これから作ろうと思った人は自分の学習のために、まずは細かな粒度まで分解して書いてみることをオススメします。もし、新しい機能の追加や既存部分の改善の機会があれば、一度エンジニアなどのメンバーを巻き込んでこのUI Flowsをホワイトボードに書いてみてはいかがでしょうか。

お互いの学びと成長を促せるメンバーを募集しています

STANDARDは「未来の豊かさにつながる仕組みをデザインする」というミッションを元に、人の役に立つ事業やビジネス、サービスの創出や改善をデザインの力で支援し続けています。

そのために、お互いの価値観を尊重し、学習と実践と内省をしながら成長できる場所であり続けることを目指しています。

あらゆる物事の仕組みを設計するデザイナーとして、ご一緒に考えながら試行錯誤していきたいという方からのご連絡をお待ちしています。