エンジニアさんとのデザインコミュニケーションで起きた4つの失敗
「エンジニアリングに興味があるデザイナー、デザインに興味があるエンジニア Advent Calendar」23日目の記事ですぞ。
今年の４月からBONOというUIデザイナーになりたい人向けの動画コンテンツコミュニティの代表しているカイクンです。
Webプロダクトに関わり始めて9年ほどが経ったでしょうか。
デザインシステムやコンポーネント機能なんて存在してなかったころから”作成したデザインデータを間違えなく反映する方法”は皆さん模索されていたと思います。
ノリでアドベントカレンダーに応募したので、今まで良かれと思ってやってきた失敗を書いていきたいと思います。皆さんの参考になれば、幸いでございま〜す。
個人的な経験則です。良いとか悪いとかないと思ってます。同じようにやって上手くいくチームもあれば、同じものもあると思います。
いろんな手法や事例が探すとありますが、正直チームメンバー同士のコミュニケーションが全て決めると思っています。正義も何もありません。全てはコミュニケーション、相互認識のシンクロ率を高めたものたちが強いと思ってます。
失敗その1
UIのマージンやフォントサイズなどの実寸をすべて出して実装のお願いをした
🍣 やったこと
・実装するUIのPxや余白表示を全て可視化してデザイン共有をした
（ボタンの余白いくつ〜など）
・Zeplinなどそういうツールを使ったり…といった具合です
🥸 失敗した…
・実装者観点だと、「次は8px….ここは32px….」と、１つ１つが意味を持ったものと捉えづらい（デザイン的にはサイズに意図がある）
・細かくやれば実装はできるが、間違いは起きやすかった
・実装者の認識コストが高い。1つ1つ見ていかないと間違える。
・なぜここはXpxなのか・・・がコミュニケーションできない。（UIをシステムとしてコミュニケーションできない
🚩 こうしたらよくなったよ
・UI要素を論理定義する（最近だとデザイントークンとか、UIキットとか言われる）
・例：余白のサイズパターンを定義（8/16/20/32/64など）。サイズごとに役割も定義しておく。
→実装がずれてた場合も「あ、こっちのサイズだったのね〜」となるので修正の認識コストが若干低め
→エンジニアさんが自ら実装するときもパターンの中から選べるので比較的カンタンになりやすい
個人的にはUI作る/サービス作る時にしっかり定義しておくと、その後のスピードとか意思決定などにも寄与すると考えてます。なので！手間をかけてでも最初から”フォント”や”配色”、”余白”、”基本グリッド”について定義して伝えるのおすすめです。
MVPだろうがUI作る人の最初の仕事として、しっかり定義しておくと、ベースとなるコミュニケーションを持てるので、ボディブローのようにチームにポジティブな影響が出ると思っております。
失敗その2
ドキュメントに動くGIFやFigmaデータを綺麗にまとめて、実装共有。疑問があればコメントもらう形で進行。結果、意図がずれた実装をさせてしまった。
🍣 やったこと
・実装タスクが多かったので、ドキュメント見れば大体内容がわかる！効率化だ！と思い、ドキュメントに動くもの付きでデザイン内容をまとめた
🥸 失敗した…
・ドキュメントの意図とずれた実装をしてしまった
→時間がないor個人の認識に任せてしまうので、読むべきところを見落としたりが発生
→内容の書き方がよくない場合は意図とずれる。し、コミュニケーションの素地がないチームだと”そのままやるか…"ととりあえず実装されてしまいがち（経験談）
🚩 こうしたらよくなったよ
・デザイン⇄実装の溝に銀の弾丸はない。人の間の認識の溝はコミュニケーション量で埋めるという発想をベースに変える。
・どれだけ業界的に素晴らしい定義だったとしても個人間で認識の違いは多少ある（人間だもの）。ので、コミュニケーション量で共通認識を作る。人やチームの数だけ”最適な定義”が存在する。というマインドに変更
・コミュニケーションから逃げない。ますは量をこなし、良い共有のやり方や定義を固めていく。
結局コミュニケーション＝相互認識とれてるかが、手法より大事です。
結局コミュニケーション！相互認識とれてるかが手法より大事です。
結局コミュニケーション。”相互認識”とれてるかが手法より大事です。
大事なので3回書いてみました。（怖
失敗その3
動くUI(プロトタイプ)で共有しようと思ったあまり、FigmaのボードではUIが読み取りづらいものになってしまった
🍣 やったこと
・条件分岐などが細かく発生するサービスの担当。なるべく触れるものを実現しようと思い、プロトタイプ機能を使って複雑な部分も触って体験できるようにした。
🥸 失敗
・プロトタイプ自体はちゃんと意図が伝わった！が、データ（サイズなど）を見るときに”Aパターンのデータはどこにあるんですか？”という戸惑いを産んでしまった。
🚩 こうしたらよくなったよ
・作成するUIの「フローの切れ目」までで、プロトタイプや仕様をまとめる
・例：購入機能であれば「1:カゴに入れる」「2:清算する」「3:清算失敗パターン」など。で分ける。
・UIのフロー図を作成。その分岐（フローの切れ目）ごとにプロトタイプや仕様をまとめて共有する
新しいツールは黙々と使い込んでしまいますが、他の人も置き去りにしてしまうと意味がなくなってしまいました（特にFigmaはみんなの拠り所になってきつつある）
プロトタイプ機能での表現は非常に重要です。ないのはあり得ないと思っています。が、作り込みしすぎず、”Figmaをドキュメントとして”使うことも視野に入れても良いかもしれません。
失敗その4
UIパターンを出して方向性を話したかったが、”エラーパターン”がない。などの仕様詳細ツッコミをもらう結果になってしまった。
🍣 やったこと
・まだ機能のアイデア段階。プロトタイプでいろんな方向性を模索したかった。
・そのため細かいパターンを抜きに、UIの方向性を検討できるレベルのUIモックを作成。
・MTGで共有した
🥸 失敗
・実装観点でのフィードバックをいっぱいもらってしまった
→まだそこを考えるフェーズではなく、MTGやUIモック作成の目的の齟齬が生まれてしまった
🚩 こうしたらよくなったよ
・デザインのフローを定義してチームにコミュニケーションするようにする
→ガチガチのものじゃなくてOK。むしろシンプルな方が良い
→例：1:模索 → 2:テスト → 3:詳細詰め → 4:共有 → 5:実装
・タスクを決めるときなどに「今週はフローの”１”です！」など言った認識を徐々に出す。
・デザイナー以外も、方向性検討に入りやすくなる（意見を出しやすくなるケースもあった）
今何を目的とやっているのか。が、分業しているとズレることはあるかなと思ってます。簡易でいいので、プロダクトチームのワークフローを共有しているとコミュニケーションが取りやすくなるんじゃないかなあと思ってます。
デザインエージェンシーなんかはきちんとやって意思疎通取ってから、プロジェクト始めてそうですよね（事業会社経験しかないので想像）
4つ書いて印象的なことを書いてみました。まとめてみると
基本的なデザイン要素は定義して共有すると、細かいズレの修正楽になりそう
手法より意思疎通。人やチームの数だけ正義がある
複雑な機能フローは体験別に整理して共有しよう
ワークフローをチームで定義するとアイデアが出しやすくなる
でした。皆さんの失敗はありますか？よければこの記事をシェアして教えてくれると僕も嬉しいです！
またユーザーさんに寄り添えるUIデザイナーを増やすためにBONOというサービスを作っています。同じ気持ちを持っている方、よければざっくばらんにおしゃべりしませんか？興味があれば直接TwitterからDMいただけると嬉しいです！
それでは！
めちゃくちゃありがとうございます😭