iphoneアプリの画面設計をしていて、画面フローの表記をしようとして普通の画面フローチャートだとUIインタラクションを表記しにくいよね、と思ったので考えてみた。
画面フロー図の限界
webの画面フロー図は以下のことができないなー、不便だなーと思ってた。- 画面展開を表記する記法がない。webだと_blankくらいしかないけどアプリだと不便
- 画面が内包しているコンポーネントを表記できないので、画面のどのボタンが次の画面につながっているのかわからない。
- ↑レベルのを練ろうとするとワイヤーフレーム/プロトタイプをつくる作業になってしまう。プロトタイプだと逆に画面のつながりや展開の法則性がとらえにくく、整合のとれたインタラクションデザインが試行錯誤しにくい
- そもそも画面展開の種類って網羅的に把握されてる?
構造化寄りの表記方法は「情報アーキテクチャ、インタラクションデザイン記述のためのビジュアルボキャブラリー」で議論されているものの、上記のようなことをやりたいとき、どうやって書いたらいいのかなー、というのが課題だった。
(画面フロー図例:via http://terasoluna.sourceforge.jp/tutorial/server-web/Document/WebTutorial_2.html)
展開形式はどれくらいあるか〜ダイアグラム化
さがしてもないので、やりましょう。ということでリサーチ。画面展開を表現するにあたり、どれくらいの展開形式があるのか。ざっと以下の7種類に集約されるのでは。
- 全面上書き展開(いわゆる”_self”)
- 別画面遷移展開(いわゆる”_blank”やiphoneでの別viewへの遷移)
- 画面分割展開(1画面を別フレームで切って展開。Eclipseなどのペイン類)
- 非同期部分変更(ajax的な画面変更)
- フロート展開-排他 ダイアログ型(フロート内でアクションしないかぎり解除されない)
- フロート展開-排他 吹き出し型(領域外クリックで容易に解除される)
- フロート展開-非排他(パレット、ドローワー類)
さらにダイアグラム化してみる。これをフロー図の画面間に差し挟めば、画面展開形式が表現できるのではないか。

利用例
実際に使ってみるとこんなかんじ。
通常のフローチャートの矢印の間に上記のダイアグラムをさしはさんで展開形式を表現します。また点線ワクで画面に付随するコンポーネントを表します。
●メリット
- 画面フロー図レベルである程度のアクションとそれに対してのコンポーネントの反応、展開後の遷移を一覧できる
- ざっとした画面フローを書いてからこれらのインタラクションを表記することで、逆算的に画面要素を決定できる
- 対外的に必要でないかぎり画面要素仕様書を省ける。プロトタイプレベルでわかる画面の動きもある程度予想できる
- 上記ダイアグラムの7つのパターンをさしかえてみることで画面展開構成の試行錯誤が網羅的にできる
- フロー図を拡張したシュミレーションという側面があるので手書き向き。
●デメリット
- スマートフォンなど要素が限られるものはいいがweb規模だと図が複雑になりすぎるか?
- ページやコンポーネントのタイプと、展開形式をひもづけて管理するには、これで構成したあとエクセルとかにまとめたほうがいいかも。
そういうわけでPDFにしてみた
ということで、「Transition Pattern Diagram」としてPDFで公開します。→Transition Pattern Diagram (PDF)
ご自由にご利用ください。
たぶんこれ、コンセントさんのsite-it!等の画面をパターン化したツールと組み合わせると相性いいような気がする。
あと手書きで書いて試行錯誤して詰めていくシーンを想定しているのでがっつりつくるよりラフにやるのがいいのかなーと。
もしよろしければフィードバックいただけるとうれしいです。あとcapeknoteが知らないだけでこんなのあるよ、とか。
twitter: @capeknote です。
それではー。