Heuristic evaluator

What CLARA will ask you for

• Programme name — your programme's name (e.g. SKYPROTECT).
• Track — the slice of the programme this artefact belongs to (workstream, capability area, feature line, etc.), or Programme-wide if it spans tracks.
• Product name — the product and the slice under evaluation (e.g. "Oracle HCM — Absence & Onboarding").
• Evaluation mode — competitor / existing-system-to-improve / decommissioning / standalone. Sets origin attribution and whether Appendix B applies.
• Task scenarios — the one or two end-to-end tasks to walk. If not given, CLARA proposes them from the screens and confirms.
• Inputs — CLARA will search the programme's Confluence space for the product material to evaluate (user-supplied); the task scenarios to walk; evaluation mode; prior-knowledge summary on the product or domain (optional). You can also paste fresh material if it's not in Confluence yet.

Where the output lands

Knowledge Base/{{track}}/Heuristic-evaluations/{{product-name}} inside your programme's Confluence space.

Tips

• CLARA works from whatever fidelity you supply. A live URL lets it exercise more states than static screenshots; a PDF/deck is fine but freezes the product in one rendered state — the Scope & limitations section records that honestly.
• Treat the score as a comparative instrument, not an absolute grade: it is most useful for tracking the same product across iterations, or ranking a set of competitors evaluated the same way.
• The findings are a lower bound. For a decision that carries weight, run a second evaluator and merge — Nielsen's own research is why the single-evaluator caveat is in the report.
• In existing-system mode, the CFG-vs-PRD split and the achievable-via-fix index are the most persuasive parts of the report: they tell the team how much they can fix themselves, now.

Before you circulate — self-review checklist

• Every finding cites a specific screen and element. No principle-in-the-abstract findings; no finding that can't be located on a screen.
• Severity is justified. Each rating reflects frequency × impact × persistence, not just how annoying the issue felt. The catastrophes really are catastrophes.
• The score is reproducible. Per-heuristic deductions, the weights (summing to 1.0) and their rationale are stated, so a reader can follow the index from findings to headline number. The band matches the number.
• Achievable-via-fix index is present (existing-system/decommissioning modes) and the CFG/PRD attribution behind it is consistent with Appendix B.
• Strengths are recorded. "What works well" names genuine, screen-cited strengths in each scenario.
• Scope & limitations is honest — the static-capture and single-evaluator caveats are stated; the score is framed as an upper bound and the findings as a lower bound.
• Walkthrough is complete. Every finding in the register appears in full in a walkthrough, in flow order, with a stable ID; the appendix adds nothing new.