Self-review
Six lenses—kept deliberately separate
Score each lens only against its own evidence. Do not average the numbers: a strong visual system must not hide an authorization flaw, and a low Vibe-Footprint must not certify quality.
Can a new visitor identify the audience, job and next action?
- Strong signal
- Specific promise, mechanism and proof
- Weak signal
- Generic transformation language
Does the system express product meaning beyond common defaults?
- Strong signal
- Intentional hierarchy and recognizable choices
- Weak signal
- Interchangeable sections and decoration
Do critical, empty, loading and error states support recovery?
- Strong signal
- Predictable state and preserved work
- Weak signal
- Happy-path-only behavior
Is the delivered interface semantic, responsive and performant?
- Strong signal
- Resilient markup and measured delivery
- Weak signal
- Visual polish hiding fragile implementation
Are public protections and private trust boundaries reviewed?
- Strong signal
- Layered controls with owners and tests
- Weak signal
- Header score treated as certification
Can the team detect, communicate and reverse a bad release?
- Strong signal
- Monitoring, support and rollback
- Weak signal
- A successful build treated as launch proof
Working sequence
The 90-minute working session
Time-box the review so it ends with decisions. Deep investigations become assigned follow-up work rather than swallowing the session.
Frame the product
- Name the target user and primary conversion
- Choose one desktop and one mobile journey
- List data, payment or account actions that raise the risk
Review the public story
- Read the page without internal context
- Compare claims with visible proof
- Mark repeated patterns that flatten hierarchy
Exercise behavior
- Use keyboard and mobile navigation
- Trigger loading, validation and failure states
- Record data loss, dead ends and unclear recovery
Inspect delivery
- Inspect semantics, assets and response headers
- Record performance bottlenecks and third parties
- Separate public observations from repository checks
Prioritize and assign
- Select no more than five immediate changes
- Assign owner, evidence and verification method
- Define what blocks launch and what can follow
Decision matrix
A severity model teams can use
Severity describes user or business impact, not how embarrassing a finding looks in a screenshot.
| Priority | Definition | Example | Required response |
|---|---|---|---|
| P0 — Stop | Credible risk of serious harm, data exposure or irreversible loss | Authorization bypass or exposed production secret | Stop launch, contain, investigate and retest |
| P1 — Fix before launch | Critical journey is unsafe, inaccessible or unreliable | Checkout loses state or login errors reveal accounts | Assign an owner and block release until verified |
| P2 — Schedule | Meaningful friction or maintainability cost with a workaround | Mobile navigation traps focus | Plan into the next release with acceptance criteria |
| P3 — Consider | Polish or distinctiveness opportunity without material harm | Decorative card repetition weakens hierarchy | Change only when it supports the product system |
Applied example
What the audit packet should contain
A useful audit can be handed to someone who did not attend the session and still be implemented safely.
- Canonical URL, viewport, timestamp and release identifier
- Observed behavior with a screenshot or response evidence
- Why the finding matters to a named user or trust boundary
- Priority, owner and the smallest coherent change
- A verification step that can fail as well as pass
Plain answers
Audit questions
Should every high Vibe-Footprint produce many findings?+
No. Similarity drivers explain the score; findings require a defensible quality or security observation. A high score and a short issue list can both be correct.
How often should the audit run?+
Run the focused public review before launch and after material changes. Deeper security, accessibility and application testing should follow the product’s risk and release process.