はじめに

私はエンジニアとして、日々デザイナーの皆さんと一緒に、実際にデザイナーがイメージしたユーザー体験の実現に向けて、橋渡しや、すり合わせを行っています。

その際に「このボタンをクリックしたとき、モーダルを開く・画面を遷移する・メッセージを表示するなど、ユーザーにはどんな反応が返るのが理想ですか？」「このコンポーネントは、エラー時や読み込み中にどのような見た目にすべきですか？」といった、動作や意図に関する質問を多くすることがあります。

こうした質問は、決して揚げ足を取るためではなく、実装をより正確に、デザイナーの意図通りに仕上げるためのものです。ただ、すでに別の設計作業に入っているであろうデザイナーに対して、あらためて意図などを確認しなければならない場面が続くと、エンジニアとしても申し訳なさを感じます。

そのような繰り返される質問は、HTML・CSS・JavaScriptといった実装面の知識や、ブラウザの仕組みに対する認識のギャップから生まれているように思います。

この記事は、そのギャップを埋めるために書いています。あくまで「現場の声のひとつ」として、何かヒントになることがあればいいなと思います。

デザイナーが実装を深く学ぶ必要はありませんが、少し視野を広げることで、お互いの仕事がよりスムーズになり、プロダクト全体の質が上がる。その第一歩になれば嬉しいなと思います。

第一回である今回は、実装について知る意義について、掘り下げたいと思います。

デザインの完成はブラウザ上にある

筆者は、デザインという工程を「完結型の作業」とは考えていません。むしろ、それは実装のスタート地点だと捉えています。

なぜなら、その後の議論、実装、そしてユーザーへの提供——すべては、Figmaなどで描かれたデザインを基に進んでいくからです。つまり、最終的なアウトプットの方向性は、デザインの段階でおおよそ決まってしまうといっても過言ではありません。

しかし、そのデザインがユーザーの目に触れるときには、もはや「デザインファイル」として存在しているわけではありません。コードに落とし込まれ、HTML・CSS・JavaScriptとして動作する「作られた体験」として、ブラウザやアプリ上に現れます。

Figma上でどれだけ美しく、機能的に見えるデザインも、ブラウザ上で意図通りに動かなければ、ユーザーには正しく伝わりません。だからこそ、「デザインの完成形はブラウザの中にある」という認識がとても大切だと筆者は思います。

すでにこうした認識を持っている方からすれば、当たり前のことを言っているだけと思われるかもしれませんが、この認識を持っている方は思うほど多くはない、というのが筆者の実感です。

デザインファイルの完成をゴールとするのではなく、「そのデザインは、どう動くのか」「どう再現されるのか」といった視点を持つことで、実装とのズレは大きく減り、ユーザーに届く価値もより大きくなるはずです。

では、どうすればその「ブラウザ上での完成形」をデザインの段階から意識できるようになるのでしょうか？

そのためには、ブラウザの持つ基本的な機能や制約、つまりHTMLやCSS、そしてJavaScriptの挙動を知る以外にないと私は思います。

コードが読める必要はありません！

と、ここまで読んで、HTML、CSS、JSと言われると身構えてしまう方もいるかもしれません。でも安心してください。この記事の目的は「コードが読めるようになること」ではありません。

筆者としても、デザイナーがエンジニアと同じようにコードを読める必要があるとはまったく思っていません。それよりも大切なのは「ブラウザがどんな標準機能を持っていて、どこまでを標準機能でやってくれるのか」といった、いわば「ブラウザという道具の使い方」を知ることです。

この記事でも、コードの紹介は必要最小限にとどめ、なるべく「何ができるか」「どんな選択肢があるか」という視点にフォーカスしていきます。

工数感がわかれば、手戻りが減らせる

ブラウザの機能や仕組みを知っておくことは「これを実現するにはどれくらいの作業が必要か？」という工数感（コスト）の把握につながります。それは、プロジェクトの進行を円滑にし、手戻りのリスクを減らす大きな要因になります。

実例：シンプルなデザインはシンプルに実装できる？

実際に筆者が体験した事例を紹介します。

あるプロジェクトで、クリックすると選択肢が表示されるドロップダウンメニューの実装が必要になり、デザイナーにUIを用意してもらいました。プロジェクト自体は、成果物を素早くユーザーに届けてフィードバックを得るというスピード重視の体制でした。

それを意識して、デザイナーは「なるべくシンプルに」と配慮してデザインをしてくれました。確かに過度な装飾要素は含まれておらず、一見して簡素なUIでした。次のようなイメージです。

しかし、ブラウザ上での「シンプル」と、Figma上での「シンプル」にはギャップがあります。

このケースでは「表示位置がウィンドウからはみ出す場合の挙動はどうするか？」「リストの開く／閉じるタイミングは？」「キーボード操作やフォーカス制御は必要か？」など、実装時に考慮すべきインタラクションがいくつも存在しました。

最終的にこれは、ブラウザに標準で備わっているセレクト要素を使えばいいと判断しました。デザイナーには、標準のセレクト要素であれば、前述した課題がすでに考慮されていること、ただ、その代わりにデザイン上の自由度は下がることなどを説明した上で、セレクト要素を用いた実装を行うことになりました。最終的な実装は次のように、三角形のアイコンのある部分をクリックすることで、ブラウザに備わっているセレクト要素のドロップダウンが表示される形になりました。

デザインをそのまま再現しようとする独自実装と、ブラウザ標準のセレクト要素を使う実装には、次のような違いがあります。

	ブラウザ標準のセレクト要素	独自実装
デザインの自由度	低い（ブラウザのデフォルトスタイルに依存）	高い（CSSで自由にカスタマイズ可能）
実装の工数	低い（ドロップダウンメニューを作る必要がなくなる）	高い（ドロップダウンメニューの実装が必要）
アクセシビリティ	高い（キーボード操作に何もしなくても対応している）	低い（アクセシビリティを考慮した独自実装が必要）

補足：セレクト要素のカスタマウズ

最近では、ブラウザに実装されたセレクト要素をカスタマイズできる機能が策定され、今後、徐々にブラウザに機能追加されていくでしょう。これにより、上述したカスタマイズの自由度というデメリットは払拭されていくことが期待されます。

もちろん、ブラウザの標準機能を使わずに独自実装のほうが望ましい場合もありますし、すべてをネイティブの標準機能に寄せるべきだとは思っていません。ただ、デザイナーから当初いただいた独自実装のセレクトメニューのデザイン案を考えてくださった時間は、結果的に少しもったいなくなってしまったと感じています。

これらの判断はプロダクトの方針や優先順位、ブランド体験など多くの要素を含むものですが、ネイティブ要素とカスタム実装それぞれのメリット・デメリットが見えていると、議論・判断のスピードも速まり、手戻りも避けやすくなると感じています。

まとめ

第一回目である今回は、デザインと実装の間にあるギャップや、それによって生まれる手戻り・認識齟齬の実例を交えながら解説してきました。

特に、ネイティブ要素とカスタム実装の違いを理解していると、実装工数の見積もりや設計方針の判断がしやすくなり、結果的に議論や意思決定のスピードが上がり、無駄な手戻りも避けられる——ということをお伝えしました。

とはいえ、すべてを一人で判断する必要はありません。プロダクトはチームでつくるものです。だからこそ、「実装側の視点」を少しでも知っておくことで、早い段階から議論できる状態が生まれ、チーム全体の足並みが揃いやすくなります。

言い換えれば「実装を知ること」は、よい議論のスタートラインに立つための力になります。その勘が少し働くだけで、プロダクト全体の開発の進み方もスムーズになるはずです。

次回以降は、今回の議論を前提として、具体的に「ブラウザにはどんな機能があるのか？」「標準の要素を使うとどんなふるまいが得られるのか？」といった内容に踏み込んでいく予定です。