Usability Heuristics Research

Problem

When I first looked at ShopGoodwill.com, I saw a tension: the site had decades of content and features, but the user interface felt cluttered and inconsistent. It wasn't clear whether users always understood where they were in the flow, if controls and labels matched their expectations, or how easy it would be for them to recover from errors. In short: usability problems were creeping in unnoticed, and the product team lacked a clear diagnostic lens.

The challenge I took on was: How can we uncover key usability issues across the site—especially hidden ones—and produce actionable guidance to improve the experience?

To refine it further, I asked:

• Which parts of the interface violate core usability principles?
• Which violations are most harmful?
• How can we prioritize fixes so they're meaningful and feasible?

Process

Scoping & Heuristic Framework

I started by defining a heuristic evaluation framework. Drawing on established usability heuristics (such as visibility of system status, user control, error prevention, consistency, etc.), I translated each into three supporting usability rules (e.g. “status updates should be visible until task completion”) and paired them with severity levels to measure how serious each violation was.

I scoped the audit to ShopGoodwill.com (an e-commerce auction site where you can buy items locally or remotely) and chose ten heuristics to apply across key flows: browsing, bidding, buying, account management, etc. This provided a structured but flexible lens to evaluate strengths and weaknesses.

Evaluation & Documentation

I walked through the site, systematically applying each heuristic and rule. For every interface element (button, form, message, navigation), I asked:

• Does this violate a heuristic rule?
• If yes, how severely (minor annoyance, major obstacle, critical breakdown)?
• What’s the root cause and how might it be addressed?

I captured annotated screenshots, notes, and severity scores. The visual annotations helped stakeholders immediately grasp where the problem was, how it manifested, and why it mattered.

As I went, certain recurrent themes emerged:

• Visibility of system status: users often didn’t get feedback after submitting actions, causing uncertainty.
• Match between system and real world: many labels, phrases, and flows felt too technical or did not align with user expectations.
• Error prevention and recovery: error states often felt abrupt or cryptic (e.g. “error 500”) rather than offering paths to recover.
• Recognition rather than recall: options, navigation, or instructions were sometimes hidden or required memory rather than being visible at the moment of need.

I grouped issues by severity and frequency, then structured them into a report that combined narrative descriptions, annotated visuals, severity mapping, and prioritized recommendations.

Reflection

This project reminded me of the power of a structured lens. Without heuristics, it’s easy to wander through a site and flag random annoyances; with heuristics, you bring a diagnostic mindset that surfaces systemic patterns.

One lesson was how much vocabulary matters. Labeling issues via known heuristics (e.g. “visibility”, “consistency”, “error recovery”) makes the problem clearer and more defensible—helping cross-discipline teams understand why something matters.

Another insight: severity is nuanced. Not all violations are equally harmful—even a small inconsistency matters less if it’s buried, whereas a status-feedback issue during a transaction can erode trust. Choosing severity judiciously is as important as flagging issues.

If I had more time or resources, I’d complement the heuristic audit with user testing or feedback, to validate which heuristic-flagged issues truly impact behavior. I’d also track which issues get overridden or deprioritized, so I could refine the heuristics over time.