blog/content/post/2009/09/21/2009-09-21-00001225.md

8.7 KiB
Raw Blame History

title author date url wordtwit_post_info categories
UIのフローをデザインするための簡易記法 kazu634 2009-09-21 /2009/09/21/_1333/
O:8:"stdClass":13:{s:6:"manual";b:0;s:11:"tweet_times";i:1;s:5:"delay";i:0;s:7:"enabled";i:1;s:10:"separation";s:2:"60";s:7:"version";s:3:"3.7";s:14:"tweet_template";b:0;s:6:"status";i:2;s:6:"result";a:0:{}s:13:"tweet_counter";i:2;s:13:"tweet_log_ids";a:1:{i:0;i:4793;}s:9:"hash_tags";a:0:{}s:8:"accounts";a:1:{i:0;s:7:"kazu634";}}
Translation

UIデザインを共有するためのシンプルな記法とは37signalsの場合 | IDEA*IDEA」で紹介されていて、気になったので訳してみました。原文はA shorthand for designing UI flows by Ryan of Basecampです。

Enjoy!

UIのフローをデザインするための簡易記法

ユーザインターフェースのフローはそのユーザーインターフェースを実際に表示する画面と劣らずに、素晴らしいインターフェースにとって重要なものだ。顧客はそれらのフローをとっかかりとして画面を眺めている。あなたが作成したアプリで顧客が仕事を行うときに、一連の行動をするように特別に促すことで、顧客を上手にリードできる。

しかし、ユーザインターフェースのフローはそれほど重要なのに、それをデザインするプロセスで、フローのデザインを語るのは難しい。フローのすべての状態を図示するのは時間の無駄だ。それに、図示しても画面が変わればすぐにそのイメージは意味がなくなる。一方で、フローを物語形式や段落で書き出しても、それについて話をするのは難しいし、そうして書き出したものからデザインやレビューの際のチェックリストを作るのも簡単じゃない。

37signals のアカウントを扱う画面のデザインに取り組んでいて、ユーザインターフェースのフローを語る問題に直面した。適切にデザインし、実装し、テストし、そして再度テストしなければならないフローが何セットもあった。だから、簡単な表記方法を考えついて、うまいことできないかためしてみたんだ。

323-flow-template

フローは個々のユーザとのやりとりで構成される。画面はいくつかの可能性を提示し、ユーザはその中から一つを選ぶ。すると何かが起きて、画面が遷移する。それは一続きの会話のようだ。フローの中の一つ一つが二つの面を持つコインのようなもの担っている。画面は一方で何かを表示し、他方でユーザはそれに対して何らかの反応を行う。僕が考えついたフロー記法は横線でこの二面性を表している。横線の上部にはユーザが見るものを書く。下部にはユーザが行うことを書く。矢印はユーザが行動を起こすと、また別な行動を促す新しい画面へと移ることを示している。

単純だけど、具体的な例で話をしてみよう。 Basecamp で to-do アイテムを追加するには、まずリストの画面に行く。そして、「項目を追加する」をクリックする。フォームが出てくる。項目の内容を入力し、その内容が妥当なものであれば、入力した項目が表示され黄色でフラッシュする。このフローをフロー記法で表すとこんな風になる:

324-todo-flow

この記法は本当に手早く書くことができて、僕が想像していたとおりにそこで何が起こるべきかについての本質を伝えることができる。いま説明したような例では、実際そんな記法なんて必要ないだろう。けど、もっと複雑なフロー、特にアプリでまったくデザインされていない部分なんかをデザインするときに、この記法は多くの振る舞いを描くことができるんだ。次はログインのフローを示す、もっとずっと複雑な例だ:

325-login-flow

このログイン・フローの場合は、もう少し説明をする必要がある。破線はユーザがとりうる行動を分けている。ログイン画面は一つしかないが、その画面では複数のことを行うことができるんだ。破線はつけ加えた行動の上に描く。破線は「または」だと思ってくれればいい。複数の行動がとれるとき、矢印が一つの行動から新しい画面に移ることを示す。とりうる行動が興味のわくものでなかったり、想定外のものであったりする画面の下には線がない。上のフローの「ダッシュボード」のように。

また、「パスワードを忘れた場合に表示される画面」の下の「メールアドレスを入力し、ユーザアカウントの情報と照合する」から二つの矢印が出ていることに気づいたと思う。それは二つの異なる画面が、ユーザがとったその行動から生じたことを示している。一つの行動から出ている複数の矢印を「かつ」と考えてくれていい。ログイン画面が更新され「あなた宛てにメールを送信しました」というメッセージがその行動をとった結果として表示される。そして、「パスワード再設定のメール」がもう一つの結果だ。メールが画面としてカウントされるのは、メールがインターフェースのフローに混ざっているからだ。

もう一つ複雑なフローを見てみよう。次のフローはユーザアカウントを作成するために、メールを送信し、招待メールからアカウントを作成するためのフローだ。

326-rsvp-flow

さて、忘れないで欲しい: すべての記法は最後には捨てられることが運命づけられている。意義のある仕事というのは、顧客が見る画面やあるいはうまく動くコードとして、直接的に私たちの顧客に影響を与えるもののことだ。けど、それを生み出す過程で自分たちの仕事を伝え、管理する必要がある。この簡易記法は、私が他のことに取り組むために、フローを頭から追い出すという最低限の必要性をこれまで満たしてきた。これを読んでいる読者の人にも、この記法が役立つといいのだけれど。