YouTube, Uber, κ²°μ , κ²μ, λ°±μ€νΌμ€, AI agent μ΄λλ λμ§λ κ³΅ν΅ μ§λ¬Έ μΈνΈλ€. λ¨μ μ½λκ° μλλΌ μ¬μ©μ±, 보μ, λ©±λ±μ±, μ¬μλ, μ ν©μ±, κ΄μΈ‘μ±, λ°°ν¬κΉμ§ κ²μ¦νλ€.
Can a real user complete the job safely, repeatedly, securely, observably, and recoverably under normal and failure conditions?
Can the user complete the main job without confusion or dead ends?
I would start from the user's critical path: what they are trying to do, where they can get stuck, and what signal proves they completed the job.
Does every screen handle loading, empty, error, disabled, and success states?
I would verify the screen states explicitly: loading, empty, error, disabled, and success. The happy path alone is not enough.
Is the API contract explicit, stable, and understandable for clients?
I would treat the API as a contract: schema, status codes, error shape, pagination, and compatibility all need to be explicit.
Are invalid inputs caught early, explained clearly, and recoverable?
I would split validation into fast client feedback and authoritative server validation, and make every error recoverable for the user.
If the same request is retried, can it duplicate side effects?
For every side-effecting operation, I would ask whether a retry can duplicate the action and where the idempotency record lives.
Where is truth stored, and what invariants must always hold?
I would name the source of truth, the allowed states, the legal transitions, and the invariant that must survive concurrency.
Can the right user perform the right action on the right resource?
I would separate authentication from authorization and verify the resource-level permission on the server for every sensitive action.
What sensitive data exists, and where can it leak?
I would identify sensitive data first, then check storage, logs, caches, analytics, third-party transfer, retention, and deletion.
How can this feature be abused, spammed, scraped, or overloaded?
I would ask how the feature can be abused, what identity we rate limit by, and what signal tells us abuse is happening.
What latency and throughput does the service need, and what breaks first at 10x?
I would define the user-visible latency target, measure p95 and p99, and identify what breaks first when traffic increases by 10x.
If this fails in production, can we see what happened?
I would ask whether we can detect, localize, and explain the failure with metrics, logs, traces, and an audit trail.
What happens when a dependency is slow, down, or partially failing?
I would identify critical dependencies, set timeouts and retry budgets, and design a degraded mode that fails visibly instead of cascading.
Can we ship this safely and recover if it is wrong?
I would treat rollout as part of the design: feature flag, canary, guardrail metrics, rollback path, and migration compatibility.
Can users operate the feature with keyboard, screen reader, and clear visual states?
I would verify accessibility through semantic controls, keyboard navigation, labels, visible focus, and clear error states.
What data is created, retained, corrected, deleted, and audited?
I would check the full data lifecycle: creation, retention, correction, deletion, audit, reconciliation, and migration.