この記事は freee Developers Advent Calendar の 13 日目です。
こんにちは、freeeのUXチームでデザイナーをしている @gakuton と言います。 2019年の新卒で、今年で2年目です。と言いつつインターンを1年半やったあとの入社なので実質4年目。実は古株寄りであることを隠して日々過ごしています。
今日は新人デザイナーが UI 設計を進めていく中で、「こうすれば確度高くプロジェクトを進められそうだな」と思ったことを中心に話せればと思います。
陥りがちな罠：UI 設計をいきなり始めてしまう
新人のデザイナーでありがちなのが、プロジェクトの企画が共有された段階でいきなり UI 設計をしてしまうこと。 例に漏れず僕もこの罠にまんまとハマった結果、あちこちに考慮漏れが見つかったり、設計していくうちに「あれ、これって誰のどんな作業をやりやすくするものなんだっけ」と方針を見失ってしまいます。 早くデザインを作成して共有できた方が自分も安心できる（特に新人は形が見えない状態が続くことが怖い！）し、チームメンバーにとっても安心だと思いがちですが、結局これでは案が固まるまでの時間が長くなってしまいます。
ユーザーストーリーをチームで洗い出し、共通認識を持とう
ユーザーストーリーとは
これを避けるためにまずやると良いのは、チームでユーザーのやりたいことのイメージを揃えることです。 ユーザーストーリーとは、「誰が・何のために・何をするのか」という要素で構成される、ユーザーからプロダクトへの要求事項です。 機能を検討しはじめた段階でユーザーストーリーをチームで洗い出しておくと、なんのために開発するのかがより明確になります。
実際にやってみる
僕が担当した「身上変更ワークフロー」というプロジェクトでは、プロジェクトの開始段階でユーザーストーリーの整理をチーム（PdM・UX・eng）で行いました。
身上変更ワークフローとは、従業員にライフイベント（結婚・引っ越し・出生など）があった際に、ソフト上で申請ができ、管理者である労務担当者の承認業務や情報の更新作業の効率化を目的とした機能です。 詳細はプレスリリースが出ているのでそちらをご覧ください。 corp.freee.co.jp
プロジェクト初期にチーム全員でユーザーストーリーを検討しました。大まかな流れとしては、まずユーザーの行動を思いつく限り洗い出し、似たユーザーストーリーをグルーピングします。その上で、どのユーザーストーリーが先に来るかといった順序を議論しながら大きなストーリーにしていく、といった形です。 今回の例でいうと、「①従業員にライフイベント発生」→ 「②従業員が労務担当者に申請を送る」→ 「③労務担当者が承認を行う」といったユーザーストーリーの順序となります。
特にプロジェクト初期は企画した PdM とその他のメンバーで認識のズレが起こりがちです。こうしてみんなで手を動かして考えることで、認識のズレも起こりづらくなります。 実際にこれを行なった以降、PdM の仕様策定・デザイナーの UI デザイン・eng の実装など各ロールの業務で手戻りが少なくなりました。
ユーザーストーリーを OOUI に落とし込む
さて、ユーザーストーリーを把握できた後、そのまま UI 設計に移行するわけではありません。UI 設計に入る段階では OOUI の原則に倣い、ユーザーストーリーを元に「その画面における主要オブジェクト」を抽出します。
OOUI とは
OOUI とは「オブジェクト指向 UI 」の略で、画面上に存在するオブジェクトを意識しながら行う UI 設計のことを指します。 UI を設計の基本の考え方のようなもので、詳細は書籍が出ているのでそちらをご参照ください。 www.amazon.co.jp
なぜこれを意識する必要があるかというと、ユーザーストーリーをそのままデザインに落とし込んでしまうと、アプリケーションとして最適な画面構成にならない場合があるからです。
例としてメモ帳アプリのデザインを考えてみましょう。ユーザーストーリーでは「メモを作成したい」「メモの内容を確認したい」「メモを削除したい」といったものが並ぶと思います。これをそのまま UI に落とし込むと、画面上にタスクの導線が並んだ UI 設計にもできてしまいますが、これは最適な画面構成ではありません。
ユーザーストーリーではユーザーのやりたいことを書き出すため、「〇〇する」といったタスク（動詞）が際出す表現になっています。OOUI の観点をここで入れることで、オブジェクト（名詞）が並ぶ一般的な UI デザインの表現に転換します。
実際にやってみる
身上変更ワークフローでは、ユーザーストーリーで多く登場する「申請」が主なオブジェクトであることがわかりました。「申請」と同じくらい「承認」という表現が登場していましたが、これは申請に対して行う一つの操作（アクション）であると考えられます。「申請」というオブジェクトに対し、提出する・承認する・差し戻すといった複数の操作がかかっているような関係性となっています。
さらに「申請」オブジェクトが持つデータの検討を進めていくと、一口に「申請」といっても内容は様々であり、申請ごとに変化する情報とそうでない情報があることがわかってきます。 例えば、[申請日] や [申請に使う承認経路] などはあらゆる申請に共通して存在します。一方で、引っ越しの際は [住所] や [電話番号]、出生の際は [扶養親族（子供や配偶者）] など、申請ごと異なる情報もあります。 また結婚申請のように、住所や扶養親族など複数の申請で扱っていた情報を一気に申請として提出したいケースなども見えてきます。
それらをオブジェクト分析を通して可視化・モデル化していきます。結果的にできたものは下記の形です。
今回の「申請」オブジェクトにおいては、まず氏名・住所・扶養親族といった最小単位としての情報群が存在し、その情報群を組み合わせることで申請が形作られる、という構成と考えました。複数の申請にまたがって関わるような情報もこの構造ならムダなく表現できます。
オブジェクトのモデル化には正解はないかと思いますが、UI 設計の前にこれを考えておくことで、画面上に何を表示すると良いかが頭の中で明確になります。
あとはこれを UI に落とし込むだけ
ここまでオブジェクトをモデル化できたら、あとはこれを UI に反映させるだけで大枠が自然と出来上がってきます。 もちろん画面にはオブジェクト以外の情報も表示しますし、インタラクションの定義も必要ですが、ベースとなる形が始めにできているので完成までのスピードは向上し、かつ一定の質を担保できます。
身上変更ワークフローで最終的に完成した申請画面はこのような形となりました。
申請内容タブの中に申請に必要な情報をブロックに分けて表示しています。この一つ一つのブロックが上述した最小単位の情報群です。まず「申請に関する情報」というブロックを表示していますが、これは全ての申請で共通のものです。それ以降は申請ごとに異なる情報を表示しています。
これらの情報群は全てオブジェクト分析で定義した内容のため、UI 設計時には画面の見やすさやビジュアルデザインにフォーカスすることができます。
オブジェクトを UI で表現する方法は様々あると思います。よりオブジェクト感のある表現（例. 情報群ごとにパネルを敷いて領域を明確にする）もありますが、今回は「情報に誤りがないか一つずつ丁寧に確認する」という申請の性質を踏まえ、一行に一つの情報・余白のみでブロック間の境界を分けるというシンプルなものにしました。
やれたらよかったこと。改善点
UI の設計においてモデル化のプロセスを進めていましたが、そのことをエンジニアに伝えたところ、「データモデルの構成とほぼ似てますね」と言われました。 当たり前といえば当たり前ですが、次回以降はエンジニアと一緒にこのモデル化のプロセスを進められると、デザインと実装で乖離がより少なくなり、さらに早く・質高くリリースに向かえるのかなと思いました。
一つのプロジェクトから始められるので、みなさんもぜひ試してみてください。
