デザインレビュー
はじめに
- この手引きはレビュー依頼時の必要事項を網羅的にまとめ、指針として共有するものです。
- レビュー時の迷いを減らし、レビュー相手への負荷の軽減する目的で定義しています。
- この手引きはレビューの手段を強制するものではありません。迷ったらお手本とし、必要があればカスタムしてください。
- 項目に更新・改修・削除が必要な場合、どんどん編集していきましょう。
本手引きの使い方
- 「推奨事項」として書かれていることは、できるだけその方法に沿ってレビュー依頼をすると望ましい事項です。
- 「任意事項」は、状況に応じて対応する、または不要な事項です。
- レビュー時は、レビューテンプレートをコピーして文書を作成して使ってください。
- その後のやり取り方法は各ツールに準拠します。
レビューとは
- レビューはクオリティを高め、レビュー依頼者が気づかないことへの気づきを与えるものです。
- レビューは意見の押し付けではなく、ディスカッションです。
- レビューはあなたの考えを否定するものではありません。
心得
- 相手の時間を使うことを意識して依頼する。
- レビューの完了はレビューを出した人が判断する。
- レビュー中に合意形成ができない場合、第三者に意見を求める。
- レビュー後の積み上げは基本OK
- 優先タスクがあればそちらを優先する。
- 重大な問題がある場合は例外とする。
- レビューを安易に進めては行けない、議論して揉んでから進む。
- 互いに納得してから先に進む。
- 後出しで負荷がかかる可能性が高い。
- 休暇取得中の人へのレビュー依頼は原則しない。
- 依頼されても別に返事はしなくてよい。
レビューの目的・目標
- レビューは、レビュー依頼側がレビューで達成したい目的・目標を設定し、レビュアーに明示する。
- レビュアーはその目的・目標に沿った成果物・コードを軸に判断し、コメント、アドバイス・助言する。
- チームの知見や気づきを糧に品質を向上し、深遠なるインターフェースの極地にたどり着くための儀式である。
レビューの種類
種類 | 目的 | 強制力 ※1 | 対象 | 対象チャンネル |
---|---|---|---|---|
開発プロジェクトレビュー | 開発プロジェクト内のレビュー | 強強 | PdM, エンジニア, ドメインマスター等 | 各プロジェクトのチャンネル |
プロダクトデザイングループレビュー | プロダクトデザイナー観点で品質を上げるためのレビュー | 柔 | プロダクトデザイナー | #design_products |
コンポーネントレビュー ※2 | Figmaライブラリとしての利便性・再利用性、実装のことを考えたレビュー | 剛 | プロダクトデザイナー, エンジニア | #pj_smarthr_ui |
- ※1 フィードバックに対しての対応がどの程度求められるか。
- ※2 現状はSmartHR UIを指す。いずれデザインシステムレビューになる想定
レビュールール
プロジェクト後に性質が違うため、それぞれ定義します。
- 開発プロジェクトレビュー
- プロダクトデザイングループレビュー
- コンポーネント(SmartHR UI)デザインレビュー
1. 開発プロジェクトレビュー
関わる人数が多く、職種も多様なので、目的・背景・概要・レビューして欲しい点を明確にして行なうことが求められる。ただし、人数が少ない場合などはこの限りではない。
推奨事項
- 前提としてデザイナー以外のメンバーが見ることを想定する。
- 仕様やどういったレビューをするか、事前に明示しておくことが望ましい。
- レビューテンプレートを元に先行して送っておく。
- レビューの数日前に送り、前日に再度確認のプッシュをしておく。
レビュー手段
- ツールは限定しない。
- レビューを依頼したいユーザーの環境次第とする。
- Slackスレッド、Jiraのチケット詳細に記述されることが多いことを前提とする。
2. プロダクトデザイングループレビュー
相談しやすいよう、雑談ベースのふんわりなレビューでも可。具体的にレビューをしてもらうことを前提とした場合としてのガイドを紹介する。
推奨事項
- 基本的に、デザイナーの文脈でレビューをしてもらう。
- 関わっていないプロジェクトへのレビューを求められることが多い。
- 背景とどういうものかの説明を用意したうえでレビュー依頼する。
- レビューポイントを絞り、要点を噛み砕いて説明する。
依頼方法
- プロデザレビュー会に持ち寄る。
- CodiMDに相談事項を書き、その場でレビューしてもらう。
- 内容が詳細にわかっている場合、テンプレートを元に書き、事前に共有しておく。
- Slackのスレッド上でレビューしてもらう。
3. コンポーネント(SmartHR UI)デザインレビュー
レビュー対象が小さく具体的なレビューとなるので、仕様やレイヤー構造まで書き、レビューを依頼する。
推奨事項
- テンプレートに従い、具体的な情報を書いて、レビューを依頼する。
依頼方法
- レビュアーは最低2人を指定し、レビュー依頼する。
- レビュアー2人からLGTMを貰えれば完了とし、masterにマージする。
レビュー手段
- Figma上でのレビューを軸とする。
- 即応性が欲しい場合等は、Slack等でも可能
- 画像が添付できないなどの制約があるので、不便と感じた場合はSlackを使う。
レビュー中のポイント
- レビュー観点から逸れそうな意見も拾うために、例えばSlackのスレッドやMiroの付箋置き場など、書き留める場所を用意しておく
- 確認を求めたい点、不安な点を明確にする。
- 完了後のアクションを明確にする。
- 意見をもらい、答えは求め過ぎない。
- 受け身でなく、能動的にレビューをもらうようにする。
レビューテンプレート
汎用テンプレート
## 関連リンク* FigmaやJiraの関連リンクを書く## レビュー概要・背景(例)- 〇〇がプロジェクトとして進行し、それと連動して〇〇の画面を〇〇することになった## レビューの目的(例)- 〇〇の対応です。〇〇に〇〇が操作的に正しいかレビューしてほしい- 〇〇について悩んでいます、その中の〇〇についてレビューしてもらいたい## レビュー完了条件通常のレビュー依頼とは違う条件がある場合に書く(例)- 〇〇さんからレビューでOKをもらったら完了- チーム全員のOKで完了## レビューして欲しい点(例)- 〇〇のライティングの認知負荷的に問題なさそうか?- 〇〇の部分がこれでいいのか悩んでいる- バリエーション・追加の状態が必要かどうか?- アクセシビリティの観点から見て問題ないか?- 既存システムへ組み込めそうか?## レビューしなくてよい点明確にこれは除外したい、余計な判断にならないようにしたい場合に記述(例)- 〇〇から以下はスタイルが崩れているが、キャプチャなので除外- 〇〇以外は見ないでおk## 言い訳理想値ではない場合、やむを得ない形で提出する場合記述する(例)- SmartHR UIを使いたかったが、機能的に不足があってたので...## 類似画面- 近しい画面、パーツがある場合は、リンク、または画像を添付する- Figmaのモックアップを使って説明する等
コンポーネントデザインレビュー用テンプレート
# 関連リンク* FigmaやJiraの関連リンクがあれば書く# 追加したコンポーネント更新した対象のコンポーネント名をかく。どのような役割かを書くとベター(例)- forms/TextArea/xxxxx- 残り何文字かを表示したテキストと、TextAreaをセットにしたコンポーネント名# コンポーネントの構造更新した対象コンポーネントのレイヤー構造を書く(例)- forms/TextArea/xxxxx- text- TextArea# 動作仕様想定している動作仕様を書く。具体的に書けると望ましい## コードレベルでの仕様(例)- 〇〇字以上入力されたら〇〇を赤くする- 横幅〇〇px以下になったら〇〇を○する## Figmaとしての仕様(例)- 〇〇はコンポーネント化して、切り替えられるようにする- 〇〇はコンポーネント化しない# チェックしてほしいこと特にチェックして欲しい点があれば書く(例)- コンポーネント名の構造的に妥当かどうか- 見た目・ラベルに違和感が無いか- 状態は〇〇と〇〇# チェックしなくてよいことレビュー時に、ここは見なくても良いという点があれば書く