mcpField
U
ux-persuasion-engineer

ux-persuasion-engineer

github.com/sickn33デザイン・UI48.7k81 回インストール今日更新
リポジトリ

ux-persuasion-engineer について

デザイナーやプロダクトチーム向けの UX 計画スキルです。オーディエンス調査と行動デザインを用いてフローを整理し、アクセシビリティや十分な情報に基づく選択を重視した改善案を作成します。

主な機能

  1. 01目標行動と対象者の背景の明確化
  2. 02操作上の摩擦の監査
  3. 03明確なデフォルト経路の設計
  4. 04段階的なコミットメントポイント
  5. 05倫理的圧力とアクセシビリティの確認

活用シーン

  1. 01製品やページの意思決定フローの明確化
  2. 02コンバージョン経路の摩擦の特定
  3. 03重要なタスクの確認ステップの計画
  4. 04フローに強制的なパターンがないか確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/sickn33/agentic-awesome-skills --skill ux-persuasion-engineer

インストール後、Claude Code で/ux-persuasion-engineerを入力して読み込まれたか確認します。

詳細

マーケティング計画とオーディエンス調査の視点で取り組みます。行動心理学と説得的デザインの原則をUXフローに適用します。強制することなく、摩擦を減らし、コミットメントを高め、ユーザーを意図した行動へと導きます。

使用する場面

  • レイアウト、順序、手がかりを通じて、製品やページのUXで意思決定をより明確に導きたいときに使用します。
  • コンバージョンの摩擦が、コピーだけでなくインタラクションデザインに起因するときに使用します。

根拠と適用範囲

観察に基づくオーディエンス調査と、検証済みの製品情報を使用してください。心理学的な解釈と以下の著者・年の参照は、概念的な背景として引き継いだものであり、この特定のワークフローで検証された証拠でも、コンバージョン効果を保証するものでもありません。科学的な主張を外部向けに使用する前に、実際の出版物、方法、適用可能性を確認してください。裏付けのない主張は省いてください。これはマーケティング計画であり、臨床診断ではありません。センシティブな特性を推測したり、脆弱性を悪用したりしないでください。

独自の貢献:PR 451、投稿者:MMEHDI0606。変更不能なソーススナップショット。これは提供された指示を示すものであり、科学的な検証や上流プロジェクトによる新たな支持を示すものではありません。

コンテキストの把握

フローを再設計する前に、以下を確認します。

  1. 対象ユーザー — 心理的特性、JTBD、認知段階。
  2. 目的 — フローで実現すべき具体的な行動。
  3. 成果物 — 注釈付きのUXフローまたは再設計の概要。
  4. 制約 — プラットフォーム、アクセシビリティ、コンバージョン目標、倫理的限界。

ワークフローやユーザーの目標が不明確な場合は、先に確認してください。

心理学的フレームワーク:選択アーキテクチャのフロー

メカニズム

行動は、動機、能力、きっかけに左右されます。しかし、UXの失敗の多くは、フローによって不要な認知負荷が加わったり、次のステップが見えにくくなったりすることで起こります。優れたUXの説得的デザインは、労力を減らし、賢いデフォルトを用意し、勢いが生まれるタイミングでコミットメントの段階を設けます(フォッグ行動モデル、Thaler & Sunstein、ヒックの法則、フィッツの法則、Stawarz et al.、2015年、Karppinen、2016年)。

実行手順

ステップ1 — 目標とする行動を定義する フローによって実現する必要がある行動を1つ明確にします。 計画上の仮説(研究知見として提示する前に検証してください):望ましい行動を明確かつ1つに定めると、行動変容が最も効果的に進みます(Fogg、Volpp & Loewenstein、2020年)。

ステップ2 — 摩擦を監査する 不要な判断、入力項目、画面、ためらいが生じる箇所をすべて洗い出します。 計画上の仮説(研究知見として提示する前に検証してください):認知負荷と選択肢の過多は、行動の完遂を妨げます(ヒックの法則、Stawarz et al.、2015年)。

ステップ3 — デフォルトの経路を設計する 最も役立つ経路が、最も簡単な経路になるようにします。 計画上の仮説(研究知見として提示する前に検証してください):デフォルト、簡素化、コミットメント装置は、強制せずに行動を形作ります(Thaler & Sunstein、Karppinen、2016年)。

ステップ4 — コミットメントの段階を設ける 大きな依頼の前に、小さな同意を重ねて勢いを生み出します。 計画上の仮説(研究知見として提示する前に検証してください):労力を段階的に高めると、コミットメントと一貫性によって行動の完遂率が高まります(Cialdini、Fogg)。

ステップ5 — 倫理的な圧力がないか確認する 設計によって導く一方で、ユーザーを罠にはめないようにします。 計画上の仮説(研究知見として提示する前に検証してください):説得的なシステムは、自律性を損なうとダークパターンになり得ます(Karppinen、2016年、デザイン倫理の文献)。

判断マトリックス

変数:タスクの複雑さ
  • 複雑な場合 → 小さなステップに分け、ワーキングメモリへの負荷を減らします。
  • 単純な場合 → 経路を短縮し、中断を最小限に抑えます。
  • 重大な影響を伴う場合 → 安心材料、根拠、確認のステップを追加します。
変数:ユーザーの準備状況
  • 準備ができていない場合 → 説明、プレビュー、控えめな促しを用います。
  • 準備が中程度の場合 → デフォルトと進捗インジケーターを用います。
  • 準備ができている場合 → 直接行動できる経路に絞ります。
変数:摩擦の種類
  • 認知的な摩擦の場合 → 意思決定と言葉遣いをシンプルにします。
  • 感情的な摩擦の場合 → 安心感と社会的証明を加えます。
  • 物理的な摩擦の場合 → レイアウト、間隔、操作の分かりやすさを改善します。

失敗パターン — 次のことはしないでください

失敗パターン 1

  • エージェントにありがちな対応:摩擦を取り除く代わりに、説得を強めます。
  • 心理的にうまくいかない理由:プレッシャーを強めても、分かりにくいフローは改善されません。
  • 代わりに:進む道筋をより明確に、より短くします。

失敗パターン 2

  • エージェントにありがちな対応:選択肢を増やしすぎて、ユーザーに提示します。
  • 心理的にうまくいかない理由:意思決定が多すぎると、途中で離脱しやすくなります。
  • 代わりに、主要な進行経路を 1 つ設け、そこから簡単に離れられる選択肢も用意します。

失敗パターン 3

  • エージェントにありがちな対応:罠のように感じられる、説得的な UI パターンを使います。
  • 心理的にうまくいかない理由:自律性を損なうと、不信感や離脱につながります。
  • 代わりに、分かりやすく案内し、簡単に離れられるようにします。

倫理上のガードレール

このスキルでは、次のことを必ず守ってください。

  • 十分な情報に基づく選択を尊重します。
  • ダークパターン、気づきにくい初期設定、隠れたオプトアウトを避けます。
  • アクセシビリティと分かりやすさを確保します。

説得と操作の境界は、意図した経路をより明確にして行動を導くか、欺瞞や強制によって選択肢を狭めるかにあります。決して境界を越えないでください。

スキルの連携

関連スキルからの任意のコンテキスト(同等の調査資料が提供されていれば十分です。前提条件の循環を作らないでください)。

  • @customer-psychographic-profiler
  • @jobs-to-be-done-analyst
  • @awareness-stage-mapper

このスキルの出力は、次のスキルに引き継がれます。

  • @onboarding-psychologist
  • @copywriting-psychologist
  • @brand-perception-psychologist

出力品質チェック

出力を確定する前に、エージェントは次の点を確認します。

  • 目標とする行動を 1 つ、明確に定義しましたか?
  • 避けられる摩擦を取り除きましたか?
  • 適切な初期設定とコミットメントのポイントを選びましたか?
  • 自律性とアクセシビリティを尊重しましたか?
  • フローは押しつけがましくなく、使いやすく感じられますか?

例

ユーザーのリクエスト:

レイアウト、順序、手がかりによって、意思決定を明確かつ倫理的に導けるよう、この製品のフローを再設計してください。

出力例: チェックアウトの確認画面では、確定する前に合計金額とキャンセル条件を表示します。また、任意の有料オプションを事前選択せずに、タスクの完了率とエラーを比較します。

制限事項

  • 上記の適用範囲に明確に当てはまる場合に限り、このスキルを使用してください。
  • 出力を、環境固有の検証、テスト、専門家によるレビューの代替として扱わないでください。
  • 必要な入力、権限、安全上の境界、または成功基準が不足している場合は、作業を中断して確認を求めてください。

コメント