Evaluation
Evaluation checks whether the design still serves the modeled use.
The point of the models is not documentation for its own sake. They give the team a concrete way to inspect, test, and improve the interface before and after release.
Evaluation Targets
Usage-centered evaluation asks whether roles can complete their essential tasks effectively. It can be applied to models, prototypes, coded software, and production behavior.
| Target | Evaluation question | Evidence |
|---|---|---|
| Role model | Have we captured the real participation patterns? | Stakeholder review, field observation, support data. |
| Use cases | Are intentions and system responsibilities accurate? | Domain walkthrough, scenario review, test derivation. |
| Prototype | Does the interface structure support the task flow? | Task walkthrough, usability session, expert review. |
| Release | Does real use show success, friction, or workarounds? | Analytics, telemetry, tickets, interviews, operational metrics. |
Model Inspection
A model inspection is a structured review of whether the design can be justified by the model. It catches many problems before usability testing because the team can inspect missing roles, unclear intentions, and unhandled exceptions directly.
- Every primary role has a path to its main tasks.
- Every high-priority task has visible system responsibilities in the prototype.
- Every risky exception has recovery support.
- Every major interface region has a reason to exist.
- Every important status change is visible to the role that depends on it.
Usability Testing
Usability testing should be planned from the role and task model. Participants should be recruited by role fit, tasks should reflect essential use cases, and observations should be mapped back to model defects or design defects.
Test by role
A participant should represent the responsibilities and knowledge assumptions of the role being tested, not just a broad user category.
Test meaningful tasks
Use tasks that correspond to high-value or high-risk essential use cases. Do not test only isolated controls.
Capture friction precisely
When a participant struggles, mark whether the problem is missing information, poor navigation, unclear status, wrong task model, or poor control choice.
Revise upstream
If a test reveals a misunderstood task, update the use case or task model before polishing the interface.
Delivery Integration
The method can fit iterative delivery if teams keep the models small and living. The model does not need to be complete before any implementation begins, but each delivered slice should be traceable to roles and task cases.
- Model the roles and tasks for the next product area.
- Prioritize a thin set of high-value task cases.
- Sketch interaction architecture and abstract prototypes for that slice.
- Review with domain experts and implementation stakeholders.
- Build, test, and update the model based on what was learned.
Useful Metrics
Metrics should reflect successful use, not only system activity. A high click count, for example, may indicate either engagement or friction depending on the task.
- Completion rate for essential tasks.
- Time to complete frequent tasks after normal training.
- Recovery rate after validation or workflow errors.
- Rate of handoff failure between roles.
- Support tickets mapped to task cases.
- Use of workaround fields, exports, or offline tracking.