見出し画像

エンジニア・コーダーに好かれる治安の良いデザイン

webデザインを作っていると、ここってどう作ったら実装しやすいんだろうって考えたりしますよね。

デザインシステムがきちんと整備されている会社ならともかく、まだUIに関しては発展途上で、デザイナー各人にお任せだよっていうところもまだまだ多いんじゃないかなって思います。
デザイン制作と実装者が同じ人なら問題ないかと思いますが、デザイナーとコーダー・フロントエンドが分業している場合だと、実装しづらいデザインを渡され、不要な工数が嵩んでしまいエンジニアにとってストレスに…なんてことも、結構あるあるなのではないでしょうか。

個人的にも、無駄に難易度高そうなデザイン渡されて、ついイラッとしてしまうことも。。


私はプロジェクトによってデザインだけ、コーディングだけ、みたいにアサインされることがあるんですが、コーディング知識のないデザイナーさんのモック見て時々、「ああ…そう作っちゃったか〜〜(めんどくさ。)」みたいなことを思ってしまう経験も割とあります(汗)

そこで、コーディング知識のないデザイナーさんや、DTP出身のデザイナーさん達へ、webデザインを考える上で知っておいて欲しいなという内容をまとめてみました。

ただ、表現の幅を狭めてしまうことも良くないことだと思うので、全てきちんと守らないとダメ、というものではもちろんありません。
ぶっちゃけた話、大抵はどんなものでも実装はできます。(よほどトリッキーじゃなければね)
実装はできるけど、拡張性や再利用性などに欠けてしまうことがあるよ、というだけのお話です。
なので、工数をかけてでもそのデザインを実現すべきだ、という理由があれば、全然アリだと思うのです。


1.可変のテキストが入る箇所の背景がシームレスじゃない

画像1


背景に画像を使用する場合は、かならずシームレス用の素材も準備しましょう。


2.可変のテキストなのに、cssで作れないくらいエフェクトかかっちゃってる

画像2

画像で出し分けるにしても限度がありますし、パターン数増やす度に画像用意するのは手間なので、動的になりうる箇所は、できるだけコードだけで変えられるデザインにしましょう。


3.可変のテキストが入る箇所に、いろんなオブジェクト重ね過ぎ

画像3

こちらも、動的な部分がある場合は、あまりパーツが重ならないデザインにした方が実装しやすいです。


4.最大・最小テキストを考慮してない枠

画像4

コーダーさんに「その枠には収まりません…!!(泣)」と言われないよう、最大テキストも考慮しましょう。
複数行入る可能性のあるデザインは、その場合のデザインパターンも作っておくと喜ばれます。

一方、最小テキストを考慮してないと、実装してもらって出来たものが残念なことになるかもしれません…。
ユーザーさんが見た時に、「その謎の余白は一体…?」と思われてしまうかも。


5.やたら行間をカーニングで調整してる

画像5

バナーやアイキャッチ画像などなら、画像丸ごと書き出しするので、細部までこだわってもらって全然OKなんですが、コーディングで実装する場合は、いちいちletter-spacingで調整するのも面倒です…。
全体的な行間ならともかく、ピンポイントの字詰めはちょっと勘弁して欲しいと思ってしまいます…。


6.似たような要素なのに微妙に使い回しできない

画像6

おっこれ同じcss行けるじゃん…と思いきや、微妙に違うデザインで、がっかりされるかもしれません。
共通で使う可能性のあるパーツは、統一されたデザインの方が、使い回ししやすく効率的に実装できます。


7.可変テキストなのに、標準ブラウザにないフォントが使われてる

画像7

「たったこれだけのためにwebフォント使えと...?」と、怒りの声が聞こえてきそうです...。
それに、モリサワはブルジョワのものです。みんなが持ってるわけじゃないんですよ…(笑)


8.目視の中央揃えになってる

画像8

目の錯覚を考慮して、中央に見えるようにデザインしたのだと思いますが、実装のしやすさを考慮すると、アイコン+テキストの中央寄せ or テキストのみで中央寄せのどちらかにした方が無難です。


9.色定義がしづらい配色(野良カラーだらけ)

画像9

野良カラーだらけなのは、見た目も美しくないので、きちんと揃えた方が良いでしょう。
似たような要素なのに、毎回色変わってると、敢えて色変えてるのか、スポイトで色持ってきてしまって色が変わっちゃっただけなのかわからず、コーダーさんは戸惑って、結果、律儀に色出し分けの処理を書いちゃったりするかもしれませんよ…。


あとは、色面積によって敢えて微妙に色を変えるなどの細かい芸当を、意識高いデザイナーさんほどやっていたりしますよね。
ここに関しては色々意見分かれるところかもしれませんが、個人的には、色定義増えてコードの管理が煩雑になりがちなので、できれば避けてほしいと思います。


最後に

冒頭でも書きましたが、全部が全部ダメ、というワケではありません。

デザインにやたら厳格な制限を設けて、無個性なデザインになってしまうのも良くないことだと思うし、デザインには、数値化や言語化できない価値もあるとは思います。

ただ、工数かかりそうな表現であることを知っていて、敢えてこのデザインにしたいのか、無知ゆえに無邪気なデザインになってしまったのかでは意味が全然違うと思います。

エンジニアでなくても、ある程度このような考え方ができると、元のデザインルールを維持しやすい上、実装も効率的にできるのではないかなと思います。


この記事が参加している募集

#振り返りnote

85,214件

この記事が気に入ったらサポートをしてみませんか?