これなら分かりやすい！Webサイトのデザイン仕様書・指示書の作り方

デザイナーがWebサイトのUIを実装する際にデベロッパーに渡すデザイン仕様書・指示書の作り方を紹介します。

仕様書を作成する基本ツール、指示に適したフォントやカラー、グリッドや要素間の距離を自動的に計算するツールをはじめ、レイアウトや各UIコンポーネントのデザイン仕様の記述例まで、デザインを仕様化する解説記事です。

ブレイクポイントの説明、スティッキー要素の仕様説明、相対サイズの要素の説明方法、ボタンの文字数の説明、アニメーションする要素の説明方法など、デベロッパーに分かりやすく、デザイナー自身も見直せるデザイン仕様書を作成します。

The Art of Design Spec'ing
by Mahdi Farra 🍉

下記は各ポイントを意訳したものです。
※当ブログでの翻訳記事は、元サイト様にライセンスを得て翻訳しています。

• デザイン仕様書とは
• デザイン仕様書に使用するツール
• デザイン仕様書がなぜ必要なのか
• デザイン仕様書を作成するタイミング
• デザイン仕様書を作成する基本ツール
• デザインをどのように仕様化するのか
• 終わりに

デザイン仕様書とは

デザイン仕様書（Design Specifications）とは、WebサイトのUIを実装する際にデベロッパーの助けとなるデザインファイルに添付される仕様書のことです。

デザイン仕様書に使用するツール

以前はこういった仕様書はデザインのあらゆる種類のサイズやスペースを明記する必要がありましたが。しかし、Zeplinの登場により、完全に変わりました。デザインファイルがZeplinにエクスポートされると、デザイナーとデベロッパーは自動的にデザイン仕様書を表示できるようになりました。

SketchからZeplinに、そしてFigmaに代わりました

さらにFigmaの登場により、デザイン仕様書の基本的な情報がツール上に表示され、デザインに変更が加えられると自動的にアップデートされるため、プロジェクトがより簡単かつ迅速に進めることができるようになりました。

• Zeplinがかなり便利！Adobe XDやPhotoshopからデザインの指示書やスタイルガイドを簡単に自動作成できる
• Figmaなら簡単！デザインシステムの作り方を詳しく解説

デザイン仕様書がなぜ必要なのか

1. 実装の正確さ

デザイン仕様書は、デザインがどのように実装されるべきか、ユーザーがデザインを操作する際にどのように動作するべきかをデベロッパーがよりよく理解するのに役立ちます。また、デザイナーは自分の仕事を別の視点や角度から見ることができるので、より多くのエッジケースをカバーでき、デザインフローを早い段階で発見できるようになります。

実装の正確さ

2. 一貫性

明確なデザイン仕様書を作成することで、デザイナーは自分が構築したUI要素の一貫性とスケーラビリティについてより深く考えることができます。また、いくつかの決定事項を評価し、それに基づいてデザインを調整する機会も得られます。

一貫性

3. コミュニケーション

デザイン仕様書は、実装プロセスにおいてデザイナーとデベロッパーの間で交わされる会話に費やす時間を削減します。実装に関する一般的な質問に対する回答を提供することで、全員の時間が節約され、それが実装プロセスのスピードアップにつながり、より効率的なものとなります。

コミュニケーション

デザイン仕様書を作成するタイミング

FigmaやSketchを使用している場合は、幅・高さ・フォントサイズなどはツール内に自動的に表示されるので、すべてを記述する必要はありません。しかし、レスポンシブやスティッキーのUI要素などは手動で仕様を記述する必要があります。

小規模なスタートアップ企業のように、動きの速い環境で作業している場合は、詳細な仕様書の作成に多くの時間を費やすことはあまり意味がないかもしれません。

とはいえ、スタートアップ企業であっても、少なくとも自分の仕事の主要部分についてはデザイン仕様書を作成することを強くお勧めします。そうすれば、デベロッパーとのやりとりが少なくなり、効率的に仕事を進めることができます。

デザイン仕様書を作成する基本ツール

デザイン仕様書はさまざまな方法で作成できますが、最も重要なことは、実際のデザインと区別できるようにすることです。それを実現するには、仕様書の注釈に独特の明るいカラーと等幅フォントを使用することをお勧めします。

私はFigmaでラインツールを使い注釈用のテキストを加えて、デザインを手動で仕様化しています。場合によっては仕様作成をスピードアップするためにRedlines（Figmaのプラグイン）を使用することもあります。

デザイン仕様書で使用するカラー、フォント、サポートツールは下記のとおりです。

• カラー

  明るいUIの仕様書には#ff00ff、暗いUIには#00ffffというカラーを使用しています。どちらもかなり鮮やかなカラーで、私のデザインではめったに使用されないためです。私はこれらの値を頭の中で記憶していますが、もちろんそれぞれにカラースタイルを作成することもできます。

• フォント

  仕様書のフォントにはRoboto Mono（Google Fonts）を12px, 14px, 16pxとかなり小さいサイズで使用しています。3つの異なるサイズは、指定された要素の階層に応じて使い分けています。

• サポートツール（プラグイン）

  Redlinesというプラグインを使用すると、デザイン内のさまざまな要素間の距離を自動的に計算してくれるので、作業のスピードアップに役立っています。

仕様書に使用するカラー・フォント・ツール

デザインをどのように仕様化するのか

ここからが、この記事で最も楽しく、興味深い部分です！

以下では、デザイン仕様書の異なる例を見ながら、いつ、なぜ、このような仕様書を作成する必要があるのかを解説します。

1. フローの説明

フローの各スクリーンの下には、そのスクリーンでのロジックやインタラクションを説明する明確な記述が必要です。多くの場合、そのスクリーンで何が起こるのかを一行で説明するだけですが、長くなる場合もあります。

これは、そのスクリーンがどれだけ複雑なのか、まったく新しいロジックなのか、それとも既存のスクリーンを更新しただけなのかが分かります。

デザイン仕様書: フローの説明

2. レスポンシブレイアウトのブレイクポイント

これは通常、ブラウザウィンドウの幅に基づいてレスポンシブレイアウトのブレイクポイントを表示するために作成されます。また、ブラウザウィンドウの高さに基づいて垂直方向のレスポンシブレイアウトのブレイクポイントを表示する場合にも適用できます。

デザイン仕様書: レスポンシブレイアウトのブレイクポイント

3. スティッキー要素

スティッキー要素とは、スクロール時にスクリーン上の一定の位置にスティッキーされる（貼り付く）要素です。

下記は、スクロールの途中でページのヘッダが上部にスティッキーに表示されます。

デザイン仕様書: スティッキー要素

同様に、スクリーンの他の位置にスティッキーされる要素の仕様にも使用できます。例えば、アプリでよく使用されるページの右下に表示されるバナーなどです。

デザイン仕様書: スティッキー要素

4. 相対サイズ

相対的なサイズ（width/height）を持つ要素には、その要素の最大幅と最小幅を指定する必要があります。

下記の例では、中央のコンテナのwidth（幅）は100%（相対サイズ）で、最小幅は240px、最大幅は640pxであることが分かります。つまり、この要素は240-640pxの幅を維持しながら、スクリーンサイズに応じて流動的になることを意味します。

デザイン仕様書: 相対サイズ

他にも、例えばボタンなどの流動的なUI要素を仕様化するためにも使用できます。

デザイン仕様書: 相対サイズ

5. ボタンとフォーム要素

これは少し物議を醸すトピックかもしれませんが、私は本当に必要でない限り、ボタンの高さと幅に固定値を指定するべきではないと強く信じています。

高さと幅に固定値を指定しない代わりに、テキストの周りのパディングでボタンのサイズを決定する必要があります。そうすれば、使用しているフォントやフォントサイズ、言語に関係なく、ボタンは常に問題なく機能することが保証されます。

ボタンは高さと幅に固定値を指定しない代わりに、パディングを決める

一方で、ボタンの高さを固定値にして、後からフォントサイズを大きくすると、テキストの周りのパディングが縮小してしまい、ボタンのデザインが壊れてしまうことがあります。

固定値にすると、デザインが壊れてしまうことがある

ボタンがレスポンシブであると同時にUIにフィットするように、min-widthとmax-widthを定義しておきます。

ボタンの最小幅と最大幅を決めておく

また、ボタンの高さについては、max-heightを定義する代わりに、ボタンの幅を超えた場合にテキストを省略するように定義できます。
参考: line-clampプロパティの効果的な実装方法、CSSで文末を3点リーダーで省略表示する

ボタンのテキストは幅を超えた場合、省略する

6. 要素のステータス（状態）

要素のステータス（状態）とは、デザインのアクセシビリティとユーザビリティに重要なホバー・アクティブ・フォーカスなどのすべての適切な状態をデザイン内の要素に持たせるためのものです。

ステータスが適切に実装されるように、各ステータスに合わせてカーソルを含めることをお勧めします。

デザイン仕様書: 要素のステータス

ラジオボタンとチェックボックスの要素を仕様化する際には、その要素のチェック状態の仕様を必ず含めるようにしてください。

デザイン仕様書: 要素のステータス

最後に、UIを少しでもスムーズにするために、異なるステータス間のトランジションの仕様を追加できます。私は通常、0.15秒間継続するイーズインアウト（0.15s ease-in-out）のトランジションを追加しています（CSSのコードスニペットですが、Swift/Javaなど他のプログラミング言語でも同じことが適用できます）。

デザイン仕様書: ステータス間のトランジション

7. 複数行のテキストを省略

通常、テキストが特定の高さや特定の行数を超えた場合の省略ルールは、...を使用して仕様化します。

デザイン仕様書: 複数行のテキストを省略

または、テキストをフェードアウトにすることもできます。その際には、目立たない部分に注釈を入れておくと、デベロッパーがどのように実装されるかを理解しやすくなります。

下記の例では、テキストの下部をハイライトして、その上にグラデーションのレイヤーを重ねてフェードアウトの効果を出すことを示しています。

デザイン仕様書: 複数行のテキストを省略

8. アニメーションとトランジション（移行）

多くの場合、アニメーションするコンポーネントやUI要素を仕様化する必要がありますが、その一般的な例としてモーダルがあります。

デザイン仕様書: アニメーションとトランジション

下記の例では、ブラウザの上部からモーダルがアニメーションで表示されます。モーダルの表示は、不透明度0%から始まる仕様になっています。

デザイン仕様書: アニメーションとトランジション

もちろん、モーダルの終了位置とどのようにトランジションさせるかも仕様化する必要があります。

アニメーションのコンポーネントの仕様を決める際には、コンポーネントの開始位置と終了位置の両方を指定する必要があり、場合によってはその間の状態も指定する必要があります。

下記の例では、モーダルの終了位置とアニメーションの仕様（イージングと継続時間）を示しています。また、モーダルの高さ（max-height）を追加して、常に画面に完全に表示されるようにしています。

デザイン仕様書: アニメーションとトランジション

上記の例では、アニメーションのタイミング機能にease-in-outを使用しています。これは基本的に、要素がゆっくりとトランジションし始め、だんだん速くなり、最後に遅くなって停止することを意味します。

また、より高度なアニメーションカーブを指定するには、トランジションが設定された要素があるWebページをブラウザで確認する必要があります。私は通常、Codepen.ioで基本的なトランジションを使用して簡単なプロトタイプを作成してから、アニメーションカーブ（アニメーションタイミング関数）の値を自分の好みに合わせて調整しています。

CSSの経験がない場合は、Principleでアニメーションカーブの値を取得することもできます。

デザイン仕様書: アニメーションとトランジション

9. デザイン仕様書にコードを加える

その機能がどのように実装されるかをデベロッパーにイメージしてもらうために、コードスニペットで仕様書をサポートできます。必ずしもデベロッパーがあなたのコードスニペットを使用するとは限りませんが、あなたが実装について時間をかけて考え、そのための解決策を用意したことをデベロッパーに示すことができます。また多くの場合、デベロッパーはあなたのコードスニペットを実際に使用します。

私がデベロッパーチームに共有した便利なCSSコードスニペットの例として、要素に複数のボーダーを追加するbox-shadowのテクニックがあります。

デザイン仕様書にコードを加える

別の例としては、position: sticky;で要素をスクロール時にスティッキーにしたり、flex: 1;でFlexコンテナのスペースいっぱいに要素を拡張します。

デザイン仕様書にコードを加える

10. スクロールバー

場合によっては、コンテナ内にスクロールバーが必要になることがあります。

下記の例では、コンテナの最大高さ（max-height）が240pxであるにもかかわらず、中のコンテンツがその高さの制限を超えてしまったため、垂直方向のスクロールバーを表示しています。もちろん、これは水平方向のスクロールにも適用できます。

デザイン仕様書: スクロールバー

スクロールバーのスタイルは実装の過程で見落とされることが多く、そのため、仕様書に記載することは常に価値があります。

私は通常、スクロールバーをカスタマイズするためのテクニックが掲載されたCSS Tricksの記事へのリンクを含めます（リンクはFigmaでクリック可能です！）。

デザイン仕様書: スクロールバー

11. 【ボーナス】プロトタイプによる仕様化

場合によってこれらの仕様だけでは、あなたのデザインがどのように実装され、ユーザーが操作したときにどのような動作をするのかをデベロッパーに伝えるのに不十分な場合があります。

そのような場合には、デザインのプロトタイプを作成することが非常に役立ちます。同時に、このプロトタイプはユーザーテストやユーザーからのフィードバックを収集するためにも使用できます。

11 A. 【ボーナス】Figma/Sketchでプロトタイプを作成する

プロトタイプを作成するためのさまざまなツールがありますが、通常は、Figma/Sketchのプロトタイピングツールを使用するのが最も早い方法であり、基本的なインタラクションには十分な効果があります。

• Figmaなら簡単！デザインシステムの作り方を詳しく解説

Figma/Sketchでプロトタイプを作成

11 B. 【ボーナス】Principle Appでプロトタイプを作成

より洗練されたインタラクションに取り組んでいて、操作方法を見せたりテストしたりするために、より詳細なプロトタイプが必要な場合は、短時間で詳細なプロトタイプを作成できるPrinciple Appをお勧めします。

Principle Appでプロトタイプを作成

11 C. 【ボーナス】コードでプロトタイプを作成

または、コードでプロトタイプを作成することも選択肢の一つです。コードの仕様書では実際のデータを使用したり、その場で変更を加えたりすることもでき、さらに最も重要なことはデベロッパーが実装に部分的または全部を利用できることです。

コードでプロトタイプを作成

コードでプロトタイプを作成するもう一つの大きな利点は、UIの一部を操作するためのコントロールを追加して、その場でテストや微調整ができることです。

下記は、Airtimeアプリのチャットバブルの出現というマイクロインタラクションのプロトタイプを作成しています。また、さまざまなアニメーションスタイルをテストしたり、アニメーションの継続時間を変更できる設定パネルも追加しました。

コードでプロトタイプを作成

終わりに

私の個人的なデザインテクニックのブログの最初の記事はこれで終わりです。この記事を気に入っていただき、情報がお役に立つことを願っています。

この記事に関するご意見やフィードバックをお待ちしています。@mahdifでチャットしましょう。