エンジニアが最低限注意すべきデザインについてのお話

こんにちは。@inase17000です。

無事に2021年を迎えることができました。今年もひとつユアマイスター（と小粋fm）をどうぞよろしくお願いいたします。

さて、今回はデザインに関する話です。

ぼくはデザインの専門家ではないので、本格的な解説は弊社デザイナーがまた粋なブログを書いてくれるのを待つとして、個人的にもっと早く知っておきたかった！と思うところを中心に最低限注意すべきことをまとめておこうと思います。

デザインはアートと違う

ぼくがデザイナーと呼ばれる方と協同作業をするようになったのも社会人でエンジニアになってから。それまで「デザイン」というものとは遠い世界で生きていました。

「デザイン」という言葉を聞いてついつい想像してしまうのは、なんとなく絵画や芸術作品にあるような一部の人だけが作ることができる美術の授業で習うようなものですよね。つまり、「アート（見る人によって感じ方が違う美的な表現）」に近いと捉えていました。

「デザイン」と「アート」は違うものです。

「デザイン」はあくまでそれを見た人にわかりやすく親しみやすく伝えることが目的の行為であり、カッコいいとか目新しいことが唯一の価値ではないということが、デザイナーと一緒に働いていく中で学んできました。

ちなみに、デザインを担うのは必ずしもデザイナーだけとは限りません。デザインを日本語に訳すと「設計」になりますので、基本設計・詳細設計を担うエンジニアもデザインを担当することがあることを忘れてはいけません。

「デザイン思考の授業（佐宗邦威著）」では以下のように紹介されています。

デザイン：人間の生活にとって理想的な姿を描く力 (What to do)

エンジニアリング：理想的な姿へ解決策を実現させる力 (How to make)

ビジネス：解決策のインパクトを持続可能に最大化する仕組みを作り、人を動かしていく力 (How to maximize)

つまり、抽象度高めの部分を担当するのがデザインで、抽象度低めの部分を担当するのがエンジニアリングであるため、デザイナー・エンジニアはそれぞれの領域は独立したものではなく連続的なものだと考えると、お互いに染み出してコラボレーションし合う環境がいいなと思うわけです。

プロフェッショナル同士がお互いの主務にリスペクトしながら、切磋琢磨する環境って素敵です。違いを認めながら、それぞれの目的を大事にして、ものづくりに携われたらいいですね。

デザインの４大原則

有名な ノンデザイナーズ・デザインブック（Robin Williams著）で紹介されているデザインの大原則が４つあります。ひょっとしたらどこかで聞いたことがあるかもしれません。

①近接（Proximity）

近接は、関連性に応じてグルーピングしたり、分類したりすることを指します。

ブレストをした付箋たちを、バラバラに配置されていたものを何らかのルールに従って各情報をグループ化した経験があると思います。

そんなイメージで、それぞれのグループにまとめたあと、グループ間の余白をしっかり設けることで、ぱっと見で分類を理解しやすくできます。

近接とは、関連する項目をまとめてグループ化することです。
切れ目のないテキストのままでは、文頭から文末まで読まなければ内容を理解できません。バラバラに配置されたまとまりのない情報も、理解するのに時間がかかります。

関連性を考慮し、同じ種類や系列の情報を近くに配置しましょう。

②整列（Alignment）

整列は、デザインの要素となるパーツの、位置・色・大きさ・形状を揃えて、見た目を整えることを指します。

整列を使うと、デザインの中に統一感を感じられるようになります。左右上下で揃えたり、中央で揃えたりと基準となる場所を要素ごとに決めて使われます。

③反復（Repetition）

反復は、デザインの中で同じようなルールを繰り返し使用することを指します。

要素を繰り返し使うことで、一貫性や統一感のあるレイアウトに繋がります。反復を行う場合には、近接や整列と同時に扱われることが多いです。

④強弱（Contrast）

強弱は、似たようなものが複数ある場合に、目立たせたいものをよりはっきり目立たせるために違いをつくることを指します。

見た目の変化の付け方としては、フォントの大きさやフォントの太さ、下線での強調などどちらか一方に加工を加えてメリハリをつけます。

要素同士の違いに着目させたいときに有効です。

この４つのポイント、新人時代、プレゼンテーションの作り方のときにも同様のことを先輩から耳にタコができるほど言い聞かされたのを覚えています。

毎回使う言葉は違いましたが、先輩に言われていた「近くにまとめる」「端をそろえる」「同じパターンを繰り返す」「メリハリをつける」と言ったアドバイスは的を得ていたんだと改めて思います。

そして、実際にプロダクトづくりにおいても非常に重要だと改めて感じている考え方です。これを知らずに画面の実装に携わることがないよう知ったかぶりできるくらいには見聞きしておきましょう。

デザイナーとエンジニアの役割の境界

さて、デザイナーとエンジニアがコラボレーションしながら開発していくわけですが、時折デザイナーとエンジニアの役割の境界線が見えづらくなることがあります。

例えば、

・「センター寄せにしてほしい」のは決まっているけど、「余白を何pxにすればいいのか？」って誰が決めるの？

・デザイナーがFigmaに置いている画像はあるけど、Retina対応をして2倍の解像度の画像もセットするのって誰が確認するの？

などなど、数えあげたらキリがないと思います。

具体的に線引きがしづらいのは何故かというと、デザイナーとエンジニアの担当領域に重複があるからなんですね。

プロダクト開発は、抽象的な要求や課題解決案を徐々に具体的にしていくプロセスの連続だと考えることができます。

事前にマーケットがあるか、顧客のニーズがあるかの仮説が立っている領域に対して、特定のプロダクトをつくり、顧客に喜んでもらえる・不を解決するために、使いやすい・わかりやすい体験を設計し、見やすい・伝わりやすいUIを考えていく段階をデザイナーが担当します。

そして一定程度の具体性が出てきたところで（実際にはデザインモックやプロトタイプ、紙芝居あたりが出来たところ）エンジニアが肩慣らしを始めるタイミングです。

もっとも実装方法がなければ、どんな優れたUI/UX案も顧客に届くことはありません。なのでエンジニアはなんとか形にすることに夢中になります。

同じUIでも実装方法は何通りも考えられますが、その中でも実装が早いものやメンテナンス性が高いものをを自信の知見からさっと選び出し、最終的なプロダクトに落とし込んでゆくのです。

このように、抽象的なもの→具体的なものに移し替えていくプロセスを、デザイナーとエンジニアがバトンパスをしていくことがプロダクト開発と言えます。

子供のころ、リレーでバトンパスするときに、「三歩目から走り出そう」とか「受け渡しのときに上から手のひらに置こう」とか仲間と練習しませんでしたか？（ぼくはクラスの中でも足が特別遅かったので機会は少なかったですがw）

このバトンパスのときの練習で決めた、お互い気持ちよく走り抜けることができる方法みたいなものが、デザイナーとエンジニアの間でも確実に存在します。

エンジニアが最低限注意すべきこと

阿吽の呼吸でバトンパスができる方法を個人的な経験から考えていることを３つ共有します。

まず１つ目。

①ひとつひとつのデザインの意義を大切にする

デザインの目的は伝えることと最初に書きましたが、この４原則ももちろんそれを見た人に伝わりやすくするためのものです。

実際のプロダクトのデザインを考えたときに、デザインの意図は明示的に書かれません。（いちいち「これらは●●だから近接して、整列しました」なんて製品上に書かれていたら邪魔なだけ）

ただなんとなく自然にそうなるわけではなく、目的を持ってデザインがなされていることを知りましょう。

その意義を理解しリスペクトを持って行間に含まれた「伝わりやすくなれぇぇぇ」というデザイナーの情熱も実装に込めてあげましょう。

側から見るとどうでもよさそうなことでも、そこに意義があり目的を見出している人にとっては必ず届けたいものの一部なのです。

そして２つ目。

②神は細部に宿るし、細部まで気づける人のほうがプロフェッショナル

ちょっと個人的な偏見も入っているかもしれませんが、多くのデザイナーと接してきた中で必ずと言っていいほど大雑把な人はいませんでした。

毎回びっくりさせられるのですが、プロフェッショナルは本当に1px単位で仕事をしているし、ずれていると気付けるのです。カラーコードもちょっとずれていたりすると必ず違いを指摘されます。

この感覚はエンジニアと似ているところもあるなぁと思っていて、変数名やメソッド名に平気で１時間くらい頭を悩ませることってありますよね。1文字単位で考え抜くし、それが検討違いな名付けをしてしまうと、後世にまで呪いを残すことになります。

そんな風に、自身の領域をこだわりを持って担当していくのは大前提として、本当のプロフェッショナルは他者ともそのリスペクトをもってやりとりができる人だと思います。

妥協なき細部までのこだわりを持って実装すること。それが高いレベルでの要求を産み、チーム内にいい緊張感を醸成していくのではないかと考えています。

最後に３つ目。

③普段から関係性を築くコミュニケーションをとる

これまで２つの視点で、意図を考え、細かく見れるようになったら正確に実装はできるようになるかもしれませんが、コラボレーションがうむ掛け算のアウトプットみたいなことまで期待するにはやっぱりコミュニケーションが大事だと思うのです。

しかも必要に迫られたコミュニケーションというより、むしろ普段から何気ないプロダクトに関する会話が重要だと考えます。

「ここってなんでこうなってるんですか？」って気軽に聞けたら、

「あーそこは●●みたいな背景があって、別案も考えたんだけど●●な理由でこっちにしたんだ」

「なるほど（そういうことか、じゃあこういう実装にしておいたほうが後々良さそうだな）」

みたいな会話につながって、あっという間にいいものが出来そうじゃないですか？

どんなデザイン、どんな機能にも必ず目的があるはずです。（目的がないものだったら即取っ払ったほうがいいw）それを共通認識として持っておけるようにコミュニケーションをとっておくことがエンジニアにとっては一番大事なことかもしれません。

あまり説教臭くなるのは御免なので今日はここら辺にしておきます！

プロダクトづくりを一緒にやってる @takuya__kuboのブログも、UXとBusinessの掛け算で面白い視点をくれますのでおすすめです！

あわせてお読みいただけると良いかと思います。

それでは、現場からは以上です！（とある方の締めのマネ）