スタサプ小中で Android エンジニアをしている石田とデザイナーの竹本です。
2023年9月に リニューアルをしたスタディサプリ 小学講座をリリースしました。小学開発ではエンジニアが実装したアプリの画面をデザイナーがレビューするプロセスを デザインQA という形で明文化したので本記事ではその紹介をしたいと思います。
デザインQAの導入経緯
これまでデザイナーが作成したデザインをもとにエンジニアが実装した成果物の確認はお互いによしなにやるという暗黙的な運用になっていました。この運用ではメンバーの裁量に依る部分が大きくなってしまうため、小学開発を機にエンジニアが実装後に必ずデザイナーにチェックを受ける運用にしそのプロセスを デザインQA と呼ぶことにしました。
ちなみにデザインQAのようなアイデアは Issue を作ってメンバーと相談しながら検討します。
実際の デザインQA でのやりとり
デザインQA のイメージが分かるように先に実際のやりとりの様子をご紹介します。例としてトピック一覧、レッスン一覧と呼んでいる画面を取り上げます。
| トピック一覧 | レッスン一覧 |
|---|---|
 |
 |
こちらがデザインQAを行っている様子の全体像です。デザイナーは Figma でデザインを作成しますが、デザインQA もまた Figma 上で行っています。同一ツールを使う方が行き来がしやすいためです。デザイナーが何か問題や相談したい点が見つかったら Figma のコメント機能でやりとりを行います。この例では「レビュー → 修正」のやり取りを3回繰り返しています。
具体的なやり取りを抜粋して紹介します。こちらはレッスンカードについてのやり取りで「カードの Corner Radius が上部と下部で異なっている点」と「カードのドロップシャドウの下部が見切れている点」の2点が指摘されています。
この指摘をもらってエンジニアの僕が正直に思ったのは「デザイナーの目ってすごい。。。」ということです。エンジニアの目ではなかなか気づくことができないこともあるのではないでしょうか。
デザインQA のガイドライン
さて、デザインQAを実施するにあたり一定の約束が必要だろうということでガイドラインを作成したのでその一部を紹介します。
エンジニアは次のスクリーンショットを用意する。
デザイナーは気持ち ゆるめ にレビューをする
- 実装中にデザイン上の問題が見つかった場合はデザインQAを待たずに相談をする。
デザインQA の利点と課題
以下にデザインQAを実際に運用して感じた利点をまとめます。
- クオリティが上がる...！デザイナーのお墨付きがもらえるので自信を持ってリリースできた。
- デザインQAで必ずエンジニアとデザイナーがコミュニケーションを取ることになるので、認識の違いや不明点について細かく会話をしながら相談をしやすくなった。いつどうやって実装をチェックしてもらうかで悩まなくなった。
- デザイナーによるチェックが入るので、エンジニアがコードレビュー時にデザイン通りに正しく実装されているかに注意を払う必要がなくなった。
デザインQA の課題
同様に課題をまとめます。
- AS-IS(実装) と TO-BE(デザイン) の違いを伝えるのに時間がかかることがあった。
- 動きのある画面のチェックが難しい。画面共有では多少カクツキが発生することがあった。
- こちらについては画面をキャプチャしたものをSlackで共有することをいったん推奨しています。一方でデザイナーが実機で実際に動作させながら確認する手段もあると考えています。
- デザインQAの実施コストが一定かかる
- 特にレビューと修正の往復が発生するため実作業の時間はそれほどかからなくても事実としてリードタイムは大きくなりがちです。しかしながら、エンジニアとデザイナーがしっかりとコミュニケーションを取る機会を作り、確実なものをリリースできるという利点が上回っていると考えています。
- また、そもそもの「デザイン→実装」の過程で差分が起きづらくなるような仕組みづくりもしていきたいと考えています。
まとめ
本記事ではリニュアールをしたスタディサプリ 小学講座の開発で導入したデザインQA について紹介しました。デザイナーが作成したデザインはエンジニアがコードにしてはじめてユーザーの元に届きます。デザイナーとエンジニアの認識をデザインQAでしっかりと合わせることによって、「チームで考えたデザインをそのままの形でユーザーにお届けすること」が可能になったように感じています。
今後はデザインQAのガイドラインのアップデートやより効率的な運用を検討していきたいと思っています。本記事がデザイナーとエンジニアのコミュニケーションの取り方の参考になれば嬉しいです。
