前置き
筆者について
新卒から5年間、主にフロントエンドを担当するWebアプリケーションエンジニアとして働いています。大学ではUIUX分野を学んだ経験があり、デザインのバックグラウンドをもっています。
この記事の成り立ち
この記事のベースとなったのは、入社2年目（エンジニアとして働いて半年から1年ほど）に部内のLTで発表したスライドです。デザインという言葉は曖昧で、当時感じた考えや自分の中の考えをまとめたものでした。
5年目となった今、過去の自分の思考を再整理し、社内に留めず広く公開してみようと思い、この記事を書くことにしました。
この記事で扱う「デザイン」の範囲
デザインという言葉は非常に広い概念ですが、私個人がエンジニアとして実務で意識することの多い、「見た目の整頓」と「使いやすさ」を中心にまとめていきます。
メッセージ性、雰囲気の出し方、ブランド戦略、といった要素は扱いません。あくまで、私個人ととしてデザインをどう捉えているのかをまとめています。
本編
ここから、スライドの画像も挟みつつ文章も交えまとめていきます。
この章では、「エンジニアとしてデザインとどう関わるべきか」を考える前提として、そもそもデザインとは何なのかを整理していきます。
デザインとは何か
「デザインとは何ですか?」と聞かれたら、答えられるでしょうか。
おそらく難しいと思いますし、人それぞれで正解はないと思います。多くの人はデザインに芸術的な側面を感じ、センスが大事だというイメージを持っているかもしれません。しかし、デザインの語源を辿ると、実は異なる側面が見えてきます。
デザインの語源
デザイン(Design)の語源は、ラテン語の「designare」で、「計画を記号に表す」という意味です。つまり、デザインとは本来「設計」を意味する言葉であり、論理的なものであると考えられます。
デザインとアートの違い
デザインという言葉をより明確にするため、「アート」との違いを見てみましょう。主観ですが、比較用に表としてまとめました。
比較してみるとなんとなく違いを感じられるのではないでしょうか。デザインはあくまで目的として問題解決があり、再現性があるもの、つまり客観的に見て論理的な側面が強い、語源通り「設計」に近い概念なのではないでしょうか。
デザインの4大原則
抽象的な話が続いたので、ここからは具体的なデザインの原則について話していきながら、デザインについて考えてみます。
4大原則についてはネットの記事も多くあるので、既に知っている方やそちらを参照したい方はこの章を飛ばしても問題ありません
近接
関係する情報は近づけ、関係しない情報は離す。これにより、視覚的なグループ化が生まれます。
関連する情報は近づける
関係しない情報は離す
ダメな例
真ん中のタイトルが上下どちらの図に紐づいているかわかりにくい。
整列
要素を意図的に揃えることで、視覚的な秩序が生まれます。
要素を揃える
ダメな例
上下左右そろっておらずガタガタしている。
反復
同じ特徴を繰り返すことで、一貫性と統一感が生まれます。
同じ特徴を繰り返す
ダメな例
図とタイトルのセットがバラバラであり、同じ要素として伝わりにくい。
対比
異なる要素に明確な違いをつけることで、重要度や状態を視覚的に伝えます。
異なる要素に違いをつける
ダメな例
タイトルと本文がぱっと見でわからない。ボタンが押せるのか押せないのかわからない。
フロントエンドエンジニアの視点からのデザイン4原則
基本的に、この4原則で見た目の整頓に関するデザインは説明できると考えています。なぜダメなのか、どう改善すればいいのか、論理的に説明できるためです。
ここで、フロントエンドエンジニアの視点からデザインの4原則を捉え直してみます。
近接
関連する要素を近づけるという原則は、UIコンポーネントのグループ化やレイアウト設計と同じです。フォームの入力項目とラベルを近づける、関連するボタンをまとめて配置する。これは視覚的な近接であると同時に、論理的なグループ化でもあります。
反復
同じパターンを繰り返すという原則は、再利用可能なコンポーネントを作る設計思想と一致します。ボタンのスタイルを統一する、カードレイアウトのパターンを繰り返す。これは見た目の一貫性を保つと同時に、コードの再利用性も高めます。
対比
要素に意味を持たせるという原則は、セマンティックなHTML設計と同じです。<h1>、<h2>といった見出しタグや、<button>、<a>といった要素の使い分けは、セマンティクス(意味論)に基づいた設計です。これは、見た目以前に要素として違い(意味)をつけることです。
整列
要素を揃えるという原則は、グリッドシステムやレイアウトの一貫性を保つことと同じです。CSSのFlexboxやGridを使って要素を整列させる、余白を統一する。これは視覚的な秩序を生むと同時に、実装の一貫性も保ちます。
まとめると
フロントエンドエンジニアとしてきちんと設計をする ≒ デザインをする と言っても過言ではないのではないでしょうか。
結局、デザインの基礎的な4大原則は、広く捉えるとフロントエンドエンジニアとしての設計と本質的に同じであるとかんがえています。論理的に説明でき、再現性があり、センスではなく論理で成り立っていると言えるのではないでしょうか。
ただ、ここまでデザインは論理的な側面が大きいと伝えるためにデザインの4大原則に絞って話してきましたが、それだけではデザインのほんの一部分しか表しきれません。
次の章では違った側面でのデザインについて考えてみます。
使いやすさとしてのデザイン
ここまで、デザインの4大原則はエンジニアにおける設計と本質的に同義という話をしてきました。では、エンジニアとして良い設計をすれば「良いデザイン」になるのでしょうか?
4大原則だけでは表せないデザイン、良いデザインの1要素である「使いやすい」に目を向けて考えてみます。
良い設計は、「使いやすい」デザインの必要条件ではありますが、十分条件ではないと思います。良い設計ができていても、それだけでは使いやすい製品にはならないのです。
では、「使いやすさ」とは何なのでしょうか。
ユーザビリティ（使いやすさ）とは
「使いやすさ」を測るための概念として、ユーザビリティがあります。
ユーザビリティは3つの観点を定め、3つの尺度で測ります。
3つの観点(何を定めるか)
3つの尺度(何で測るか)
使いやすさはコンテキスト依存
ここで伝えたかったのは、ユーザー、利用の状況、目的などが異なると、ユーザビリティは変化するということです。
つまり、すべての人にとって使いやすいデザインは存在しません。
お客様の利用状況や目的を正しく汲み取り、そのユーザーにとって使いやすいデザインを検討し作り出してくれる。これがデザイナーの力であり、エンジニアとは異なる専門性だと考えています。（もちろん、エンジニアもお客様目線で考えることが大事ですが）
まとめ （エンジニアとしてのデザインへの関わり方）
ここまでの話を整理すると、デザインには2つの側面があることが分かります。
良い設計（ここでは4大原則を指す）は変化しない。 どんなユーザーにとっても、どんな状況でも、近接・整列・反復・対比は有効であり、これは普遍的な原則だと考えています。
一方、使いやすさは変化します。 ユーザー、状況、目的によって、何が使いやすいかは変わります。これはコンテキストに依存します。
普段私たちはこの2つ一つのデザインの概念として混同しがちですが、明確に分けて考える必要があるのではないでしょうか
エンジニアとして何を担保すべきか
結論として、エンジニアは変化しない部分のデザインを担保すべきです。
もちろん、使いやすさについて意見を持つことは重要です。しかし、それはコンテキストに依存し、変化するものだと理解しておくことが大事だと考えます。
まずは、誰にとっても必要な、変化しない設計をしっかりと守ること。これが、エンジニアとして目を向けるべきことではないでしょうか。