jpskill.com
💬 コミュニケーション コミュニティ

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本体の挙動とは独立した参考情報です。

⚡ おすすめ: コマンド1行でインストール(60秒)

下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。

🍎 Mac / 🐧 Linux
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
🪟 Windows (PowerShell)
$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. 1. 下の青いボタンを押して ux-waiting-audit.zip をダウンロード
  2. 2. ZIPファイルをダブルクリックで解凍 → ux-waiting-audit フォルダができる
  3. 3. そのフォルダを C:\Users\あなたの名前\.claude\skills\(Win)または ~/.claude/skills/(Mac)へ移動
  4. 4. Claude Code を再起動

⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。

🎯 このSkillでできること

下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。

📦 インストール方法 (3ステップ)

  1. 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
  2. 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
  3. 3. 展開してできたフォルダを、ホームフォルダの .claude/skills/ に置く
    • · macOS / Linux: ~/.claude/skills/
    • · Windows: %USERPROFILE%\.claude\skills\

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" を返す

これは通常、次のことを意味します。

  1. スクリプトが複雑すぎる (簡略化する)
  2. 要素が存在しない (スクリーンショットで確認する)
  3. タイミングの問題 (sleep を追加、再試行)

修正: 複雑な関数ではなく、シンプルな 1 行の JS を使用します。

// ❌ 複雑 (サイレントに失敗する)
(function() { const elements = []; ... return JSON.stringify(elements); })()

// ✅ シンプル (明確な結果)
document.body.innerText.substring(0, 500)
document.querySelectorAll('button').length
document.querySelector('.loading') !== null

問題: フォームが送信されない

順番に試してください:

  1. 送信ボタンの場所を確認するためにスクリーンショットを撮る
  2. document.forms[0].submit()
  3. 座標で送信ボタンをクリックする
  4. ユーザーに手動で送信してもらう

監査手順

ステップ 1: ターゲットを理解する

ユーザーに以下を尋ねる:

  1. 監査する URL
  2. テストする 操作 (検索、レポート生成、AI タスクなど)
  3. トリガーする方法 — ボタン名、場所、または手順
  4. 予想される期間 (スクリーンショットの間隔を調整するのに役立ちます)
  5. 認証要件 (必要な場合はログイン資格情報)

ユーザーが利用可能な場合: スクリーンショットをキャプチャしている間、手動で操作をトリガーするように依頼します。これにより、ナビゲーションの複雑さを回避できます。

ステップ 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:

  1. The script is too complex (simplify it)
  2. The element doesn't exist (screenshot to verify)
  3. 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:

  1. Screenshot to see submit button location
  2. document.forms[0].submit()
  3. Click submit button by coordinates
  4. Ask user to submit manually

Audit Instructions

Step 1: Understand the Target

Ask user for:

  1. URL to audit
  2. Operation to test (search, report generation, AI task, etc.)
  3. How to trigger — button name, location, or steps
  4. Expected duration (helps calibrate screenshot intervals)
  5. 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:

  1. What changed from previous screenshot
  2. Activity signals (counters, animations, partial results)
  3. 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:

  1. Summary Score: X/10 categories addressed
  2. Screenshots Gallery: With timestamps and annotations
  3. Strengths: What works well
  4. Critical Gaps: Missing elements hurting UX most
  5. Quick Wins: Low-effort, high-impact improvements
  6. Detailed Findings Table: See references/report-template.md
  7. 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:

  1. Partial failure: Does UI degrade gracefully?
  2. Network interruption: Is progress preserved?
  3. 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` 本体に加え、参考資料・サンプル・スクリプトが入っている場合があります。