2014.11.19 / UI
クライアントやディレクターから渡された画面遷移図を元にワイヤーフレームを作ってみると、後から足りない画面が次々に発見された、または画面内の情報がどこに繋がるのか分からないといった経験はありませんか?
この画面遷移図というものは本来は制作範囲の全体像と構造を明確にし、必要な画面というものを洗い出したりするものです。通常のWebサイトであれば、従来のような画面遷移図でも問題ないかもしれませんが、多くのインタラクションが発生するサービスの設計では複雑化しやすく、何度も情報を行き来して確認することになるため時間がかかります。
原因のひとつとして、画面遷移図では画面名のみを記載して繋げていくことになるため、必要な情報が不足していることが挙げられます。その結果、本来であれば条件によって変化する画面、例えばデータがない場合やエラーなどの想定ができず、開発の後まで発見されないといった問題に繋がります。
こういった問題を解決するために、今回はSTANDARDで導入しているUI Flowsという可視化手法について紹介します。
この記事は以前の、アプリUI勉強会 in ネットイヤーグループの中で紹介していたUI Flowsというツールについてのフォローアップ記事になります。
元は37Signalsの記事で紹介されていたものです。従来の画面遷移図のように矢印で情報同士を繋げていくものですが、画面内でユーザーが見るものとユーザーがすることに分解して情報の関係を記述していくため、画面遷移図よりも詳細で、利用の流れも把握しやすいという特徴があります。
STANDARDでは利用中の流れを定義したシナリオを元に、このUI Flowsの形に落とし込んでいき、そこからワイヤーフレームを作成します。
最低限の要素のみでプロトタイピングまで進むことができるため、MVPの作成時などには特に有効です。シナリオが複数ある場合には、シナリオごとにUI Flowsをいくつかのパターンに分けて作成した後にマージ、ナビゲーション構造の検討などをした後にプロトタイピングを行います。
参考: A shorthand for designing UI flows – (37signals)
UIデザインを共有するためのシンプルな記法とは?(37signalsの場合) – IDEA*IDEA
UI Flowsの基本的な書き方としては、まず「ユーザーが見るもの」を書き、そこに一本の線を引き、その下に「ユーザーがすること」という形で書いていきます。
そして、「ユーザーがすること」の次には「次にユーザーが見るもの」「次にユーザーがすること」という流れで繋がっていきます。見るものというのは、同じ見るものであっても、ラベルなどまで書いてしまうと一気に複雑化してしまうため、基本的なアクションのトリガー(ボタンやフォームなど)を記述していくようにしましょう。
これによりアクション→フィードバック→アクション→フィードバック…という簡単なインタラクションが繋がっていく様を可視化することができます。
例えばSNSなどのログインフローなどであれば、すごく簡易的ですがログインIDとパスワードを入力し、ログインボタンを押してログインを完了させるという流れになります。
これを元にUI Flowsと書いていくと次のようになります。
続いてユーザーがすることが複数ある場合です。先ほどの流れと同じですが、「ユーザーがすること①」の下に点線を引き、2つめの「ユーザーがすること②」を書きます。
この「ユーザーがすること②」も当然アクションをするからにはフィードバックが必要になるため、「ユーザーが見るもの②」に繋がります。
同じように先ほどのログインについて考えていきましょう。
ユーザーはパスワードを勘違いしているなどの理由で、間違った情報を入力してしまうことがあります。
その場合には下記のような流れになります。
(ログインIDも間違っているケースは複雑化回避のため、この例では一旦置いておきます)
UI Flowsを作成する上で実は重要なのがこの粒度かもしれません。
今までの基本の書き方で紹介した粒度はかなり細かく、画面内のユーザーが操作するコンポーネントが想像できるほどの粒度です。ここまで細かく分解されていれば、ワイヤーフレームの作成時には情報を配置するだけで最低限のプロトタイプは作れます。しかし、多くの機能がある場合などには情報が大規模化しやすく、一覧性が低くなります。
今までの書き方では、作成時などの小規模な場合や、細かな粒度にすることでミスを減らしたい場合などに有効です。
次に、もっと荒い粒度の書き方を紹介します。
こちらは先ほどまでの書き方に比べ、かなりざっくりと情報を記述している例です。
線の上の「ユーザーが見るもの」がほぼ画面名のような粒度であり、「ユーザーがすること」も省略して分けられているものです。細かな粒度の時のようにコンポーネントなどまでは記述されていませんが、「ユーザーがすること」から情報を読み取れる人同士であればこの程度でも問題なく確認することができるでしょう。
画面名だけが書かれている遷移よりも、そこでユーザーがするべきことが明確になっているため、ワイヤーフレーム作成までスムーズに進むことができます。細かなラベルまではUI Flowsに記載はされませんが、MVPを作成するための最低限の情報は網羅することができます。
これは正直確実とは言えませんが、制作時に必ずUI Flowsの前にシナリオを作成するということを徹底していると、コンテキストを明確にする必要があるため、便利そうだったりやちょっとした思いつきによる余計な機能の追加を防ぐ抑止力になることがあります(後ほど紹介しますがあまり厳密にやりすぎるとスピードダウンの要因にもなります)。
UI Flowsでは単純なアクティビティにまで情報を分解しているため、デザイナー以外のメンバーとも一緒に作成することができます。むしろエンジニアも参加したほうが、エラー時の挙動などについて漏れなく記述することができるようになるため、後工程からの余計な手戻りを減らすことができるでしょう。
先ほどの余計な機能の追加を防止することの裏になりますが、当然画面遷移図よりも多くの情報を記述することになるため時間がかかります。このデメリットを解消するための方法としては、コアシナリオのみはUI Flowsを作成し、ほかはプロトタイピング中にマージするといったことや、UI Flowsの粒度を荒くすることで対応できるかと思います。
簡単にですが、画面遷移の代替手段となるUI Flowsについて紹介しました。
今年の4月くらいから何度か実際の案件でも使用していますが、画面遷移のみの場合に比べ情報の流れを意識できるようになり、ワイヤーフレームの作成時にも何が必要なのか…と考えることがなくなりました。
何度か作成しているとインタラクションについての理解も深まるため粒度は荒くなりますが、これから作ろうと思った人は自分の学習のために、まずは細かな粒度まで分解して書いてみることをオススメします。もし、新しい機能の追加や既存部分の改善の機会があれば、一度エンジニアなどのメンバーを巻き込んでこのUI Flowsをホワイトボードに書いてみてはいかがでしょうか。
STANDARDは「未来の豊かさにつながる仕組みをデザインする」というミッションを元に、人の役に立つ事業やビジネス、サービスの創出や改善をデザインの力で支援し続けています。
そのために、お互いの価値観を尊重し、学習と実践と内省をしながら成長できる場所であり続けることを目指しています。
あらゆる物事の仕組みを設計するデザイナーとして、ご一緒に考えながら試行錯誤していきたいという方からのご連絡をお待ちしています。
2017.5.23 / UI
本日、BNN新社さまより「UIデザイナーのためのSketch入門&実践ガイド(吉竹遼 著)」が刊行されました。 Amazonでのご購入はこちら (Kindle版もご用意しています) せっかくですので、執筆を務めさせて頂いた私の視点から、本書についての見どころを紹介させて頂きます。 どんな本か アプリやWebサービスなどのデジタルデザインにおいて、昨今普及が進んでいるSketchについての使い方を網 […]
by Ryo Yoshitake
2017.3.9 / UX
以前の記事にて、なぜ新規事業にユーザーリサーチが必要なのかを主に述べました。しかし、いざ行おうと思ってもどのように行えばいいのか悩まれる方は多いのではないでしょうか。 そこで、今回はUXデザインのリサーチ手法にはどのようなものがあるのかを分類した上で、その中でも利用頻度の高いユーザーインタビューの方法、特に質問設計にフォーカスしてお話したいと思います。 今回の記事では主に下記のポイントについて見て […]
by Masafumi Kawachi
2017.3.1 / Business
新規事業の立ち上げやサービスの改善の際、社内の声だけでなく外部の専門的な意見を求めるために相談できるデザイン会社を探そうとしたことはありますか? STANDARDでは、「新規事業のアイデアはあるけど具体性が見えない」「リリースしたサービスの数字が伸びない」のような悩みをお持ちの企業に対し、UXデザインやUIデザインのサービスをご提供しており、様々な業界の企業様からお話をいただくことが多いのですが、 […]
by Kenichi Suzuki
STANDARDはUXデザインを軸に、新規事業の立ち上げや既存サービスの改善を支援するデザイン会社です。