今日からできる！開発を考慮してデザインするための「きほんのき」

今回は、開発を考慮したデザインをするために気をつけるべき基本事項について、「デザイン編」「要件定義編」に分けてご紹介します。

「開発を考慮する」というと、コーディングの知識をつけるという方向に行きがちですが、実際にはそれだけではありません。

エンジニアさんに気持ちよくデザインをパスするために今日からできることをまとめてみたので、ぜひ参考にしてみてください！

デザイン編

デザインを作成するとき、開発を考慮して気をつけている基本事項2点です。

レギュレーションを統一する

デザイナーやユーザーにとってもメリットがあるので、既にできている方が多いかと思いますが、
開発目線の話として改めて簡単に解説します。

レギュレーションが曖昧だと、ページやコンテンツごとにデザインが微妙に異なるとき、
意図的なのか、ミスなのか、エンジニアが判断することができないので、確認するコストが発生してしまいます。

また、レギュレーションの数は少なければ少ないほど効率的に実装できます。

部分的にレギュレーションに従わないデザインを作りたいときは、「レギュレーションに従うデメリット」と「工数が増えるコスト」を天秤にかけて判断しましょう。

レギュレーションを統一することは、表現の幅が狭まるというデメリットもあります。

サイトの種類や目的に合わせて、どこまで揃えるかを決められると良いですね。

UI Stackを考える

デザインを作成するときは、まず理想の状態のページから考えることがほとんどだと思いますが、
他の側面を考慮せずに、あとからエンジニアさんに「該当データない時は何を表示しますか？」「エラーの時どうしますか？」と聞かれた経験のあるデザイナーは少なくないですよね。

UI Stackとは、考慮すべきUIの側面のことで、以下の5つを指します。（元記事はこちら）

1. Blank State（空の状態）：検索結果0や該当データが存在しない時/初めてサービスを使う時
2. Loading State（読み込み中の状態）：データを読み込んでいる時/接続中の時
3. Partial State（部分的な状態）：空の状態→理想の状態の間
4. Error State（エラー状態）：エラーが起きている時
5. Ideal State（理想の状態）：全てのコンテンツが表示される時/正常に利用できる時

これらの5つが網羅できれば、大体のページのステータスは満たせます。

要件定義編

WEBサイトには動きがあります。（100%ではありません）

静的なデザインを動的なものに実装するため、デザイナーが定義すべき基本事項4点です。

モーションの挙動

モーションというと、ダイナミックに動くアニメーションのようなものを想像しがちですが、
ホバーエフェクトやスクロールエフェクトも含みます。

よほど複雑な挙動でない限り、以下の3点がわかるように伝えられればOKです。

• モーションが起こる前
• モーション（どう動くか、何秒動くか、何px動くか、何%動くか　など）
• モーションが起きた後

参考サイトだけで伝わることもありますが、実際のデザインでアニメーションで作成できると、より正確に伝えられます。

簡単な挙動であればKeynoteのアニメーションを使って作成できるので、ぜひ活用してみてください！

クリッカブル領域

「アイコン+テキスト」「見出し+本文」など、ブロック内に複数の要素が入ったデザインを作成したとき、クリッカブル領域は必ず決めましょう。

「イラスト+見出し+リスト」というブロックだけでも、8通りの指定の仕方が存在します。

かくあるべきという通念的なルールがなく共通認識が取りにくいものは、デザイナーが明確に定義することが必要です。

表示数

意外と考慮漏れしがちなのがこちら。

よくあるのは

• 何個表示されるのか
• 何回表示されるのか
• 何行表示されるのか
• どのくらいの頻度で表示されるのか

など。

考慮漏れだけでなく、伝え忘れることも多い項目なので、注意しましょう。

さいごに

開発も考慮したデザインを作るために、今日からできる基本事項をまとめてみました。

もちろん、他にもデザイナーとして知っておくべき開発に関する知識はたくさんありますが、まずは基本をおさえられれば、エンジニアさんとコミュニケーションをとりながら仕様を決めていくことができます。

私たちデザイナーが作る画面はあくまでデザインデータであり、デザインは実装してはじめてプロダクトになり、ユーザーの目に入ります。

実装できないデザインを作ったり、画面だけ作ってあとは開発に丸投げ、なんてことにはならないよう、開発視点も考慮できるデザイナーになりましょう！