Home > WarlockReport > #hcdvalue ワークショップ UXのためのUIデザイン

#hcdvalue ワークショップ UXのためのUIデザイン

コミュニティ hcdvalue のワークショップに行ってきました。
ワークショップは久しぶりな気がします。

講師はクラスメイト@aokaoq さん
テーマは「UXのためのUIデザイン」です。

スライドもアップされているので、開発者視点で整理しながら振りかえってみようと思います。

UX と UI をユースケースでつなぐ

UX = ユーザー体験
語られる言葉は、体験です。
UI = ユーザーインターフェイス
語られる言葉は、インタラクションであり、ビジュアルであり、アーキテクチャです。
ユースケース
ユーザーがUXを達成するために行う最小単位の行動を指します。
表現としては、(ユーザーが)○○する。(ユーザーが)△△を する。

今なお混同されがちな UX と UI ですが、実際に設計・実装する際はきちんと分けて考える方が良いと思っています。
そこを分けた上で、ユースケースで「つなぐ」という視点が今回、特に感心(感動)したポイントです。
着眼点にセンスがある...というか実務で磨かれた「技術」のようなものを感じました。

ここを個人的に解釈し直してみると、こうなります。

  • UX ⇒ 実現したい、創り出したい「体験」 ⇒ 要件定義(として捉え直す)
  • そのために必要なユーザーの「行動」 ⇒ ユースケース
  • 行動において「操作対象」となるもの ⇒ UI

更に UI の向こう側に実装 / ソフトウェア / システム / プログラムなどと呼ばれるものの「振る舞い」があります(ここは今回のテーマとは別の領域)。
要件定義としての UX からスタートして、設計と実装がユーザー側に進む UI デザインと、システム側に進むシステム設計。
こう考えると、UI デザインのプロセスがとても腑に落ちました。

具体的には 5 つのプロセスがあるので、順に見ていきます。

挙げる
2つに分ける
優先順位をつける
つなげる
描く

ユースケースを挙げる

まず、ユースケースを挙げて行きます。
要件定義からユースケースを抽出する...と考えると、ソフトウェア開発者にとっては馴染みのフェーズ。
意識するのは、その粒度です。
例えば Twitter クライアントを例にすると、「ツイートする」や「ダイレクトメッセージをチェックする」ような粒度。
「編集ボタンをタップする」や「OKボタンをクリックする」は細か過ぎるようです。
構造化シナリオでいうとアクティビティとインタラクションの間くらいとのこと。
オブジェクトの操作ではなく、ユーザーの行動を記述すれば良さそうな気がしました。

ユースケースを2つに分ける

ユースケースが抽出できたら、それらをプライマリとセカンダリの 2 つに分けます。
最終的には 4 つに細分化できました。(下記、A~D)。

  • 分類1.プライマリユースケース
    • UX を実現するためにユーザーが必ず行うこと(A)
  • 分類2.セカンダリユースケース
    • プライマリのためにユーザーが行う必要があるもの(B)
    • サポートすることでより良い UX が提供できるもの(C)
  • 不要なユースケース(D)

再び Twitter クライアントを例にすると、A「ツイートする」、B「アカウント登録をする」、C「タイムライン上でサムネイル画像を見る」「ダイレクトメッセージのプッシュ通知を受け取る」、D「現在位置を更新する」という感じでしょうか。
C や D は実現しようとする UX によって変わってくるでしょう。

現場ではついつい多くのユースケースを C に入れてしまいがちです。
しかし、ここはキリッと D に入れることで、アプリやサービスが目指すところを明確にした方が良いでしょう。

また、「できないこと」は「やらないこと」と切り分けて、残しておくとのこと。

ユースケースに優先順位をつける

分類が終わったら、その中で更に優先順位をつけます。
優先順位が高いものは以下のようなユースケース。

ユーザーが期待するユースケース(何をしたいか?)
ユーザーがよく行うユースケース (何を行うか?)

もし、ここでペルソナが用意されているようなら「ペルソナに聴く」こともできるでしょう。
あるいは「シナリオ」に記述されているかもしれません。

優先順位をつけることは「ユーザーにとって必要なことを知る」ことにつながります。

ユースケースをつなげる

そして、ユースケースをつないでフローを作ります。

分類1は少ないステップで達成できることが大切です。
分類2で分類1のユースケースを妨げないようにしましょう。
優先度優先度の高いものは、分類1の中でもより最短でたどり着けるようにしましょう。
優先度の付け方に迷ったものは、フローを分けるべきかもしれません。

最初はユーザー行動のフローとして見ることができますが、一定のユースケースをまとまりとして見たり分けてみたり(ワークショップでは分けませんでしたが)することで、画面や画面遷移が浮かび上がってきます。

この時点でユースケースの粒度を再考してみるのも、ひょっとしたら良いのかもしれません。
個別で上げていたユースケースをフローとしてつなげることで、新たに見えてくるものがありますし、「フローにしてみたが、つながらなかった」という場合は、ユースケースが足りなかったとも言えるでしょう。

ここまでは実務でも繰り返しやっているところだろうな、と思いました。

画面を描く

いよいよ具体的に画面を描いていきます。

分類1のユースケースが含まれる画面を優先的に描きましょう。
分類1は画面上のわかりやすい位置に置くことが大切です。
分類2は二次的なユースケース、もしくはよりよいUXを提供できるものですが、必須でないものです。
そのため、分類1を優先したレイアウトにしましょう。

UI を描くこと自体は慣れていないと難しいところですが、「質的変換」のプロセスだと考えれば納得できます。
エンジニアなら、ここまでで作ったフローがあれば、更に UML なり Excel 方眼紙なりを踏まえるなどして、設計から実装へと進むことができるでしょう。
今回は UI デザイナーが進む道をワークショップで体験しているということですね。

以上、ワークショップの振り返りでした。

全体を通して再確認したのは「デザインには理由がある」ということです。
この話はまた別のエントリーにした方が良さそうなので、今日はここまで。

@aokaoq さん、そして hcdvalue の WS 企画・運営チームの方々、ありがとうございました。
また会いましょう。

#hcdvalue ワークショップ「UXのためのUIデザイン」 - Togetter

Home > WarlockReport > #hcdvalue ワークショップ UXのためのUIデザイン

Page Top