デザイナーといい感じに連携したいエンジニアの取り組み

こちらの記事を拝見して、とても開発しやすそうで目指していきたいところでした。
https://note.com/sn_taiga/n/n6015e1e2090b

記事内で指摘されている場面と同じ内容をエンジニアからも、アクションができるといいなと思いつつ、エンジニア側からももっと歩み寄って連携できることがあるのではないかと思い逆の視点で取り組んでいることを考えてみました。

組織的な取り組み

会話が生まれやすい技術選定をする

まず大切なのが「会話が生まれやすい」技術選定をする、ということです。

このために重要なのは、ユーティリティオンリーな記法と、自由な記法を組み合わせることです。
ご存知の通りスタイリングの手法はさまざまありますが、自分はtwin.macroを用いてtailwindとemotionの記法を併用しています。

これによって以下の状況を生み出すことが可能になります。

• ユーティリティオンリーに記述ができないことによって、今実装しようとしているものが事前にデザイナーとともに定めた原則に反するものであると気づくことができる。
• 自由な記法を使って一旦実装してしまうことによって、原則との差分の把握とデザイナーに対する提案を思考しやすくなる。
• 記法が違うことによって、レビュイー、レビュワーなどエンジニア組織内のいずれかの段階で検知されやすく、行動促進がしやすい。

このように、スタイリングの方法に適度な制約を設けることで、エンジニア組織内での気付きを生み出し、そこから会話の機会を生むことができると考えています。

大抵の場合、デザイナーよりもエンジニアの人数が多く、エンジニアは複数名以上で開発するというケースが多いのではないでしょうか。
デザイン知識のある特定のエンジニアに依存しない形で継続的に気づきを生み出し、デザイナーのリソース搾取を減らす形で仕組み化するためには、エンジニアだけの視点で技術を選んでいないか注意する必要があると思います。

個人的な取り組み

問いかける

元の記事で、理由や目的を合わせて伝えるというものがありました。

とてもありがたいことです。
ただし、これがあってもなくても、意見を鵜呑みにしていないか適度に自問自答する機会を設けると良いと思っています。

デザイナーの方々は、UIUX領域に関して、少なくともエンジニアよりはプロフェッショナルと言えます。その人たちが渡してくれたものは疑問なしに受け入れがちですが、それが本当にプロダクトの目標(やらないと決めたことも)に沿っているのか?要件を満たしているのか?などをスキップしてそのまま受け取らないように注意しなければなりません。
ここで少しでも疑問が生まれれば必ずデザイナーに対して、こちらから理由や目的を問いかけるようにしています。

例えば最近デザインシステムを構築しているにあたって、細かいコンポーネントを再整理しているときの一幕です。
Figmaに定義してもらった複数の状態が存在するコンポーネントに対して、疑問をもって問いかけて見ることで

このように、回答を貰え、互いの思考の整理や更なる改善に繋げることができました。

原則を知る

Material Design, Human Interface Guidelines, もしくは組織独自のものかもしれません。
いずれにせよデザインはなんらかの原則に基づいて作成されています。

デザインをしてくれる人にどの原則に基づいているのかを聞いてみましょう、またそのとき実装するコンポーネント単位だけでも原則を覗いて見ると良いでしょう
以前以下のような記事を書きましたが、その少しのリサーチによって実装する時間自体をデザインレビューの機会にすることができると思います。

https://zenn.dev/kodai/articles/32bb66597d01a9