こんにちは。エンタメ領域のDXを推進するブロックチェーンスタートアップ、Gaudiyでフロントエンドエンジニアをしているkodai（@r34b26）です。
Gaudiyでは、数ヶ月前からエンジニアによる「デザインレビュー」をワークフローに取り入れました。僕自身は、デザインとエンジニアリングをつなぐことに関心があるのですが、一般的にデザイナーとエンジニアの協業については語られているケースが少ないですし、あったとしても、デザイナー側から寄り添ってくれるケースがほとんどだと感じています。
そこで今回は、Gaudiyでエンジニア側としても課題意識を持って取り組んできたデザインレビューについて、ご紹介したいと思います。
プロダクト品質を高めるために大事な観点だと思うので、よければご参考ください！
1. エンジニアによるデザインレビューを導入した理由
Gaudiyでは、職種を横断したコラボレーションを大事にしています。
デザイナーがプロダクトのUI/UXをデザインし、フロントエンドエンジニアがそのデザインをもとに実装する。それぞれに専門領域があるのはもちろんですが、大事なのはその「橋渡し」だと考えています。
よくありがちなのは、共有されたUIデザインを「決定事項」としてエンジニアが受け取ってしまうことです。そうすると、本来デザイナーが意図していたユーザー体験を実現できない、デザイナーが気付けていない観点を指摘できない、といった問題が生じてしまいます。
Gaudiyでも実際に、Figma上で表現しきれないデザイナーの意図を汲み取れていなかったり、まだFIXしていないFigmaのデザインを参照して実装してしまったり、といった問題がありました。
その結果、フロントエンドの実装では、
- errorやloadingのstatusを考慮しない実装になってしまった
- ユーザーフィードバックへの考慮がされていなかった
- spacingのpxが統一されていなかった
- デザインシステムに定義したものと酷似した”別物”を作り出してしまった
- 必要以上の工数をかけて実装してしまった
- デザイナーの設定ミス(design systemを使わないなど)が実装まで反映されてしまった
などが繰り返し起きていました。
これらは、実装を終えたPRやQAの段階で発見されており、場合によっては期限や優先度を考慮した結果、再実装されないこともありました。
また、上記のような点をPRレビューの段階で「発見できる人」についても、デザインと実装の両視点を持つ特定の人に依存してしまっている状況でした。
こうした課題に対して、手戻りコスト少なく、チーム全体でプロダクトの品質をあげていくため、開発フローにデザインレビューを取り入れることにしました。
2. チーム全体でデザインレビューを強化
では次に、どのような方法でデザインレビューをチームに導入、浸透させていったかについて具体的にお伝えしていきます。
2-1. スタンスを揃える
まずは、デザインに対するエンジニアのスタンスを揃えることから始めました。
「Figmaのデザインは決定事項ではない」ということを明確に伝えた上で、デザイナーにヒアリングして提案する、というコミュニケーションの指針を明確にしました。
2-2. デザインレビューの観点を明示する
次に、上記スタンスのもと、エンジニアがもつべき視点についても言語化しました。
個人的には以前から、デザイナーの成果物に対して以下項目のような視点を持って確認や調整を行っていましたが、それが属人的になっていたのでNotionに書いて他のチームメンバーにも展開しました。
実際の項目を、以下にご紹介してみます。
★最適な機能実装をするために
- 確認しているUIは全て今回の実装スコープですか？
- 確認しているUIは要件やUXのレビューを受けていますか？
- 実装コストの高すぎるUIはデザイナー視点でマストなものですか？
- 実装上の制限で実現できないものはありますか？
- 要件レビューを改めて挟んでもらった方がいい項目はないですか？
★一貫したUIを作成するために
- Figma上、共通コンポーネントが使用されていますか？
- Figma上、デザイントークンが使用されていますか？
- Figmaと実装のコンポーネントの組み方は揃っていますか？
- Figmaと実装の名前は揃っていますか？
★手戻り/抜け落ちがないように
- 新規に共通コンポーネントを作成するべきですか？
- 本当にそこだけのために新しいコンポーネントを作成するべきですか？
- 似てるけど微妙な違いは、本当に生み出すべき違いですか？
- 新規実装するUIの意図は把握してますか？
- 既存のUIとの違いは把握してますか？
★仕様の確認
- レスポンシブの挙動は把握できてますか？
- デザインとデザインの間の挙動は把握できてますか？
- アニメーションはつけなくていいですか？
- 実装上Empty, エラー, ローディング状態は発生しますか？
- ユーザーにEmpty, エラー, ローディング状態は表現しますか？
- アクションできる箇所に対して、フィードバックをつけなくて良いですか？
- 実装上遅れて表示されるところはないですか？
2-3. 日々のワークフローに落とし込む
また、こうしたデザインレビューをチーム全体で意識し、PRやQA間のロスタイムを削るために、ワークフローの中にも「デザインレビュー」を設けることにしました。
2-4. 同期レビューとログの蓄積
さらに実際の行動に移しやすいよう、開発で推奨する行動についてもNotionに言語化しました。これを明記したことで、メンバーにもデザインを確認・調整する行動ができているかどうか促しやすくなりました。
① 同期レビュー
Figma上で「リアルタイムにコメントできる機能」などを活用して、実際のUIを触り、Figma上での組まれ方を見ながら会話をしています。
② ログの蓄積
同期レビューの結果、至った結論や追加の相談事項、対応箇所などに関しては、チケットに書いて受け入れ条件にしています。 また、非同期のレビュー時にも、実物に近いものを見ながら会話するために利用しています。
3. 実際にやってみて感じたメリットと今後の課題
実際にこの取り組みを始めてから、デザインを決定事項として捉えてしまう気持ちがやはり割と強かったんだなと感じました。そこが解消されたことで、エンジニアとデザイナーが適切にコラボレーションする機会が増えたことが一番良かったと思います。
一方で、確認事項にaskベースの項目を並べてしまったのも影響しているかもしれませんが、まだまだ改善しないといけないことは多いなと感じています。
例えば、デザインのパターンや導線、共通化の仕方など、エンジニア側からデザイナーに対する工数や実装方法などを踏まえた提案に関しては、まだまだできていないです。 また、それらの確認や提案が自分で考慮できない時に、他のエンジニアやPMに相談を持ちかける動きができていないことで、考慮すべき点がまだ抜けていることもあります。
この辺りは、引き続きチーム全体で改善を進めていきたいと思っています。
4. さいごに
今回は、Gaudiyで取り組んでいるフロントエンジニアによるデザインレビューについてご紹介しました。
デザインとエンジニアリングをシームレスにつなぐために、今後も試行錯誤を繰り返しながら、よりコラボレーションを深めて良いユーザー体験をつくっていきたいと思います。
またこうした取り組みを進める中で、iCAREさんの以下のスライドが勉強になったので最後にご紹介させていただきます。
エンジニアリングとデザインをつなぐことに関心の高いエンジニアの方は、ぜひカジュアルにお話ししましょう！
Gaudiyの技術選定については、こちらのblogをご参考ください〜
オープン勉強会もやってます
