見出し画像

デザインと開発をつなぐ、PMの武器を3つ選んでみた

Shinji Nakashima

僕は普段、UIデザイナーやPMといったロールで、サービスの立ち上げ・改善・リニューアルのプロジェクトの支援をさせていただいています。

その中で、よく課題になるのが、「検討を重ねて決定したUI/仕様を、開発チームにうまく連携できず（コンセンサスが取れず）、手戻りが発生する」ということです。
また、特に新規サービスの立ち上げなどで顕著ですが、探索的・アジャイルに開発を進めていく場合に、仕様の変更が入ることを前提とした柔軟な体制を取ることが求められます。

今回は、そういった課題を乗り越え、ユーザーストーリーを早く正しく、そして変化に強く実装できるようにするために、PM/UIデザイナーとして大切にしていることをまとめたいと思います。


そもそも、何が課題なの？

「検討を重ねて決定したUI/仕様を、開発チームにうまく連携できず（コンセンサスが取れず）、手戻りが発生する」ことの主な要因は、「コンテキストが共有できていないがゆえに、文書化されていない事柄に関しての想像にズレが生じる」ことにあるんじゃないかなと思っています。
（ここでいうコンテキストは、「この機能/画面は何のためにあるのか」を示すもの）

これを防ぐべくできそうなこととしては、こんな感じでしょうか。

  • a. コンテキストを共有する:
    「この画面/機能が実現するユーザーストーリーは何か」「この画面/機能のユースケースは何か」「ユーザーはどういう経緯でこの画面に至るのか」などを伝える。
    それによって、想像のズレを防ぐ。（どうしても想像ゼロで実装することはできないので）

  • b. 想像の余地を小さくする:
    実装時に検討が必要になるパターンを事前に予見して、デザイナー側がアウトプットしておく。
    それによって、エンジニアが想像しなければならないことを減らす。

  • c. （想像のズレがあることを前提に）想像のズレを無力化する:
    実装上キモになる設計にデザイナーも参画する。
    それによって、仮に想像のズレが生じていても、実装に大きなズレが起きないようにする。

これらを実現するために使える手法（を大げさに武器と呼んでみました）は、次の3つじゃないかなと思っています。

  1. 状態違いの検討（UI Stack） [←b]

  2. デザイン仕様の文書化（UI Spec） [←a, b]

  3. API仕様の設計 [←c]

それぞれどのようなものか、紐解いていきます。

武器1. 状態違いの検討（UI Stack）

UI Stackとは？

UI Stackとは、アメリカのデザイナーScott Hurff氏が提唱した、「UIにおいて考慮すべき5つの状態」のことです。

  • Ideal State (理想状態): 
    画面上のすべてのコンテンツが充足した、理想の状態。この状態を起点に、各状態を検討します。

  • Empty State (空の状態):
    ユーザー未登録の状態や、表示コンテンツが0件の場合。コンテンツが充足するように、ユーザーにアクションを促す必要があります。(e.g. ユーザー登録を促す、検索キーワードの変更を促す、他のキーワードをサジェストする)

  • Loading State (待ち状態):
    サーバー側の処理や読み込みの完了を待っている状態。処理が進んでいることを示して、ユーザーを安心させる必要があります。(e.g. スピナーを表示する、進捗状況を%で表示する)

  • Partial State (部分的な状態):
    コンテンツがわずかにある状態で、EmptyからIdealへ進む途中の状態。ユーザーの次のアクションを促したり安心させたりする必要があります。(e.g. 進捗状況を%で表示する、次のアクションを表示する)

  • Error State (エラー時の状態): 
    404ページやフォームのバリデーションエラーなど、意図しない動きをユーザーが取ったときの状態。ユーザーのショックを和らげると同時に、正すためのアクションを促す必要があります。(e.g. イラストとともにエラー内容を表示する、次の遷移先候補を提示する、バリデーションの内容を具体的に表示する)

なぜ必要なのか？

UIを作成する上でやりがちなのが、「完成状態（= Ideal State）のUIのみを作成する」ことです。（もちろんここが一番重要ですし、時間的制約がある中でここだけになってしまうのはわかる…）
ただ、完成状態のみでは、プロダクトの体験を設計できたとは言えず、考慮不足が生じます。

また、実装上も完成状態以外のとき（例えば、読み込み中や、エラーが発生したとき）の挙動を想定することが必要になるため、それらがUIに起こされていないとエンジニアとのコミュニケーションロスが発生しやすくなります。

そこで、UI Stackを検討/作成することで、次のようなことが実現できます。

  • ユーザー体験全体の設計:
    ユーザー体験のスナップショットではなく全体をUIに落として設計することで、ユーザーが安心して（快く）なめらかに利用できる体験を目指せます。

  • 明確なコミュニケーション: 
    UI Specを用いることで、デザインチームとエンジニアリングチーム間の認識の齟齬を防ぎます。

武器2. デザイン仕様の文書化（UI Spec）

UI Specとは？

UI Spec (UI Specification) とは、ひと言で言えば、(文字通り) UIに関する仕様書です。
ただし、一般的な仕様書と異なり、機能ユースケースをもとに作成しています。

具体的には、次のような項目で構成されています。ただし、全ての項目を丁寧に埋めることが必ずしも優先とは限らず、開発チームの状態やプロジェクトの納期、メンテナンスの実現可能性などを踏まえて、項目および分量はアレンジすることを推奨します。

  • 対応するユースケース:
    全体におけるどの機能ユースケースに対応しているのかを記載します。

  • 画面デザイン:
    Figmaの該当フレームへのURLを添付します。

  • 遷移元/遷移先:
    遷移元と遷移先の画面を記載します。できれば、遷移元と遷移先のUI Specページのリンクを貼れるとよいです。
    ユースケースを線で理解してもらえるようにすることが主な目的です。

  • 画面タイプ:
    どのように画面に表示するのかを明記します。(e.g. ページ, ページの一部, ダイアログ, メール文面など)

  • 表示要素・表示形式:
    デザイン上にあるテキストが何を指しているのか（特に分かりづらいものにフォーカスして）記載します。(e.g. "ID"とは何を指すか, "ステータス"はどういう種類があるのか)
    また、日時や数値などについては、表示形式を記載します。(e.g. YYYY/MM/DD, 小数第2位まで表示)

  • 文字数:
    各テキスト要素について、最大文字数・最大行数・省略表示の有無および省略表示の方法などを記載します。
    画面表示の仕様を示すだけでなく、データベースやAPIの仕様検討の際の参考にもなります。

  • 表示・非表示導線:
    要素の表示/非表示を切り替える導線がある場合、何をどう操作することでどう切り替わるのかを記載します。(e.g. アコーディオン, トグル)

  • 表示件数・表示順序:
    主にリスト/テーブル/カルーセルなどのUIにおいて、どのような順序で何件表示するのかを記載します。
    また、ソートやフィルター、ページネーションについても記載します。

  • 状態遷移/エラー/バリデーションの挙動:
    エラーとなる条件や、その時にどのように表示/挙動するかを記載します。
    ※パターンの洗い出し時には、UI Stackの考え方が参考になります。

  • クリッカブルエリア・挙動:
    クリック等のアクションができる要素と、どのような操作をすることでどのように挙動するのかを記述します。(e.g. 記入例リンクを押すとPDFをダウンロード, 「利用規約」 のリンク先はサービス利用規約ページ)

なぜ必要なのか？

Figmaなどのデザインツールで作成されたUIデザインは、プロダクトの見た目を示す上で非常に有効ですが、ある状態での見た目のスナップショットを伝えるに留まります。
他方、実際にプロダクトの実装をする際には、ある状態での見た目だけではなく、「ユーザーがボタンをクリックしたときに何が起こるのか」や「特定のエラーが発生した際にどのようにユーザーに通知するか」、「異なるパターンの値が入った場合にどのように表示するのか」などの動作仕様も理解する必要があります。

そこで、UI Specを作成することで、次のようなことが実現できます。

  • 明確なコミュニケーション: 
    デザインチームとエンジニアリングチーム間の認識の齟齬を防ぎます。

  • 開発効率の向上:
    エンジニアが実装中にデザイナーに確認を取る必要が減り、開発プロセスがスムーズに進みます。

  • 品質の担保:
    デザインの意図が正確に伝わり、高い品質のプロダクトが実現されます。

UI Specの作成・活用プロセス

  1. デザインレビュー:
    UI Specを作成する前に、POおよびデザインチーム内で (UI Stackを含めた) デザインのレビューを行い、UIが最終的なユーザーストーリーや要件を満たしていることを確認します。

  2. UI Specの作成:
    前述の項目に則って、UI Specを記述します。1の段階で決まっていない事項が多く現れるので、未確定事項をマークしておくことも重要です。

  3. UI Specレビュー:
    作成したUI Specをデザインチームやエンジニアを含めてレビューします。この際、開発上必要な観点も回収し、追記します。

  4. 実装:
    ユースケースをもとに優先順位を決めてスプリントに組み込み、UI Specを完成の定義として活用して実装を進めます。

武器3. API仕様の設計

API仕様書とその役割

API仕様書は、(その名の通り) フロントエンドとサーバーサイドの結節点となるAPIの仕様を定義するものです。
RESTful APIを採用している場合はSwaggerで記述したり、GraphQLを採用している場合はスキーマ定義を記述したりします。

なぜPM/UIデザイナーがやるべきか？

フロントエンドとサーバーサイドの開発チームが独立して実装を進める場合において、予め明確なAPI仕様があるとよいです。API仕様が決まっていないと、「API仕様が決まっていないがゆえに実装が進められない」という事態が多発します。

また、API仕様書を開発チームに完全に委ねると、UIが意図する表示や挙動をするために必要なデータがAPIに含まれず、フロントエンド・サーバーサイド双方に手戻りが発生することも多々あります。(もちろん、デザインチームと開発チームが同じ解像度でプロダクトの仕様を理解できていればそういった事態は起こりにくいですが、これがなかなか難しい…)
そのため、デザインチームから画面仕様を満たすために必要なデータを定義し、開発チームの観点を踏まえてAPI仕様をFixすることが重要になります。

API仕様の設計プロセス

  1. オブジェクトの整理:
    画面仕様をもとに、画面に登場するオブジェクトを構造化して整理する。このとき、UI Stackで作成した各状態や、UI Specで定義した表示内容もカバーできるように留意します。

  2. 遷移時・遷移先の状態再現に必要なデータの考慮:
    遷移時の状態を再現したり、遷移先に飛ばしたりするために必要な情報が何かを検討します。(e.g. 詳細ページに遷移させるためにはそのアイテムのIDが必要)

  3. 開発チームによるレビュー:
    実装上他に必要なデータはないか、またデータベースのデータ構造などと相違がないかなど、エンジニア観点でのフィードバックを取り入れて修正します。

  4. 実装:
    完成したAPI仕様をもとに実装を進めます。このとき、実装上必要な仕様修正は開発チームに任せながら、ユーザー体験が変わってしまうような変更が起きていないかに留意します。

とはいえ、どこまでやるべき？

と、ここまで（比較的）理想的なドキュメンテーションについて述べてみましたが、全て緻密にやるのが常によいということでもありません。
たくさんドキュメンテーションするということは、それだけたくさんこれからメンテナンスしていかないといけないということになります。（もしくは、これまで書いたものを大量の紙くずにしちゃうか…）

なので、プロジェクトのサイズや、メンテするだけのリソースがあるか、オーナーシップを持って運用できるメンバーを置けるか、などなどによって、採否やどの程度きっちりやるのかは決めるべきかなと思っています。
その閾値をどこに置くべきかは、模索中です…

いずれにせよ、この3つの武器を少なくとも意識しながら、PM/UIデザイナーとして動けると、ユーザーストーリーを早く正しく、そして変化に強く実装できるようになる（はず）と思っています。

最後に

今回は、デザインと開発がうまく連携できていない…といったどこにでもある悩みを解決する武器を3つ厳選してまとめてみました。
誰かのお役に立っていたら、嬉しいなと思ったり。

また、今回ご紹介した3つ以外にも、PM/UIデザイナーができること・すべきことはたくさんあると思います。
こういうものもあるよ、こうやったほうがいいんじゃないの、等々、コメントいただけたらありがたいです。

この記事が気に入ったらサポートをしてみませんか？