はじめに
ユーザーテストでプロトタイプを検証した。課題が見つかり、修正が加わった。あとは実装に渡すだけだ。しかし、プロトタイプを開発者にそのまま渡しても、意図は伝わらない。「なぜこの動き」「なぜこの構成」という判断の背景は、プロトタイプには含まれていない。
ハイファイデザインと仕様書は、その橋渡しを担う。ハイファイで完成形の見た目とインタラクションを固め、仕様書で判断の文脈を残す。この2つがそろって、はじめて開発者は設計の意図を引き継いで実装できる。この記事では、Step 7のテスト結果を反映しながら、仕様書の作成とハイファイデザインの仕上げまでを解説する。
2. デザイン仕様書とは
デザイン仕様書は、デザインの意図を開発者に伝える文書だ。画面の見た目だけでなく、インタラクションの挙動、状態の変化、エラー時の動きなど、実装に必要な情報を整理して記載する。
プロトタイプとの違い
プロトタイプはある時点での「状態」を動かして見せる。だが、開発者が見るのは「ある時点での画面」で、遷移の意図や判断の背景は見えにくい。
仕様書は、その「文脈」を補完する。プロトタイプで示したタスク完了フローが、なぜそのステップで、どういう例外を考慮しているかを、文字と図で伝える。
仕様書が開発に役立つ理由
仕様書があると、実装時の認識の齟齬が減る。デザイナーの頭の中にある「当たり前」が、開発者にとっても「当たり前」にならないことを防ぐ。
また、後からの仕様変更やメンバー変更時にも、なぜこの設計になったかの根拠を残せる。プロトタイプが更新されても、意図は文書に残る。
崩れやすいポイント
仕様書は実務でよく崩れる。理由は「網羅しすぎる」と「文脈を欠落させる」の両方が起きやすいことだ。
初心者が陥りやすいのは、全ての画面を1枚ずつ詳細に書こうとすることだ。100ページの仕様書を作り、誰も読まなくなる。重要な判断が埋没し、開発者は必要な情報を探し出せない。
また、前工程で決めたペルソナやユーザージャーニーを無視して、画面の見た目だけを並べることもある。これでは「誰のための仕様か」が見えなくなり、実際の使用場面との齟齬が生まれる。
仕様書は「設計判断の文脈を残すもの」である。何を残して、何を削ぐかの判断が、仕様書の価値を決める。
3. ハイファイデザインとは
ハイファイデザインは、実際の製品に近い見た目と動きを持つデザインだ。色やフォント、画像などのビジュアルを確定させ、プロトタイプに近い形で表現する。
プロトタイプとの違い
プロトタイプは「動き」を検証するためのものだ。見た目は仮のまま、遷移やインタラクションの自然さを確認する。
ハイファイデザインは、「見た目」を確定させる。実際のブランドカラーやフォント、画像素材を適用し、製品としての完成形に近づける。
ただし、見た目を詰めることと、インタラクションを詰めることは並行して行われる。ハイファイデザインにする過程で、プロトタイプで見えなかった細部の問題が見つかることもある。
ハイファイデザインが設計に役立つ理由
ハイファイデザインがあると、実際の使用感に近い検証ができる。色の組み合わせによる視認性、フォントサイズによる読みやすさ、画像による印象など、低・中忠実度では見えにくい点が見える。
また、ステークホルダーへの説明やユーザーテストでも、実際の製品に近い形で意図が伝わりやすい。完成形のイメージが共有でき、最終調整の精度が上がる。
崩れやすいポイント
ハイファイデザインは実務でよく崩れる。理由は「ビジュアルを先に詰めすぎる」と「インタラクションを軽視する」が起きやすいことだ。
初心者が陥りやすいのは、色やフォント、画像の調整に時間をかけすぎて、インタラクションやエラー状態などの「状態設計」を後回しにすることだ。見た目は完成していても、実際に動かすと齟齬が出る。
また、ハイファイデザインを「完成品」として捉えて、仕様書作成を怠ることもある。見た目ができたら終わり、ではなく、それを開発にどう伝えるかがこの工程の本質だ。
ハイファイデザインは「見た目を確定させ、仕様書とともに開発に引き継ぐもの」である。ビジュアルとインタラクションの両方を整え、文脈を残す意識で進める。
4. 仕様書に含める要素
仕様書に何を含めるかは、開発者が実装に必要な情報を選ぶ。全部を書くのではなく、判断に必要な文脈を残す。
画面の構成
画面に何が表示されるか、配置と機能を示す。ただし、ワイヤーフレームの貼り付けだけでは不十分。なぜこの配置か、どういう優先順位で情報を並べているかを添える。
インタラクションの挙動
ボタンを押したら何が起きるか、入力したらどう変わるか。プロトタイプで示した動きを、具体的な値やタイミングとともに記載する。
状態とエラー
通常時だけでなく、ローディング中、空状態、エラー時の表示を示す。特にエラー時の動きは、実装で後付けになりがちなので、明示しておく。
デザインのトークン
色やフォントサイズ、マージンなどの具体値をまとめる。ハイファイデザインから抽出した値を、開発者が参照できる形に整理する。
崩れやすいポイント
「全部書こう」とすると、仕様書が肥大化する。100画面あるプロダクトなら、100ページの仕様書になって誰も読まなくなる。
重要なのは「判断に必要な情報」を絞ること。標準パターンはデザインシステムに任せ、独自の判断が必要な箇所だけを詳しく書く。
仕様書サンプル
「何を書くか」を具体的に理解するために、簡易サンプルを示す。タローのタスク確認画面を例に、必要最低限の情報をまとめた一例だ。
| 項目 | 内容 |
|---|---|
| 画面名 | タスク完了確認モーダル |
| 目的 | 誤操作を防ぎつつ、完了操作を明確に伝える |
| 表示条件 | 完了ボタン押下時 |
| 主要要素 | タイトル、説明文、完了CTA、キャンセル |
| 正常時 | 完了後に一覧へ戻る、完了トースト表示 |
| エラー時 | 通信失敗時は再試行導線を表示 |
| 注釈 | 通勤中の片手操作を想定し、CTAを下部固定 |
この表が示しているのは「画面の全情報」ではなく「判断が必要な情報だけ」だ。標準パターンに沿う要素は省略し、タローの文脈から生まれた独自の設計判断（CTAの位置、再試行導線）だけを残している。
5. 仕様書の作り方
ここからは実際の作り方に入る。プロトタイプとハイファイデザインを前提に、仕様書を作成する流れを解説する。
5-1 何を残すかの判断
仕様書を書く前に、この画面で何を伝える必要があるかを判断する。全部を書くのではなく、設計判断の文脈を残す。
標準と独自の切り分け
デザインシステムや共通パターンでカバーできる部分は、参照先を示すだけで十分。独自の判断が必要な箇所、例えば特別なインタラクションや例外処理などだけを詳しく書く。
タスク確認画面の「完了」ボタンが標準パターンなら、「完了ボタン：標準パターン参照」で十分。だが、電車の揺れを考慮した押下エリアの拡大があるなら、その判断と理由を記載する。
文脈を残す
なぜこの画面構成にしたのか、ペルソナのどの状況を考慮したのかを添える。タローが通勤中に片手で操作すること、時間に追われていることを前提にしていることを示す。
この文脈があると、開発者が実装時に判断を補完できる。「ここは不明瞭だけど、タローの文脈ならこう動くはずだ」と推論できる。
5-2 具体的な記載方法
判断した内容を、仕様書として記載する。見た目と動きの両方を、開発者が理解できる形で示す。
画面と注釈
画面のスクリーンショットに、注釈を添える。赤枠や矢印で要素を示し、その横に挙動や値を記載する。文章だけではなく、視覚的に伝わる形にする。
フローの記載
画面単体だけでなく、遷移の流れを示す。どの画面からどこへ遷移し、どういう条件で分岐するかを、フローチャートや矢印で表現する。
具体値の明示
「大きめのボタン」ではなく「幅120px、高さ48px」。「少し待つ」ではなく「300msの遅延」。曖昧な表現を避け、実装できるレベルで具体化する。
5-3 ハイファイとの整合
仕様書を書く過程で、ハイファイデザインの不備が見つかることがある。仕様として矛盾がある、あるいは実装が難しい箇所が見える。
デザインの見直し
仕様書化で問題が見つかったら、ハイファイデザインに戻る。見た目を優先してインタラクションが無理な構成になっていないか、技術的に実装が困難な動きになっていないかを確認する。
仕様書を無理に書こうとせず、デザインを修正する。仕様書はデザインの品質チェックの役割も果たす。
崩れやすいポイント
ここで陥りやすいのは、仕様書を「デザインの説明」として書くことだ。ハイファイデザインを言葉で言い換えただけになり、設計判断の文脈が抜ける。
また、開発者の都合を無視して理想論だけ書くこともある。実装コストや技術的制約を考慮せず、動きを詰めすぎて後で破綻する。
仕様書は「デザインと実装の橋渡し」である。両方の文脈を持ち、実現可能な形で残す。
6. 開発への引き継ぎ
仕様書とハイファイデザインを、開発者に伝える。単に渡すだけでなく、意図を説明して認識を揃える。
説明会の実施
資料を渡す前に、設計の意図を口頭で説明する。なぜこの画面構成にしたのか、どういうユーザーを想定しているのかを伝える。文書だけでは伝わらないニュアンスを補完する。
質問の受け答え
開発者からの質問を受け、仕様書に反映する。実装時に生じた疑問は、仕様書が不明瞭だったサインだ。FAQを仕様書に追記し、次回の引き継ぎに活かす。
継続的な更新
仕様書は一度書いたら終わりではない。実装中に設計が変更になったら、仕様書も更新する。デザインと仕様書の齟齬が生じないよう、開発と並行してメンテナンスする。
崩れやすいポイント
ここで陥りやすいのは、引き継ぎを「資料の受け渡し」として終わらせることだ。ファイルを共有したら自分の仕事は終わり、と捉えてしまう。
また、開発中の変更に仕様書を追従させないこともある。現場で口頭で調整したまま、文書が古くなる。次のメンバーが参照したときに、実装と仕様が食い違っている。
引き継ぎは継続的なコミュニケーションだ。文書はその記録であり、生きたものとして管理する。
7. この知識がUI設計で効く場面
仕様書とハイファイデザインは、開発フェーズで設計の判断を保護する。以下の判断を下すとき、この工程が直接の根拠になる。
- 実装時に解釈が割れる箇所を減らすとき: 「なんとなくこう実装した」が起きやすいのは、設計の意図が仕様に残っていないときだ。独自判断の箇所を明示することで、実装者の推測による解釈ズレを防げる。
- エラー状態や例外状態を漏れなく渡すとき: 通常フローだけ設計して終わりにしがちだが、ローディング・空状態・エラー時の動きも仕様に含めることで、実装後の後付け修正が減る。
- インタラクションの細部を実装に落とすとき: 「300msの遅延」「押下エリアを拡大」といった具体値は、プロトタイプだけでは伝わらない。仕様書に書き残すことで、開発者が迷わず実装できる。
- デザインと開発の認識差を減らすとき: 引き継ぎ時の認識の齟齬は、仕様書と説明の組み合わせで下げられる。「なぜこうなっているか」の文脈を残すことが、認識差防止の本質だ。
設計フェーズを終えて開発に渡すとき、この4つの問いを仕様書の整理軸にすると、何を書くべきかが見えやすくなる。
8. まとめ
仕様書とハイファイデザインは、設計の「完成形と意図」を開発に渡すツールだ。ハイファイで見た目とインタラクションを確定し、仕様書で「なぜそうなのか」の文脈を残す。この2つがそろって、はじめて実装者が設計の判断を引き継いで動ける。
実務で崩れやすいのは、仕様書を「全部書こう」とすることと、「ハイファイができたら終わり」にすることだ。重要なのは、標準パターンは省略し、独自判断だけを詳しく書くこと。引き継ぎは資料の受け渡しではなく、認識を揃える継続的なコミュニケーションだ。
このStep 8で初心者ルートの設計ステップは一巡する。リサーチ・ペルソナ・ジャーニー・ワイヤー・プロトタイプ・テスト・仕様書という流れを一度経験することで、「誰のための設計か」「なぜこの判断か」を実装まで引き継ぐサイクルが身につく。次のプロジェクトでは、この流れを自分のものにして進もう。
関連知識
この記事に登場した概念の定義は、以下の用語集で確認できる。
- プロトタイプ：Step 7で検証し、仕様書のインプットになる作成物
- デザインシステム：仕様書で標準パターンを省略するときの参照先
- ユーザビリティテスト：Step 7でプロトタイプを検証し、仕様書に反映する知見の源泉
- フィードバック：開発との引き継ぎで継続的に行う認識の確認と更新
- インタラクションコスト：仕様書で明示すべき操作負荷の根拠
- ペルソナ：仕様書で「誰のための判断か」を残すために参照するユーザー像