ux-waiting-audit
Webアプリケーションで時間のかかる処理(30秒以上)が発生する際の、読み込み表示や待ち時間に関するUX(ユーザー体験)を評価し、改善点をまとめた報告書を作成するSkill。
📜 元の英語説明(参考)
Audit UX waiting states for web applications with long-running operations (30+ seconds). Use when asked to evaluate, audit, or analyze a product's loading states, wait times, progress indicators, or user experience during slow operations. Requires browser automation (Chrome MCP tools). Generates comprehensive reports with screenshots, checklist evaluation, and prioritized recommendations.
🇯🇵 日本人クリエイター向け解説
Webアプリケーションで時間のかかる処理(30秒以上)が発生する際の、読み込み表示や待ち時間に関するUX(ユーザー体験)を評価し、改善点をまとめた報告書を作成するSkill。
※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。
下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o ux-waiting-audit.zip https://jpskill.com/download/17485.zip && unzip -o ux-waiting-audit.zip && rm ux-waiting-audit.zip
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/17485.zip -OutFile "$d\ux-waiting-audit.zip"; Expand-Archive "$d\ux-waiting-audit.zip" -DestinationPath $d -Force; ri "$d\ux-waiting-audit.zip"
完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。
💾 手動でダウンロードしたい(コマンドが難しい人向け)
- 1. 下の青いボタンを押して
ux-waiting-audit.zipをダウンロード - 2. ZIPファイルをダブルクリックで解凍 →
ux-waiting-auditフォルダができる - 3. そのフォルダを
C:\Users\あなたの名前\.claude\skills\(Win)または~/.claude/skills/(Mac)へ移動 - 4. Claude Code を再起動
⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。
🎯 このSkillでできること
下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。
📦 インストール方法 (3ステップ)
- 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
- 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
- 3. 展開してできたフォルダを、ホームフォルダの
.claude/skills/に置く- · macOS / Linux:
~/.claude/skills/ - · Windows:
%USERPROFILE%\.claude\skills\
- · macOS / Linux:
Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。
詳しい使い方ガイドを見る →- 最終更新
- 2026-05-18
- 取得日時
- 2026-05-18
- 同梱ファイル
- 5
📖 Skill本文(日本語訳)
※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。
UX 待ち状態監査
ブラウザ自動化を使用して、アプリケーションが長時間実行される操作(30秒以上)をどのように処理するかを評価します。
コア原則
スクリーンショットを最初に、DOMを次に — ナビゲートまたはスタックした場合は常にスクリーンショットを撮ります。視覚的な検査はDOMプロービングに勝ります。
📸 スクリーンショット → 👀 視覚的に分析 → 🎯 座標をクリック → 📸 検証 → 繰り返し
重要: スクリーンショットを最初に行う自動化
スクリーンショットを撮るタイミング
常にスクリーンショットを撮る:
- 任意の URL を開いた後 (初期状態)
- 要素を操作しようとする前
- JavaScript が "missing value" を返すか、失敗した場合
- クリック/送信後 (成功を検証)
- 長時間操作中の一定間隔
スクリーンショットが DOM プロービングに勝る理由
| DOM アプローチ | スクリーンショットアプローチ |
|---|---|
| 複雑なセレクターはサイレントに失敗する | 視覚的に正確な UI 状態を示す |
| "missing value" は情報を提供しない | 画像はボタンの場所を明らかにする |
| 要素を見つけるために 10 回以上試行 | 1 つのスクリーンショット → 座標をクリック |
| 実際のユーザーエクスペリエンスを見ることができない | ユーザーが見るものを正確に見る |
スクリーンショットワークフローパターン
# 1. ナビゲート
Control Chrome:open_url(TARGET_URL)
sleep(2)
# 2. 常に最初にスクリーンショットを撮る
# ブラウザのスクリーンショットまたは html2canvas を使用
# 相互作用の前に画像を分析
# 3. 相互作用が必要な場合は、セレクターよりも座標を優先
# スクリーンショットを見た後: "送信ボタンは ~(1200, 650) にあります"
Control Chrome:execute_javascript("document.elementFromPoint(1200, 650).click()")
# 4. もう一度スクリーンショットを撮って検証
クイックスタートワークフロー
フェーズ 1: セットアップとナビゲート
# 1. ターゲット URL にナビゲート
Control Chrome:open_url(TARGET_URL)
sleep(3)
# 2. スクリーンショット - 何がロードされたかを確認
# 分析: 何が表示されていますか?インタラクティブな要素はどこにありますか?
# 3. ユーザーに特定を手伝ってもらう:
# - テストする操作
# - それをトリガーする方法 (ボタンの場所、必要な入力)
フェーズ 2: 操作のトリガー (難しい部分)
これは監査がしばしば行き詰まる場所です。 最新の SPA には複雑な UI があります。
# 戦略 1: ユーザーにガイダンスを求める
# "ページが表示されています。ボタンの場所やクリックする場所を説明してもらえますか?"
# 戦略 2: シンプルでターゲットを絞った JS を使用
Control Chrome:execute_javascript("document.querySelector('button[type=submit]').click()")
# 戦略 3: 座標ベースのクリック (スクリーンショット後)
Control Chrome:execute_javascript("document.elementFromPoint(X, Y).click()")
# 戦略 4: ユーザーに手動でトリガーさせる
# "操作を開始するためにボタンをクリックしてください。処理中になったら教えてください"
フェーズ 3: 待ち状態のキャプチャ
操作が実行されたら:
# T+0s: 操作が開始されたらすぐにスクリーンショットを撮る
# T+10s: 10 秒後にスクリーンショットを撮る
sleep(10)
# スクリーンショット + capture_state.js
# T+30s: 30 秒後にスクリーンショットを撮る
sleep(20)
# スクリーンショット + capture_state.js
# T+完了: 完了時にスクリーンショットを撮る
# 完了を示す UI の変更を監視
フェーズ 4: 評価とレポート
# 1. チェックリストに対してスクリーンショットを評価 (references/checklist.md を参照)
# 2. 注釈付きのスクリーンショットでレポートを生成
# 3. 推奨事項に優先順位を付ける
トラブルシューティング: 行き詰まった場合
問題: 要素を見つけたりクリックしたりできない
❌ 間違い: さまざまなセレクターを試行し続ける
→ 時間の浪費、サイレントな失敗
✅ 正しい: スクリーンショットを撮り、視覚的に分析する
→ 必要に応じてユーザーに助けを求める
→ 座標ベースのクリックを使用する
問題: JavaScript が "missing value" を返す
これは通常、次のことを意味します。
- スクリプトが複雑すぎる (簡略化する)
- 要素が存在しない (スクリーンショットで確認する)
- タイミングの問題 (sleep を追加、再試行)
修正: 複雑な関数ではなく、シンプルな 1 行の JS を使用します。
// ❌ 複雑 (サイレントに失敗する)
(function() { const elements = []; ... return JSON.stringify(elements); })()
// ✅ シンプル (明確な結果)
document.body.innerText.substring(0, 500)
document.querySelectorAll('button').length
document.querySelector('.loading') !== null
問題: フォームが送信されない
順番に試してください:
- 送信ボタンの場所を確認するためにスクリーンショットを撮る
document.forms[0].submit()- 座標で送信ボタンをクリックする
- ユーザーに手動で送信してもらう
監査手順
ステップ 1: ターゲットを理解する
ユーザーに以下を尋ねる:
- 監査する URL
- テストする 操作 (検索、レポート生成、AI タスクなど)
- トリガーする方法 — ボタン名、場所、または手順
- 予想される期間 (スクリーンショットの間隔を調整するのに役立ちます)
- 認証要件 (必要な場合はログイン資格情報)
ユーザーが利用可能な場合: スクリーンショットをキャプチャしている間、手動で操作をトリガーするように依頼します。これにより、ナビゲーションの複雑さを回避できます。
ステップ 2: シーケンスのキャプチャ
常に最初にスクリーンショットを撮ります。 次に、簡単な状態チェックを実行します。
// サイレントに失敗しないシンプルな 1 行:
// スピナーの確認
!!document.querySelector('[class*="spin"], [class*="load"], .spinner')
// プログレスバーの確認
!!document.querySelector('progress, [role="progressbar"]')
// 可視テキストを取得 (ステータスメッセージを探す)
document.body.innerText.substring(0, 1000)
// 表示される結果をカウント
document.querySelectorAll('[class*="result"], [class*="item"]').length
タイムラインのキャプチャ: | 時間 | アクション | |------|--------| | T+0s | スクリーンショット + 何がトリガーされたかをメモ | | T+10s | スクリーンショット + 簡単な状態チェック | | T+30s | スクリーンショット + 簡単な状態チェック | | T+完了 | スクリーンショット + 最終状態 |
ステップ 3: チェックリストに対する評価
references/checklist.md をロードして評価します。各カテゴリをスコアリングします。
- ✅ 存在し、適切に実装されている
- ⚠️ 部分的に実装されている / 改善が必要
- ❌ 欠落している
- N/A この操作には適用されない
ステップ 4: レポートの生成
references/report-template.md のテンプレートを使用します。
主要な評価パターン
プログレッシブな値の検出
以下を探す:
// 部分的な結果が表示される
document.querySelectorAll('[class*="result"], [class*="item"], li, tr').length
// ストリーミングコンテンツ
document.querySelector('[class*="stream"], [class*="typing"], [class*="cursor"]')
ハートビートインディ
(原文がここで切り詰められています)
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開
UX Waiting States Audit
Evaluate how applications handle long-running operations (30+ seconds) using browser automation.
Core Principle
Screenshot First, DOM Second — always take a screenshot when navigating or stuck. Visual inspection beats DOM probing.
📸 Screenshot → 👀 Analyze visually → 🎯 Click coordinates → 📸 Verify → Repeat
Critical: Screenshot-First Automation
When to Screenshot
ALWAYS screenshot:
- After opening any URL (initial state)
- Before trying to interact with elements
- When ANY JavaScript returns "missing value" or fails
- After clicking/submitting (verify success)
- At timed intervals during long operations
Why Screenshots Beat DOM Probing
| DOM Approach | Screenshot Approach |
|---|---|
| Complex selectors fail silently | Visual shows exact UI state |
| "missing value" gives no info | Image reveals button locations |
| 10+ attempts to find element | 1 screenshot → click coordinates |
| Can't see actual user experience | See exactly what user sees |
Screenshot Workflow Pattern
# 1. Navigate
Control Chrome:open_url(TARGET_URL)
sleep(2)
# 2. ALWAYS screenshot first
# Use browser screenshot or html2canvas
# Analyze the image before ANY interaction
# 3. If interaction needed, prefer coordinates over selectors
# After seeing screenshot: "The submit button is at ~(1200, 650)"
Control Chrome:execute_javascript("document.elementFromPoint(1200, 650).click()")
# 4. Screenshot again to verify
Quick Start Workflow
Phase 1: Setup & Navigate
# 1. Navigate to target URL
Control Chrome:open_url(TARGET_URL)
sleep(3)
# 2. SCREENSHOT - See what loaded
# Analyze: What's visible? Where are interactive elements?
# 3. Ask user to help identify:
# - Which operation to test
# - How to trigger it (button location, input needed)
Phase 2: Trigger Operation (The Hard Part)
This is often where audits get stuck. Modern SPAs have complex UIs.
# Strategy 1: Ask user for guidance
# "I see the page. Can you describe where the button is or what to click?"
# Strategy 2: Use simple, targeted JS
Control Chrome:execute_javascript("document.querySelector('button[type=submit]').click()")
# Strategy 3: Coordinate-based clicking (after screenshot)
Control Chrome:execute_javascript("document.elementFromPoint(X, Y).click()")
# Strategy 4: Let user trigger manually
# "Please click the button to start the operation, then tell me when it's processing"
Phase 3: Capture Waiting States
Once operation is running:
# T+0s: Screenshot immediately when operation starts
# T+10s: Screenshot after 10 seconds
sleep(10)
# Screenshot + capture_state.js
# T+30s: Screenshot after 30 seconds
sleep(20)
# Screenshot + capture_state.js
# T+Complete: Screenshot when done
# Watch for UI changes indicating completion
Phase 4: Evaluate & Report
# 1. Evaluate screenshots against checklist (see references/checklist.md)
# 2. Generate report with annotated screenshots
# 3. Prioritize recommendations
Troubleshooting: When Stuck
Problem: Can't find/click element
❌ WRONG: Keep trying different selectors
→ Wastes time, silent failures
✅ RIGHT: Take screenshot, analyze visually
→ Ask user for help if needed
→ Use coordinate-based clicking
Problem: JavaScript returns "missing value"
This usually means:
- The script is too complex (simplify it)
- The element doesn't exist (screenshot to verify)
- Timing issue (add sleep, retry)
Fix: Use simple one-liner JS, not complex functions.
// ❌ Complex (fails silently)
(function() { const elements = []; ... return JSON.stringify(elements); })()
// ✅ Simple (clear result)
document.body.innerText.substring(0, 500)
document.querySelectorAll('button').length
document.querySelector('.loading') !== null
Problem: Form won't submit
Try in order:
- Screenshot to see submit button location
document.forms[0].submit()- Click submit button by coordinates
- Ask user to submit manually
Audit Instructions
Step 1: Understand the Target
Ask user for:
- URL to audit
- Operation to test (search, report generation, AI task, etc.)
- How to trigger — button name, location, or steps
- Expected duration (helps calibrate screenshot intervals)
- Any auth requirements (login credentials if needed)
If user is available: Ask them to trigger the operation manually while you capture screenshots. This avoids navigation complexity.
Step 2: Capture Sequence
Always screenshot first. Then run simple state checks:
// Simple one-liners that won't fail silently:
// Check for spinner
!!document.querySelector('[class*="spin"], [class*="load"], .spinner')
// Check for progress bar
!!document.querySelector('progress, [role="progressbar"]')
// Get visible text (look for status messages)
document.body.innerText.substring(0, 1000)
// Count results appearing
document.querySelectorAll('[class*="result"], [class*="item"]').length
Capture Timeline: | Time | Action | |------|--------| | T+0s | Screenshot + note what triggered | | T+10s | Screenshot + simple state checks | | T+30s | Screenshot + simple state checks | | T+Complete | Screenshot + final state |
Step 3: Evaluate Against Checklist
Load and evaluate against references/checklist.md. Score each category:
- ✅ Present and well-implemented
- ⚠️ Partially implemented / needs improvement
- ❌ Missing
- N/A Not applicable to this operation
Step 4: Generate Report
Use template from references/report-template.md.
Key Evaluation Patterns
Progressive Value Detection
Look for:
// Partial results appearing
document.querySelectorAll('[class*="result"], [class*="item"], li, tr').length
// Streaming content
document.querySelector('[class*="stream"], [class*="typing"], [class*="cursor"]')
Heartbeat Indicators
Look for:
// Counters
document.body.innerText.match(/\d+\s*(found|processed|complete|%)/gi)
// Animations (CSS or JS)
document.querySelectorAll('[class*="animate"], [class*="pulse"], [class*="spin"]')
Time Estimation
Look for:
// Time remaining text
document.body.innerText.match(/(\d+\s*(sec|min|second|minute)|remaining|left|ETA)/gi)
// Progress percentage
document.querySelector('[role="progressbar"]')?.getAttribute('aria-valuenow')
Screenshot Comparison Strategy
For each interval, note:
- What changed from previous screenshot
- Activity signals (counters, animations, partial results)
- User anxiety factors (frozen UI, no feedback)
Compare: | Element | T+0s | T+10s | T+30s | Complete | |---------|------|-------|-------|----------| | Results visible | | | | | | Counter/progress | | | | | | Status message | | | | | | Animation active | | | | |
Report Output Structure
Generate markdown report with:
- Summary Score: X/10 categories addressed
- Screenshots Gallery: With timestamps and annotations
- Strengths: What works well
- Critical Gaps: Missing elements hurting UX most
- Quick Wins: Low-effort, high-impact improvements
- Detailed Findings Table: See
references/report-template.md - Priority Matrix: P1/P2/P3 recommendations
Best-in-Class Comparisons
Reference these examples of excellent waiting UX:
- Figma exports: Progress bar + percentage + file count
- Notion AI: Streaming text + cursor animation
- ChatGPT: Token-by-token streaming + stop button
- Linear search: Instant partial results + refinement
- Vercel deployments: Step-by-step progress + logs
Error Scenarios to Test
If possible, test:
- Partial failure: Does UI degrade gracefully?
- Network interruption: Is progress preserved?
- Timeout: Is there clear feedback?
// Simulate slow network (if DevTools available)
// Or disconnect briefly and observe behavior
Common Issues to Flag
| Issue | User Impact | Quick Fix |
|---|---|---|
| Spinner only | Anxiety, abandon | Add status text |
| No progress | "Is it stuck?" | Add heartbeat counter |
| No cancellation | Trapped feeling | Add cancel button |
| Silent completion | Missed results | Add completion animation |
| Full-page block | Can't multitask | Move to background |
同梱ファイル
※ ZIPに含まれるファイル一覧。`SKILL.md` 本体に加え、参考資料・サンプル・スクリプトが入っている場合があります。
- 📄 SKILL.md (8,927 bytes)
- 📎 README.md (3,497 bytes)
- 📎 references/checklist.md (7,437 bytes)
- 📎 references/report-template.md (4,784 bytes)
- 📎 scripts/capture_state.js (3,192 bytes)