デザインレビュー

はじめに

  • この手引きはレビュー依頼時の必要事項を網羅的にまとめ、指針として共有するものです。
  • レビュー時の迷いを減らし、レビュー相手への負荷の軽減する目的で定義しています。
  • この手引きはレビューの手段を強制するものではありません。迷ったらお手本とし、必要があればカスタムしてください。
  • 項目に更新・改修・削除が必要な場合、どんどん編集していきましょう。

本手引きの使い方

  1. 「推奨事項」として書かれていることは、できるだけその方法に沿ってレビュー依頼をすると望ましい事項です。
  2. 「任意事項」は、状況に応じて対応する、または不要な事項です。
  3. レビュー時は、レビューテンプレートをコピーして文書を作成して使ってください。
  4. その後のやり取り方法は各ツールに準拠します。

レビューとは

  • レビューはクオリティを高め、レビュー依頼者が気づかないことへの気づきを与えるものです。
  • レビューは意見の押し付けではなく、ディスカッションです。
  • レビューはあなたの考えを否定するものではありません。

心得

  • 相手の時間を使うことを意識して依頼する。
  • レビューの完了はレビューを出した人が判断する。
  • レビュー中に合意形成ができない場合、第三者に意見を求める。
  • レビュー後の積み上げは基本OK
  • 優先タスクがあればそちらを優先する。
  • 重大な問題がある場合は例外とする。
  • レビューを安易に進めては行けない、議論して揉んでから進む。
  • 互いに納得してから先に進む。
  • 後出しで負荷がかかる可能性が高い。
  • 休暇取得中の人へのレビュー依頼は原則しない。
  • 依頼されても別に返事はしなくてよい。

レビューの目的・目標

  • レビューは、レビュー依頼側がレビューで達成したい目的・目標を設定し、レビュアーに明示する。
  • レビュアーはその目的・目標に沿った成果物・コードを軸に判断し、コメント、アドバイス・助言する。
  • チームの知見や気づきを糧に品質を向上し、深遠なるインターフェースの極地にたどり着くための儀式である。

レビューの種類

種類目的強制力 ※1対象対象チャンネル
開発プロジェクトレビュー開発プロジェクト内のレビュー強強PdM, エンジニア, ドメインマスター等各プロジェクトのチャンネル
プロダクトデザイングループレビュープロダクトデザイナー観点で品質を上げるためのレビュープロダクトデザイナー#design_products
コンポーネントレビュー ※2Figmaライブラリとしての利便性・再利用性、実装のことを考えたレビュープロダクトデザイナー, エンジニア#pj_smarthr_ui
  • ※1 フィードバックに対しての対応がどの程度求められるか。
  • ※2 現状はSmartHR UIを指す。いずれデザインシステムレビューになる想定

レビュールール

プロジェクト後に性質が違うため、それぞれ定義します。

  1. 開発プロジェクトレビュー
  2. プロダクトデザイングループレビュー
  3. コンポーネント(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としての仕様
(例)
- 〇〇はコンポーネント化して、切り替えられるようにする
- 〇〇はコンポーネント化しない
# チェックしてほしいこと
特にチェックして欲しい点があれば書く
(例)
- コンポーネント名の構造的に妥当かどうか
- 見た目・ラベルに違和感が無いか
- 状態は〇〇と〇〇
# チェックしなくてよいこと
レビュー時に、ここは見なくても良いという点があれば書く