![見出し画像](https://assets.st-note.com/production/uploads/images/124893075/rectangle_large_type_2_fbf366307bf52f6193fc9b8b8854b3d8.png?width=1200)
フロントエンドエンジニアがデザイナーさんに意識してほしい6つのポイント
こんにちは、アジケフロントエンドエンジニアの本田です。
今回は、実装する時にデザインがどんな風になっていたら助かるかを弊社のエンジニアチームにヒアリングしたので紹介します。
なぜそうなっていた方がいいか、エンジニア目線で書いてあるので、参考にしてみてください!
1.色やフォントサイズ、マージンのルールがある
Sassなどを導入している場合、エンジニア側で変数の定義を行うことがあります(デザイナーさんにとってのカラーパレットのをイメージしてもらえるとわかりやすいと思います)。
色だけでなく、<h1>や<h2>、<p>などのタグごとだったり、フォントサイズとマージンのセットなどでルールが決まっていると、カラーパレットのような感覚で使い回しができるため、ルールが決められていると実装がスムーズに進められます。
弊社でも、実際のプロジェクトにて下記のようなデザインガイドラインを作成して使用しています。
![](https://assets.st-note.com/img/1702874825655-uIujRCxAJq.png?width=1200)
![](https://assets.st-note.com/img/1702874825740-DtcnCyt2OD.png?width=1200)
また、同様にUIもコンポーネント化して再利用することが多いです。
そのため、同じ見た目のUIなのにページごとに若干フォントサイズやマージンなどが違うと、どちらかに揃えるのか、それともそれぞれのページで別々にすべきかで迷ってしまいます。
ページごとに変更する意図がない場合、同一のUIを使用する際には他のページとの差がないようになっていると助かります。
2.ホバー、選択、ローディングなどのルールが用意されている
実装前にボタンやリンクのホバー、入力フォームのフォーカス、ページ読み込みのローディングのルールが漏れなく揃っていると、「この部分のUIはどう実装すればいいんだろう?」という疑問が一つ無くなります。
エンジニア側でもある程度「こういったUIでいいかな?」といった案は浮かびはするのですが、最終的にはデバッグ時などにデザイナーさんにご確認いただくことになるので、事前に用意していただけると助かります。
特にこだわりがない場合、事前によしなにやってほしい旨を伝えておいてくれれば、思いついた案で適宜対応してくれると思います。
下記は用意されていると嬉しいルールのリストです。
基本的なものは書き出してありますが、プロジェクトによって色々なパターンがあるため、ここにあるものだけでは足りないこともあります。
その場合は実装に入る前にエンジニアに相談すると、「こういった場合のこういうルールがほしい」というものを教えてくれると思います。
![](https://assets.st-note.com/img/1702875016325-oSE2oXPE10.png?width=1200)
3.例外のデザインが用意されている
静的なページでない場合、Webサイトは必ず理想の状態で表示されるわけではありません。
例えばブログ記事を例に挙げると、記事タイトルの文字数が多い場合や、投稿件数が0件の場合にどうなるかなど、例外のデザインが必要になります。
他の例としては、SPやタブレットなどの他のデバイスで見たらどうなるか、金額や人数が表示されるUIで、想定外の数値になった場合にレイアウトが崩れないか、もし想定された数値をオーバーしてしまったらどのような見た目になるかなどがあります。
エンジニアは、表示する内容がデータによって変わる箇所に対して「もしもこんなデータが表示されたらこのUIはどうなるんだろう?」という視点でデザインを見ています。
そのため、先回りして「こういう場合にはこういう表示になる」が用意されているととても助かります。
![](https://assets.st-note.com/img/1702875094641-vGBGj2nKT1.png?width=1200)
4.アニメーションにサンプルがある
「ここまでスクロールした時に、下からふわっと出してください」「ローディング時はこれらの画像を順番に切り替えて表示してください」などの指定をいただくことがありますが、実は実装後にデザイナーさんが想像しているものになっているかで毎回悩みます。
また、細かい調整が必要な場合には、実際にcssなどを調整してデザイナーさんの想定通りの実装になるようにミーティングですり合わせが必要になってくる場合もあります。
「このサイトのこのアニメーションのような実装にしてください」といった具体的な指定があったり、複雑なものはサンプルの動画があったりすると、デザイナーさんがイメージしているものが伝わり、エンジニア側も安心して実装することができます。
5.カラーコードに対してデザインと実装で共通して使える命名がされている
実装する上で必須というよりは、あくまでもコミュニケーションをより円滑にするためにあると嬉しいなという観点でアジケ社内のエンジニアから出てきた意見です。
特にグレーなどは1つのデザインで複数色用意されている場合が多いと思うのですが、質問するときや実装のデザインレビューで色に関連する指摘をもらった際に、カラーコードだと直感でわかりづらいです。
代わりに、複数色あるグレーに対してそれぞれgray1、gray2だったり、light-gray、dark-grayなどで色の名前を共通認識として持てたらコミュニケーションがスムーズになるのではないかと思います。
どのような命名にするかはお互いわかりやすいように擦り合わせていただく必要はあると思いますが、設定することでよりスムーズにやり取りできると思います。
6.色指定のopacity(不透明度)が100%になっている
下記の図のように、背景が白以外の場所に不透明度が100%未満で指定されているボタンを設置すると想定しない色味になってしまうため、ツールを使って不透明度100%で同じ色にするためのカラーコードに変換しています。
最初にデザインを作成したときにこの現象が発生しなくても、後々改修が入った際に背景に色がついた場所に設置される可能性があるためです。
デザイン上ではopacityの変更によってデザインガイドラインで指定された色を使用した想定になっているのかと思いますが、実装上では別の色として扱われてしまいます。
可能な限りはデザインガイドラインで指定された色を使用してほしいですが、理想通りに進まないこともあると思います。
どうしても難しい場合は例外としてピンポイントで使用するか、デザインガイドラインに色を追加して使うなどの対応にし、ヘッダーなどのように意図的に透けさせたい場合を除いてopacityは100%を指定してください。
![](https://assets.st-note.com/img/1702875204119-g97HIgLnHA.png?width=1200)
最後に
今回ご紹介した内容を含めたデザインをしてもらえると、「このデザインに他に想定外のデータが入った時に崩れてしまいそうなUIはないか」など、エンジニア側で細かい点に気を配る時間が取れるようになると思います。
デザイナーさんにも、既に他の案件に入っているのにエンジニアから質問が来て前の案件の修正に時間を取られてしまうようなことが少なくなるメリットがあるのではないかと思います。
色々と書きましたが、結局デザイナーとエンジニア間でお互いの共通認識ができているという点がスムーズに進めるために一番大事です。
お互いがスムーズにやり取りや進行をできるよう、上記を気をつけつつデザインしてもらえるととても助かります!
🤝メンバーを募集しています!【チーム伴走型のサービスデザイン会社|アジケ】✒️]
アジケでは、一緒に「人にとって豊かな体験をデザインすることで、『味気ある世の中』をつくる ”同志”を募集しています!
<働き方>
・フルリモートワークOK
・フレックスタイム制(コアタイム11:00~16:00)
<現在募集中のポジション>
・UXデザイナー/ディレクター
・リードUI/UXデザイナー
・リードエンジニア(テックリード)
<アジケってどんな会社?を3分でお伝えします>
<数字で見るアジケ紹介 〜こんな社員が働いています〜>
選考の前段階として、お互いを知るカジュアル面談も大歓迎です!
「まだ応募までは決めきれないけど、会社のことを知りたい」という方もお気軽にご連絡ください🙌
(カジュアル面談をご希望の方はこちらから)
採用に関するご不明、ご質問などがございましたら、お気軽に recruit@ajike.co.jp までご連絡ください📩
▼アジケのカルチャーを知りたい方|アジケのカルチャーデック
https://www.craft.do/s/ki01ioOMjsgvSv
▼アジケの事業内容と今後の展望を知りたい方|アジケの事業紹介
https://www.craft.do/s/K8K1fm63kxSmG8
おいしいお菓子を買います