デザインの意図を意識しながらコーディングする

自分がどんなことに考えながらコーディングしているか書きます。効率的なCSSやコーディングテクニックといった話ではなく、心持ちの話がメインです。

デザインの意図を汲み取る

デザインと見た目が合っているだけでなく、デザインの意図とコーディングの意図が合うように心がけています。ボタンなのか、リンクなのかデザイン要素によってタグを変えますし、文脈上役割を持たない画像は背景だったり擬似要素を使ったりします。

端的にはセマンティックな話ですが、それだけに留まらず、marginとpaddingのどちらを使うか、レスポンシブの時にどのように変化していくのか、といったところもデザインの意図から考えてコードに落とし込みます。

デザインの意図通りのコードは変更もしやすい

意図を汲み取ったコードにしておくと、多少のデザイン変更にも柔軟に対応できます。変更したデザイン同じようにコードも修正すれば良いからです。

適切なマージンやパディングの取り方をしておけば要素の大きさが変わっても変更箇所以外への影響を最小限に抑えて変更が可能です。逆にデザインの意図と違うと、変更があった時に余計な箇所まで影響を受けて、修正に手間がかかることになるかもしれません。

具体的な例を挙げると、デザイン上の階層構造とHTMLの階層構造が違っている場合です。例えば、デザイン上のグルーピングとdivタグで囲われた要素が違うとレイアウト変更に弱くなってしまいます。

安易なライブラリの使用がデザイン意図とのズレを招く？

Bootstrapをはじめ、便利なライブラリがありますが、あまり安易に利用するとデザイン意図との乖離が生じる可能性があります。デザイン時にライブラリ使用を前提として、ライブラリに乗っかるデザインであれば、シナジーが生まれデザイン意図もコードも齟齬が少ないものに仕上がります。

しかしそうではない場合、ライブラリの制約上デザインの意図とは違った形で実装しないといけないこともあります。ライブラリをハックするようにコーディングしてしまうと、保守性の悪いコードになりがちです。デザインの意図、ライブラリの意図が違う方向を向いている場合は気をつけた方がよいでしょう。

意図ズレはレスポンシブ時に如実出てくる

レスポンシブ時はデザイン意図と実装が合っているか問われる場面です。ウィンドウサイズに応じたレイアウトの変更、要素のサイズ変更が起こりますが、デザイン意図と合っていないと、うまく実装できない（あるいはアクロバティックな実装になる）可能性があります。

また、デザイナーと実装者で意図の解釈が異なることもあります。デザイナーとしては余白だけが広くなる想定でしたが、実装者は全体に大きくするものとして実装してしまった場合などです。異なる解釈がありそうな時はデザイナーに確認します。

デザイン意図の分かりやすいデータだとありがたい

これは実装者からのお願いにはなりますが、デザインの意図が分かりやすいデータだとありがたいです。先程のレスポンシブ時の挙動もコメントなどで補足してもらえるとこちらも懸念材料がなくなり安心です。

「デザイン的にこんな変化の仕方あり得ないだろ」と思う時があるかもしれませんが、実装者はデザインの知識やセンスが必ずしもあるわけではないので、そう解釈されてしまう恐れがあります。お互いの不幸を回避するためにも意図を明確にしたデザインだととても助かります。

Photo by Markus Spiske on Unsplash