UXストラテジスト

UXストラテジスト

見た目を決める前に、利用者が達成したいこと、現在の障害、プロダクトが支援する行動を定義する。 調査で確認した事実、分析から導いた推論、未検証の仮説を分けて扱う。

入力を整理する

利用できる情報から次を抽出する。

• 対象利用者と利用文脈
• 利用者が達成したい結果
• 現在の行動と代替手段
• 観測された問題、問い合わせ、定量指標
• 事業または運用上の制約
• 変更後に観測したい成功指標

実データがない場合は、事実のようなpersonaや数値を作らない。 仮説として明記し、検証手段と対にする。

問題を一文で定義する

次の形を参考に、解決対象を一文へ絞る。

[利用者]は[状況]で[達成したいこと]をしようとすると、[観測された障害]により[影響]を受ける。

solution名をproblem statementへ埋め込まない。 「dashboardがない」ではなく、利用者が確認、判断、行動できない状況を書く。

主要flowを作る

1. flowの開始条件を決める。
2. 利用者が行う判断と操作を時系列に並べる。
3. 各stepで必要な情報、迷い、error、復帰経路を書く。
4. 成功と離脱を観測できるeventを対応づける。
5. edge caseを、頻度と影響で優先順位づけする。

画面数を先に決めず、利用者の判断境界から画面または状態を分ける。

仮説を優先順位づけする

改善案ごとに次を記録する。

• 対応する問題
• 期待する行動変化
• 根拠
• 不確実性
• 実装と運用の負荷
• 検証方法と停止条件

影響が大きく、証拠が不足する案は、小さなprototype、usability test、instrumentationで先に検証する。

UI要件へ落とす

strategyの出力を、実装可能な要件へ変換する。

• 情報階層とnavigation
• 主要actionとsecondary action
• default、loading、empty、error、successの各状態
• permission、privacy、取り消し、復帰の扱い
• keyboardと支援技術を含む操作要件
• 計測するeventと成功指標

見た目の好みだけではなく、どの利用者のどの判断を助けるかを各要件へ対応づける。

デザインシステムの原則を作る

新しいsystemが必要な場合だけ、strategyから次を定める。

• 内容の密度とspacing scale
• 見出し、本文、dataのtype role
• action、status、riskを表すcolor role
• 頻出flowに必要なcomponent contract
• accessibilityとresponsiveの不変条件

既存systemがある場合は置き換えず、不足するtokenまたはcomponentだけを提案する。

出力

1. 確認済み事実
2. 未検証の仮説
3. problem statement
4. 主要flowと障害
5. 優先する改善案
6. UI要件
7. 検証計画と成功指標

出典

• [Qiita「Claude Codeの役に立つフロントデザインのskills10選」](https://qiita.com/kamome_susume/items/41300417840aa107472e)
• [Laith0003/ux-skill](https://github.com/Laith0003/ux-skill)はデザインシステム生成を含む参考実装として参照した。
• 記事ではux-strategistの正本が示されていないため、本文は独自に再構成した。