エンジニアだってデザインガイドを書きたい

プロのデザイナーさんがいれば良いのですが、状況によってはエンジニアがデザインをして、それがそのまま開発のインプットになることがあると思います。
そんなときに闇雲にデザインを作るのではなく、整理して開発のインプットとできるようにこの記事を書きます。

今回の記事では以前書いた以下のような内容ではなく、より具体的に開発のインプットとして整理するための話です。

前提

デザインの対象はWebアプリケーションやスマホアプリのデザインです。
私自身はデザイナーではないのでプロ目線だと足りない箇所もあるだろうと思いますがご容赦ください。

デザインのガイドラインを書こう

作りたいアプリケーションの各画面、画面遷移はもちろん作ることかと思いますが、それだけではなくデザインガイドを作った方が良いです。
そして自分自身でデザインガイドを利用しながら画面を作って行った方が素早く品質の高いものが作れます。
この記事ではデザインガイドにどんなことを書けば良いのかを整理していきます。

「デザイントークン」で検索すると色々記事がでてきます。
「私の記事よりこれらを見た方が良いです。完。」ではあるのですが、じゃあ素人が全部書けるかと言われると辛いと思うし、そこまで立派なものは不要ということもありますので、「これだけあれば良いんじゃないか」というものをこの記事では書いていきます。

タイポグラフィ

どれだけの種類が必要かはモノによりますが、この例では４種類の定義を書いています。
文字サイズ、色、ウェイト、フォントファミリーを書いています。追加でline-heightもあるとオシャレ感が増すかもしれません。

フォントファミリーについては利用環境によって変わってきます。
Windows, macOS, iOS, Androidなど利用される環境に応じて利用可能なフォントを採用するかGoogleフォントのようなWebフォントを利用します。

このようなガイドを最初に開発者へ提示してあげることで、開発者はデザインのベース部分を各画面開発から分離して定義することができ、画面ごとに独自に同じデザインが定義されたり、微妙に見た目が違うという自体を避けることができます。

// Flutter(dart)の例
static TextStyle heading1() {
  return const TextStyle(
    fontSize: 24,
    color: Color(0xFFFFFFFF),
    fontWeight: FontWeight.w600,
  );
}

// CSSの例
h1 {
  /* Heading1の見た目を書く。省略。 */
}

// tailwindcssを使ってHTMLに直接書いた例。ただし、この場合は全部のCaptionで同じことを書くことになる。
<div class="text-sm text-slate-700">Captionをここに書く</div>

ちなみにフォントについては過去に記事を書いたことがあります。

カラーリング

ここもどれだけ種類が必要かはモノによりですが、アプリ内で登場する色の種類を定義してあげます。
こうすることでタイポグラフィと同じでデザインのベースとして開発することができます。

// Flutter
static const Color primary = Color(0x0277BD);

// CSS
--primary-color: #0277bd;

過去に色についての記事も書きましたが、色も闇雲に選ぶのではなく何かしらのカラーパレットから選んだ方が楽です。

Material Design3

Material Theme Builder でカラースキーマが作れます。

https://material-foundation.github.io/material-theme-builder/

Material Desing2

個人的には結構このカラーパレットを使ってたりします。

https://m2.material.io/design/color/the-color-system.html

ここで色選びのポイントは、同じトーンの色を選んだ方が無難です。
トーンが統一できていないと全体として統一感がなくなる可能性かもしれません。

また、白や黒も真っ白や真っ黒ではなくて少しグレーがかったものにするとオシャレ感が増します。

Tailwind CSS

Tailwindでも同じように色が定義されています。
ここも同じトーンのものを選ぶと無難です。

https://tailwindcss.com/docs/text-color

スペーシング

余白はとても重要です。素人が作って野暮ったさがでる一番のポイントです。
なんらかのCSSフレームワークをいれると綺麗に見えるのは余白が入っているからです。

TailwindなどのCSSフレームワークでもMargin/Paddingが定義されています。

表やカード、各部品間に余白を入れてあげることで野暮ったさがなくなります。
極端な例かもしれませんが、以下はpaddingの定義がないバッジと定義があるバッジの見た目の違いです。
素のHTMLだと余白を入れてあげないと全然余白がない見た目になってしまいます。

ちなみに過去の私の記事で以下を参考にあげていました。

ローディング

読み込み中のグルグルです。Busy Indicator とか Progress Indicator とか呼んだります。
ここはデザインのコツの話ではなく、静的な画面のデザインと画面遷移だけを考えているとローディングのデザインが抜けてしまうのでここに書きました。
たいていのアプリでは通信中にぐるぐるを出すと思いますので、そのデザインをしてあげると開発者は助かります。

ちなみにグルグルのパターンは２種類の出し方があります。

• 画面全体にグレーまたは透明な板を乗せて、どこも触れないようにしてグルグルを表示する
• 結果が表示される箇所や押したボタンなどにグルグルを表示する（画面自体は触れる）

アプリに適したグルグルの出し方を考えましょう。もし考え事を減らしたいのなら1個目の方が楽です。
ローディング中に画面を触れないため、ローディング中に他の画面にいくことができず想定漏れを減らすことができます。

ダイアログ

ダイアログで決めることは以下です。

• ダイアログの背景クリックでダイアログを閉じさせるかどうか（もしくは閉じれるものと、閉じれないものを使い分けるか）
• タイトルの有無
• はい / OK / Yes / いいえ / キャンセル / No / 閉じる、などの文言の決め
• はい / いいえボタンの色と配置（「はい」は右か左か）

こういった取り決めをしてあげると、開発ではダイアログ表示用のUtilを作ることができ、画面ごとに表記揺れするようなことを避けることができます。

static Future<void> showDialog({
  String? title,
  required message,
  String? yesCaption = "はい",
  String? noCaption = "いいえ",
  VoidCallback? yesCallback,
  VoidCallback? noCallback,
})

ただし、以下の記事でも触れたようにOS固有のダイアログを使う場合は制御できる部分とそうでない部分とあるので注意が必要です。

各コントロール

必要な数のUI部品の定義を書きます。
これらもガイドラインとして提供することで共通的な部品として最初に開発することができます。
マウスオーバーやクリック時のアニメーション/カラーも忘れずに定義してください。

もちろんこういった部品も事前に定義したスペーシングを守って作り、各画面で同じ部品を使った画面デザインを作ります。
そうしないと、デザイン通りに作ろうと頑張ってくれる開発者は各画面で独自にスペーシングの定義を作り始めてしまい、無駄な工数と不具合を生みます。

最低限であればアプリに必要なコントロールだけで良いですし、プロのデザイナーが作るのでなければ稼働環境のデフォルトや、なんらかのデザインのフレームワークのデザインそのままでも良いと思います。

リストの表示

多くのアプリケーションでは、配列としてデータを受け取り、それを画面に表示します。
表示のパターンとしては以下の形式があります。

• 表（Table）
• リスト / カード

表

Material Design2 から引用しましたが、以下のような表でデータを見せるパターンです。

https://m2.material.io/components/data-tables#usage

デザインに慣れていないと以下の点を忘れがちです。

• マウスオーバーで行の色が変わるかどうか
• 文字は左寄せ、数値は右寄せ
• PCで行をクリックできる場合はマウスカーソルをポインターに変えるのを忘れずに

また、何も考えずにHTMLでTableを書くと余白のない見た目になり、何かしらCSSフレームワークを入れると余白たっぷりで綺麗になります。
ここで一度考えてもらいたいのは、余白が重要という話をしましたが、それはあくまで見た目の美しさの話で使い勝手は別です。
例えば、帳票を見せる場合はあまり余白はいりません。余白があると項目間の距離が離れて見づらかったり、ディスプレイに収まらずにスクロールが発生し、逆に使いづらいアプリケーションとなってしまう可能性があります。

リスト / カード

同じく Material Design2 からの引用です。

https://m2.material.io/components/lists

https://m2.material.io/components/cards

本質的には配列型のデータを表示するという点で表と同じです。
大雑把に言うと、PCが表でスマホがリスト/カードをまず考えるという線引きでも良いと思っています。

表とカードの違いで注意したいのが、カードはレスポンシブ表示可能だが表は難しいという点です。
表の場合、画面に収まらない場合はスクロール以外に対応方法がありません。

厳密には、表を2段組にすることで対応はできますが作り込みが面倒です。
HTMLなどのUI側の定義は1個で表現できず、2個用意して幅に応じて切り替わるような処理が必要です。

カードの場合、雑な例ではありますが折り返しの実装が楽です。

アイコン

アプリ中にアイコンを使うことがあるかと思います。
エンジニアにとってアイコン自体にあまり思い入れはないことがあるかもしれませんが、「何のアイコンを使うか」は明示してあげた方が良いです。
そうしないと、開発側がライセンス的に問題のあるアイコンを持ってくる可能性もあり得るからです。
私の場合はとりあえずGoogleのアイコンを使ってます。

https://fonts.google.com/icons

動作保証範囲

デザインガイドとは関係ないかもしれませんが、開発には動作保証範囲の定義が必要です。
以下のことを決める必要があります。

• サポートOSの種類とバージョン
• サポートブラウザの種類
• サポートする画面解像度
• スマホの場合は動作保証機種（テストする機種）

おわりに

以下の記事もあわせて読んでいただけると良いかもしれません。

内容について足りない部分があればご指摘いただけると幸いです。