A practical quality scorecard for AI-assisted design

A quality scorecard makes a review easier to discuss. It should reveal weaknesses, not average them away. Use it on human-created and AI-assisted work alike, and retain the concrete observations behind each score.

Define the review object

Specify the artifact, version, audience, primary task and intended fidelity. A concept sketch should not be judged as production software. A public application should not receive a pass because its first screenshot looks polished. List what the review covers and what needs a separate specialist evaluation.

Use eight dimensions

Task clarity: can people understand what to do and what completion means? Content integrity: are facts, labels and claims accurate? Interaction completeness: do loading, empty, error, success and recovery states make sense? Visual hierarchy: do type, spacing and composition support the task?

Brand specificity: does the work fit this organization and content? Accessibility: have relevant keyboard, semantic, contrast, zoom and assistive-technology checks been performed? Responsive behavior: does the experience remain usable with narrow widths and long content? Maintainability: can the team understand, edit and extend what was produced?

Score with evidence

Use 0 for missing or blocking, 1 for major revision, 2 for minor revision and 3 for meeting the agreed brief. Add “not evaluated” when appropriate; do not silently score an untested dimension as successful. For each rating, write the observation, its source and the next action.

These ratings are a team rubric, not a validated psychometric scale. Use them to compare revisions under similar conditions. Do not publish a total score as an objective ranking of products or models unless the evaluation design supports that claim.

Keep blockers outside the average

Define release blockers before review: misleading product claims, loss of entered data, a broken primary action, inaccessible essential controls or unsafe permissions. A beautiful page with a blocked keyboard path does not become acceptable because seven other dimensions scored well.

Automated accessibility checks identify some issues. Manual review and relevant assistive-technology testing remain necessary, and a short checklist is not a conformance certification. Escalate questions beyond the team's expertise.

Compare revisions fairly

Use the same content, viewport set, task scenarios and review criteria. Record model and tool versions when comparing generated outputs. Include time spent on briefing, generation, correction and verification. A higher initial score may not translate into a better final deliverable if maintenance is difficult.

Close the review with an owner, next action and evidence needed for each unresolved item. The useful endpoint is a decision about readiness and remaining risk, not a decorative number on a presentation.