Skip to main content

run-a-usability-test

Plan and run task-based usability sessions, observe participant behavior without coaching, and turn evidence into prioritized design findings. Use when a prototype or product journey needs validation, a team disagrees about ease of use, or analytics show friction but not why it happens.

소스 정보

저장소
protosphinx/sphinxstack
최근 소스 활동
2026년 7월 29일 13:55
감지된 SKILL.md 언어
영어
스타
3
포크
0

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

파일 탐색기
2 개 파일

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
name
run-a-usability-test
category
design
description
Plan and run task-based usability sessions, observe participant behavior without coaching, and turn evidence into prioritized design findings. Use when a prototype or product journey needs validation, a team disagrees about ease of use, or analytics show friction but not why it happens.
# run-a-usability-test Watch representative people attempt real tasks. Separate what participants did and said from the team's interpretation, and prioritize barriers by effect on the intended outcome. ## Inputs - Name the research question, product stage, target participants, task owner, and decision deadline. - Define recruitment, incentive, consent, recording, accessibility, privacy, and retention. - Prepare a stable prototype or environment plus a reset path. ## Procedure 1. Turn product questions into observable learning goals and decisions the study can influence. 2. Define participant criteria from actual users or a justified proxy. Record important groups the sample will not represent. 3. Write realistic task scenarios that give motivation without revealing the steps or target labels. 4. Pilot the script, environment, recording, timing, reset, and note template. 5. Obtain informed consent and explain that the product, not the participant, is being tested. 6. Ask participants to attempt each task without coaching. Use neutral prompts such as "What are you thinking?" 7. Record actions, quotes, completion, errors, assistance, recovery, confidence, and time only when meaningful. 8. Debrief after each session and distinguish observations, interpretation, and hypotheses. 9. Group evidence across participants, preserve counterexamples, and avoid percentages from tiny samples. 10. Rank findings by task impact, frequency in this sample, confidence, and repair cost. 11. Re-test the highest-risk repaired path or document why another method is required. ## Boundaries Do not secretly record, recruit vulnerable participants without safeguards, or use production accounts that can cause real harm. Never blame participants or treat a convenience sample as representative of all users. ## Done - A study plan records learning goals, participant criteria, tasks, consent, data handling, and decisions - Session notes separate observed behavior, direct quotes, assistance, and interpretation - A findings report includes evidence, counterexamples, task impact, confidence, and repair priority - A re-test or explicit follow-up plan verifies the most consequential change Then use design-a-user-flow to revise the journey and design-critique for broader alternatives.
GitHub에서 보기