ux-checkout-payment について
商品購入、予約、サブスクリプションの決済フローを設計する生成型 UX スキルです。手順を取引内容に合わせ、離脱要因を減らし、費用を明確に示すことに重点を置きます。
主な機能
- 01取引種別に応じた段階設計
- 02ゲスト購入を優先
- 03費用の内訳をすべて表示
- 04オートフィルで入力を削減
- 05インライン検証とエラー案内
- 06決済結果と次の手順を通知
活用シーン
- 01物理・デジタル商品の購入手続き設計
- 02空き状況を軸にした予約フロー設計
- 03サブスクリプションの請求条件を明示
- 04決済エラー表示と完了案内の改善
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ uxcel-lab/ product-skills --skill ux-checkout-paymentインストール後、Claude Code で/ux-checkout-paymentを入力して読み込まれたか確認します。
詳細
チェックアウトと支払いフローのスキル
このスキルの動作 (最初にお読みください)
これは生成型のスキルです。チェックアウトは製品の中で最もリスクの高いフローです — ここでのわずかな摩擦がカゴ落ちという形で代償を払うことになり、デフォルト設定は漏れやすいものです。本能的な設計 — アカウント作成の強制、1つの長いフォームの表示、送信時ののみの検証、空のプロモコード欄の表示、内訳なしの最終価格の提示、支払い後の行き止まり — は、意欲のある購入者を最後のステップで失わせます。このフローは一連の流れであり — カート → 本人確認 → 詳細/住所 → 支払い → 処理 → 確認 (予約の場合は前半が空き状況の検索 → 選択に入れ替わります) — どの段階に投資すべきかは、何が購入されるかによって決まります。そこでこのスキルは次のことをゲートします:
- 何が、誰のために購入されるのかを明確にする — これが段階、フィールド、支払い手段の構成を決定します。
- 常に当てはまる核心を適用する — ほぼすべての取引に当てはまる、コンバージョンを守るパターンです。
- 文脈依存の判断 (氏名フィールド、支払い方法の数、シングルページかマルチページか、予約のピッカー、プロモの目立ち具合) をトレードオフとともに提示します。
その後、結果を検証のために監査レンズに引き渡します (候補。姿勢は docs/orchestration-policy.md に準拠)。コンポジション (§9): チェックアウトは ux-inputs-and-forms、ux-buttons、ux-selection-controls を中核の子として構成し、確認モーダルの仕組みは ux-modals-and-dialogs に、トーストの挙動は ux-notifications-and-toasts に委ねます (ピア — 到達した場合、それらのサブパートはピアが所有します)。既存のデザインシステムがある場合は、色/タイポグラフィ/スペーシングのトークンを継承します。
ステップ 0 — 設計前に文脈を確立する
不明な場合は尋ねてください。回答なしで進める場合は前提を明示してください:
- 何が購入されますか? 単発購入 (物理的な商品 → 配送先住所 + カート概要、デジタル → 配送なし) か、予約/取り置き (日付/時間/空き状況が核心で、検索ステップによって前段に置かれる) か、サブスクリプション (継続的な条件、トライアルから有料への移行、請求サイクルを明確に示す必要がある) か。これによりどの段階が存在するかが変わります。
- プラットフォーム — モバイルではすべてが厳しくなります: 数量にはドロップダウンより入力ステッパー、単一の氏名フィールド、文脈に応じた数値キーパッド、OTP の自動入力、48×48dp 以上で 8dp 以上間隔を空けたタッチターゲット。デスクトップにはラベルや並列表示の概要を置く余地があります。
- 対象ユーザー / 地域 — 国際向けなら単一の氏名フィールド、国を先頭にした住所の階層、地域に適した支払い手段の構成 (クレジットカードは普遍的ではありません — ドイツや中国などでは弱い) が必要です。単一地域の国内向けならこれらは緩和されます。
- アカウントモデル — 製品が機能するために本当にアカウントを必要とするのか、それとも単なるデータ収集なのか? これがゲストチェックアウトをどれだけ強く求めるかを決めます。
フロー全体を左右する1つの事実に軸足を置いてください: ユーザーはすでに購入を決めています。 すべての画面の唯一の役割は、止まる理由を取り除くことです。
常に適用する核心 (ほぼすべてのチェックアウトで正しい)
コンバージョンを守る
- ゲストチェックアウトを提供する — そしてそれを目立つ選択肢にする。 購入前のサインアップ強制は威圧的で、カゴ落ちの主な原因です。アカウント作成を遅らせると完了率が上がります。注文確定後に登録を提供しましょう (すでに詳細を持っているのでワンクリックで)。
- ❌ 「アカウント作成」が大きなボタンで、ゲストチェックアウトが埋もれたテキストリンクになっているアカウント選択ステップ。
- ✅ 「ゲストとして続行」がプライマリで最も目立つ経路であり、アカウント作成は確認画面で提供される。
- チェックアウトページから気を散らすものを取り除く。 その唯一の目的は完了です。トップナビとフッターのリンクを削り、広告やポップアップを排除し、ユーザーが離れずにその場で商品を編集できるようにしましょう。必要最小限 (例: ライブサポートへのリンク) だけを残します。
- ❌ 支払いページに全サイトのヘッダー、メガメニュー、ニュースレターのポップアップ、フッターのリンク集。
- ✅ ロゴ、カートに戻る導線、サポートリンク — 支払いボタンと競合するものは他に何もない。
コストを信頼できるものにする
- 支払い前に注文を要約し、完全なコスト内訳を表示する — 明細項目、数量、サムネイル(選択したバリエーション/カラーに一致)、商品ページへのリンク、配送料、税金。最終合計だけを表示すると信頼が損なわれます。手数料を後から明かすのはダークパターンです。
- カートでは明確な要約を表示し、注文内容の詳細の後にチェックアウトボタンを配置する ことで、ユーザーが進む前に確認できます。商品数を示し(目に見えるカートバッジ)、ステッパーによる数量編集、カート内でのバリエーション編集、一括削除を可能にします — ミスが最初からのやり直しを意味するようにしないでください。
入力の手間を減らす
- あらゆる場所で自動入力を有効にする — 名前/住所/メール/電話番号のブラウザ自動入力、保存されたカード情報、カードスキャン、OTP の自動入力により、支払いの途中でユーザーがアプリを切り替えずに済みます。データは機微であるため、セキュリティ対策と組み合わせてください。
- カード入力には入力マスクとスマートなデフォルトを使用する — カード番号を自動でグループ化し、最初の数桁からカード種別を自動判別し(手動のブランド選択は不要)、選択した国から通貨を取得します。
思いやりをもって検証し、優雅に失敗する
- すべてのフィールドでインライン検証を、blur 時に行う — 送信時ではなく。 送信するまでエラーを隠すフォームは放棄されます。ユーザーがフィールドから離れたときに検証し(キーストロークごとは押し付けがましく感じられます)、失敗だけでなく成功も確認します。
- エラーメッセージは明示的、簡潔、丁寧、正確、建設的、人道的に(NN/g)。決してユーザーを責めず、何が問題でどう直すかを伝えます。さらに良いのは、エラーを未然に防ぐのに十分明確なラベル/プレースホルダーを書くことです。
ユーザーを放置しない
- 支払い処理を表示する。 支払いには数秒から数分かかります。ローディング/ステータス画面はユーザーを安心させ、二重送信やパニックを防ぎます。
- 成功を画面およびメールで確認する。 成功メッセージ(明確に表示され、読める程度に持続する)→ 確認画面 → 詳細なメール: 注文要約、完全なコスト内訳、配達予定/次のステップ、追跡、サポートの詳細、ゲストからアカウントへの登録案内。次に何が起きるかを示します(「配送状況の更新をメールします」、「サブスクリプションを有効にしてください」)— 支払いで作業が完了したかのようにほのめかさないでください。
セキュリティを強化する(知覚面と実態面の両方)
- 支払いステップに視覚的なセキュリティの手がかりを追加する: HTTPS + 鍵アイコン、および信頼のシール/SSL バッジ(Norton、TRUSTe、BBB など)。ほとんどのユーザーは直感でセキュリティを判断します。こうした手がかりがそれを高めます。(知覚されるセキュリティの欠如と支払い手段の少なさは、文書化された離脱原因です。)
コンバージョンを逃さないプロモコード
- 大きな Apply ボタン付きの空白のプロモ欄を決して表示しない — コードを持たないユーザーは特典を逃していると感じ、コードを探しに出かけて戻ってきません。クリックで入力欄に展開する、控えめな 「プロモコードをお持ちですか?」リンクを使用します。
- 思い出すのではなくクリックで適用する — 利用可能なコードから選択させ、またはメール/広告から直接適用できるようにします。グローバルプロモ(サインアップ、しきい値)は再入力させるのではなく自動適用します。割引を合計に反映させ、その近くに表示し、明確な成功/エラー/削除の状態を示します(期限切れコードのエラーは他の利用可能な特典にリンクすべきです)。
文脈に依存する判断 (表面化させ、自動適用しない)
それぞれについてトレードオフと、ステップ0に結び付けた推奨事項を提示します。これらすべてをデフォルトで適用することが失敗パターンです — たとえば、すべてのチェックアウトを5ページに分割したり、世の中のあらゆる支払い方法を提供したりすることです。
| 判断 | 適用する場合 | 避ける / 適応させる場合 | デフォルトの推奨 |
|---|---|---|---|
| 単一の「氏名」 vs. 姓/名の分離 | 単一: グローバルなオーディエンス、モバイル、エラーが少なく入力が速い (特に姓を先に書く文化) | 分離: マーケティングのパーソナライゼーション (「Hey John」)、または医療/政府/金融の本人確認要件、あるいは分割が必要な API | 本人確認/パーソナライゼーションの要件が分割を強制しない限り、単一フィールド |
| 支払い方法の数 | 方法が多いほど国際販売に有利で、「便利な方法がない」ことによる離脱 (~9%) を削減 | 多すぎると選択麻痺を引き起こし、それぞれがコストを増やす | オーディエンス/地域に関連する方法を、最も人気のあるものを先頭に提供し、成長に合わせて拡張する — すべてを列挙しない |
| シングルページ vs. マルチステップのチェックアウト | フィールドが多い場合はマルチステップ (進捗トラッカー付き) — 分割すると認知負荷が下がる | 短いフォームを不要なページに分割するとクリックが増える | 短ければシングルページ、長ければマルチステップで進捗トラッカー付き (または1ページのアコーディオン)。常に現在地と残りのステップ数を示す |
| 国を先にする住所階層 | 国際/国内配送 — 国/州によって適用されるフィールドと形式が決まる | 単一の固定形式を持つ単一地域のストア | 地域が異なる場合は国/州を先に尋ね、その後は関連する、適切にラベル付けされたフィールドのみを入力例のプレースホルダー付きで表示する |
| 予約: 日付範囲ピッカーと空き状況 | 予約/リザベーションフロー — ピッカーがまさに中核のインタラクション | 一度きりの製品購入 (スケジュール設定なし) | 上部に目立つ検索バー、選択した範囲をホバー状態でハイライト、今日を明示、範囲選択時に自動入力、出発地/目的地 (または相当するもの) を自然な順序でグループ化して入れ替え可能に、結果ページでクエリを保持 |
| 予約: 結果の保存 / ブックマーク | 複数セッションにまたがる判断を伴う、比較中心の裁量的な予約 (旅行、宿泊) | 迅速なトランザクション型の予約 | 後で保存するためのツールチップ付きブックマーク/ハートを提供。高速な単一ステップの予約では省略 |
| プロモコードの目立ち方 | 展開可能なリンク (デフォルト) はプロモ以外のユーザーの集中を保つ | コードがほぼ普遍的な場合 (例: キャンペーンのランディングページ) に限り、常時開いたフィールドでよい | 折りたたまれた「コードをお持ちですか?」リンク → クリックで展開。どのコードが存在するかを制御できる場合は選択可能なリストも |
いくつかのデフォルトを一度に反転させる文脈が1つあります: モバイルです。 それは単一の氏名フィールド、入力ステッパー、文脈依存キーパッド、OTP 自動入力、大きな間隔のタッチターゲットへと同時に押し進めます — モバイルのチェックアウトは、デスクトップを圧縮したものではなく、それ自体として設計してください。
結果を検証する(オーケストレーション)
ハンドオフでは、各レンズをインストール可能なスキルの
nameで指定します。そのスキルがインストールされている場合にのみ呼び出してください。インストールされていない場合でも、このスキル自体のコアにこれらのルールがすでに含まれているため、ブロックせずにそのまま進めてください。
設計または改訂を行った後は、完了と宣言するのではなく、出力を監査レンズに引き渡してください。これらは候補のレンズです。姿勢は docs/orchestration-policy.md で設定するか、フロー全体を ux-design-review 経由でルーティングしてください。ここでは、**dark-patterns、heuristics、microcopy は Tier A(自動実行)、accessibility、aesthetics、mobile-responsiveness、information-architecture は Tier B(提案)**です。既存のデザインシステムがある場合、aesthetics は抑制され、accessibility は使用法に絞り込まれます。mobile-responsiveness はプラットフォームがモバイルの場合にのみ適用されます。ユーザーが特定の目的でこのスキルを呼び出した場合は、その範囲を尊重してください。
ux-dark-patterns-audit(Tier A) — ここで最優先のハンドオフです。チェックアウトには最悪の違反が集中します。後から判明する隠れた費用(ドリッププライシング)、強制的なアカウント作成、バスケットへのこっそり追加(アドオンや保険が事前にチェック済み)、強制的な継続(トライアルが黙って自動更新)、そして拒否をためらわせる コンファームシェイミングです。コアにある透明な費用サマリー、ゲストチェックアウト、明確なサブスクリプション条件は、この監査をクリーンに保つために存在します。ux-heuristics-audit— システム状態の可視性(カートバッジ、処理状態、適用された割引、ステップの進捗)、ユーザーによる制御(カートの編集、プロモの削除、データを失わずに戻る)、エラーの防止と回復。ux-accessibility-audit— ピッカー/ステッパーのキーボード操作、タッチターゲット(≥48dp、≥8dp の間隔)、コントラスト、ステップ間のフォーカス管理、すべてのフィールドのラベル。ux-aesthetics-audit— カート/サマリーの階層(商品名 + 価格を強調)、明確な焦点としての支払いボタン、完了を妨げる雑然とした要素がないこと。ux-microcopy-audit— エラーを防ぐフィールドラベルとプレースホルダー、人間に寄り添うエラーメッセージ、CTA の文言、確認/次のステップのコピー、平易に記載されたサブスクリプション/請求条件。ux-mobile-responsiveness-audit— コンテキストがモバイルの場合: ステッパー、文脈に応じたキーパッド、片手でのリーチ、モバイル固有の氏名/住所の扱い。ux-information-architecture-audit— 複数ステップまたは予約フローの場合: ステップの順序と空き状況/結果の構造が、ユーザーのメンタルモデルと一致しているか。
監査で相反する点が浮上した場合(例: 支払い方法の増加と選択麻痺、セキュリティバッジと視覚的な雑然さ)、主要タスクへと立ち返って解決してください。ユーザーはすでに購入を決めています — 止まる理由を取り除き、完了を速めないものは何も追加しないでください。
よくある do/don't パターン
| ❌ しない | ✅ する |
|---|---|
| 購入前にアカウント作成を強制する | ゲストチェックアウトを目立たせ、注文後に登録を提案する |
| 最終価格しか表示しない | 支払い前に商品、送料、税金などの全費用の内訳を表示する |
| 手数料や送料を最後のステップで明かす | すべての費用をカートと概要で事前に提示する(→ ダークパターン) |
| チェックアウトページにフルナビ、フッター、広告、ポップアップを残す | 気を散らす要素を排除し、完了に必要なリンクだけを残す |
| 送信時にフォーム全体を検証する | フォーカスが外れた時点でインライン検証し、成功も確認する |
| 「無効な入力です。」/ユーザーを責める | 何が問題でどう直すかを、明確で丁寧かつ建設的に伝える |
| 空のプロモ欄+大きな適用ボタン | 折りたたまれた「コードをお持ちですか?」リンク、クリックで適用、合計に割引を反映 |
| モバイルで数量変更にドロップダウン | 入力ステッパー、カート内編集、一括削除 |
| 手動のカード種別選択、書式なしの番号欄 | 種別の自動検出、入力マスク、オートフィル、OTP オートフィル |
| 決済中に黙ってフリーズまたは跳ねる | 処理中状態を表示し、その後画面とメールで確認を出す |
| 「支払い完了。」で終わる | 確認+次のステップ+詳細メール+登録の提案 |
| 4 項目のフォームを 4 ページに分割する | 短ければ 1 ページ、長い場合のみ進捗表示付きのマルチステップ |
| 利用可能なすべての支払い方法を提示する | 対象者や地域に関連する方法を、よく使われる順に提示する |
| 確認せずにリリースする | ダークパターン+ヒューリスティクス+アクセシビリティ+美学+マイクロコピーで見直す |