デザイナー・エンジニア間の「認知の違い」と「互いの歩み寄り」について

こんにちは、株式会社アジアクエストでフロントエンドエンジニア兼UIデザイナーをしています石亀と申します。コロナウィルスの影響によりリモートでのお仕事になり、家の中のワークスペースが充実していって外出するのが億劫になってますが、みなさんいかがお過ごしでしょうか？

フロントエンドエンジニアとして３年ほどお仕事させていただいてまして、デザイン部分で苦労することだったり勉強になる部分がたくさんあります。

その中でも、デザイナー・エンジニア間のコミュニケーションは非常に重要でありつつも最も苦労する部分で、特にデザインの齟齬は非常に厄介な問題であります。しかし、変化の激しい世の中でソフトウェアを開発するという不確実かつ複雑性を伴う分野において、かなり重要な問題になると思ってます。

そこで今回は、なぜそんなことが起こるのか、それがどんな影響を及ぼすか、解決するためには前提として何を知らなければならないのかを体系的にまとめてみたので、ご参考にしていただければと思います。

デザイナーとエンジニア間の「認知の違い」について

みなさん、こんな苦労をしたことは無いでしょうか？

・同じ部品なのに大きさが微妙に違う
・デザインの修正や仕様確認が多くて実装がなかなか進まない
・XDやFigmaで上がってきたデザインの手戻りが多い
・文字がはみ出る場合や非活性時のデザインが考慮されていない
・etc...

など上げ出したらキリが無いと思います。

デザイナーが満を時して作ったUIをエンジニアが実装するときになって、画面の数が多ければ多いほど都度都度手戻りや確認などの差込作業が入り、もどかしい思いをする人もいると思います。

なぜ、同じデザインに関心を寄せているのにも関わらず、こうも手戻りやコミュニケーションコストが爆増してしまうのでしょうか。　

そもそも、同じデザインを見ていても職業の役割と特性上、視点が違う結果インプットする情報が異なっている、つまり「認知」が異なっていると考えています。

デザイナーの視点

仕事の特性上デザイナーは、サービスのブランドとしてなぜ・何を・どうやって表現するのか、ユーザーは何を課題解決するのかという抽象度の高い情報を噛み砕きチャンクダウンしていきながら、必要な情報設計やナビゲーション、そしてユーザーインターフェースへとビジュアライズしていきます。

つまり、サービス全体あるいは必要なタスク全体を見渡しているので、非常に コンテキストドリブンな見え方になっています。キーワードとしては以下のような感じになると思います。

・抽象的、広いカバー範囲、コンテキスト
・ブランドとしての表現
・ユーザーの導線
・ナビゲーション、画面遷移
・情報設計

エンジニアの視点

一方、エンジニアは画面や部品一つ一つに対してどういった振る舞いを持つのか、というところに関心があります。

例えば、
・このボタンは非活性時にどんな色になるのか
・ホバーした時押した時にどんなアニメーションが効くのか
・幅が変わった時や文字がたくさん入った時どうなるか

などオブジェクトが持つ状態（ステート）によってどんな挙動をするのかに関心を寄せている場合が多いです。オブジェクト指向プログラミングでプロパティとメソッドを持っている感覚に近いですね。

つまり、ビジュアライズされた画面やオブジェクトがどう配置され、どのような機能・動作・振る舞いをするかという「コンテンツドリブン」な見え方になっています。キーワードとしては以下のような感じになると思います。

・具体的、深いカバー範囲、コンテンツ
・状態（ステート）の管理、それによる振る舞い
・オブジェクト指向
・プロパティとメソッド

関心ごとの抽象度の違いもありますが、上がっているキーワードを見てみても、全然違うことがわかりますね。

上記の明確な違いがあることがわかりましたが、それによって以下の弊害が起こり得ます。

・デザイン手戻りによるコミュニケーションコストの増加と遅延
・デザインの修正や確認などの差込作業によるDX（開発体験）の低下
・ブランドの表現担保が出来ない

そして昨今のフロントエンド実装ではコンポーネント指向が開発が主流であるため、再利用性を高めたデザインというのもエンジニアにとっては非常に都合が良いのですが、コンテキストによってデザインが変わる認知をしているデザイナーの認知とバッディングしてしまう、ということも起こります。

そのために、僕らは何を知り、何を解決すべきか

UI/UXの重要度が如実に上がってきている時代に、デザインの担保と開発との繋ぎ込みの問題は組織だけでなく事業に影響を与えうる問題に繋がると考えているので、実は解決すべき大事なイシューだと思ってます。

では、先ほどの弊害が起こらないようにする、あるいは低減させるために何ができるか

一つ目は、「UI Stackについて知る」です。

UI Stackについてはこちらの記事で非常にわかりやすく説明されています。

端的にいうとUIは「状態」を持っていてそれによる振る舞いを考慮しましょう、というフレームワークです。もちろん、部品によってその状態が増えたり減ったりすることがあるかもしれませんが、エンジニア観点でみても非常に考慮漏れが減りますし、サービス問わず使えるので観点として持っておくと自然と共通言語が出来、建設的なUIの議論ができるようになります。

二つ目は、「お互いの認知が違うということを知る」です。

先ほど、デザイナーはコンテキストドリブンで見ていて、エンジニはコンテンツドリブンで見ている、ということを書きました。言ってしまえば、一方は赤い透明フィルターを通して外を見ていて、一方は青いフィルターを通して外を見ている感じですね。

かけてる眼鏡が違うので同じものをみても青と見えるひとに、「それは赤だろ」と苛立つ状態だと、たとえ軌道修正しようとしても、お互いのバックグラウンドや置かれてる立場や役割を知らなければなかなか建設的な議論をするのは難しいです。

ですので、お互いの色眼鏡の色が違う、ということを知るのが大前提として知るべきことです。つまりは「お互いに歩み寄る」ということです。

色眼鏡の色が違うのはカバーすべき情報が異なってしまっているだけなので、その背景を踏まえて上でデザインを見つめ直すことが重要です。両者とも良いデザインにしていこうという意思はあるはずなので、両者の違いを理解した上でデザイン業務を行っていきましょう。それでは！