Question 1

How do you do usability testing? What do you look at?

Accepted Answer

Start with the frame: I anchor on Nielsen's heuristics to avoid the subjective "I don't like it" position. Then list concrete checks: is system status visible (loading, progress), do error messages state the problem AND the fix, can you undo a wrong step, is terminology consistent across screens, how many steps the critical flow takes. Add a practical method too: "I give the new feature to someone outside the team, explain nothing and watch where they hesitate — that 20 minutes beats a lot of heuristic reading." Then say how you write findings up: heuristic + observation + impact + suggestion.

Question 2

What do you know about accessibility testing and which checks do you run yourself?

Accepted Answer

Start with WCAG's POUR principles (Perceivable, Operable, Understandable, Robust) and that AA is the practical target. Then list what you actually do: keyboard navigation (is the Tab order logical, is focus visible, can you escape a modal), 200% zoom, errors not signalled by colour alone, a visible label on every input, and reading a key form with a screen reader (VoiceOver on macOS, the free NVDA on Windows). Then state the limits: a deep ARIA audit and a full WCAG conformance report are specialist work. In an insurance context add: our customer base skews older, so font size and contrast are a real complaint topic — that detail makes the answer live.

Question 3

Can a usability problem be logged as a bug? How do you justify it?

Accepted Answer

Yes — but with the right justification, otherwise it gets closed as a matter of taste. If it violates a requirement or acceptance criterion (e.g. the AC says "the user sees the discount" and they don't) it is unambiguously a bug. If the requirements are silent, I raise it as an improvement and strengthen it with three things: which heuristic is violated, the observed real impact (e.g. 3 of 5 internal users hesitated, support calls expected) and one concrete suggestion. I note severity as low functionally but call out business impact separately. The emphasis: the decision is the PO's, my job is making it visible and measurable.

Question 4

The team doesn't want to spend time on accessibility — "our users don't have those problems". How do you respond?

Accepted Answer

I don't argue, I reframe. First, accessibility isn't only for people with permanent impairments: a user in bright sunlight, with a broken arm, an older customer or someone on a slow connection all benefit — that softens the "tiny minority" argument. Second, in insurance/banking there may be regulatory or corporate tender requirements — this turns a technical topic into a business risk. Third, I propose a small start: not a full audit, but a 20-minute keyboard + contrast check on new screens each sprint. A small proposal is hard to refuse. Finally I show a real finding from that first check — if the Pay button can't be reached by keyboard, the topic stops being abstract.

Nielsen heuristic (selected)	What the manual QA checks
Visibility of system status	Is there a loading indicator during payment? Is progress shown for long operations?
Match between system and the real world	Is there technical jargon? Is "Error 4012" replaced with plain language?
User control and freedom	Can you undo a wrong step? Is there a Cancel? Does Back lose entered data?
Error prevention	Is confirmation asked for destructive actions? Is the field format shown up front?
Error recognition and recovery	Does the error message state the problem AND the fix? Or only "An error occurred"?
Consistency and standards	Is the same action named identically everywhere? Are buttons in the same place?

Usability & accessibility testing

📚 Sources and documentation