スキル自身の言葉で
UIコンポーネントを構築する人やフロントエンドのコードをレビューする人のために書かれた、インターフェースを洗練させるためのデザインエンジニアリングの原則です：ホバー状態、シャドウ、ボーダー、タイポグラフィ、アイコン、マイクロインタラクション、エンター／エグジットアニメーションを扱います。
19の番号付きコア原則とハードデフォルトを備えています——同心円状のボーダー半径、オプティカルアライメント、偽の立体感を出すボーダーの代わりに使う多層ボックスシャドウ、中断可能なCSSトランジション、約100msのスタガー、アンチエイリアス処理されたテキスト、等幅数字、純粋な黒または白の画像アウトライン、押下時の scale(0.96)、44×44pxのヒット領域、テキストに合わせたアイコンのストローク幅などです。クイックとフルの2つのレビューモードがあり、原則ごとにグループ化されたSeverity/Location/Before/After/Whyのテーブルを生成し、5件または15件の指摘に上限を設け、最後にBlock、Needs changes、Approveのいずれかで結論づけます。
生成されるもの
- 最初に何を検査したかを明示し、検査していない範囲をカバーしたかのように示唆しないレビューレポートです。
- Severity、Location、Before、After、Whyのテーブル内で原則ごとにグループ化された指摘事項で、一部だけでなく行われた、または提案されたすべての変更を列挙します。
- クイックモードでは1〜3件、フルモードでは2〜5件の実在する候補を挙げ、それぞれが採用されなかった理由を示す「検討したが採用しなかった」テーブルです。
- 実行した具体的なコマンドや操作と、その観察結果を列挙した検証セクションで、その後に判定が続きます。
仕組み
- 01修正内容をプロジェクト自体のスタイリングシステムで表現する
修正を提案したり書いたりする前に、プロジェクトが既にどのようにスタイリングしているかを特定し、その体系に沿って変更を表現してください——Tailwind プロジェクトなら Tailwind で、CSS プロジェクトなら通常の CSS で、確立された CSS-in-JS の手法があればそれで。
- 02インターフェースの動きを遅くする
レビューの際は、ブラウザの Animations パネルでモーションを10%速度で再生してください。10%速度でおかしく見えるものは、フル速度では微妙に間違っているものです。
- 03デフォルトはフルモード
レビューモードが指定されない場合は常にフルモードが使用され、クイックモードは明示的に指定する必要があります。
- 04所見は固定のテーブル形式で記述する
所見は原則ごとにグループ化し、Severity、Location、Before、After、Why の列を持つ markdown テーブルにまとめてください。Location には path/to/file:line を記載します。
- 055つのカテゴリすべてを対象とする
スコープテーブルには Quick Reference の5つのカテゴリすべてを含める必要があり、未検査の対象がレビュー済みであるかのように示唆されてはなりません。
- 06検証と判定で締める
判定は、HIGH の所見が残っている場合は Block、MEDIUM または LOW の所見のみが残っている場合は Needs changes、対応すべき事項が何も残っていない場合のみ Approve となります。