Adversarial Ux Test

意地の悪い利用者を演じて、使いにくさを見つけて仕分けます。

skill の情報

参考: SKILL.md 全文

Adversarial UX Test

自分の製品にとって最悪の利用者を演じます。技術が嫌いで、そのソフトを使いたいとも思っておらず、文句をつける理由をいくらでも見つけてくる人です。そのうえで、出てきた不満を現実的かどうかの層に通し、本物の使いにくさと「そもそもパソコンが嫌い」という雑音とを分けます。

自動化された「母親テスト」だと思ってください。ただし怒っています。

なぜこれが効くのか

たいていの品質確認は不具合を見つけます。これが見つけるのは引っかかりです。技術的に正しいアプリでも、生身の人には使えないことがあります。意地の悪い人物像は、こういうものを拾います。

• 開発者には通じるが利用者には通じない用語
• ありふれた用事を済ませるのに手順が多すぎること
• 最初の案内や「なるほど」と思える瞬間がないこと
• 見え方・触りやすさの問題（文字の大きさ、色のコントラスト、押せる範囲の広さ）
• 始めたばかりのときの問題（何もない画面、お試し用のデータがない）
• 登録や課金の壁で離脱してしまうこと

現実的かどうかの層（手順 3）があるからこそ、面白いだけで終わらずに役に立ちます。これがないと、おじいちゃんが PDF を扱えないからという理由で、全画面に「このページを印刷」ボタンを付けることになります。

使い方

エージェントにこう伝えます。

"Run an adversarial UX test on [URL]"
"Be a grumpy [persona type] and test [app name]"
"Do an asshole user test on my staging site"

人物像を自分で渡してもいいですし、製品の想定利用者からエージェントに作らせても構いません。

手順 1: 人物像を決める

人物像を渡さない場合は、次の問いに答える形で作ります。

1. この製品にとって、いちばん手ごわい利用者は誰か。（50 歳以上、技術職ではない、何十年も「昔からのやり方」で通してきた）
2. その人はどのくらい機械に慣れているか。（慣れていないほどよい — WhatsApp しか使わない、紙のノート、メールの設定は配偶者がやった）
3. その人が済ませたい用事はたった一つ、何か。（機能の一覧ではなく、その人の本来の仕事）
4. どうなったら諦めるか。（手数が多い、専門用語、遅い、わかりにくい）
5. いらついたとき、どんな話し方をするか。（ぶっきらぼう、口が悪い、突き放す、ため息）

よい人物像の例

> 「ビッグ・ミック」マカリスター — 58 歳のストレングス＆コンディショニングのコーチ。使うのは WhatsApp だけ。「表計算」の代わりは紙のノート。「10 秒でわからなかったらノートに戻る」。25 人分の練習結果を記録したい。小さい文字と専門用語とパスワードが嫌い。

よくない人物像の例

> 「アプリが気に入らない利用者」 — ぼんやりしすぎで、条件も声もありません。

人物像は、20 分のテストのあいだ役を保てるくらい具体的である必要があります。

手順 2: 嫌な奴になりきる（その人物としてアプリを触る）

1. アプリの背景と URL を知るために、手元にあるプロジェクトの資料に目を通す
2. その人物になりきる — 何にいらつくのか、何ができないのか、何をしたいのか
3. ブラウザのツールでアプリを開く
4. その人物が本当にやりたいことを試す（機能の紹介ツアーではありません）

• そもそも、やりたかったことができるか
• 済ませるまでに何回クリックし、何画面またぐか
• どこで戸惑うか
• どこで腹を立てるか
• どこで迷子になるか
• どこで諦めて元のやり方に戻るか

1. 次の観点で引っかかりを試す

• 第一印象 — そもそも最初の画面から先に進む気になるか
• ふだんの流れ — いちばんよくやる、たった一つの用事
• 失敗からの立て直し — 操作を間違えたとき何が起きるか
• 読みやすさ — 文字の大きさ、コントラスト、情報の詰まり具合
• 速さ — 今までのやり方より速いと感じるか
• 言葉づかい — その人に通じない専門用語はないか
• 行き来のしやすさ — 元の場所に戻れるか。今どこにいるかわかるか

1. 引っかかったところは、すべて画面を撮っておく
2. どのページでも、ブラウザのコンソールに JS のエラーが出ていないか確認する

手順 3: 不満をぶちまける（その人物の口調で書く）

感想は、その人物として、その口調で、いらだちごと書きます。不具合の報告書ではありません。生身の人が愚痴をこぼしているところです。

[PERSONA NAME]'s Review of [PRODUCT]

Overall: [Would they keep using it? Yes/No/Maybe with conditions]

THE GOOD (grudging admission):
- [things even they have to admit work]

THE BAD (legitimate UX issues):
- [real problems that would stop them from using the product]

THE UGLY (showstoppers):
- [things that would make them uninstall/cancel immediately]

SPECIFIC COMPLAINTS:
1. [Page/feature]: "[quote in persona voice]" — [what happened, expected]
2. ...

VERDICT: "[one-line persona quote summarizing their experience]"

手順 4: 現実的かどうかの層（ここが肝心。飛ばさないこと）

人物像から抜け出します。ひとつひとつの不満を、製品を作る側として見直します。

• 赤: 本物の使いにくさ — 機嫌の悪い人に限らず、誰でもぶつかる問題です。直してください。
• 黄: 妥当だが急がない — 実際の問題ですが、極端な利用者に限られます。書き留めておきます。
• 白: 人物像の雑音 — 「パソコンが嫌い」の話であって、製品の問題ではありません。飛ばします。
• 緑: 機能の要望 — 不満のなかに隠れたよい案です。検討します。

仕分けの基準

1. 35 歳の、慣れてはいるが忙しい利用者でも同じ不満を言うか → 赤
2. 見え方・触りやすさの本物の問題か（文字の大きさ、コントラスト、押せる範囲） → 赤
3. 「紙と同じように動いてほしい」という、デジタルへの拒否反応か → 白
4. その人物がたまたま踏んだ、本物の流れの無駄か → 黄か赤
5. これを直すと、問題なく使えている 8 割の人にとって複雑になるか → 白
6. 最初の案内が足りていない、と気づかせる不満か → 緑

この仕分けは必須です。 人物像の不満を、そのまま課題として登録しないでください。

手順 5: 課題を作る

赤と緑の項目だけを対象にします。

• はっきりした、手が動く題名
• その人物の言葉をそのまま入れる（面白くて記憶に残ります）
• その裏にある本当の使いにくさ（事実として）
• 直し方の案（手が動く形で）
• ラベルは "ux-review"

黄の項目は、まとめて 1 件の課題に書き出します。

白の項目は報告に載せるだけです。課題は作りません。

1 回のテストにつき課題は最大 10 件 — いちばんひどいものに絞ります。

手順 6: 報告する

次のものを届けます。

1. 人物像の愚痴（手順 3） — 面白くて、生々しいもの
2. 仕分けたあとの評価（手順 4） — 現実的で、手が動くもの
3. 作った課題（手順 5） — リンク付き
4. 主な問題の画面写真

こつ

• 1 回のテストにつき人物像は 1 人。 視点を混ぜないこと。
• 手順 2〜3 のあいだは役を保つ。 役を抜けるのは手順 4 だけです。
• まず、ふだんの流れを試す。 設定画面に気を取られないこと。
• 何もない画面は宝の山。 使い始めたばかりの体験に、引っかかりがいちばん多く出ます。
• いちばんよい発見は、その人物が別のことをしようとして偶然見つけた赤の項目です。
• 人物像から不満がまったく出ないなら、その人物は機械に慣れすぎています。 もっと年上で、もっと気が短くて、もっとやり方を変えない人にしてください。
• デモの前、公開の前、機能をまとめて出した後に実行してください。
• できるかぎり新しい利用者として登録してください。 あらかじめ用意された管理者のアカウントを使わないこと。引っかかりのほとんどは、使い始めの体験に潜んでいます。
• 白の項目がゼロなのは失敗ではなく合図です。 仕分けで雑音が一つも出ないなら、機嫌の悪い人物像のせいではなく、製品に本物の使いにくさがあるということです。
• プロジェクトの資料にある既知の問題は、テストの後で確認してください。 その人物が見つけた不具合が既知の問題の一覧にすでに載っていたなら、それがいちばん痛い発見です。作り手は知っていながら、利用者の痛みを感じていなかったということです。
• 購読や課金の壁を試すことが欠かせません。 有効なアカウントだけでなく、期限切れのアカウントでも試してください。「支払えなくなったとき何が起きるか」は、その製品が利用者を尊重しているのか、データを人質に取っているのかを映します。
• その人物のたった一つの用事を済ませるまでのクリック数を数えてください。 5 回を超えるなら、その人物が機械にどれだけ慣れていようと、ほぼ確実に赤の発見です。

業種ごとの人物像の例

出発点として使い、自分の製品に合わせて作り替えてください。

決まりごと

• 手順 2〜3 のあいだは役を保つこと
• 本気で意地悪に、それでいて公平に — 作り物ではなく本物の問題を見つけること
• 現実的かどうかの層（手順 4）は必須
• 不満ひとつにつき画面写真が要ること
• 1 回のテストにつき課題は最大 10 件
• 手元の開発環境ではなく、検証用か公開済みのアプリで試すこと
• 人物像は 1 人、テストは 1 回、報告は 1 本