/
Three user groups, one document tool that slowed everyone down.
A research-led redesign of an internal document service — interviews, usability testing and log analysis turned into a prioritised, phased spec.
Role
UX Designer & Researcher (research → design, end-to-end)
Company
Internal tooling for a document-heavy business process
Methods
heuristic audit, qualitative interviews, usability testing, log analytics
Context
An internal service for generating document templates sat at the centre of a real business process at a cloud infrastructure company. It had grown organically and started to slow people down. Three groups used it very differently — a large group of users who find and download documents (engineers and payment support), contract specialists who occasionally edit versions, and developers who hand-code new templates. Much of that usage was invisible to the team.
Problem
The tool created friction in daily work and dragged on efficiency, but there were no structured data why. Before redesigning anything, I needed to understand who actually used it, how, and where it hurt.
Document template service before redesign
Process
1
UX audit
Evaluated the interface against usability heuristics and documented how the service behaved today: a shared baseline no one had before.
2
Qualitative research
Identified three user groups by role and ran 15 interviews plus usability sessions to surface the real problem flows.
3
Behavioural analytics
I analysed usage logs and interface error data to size the problems quantitatively: which roles leaned on the service most, and how often errors actually recurred.
4
Prioritisation
Turned findings into a ranked list, split across three iterations so value could ship early.
5
Design & spec
Designed the new version and wrote the specification for engineering hand-off.
interview pieces coded and grouped by emerged themes; stickers' colors indicate user group
Solution
The three groups didn't just use the tool differently — they needed different things from it. Most people are users: they find a document, fill it by client id and download it — high volume, low tolerance for friction. A smaller group edits versions, and developers hand-code new templates. So the redesign started from function, not org chart.
The redesign mapped each group's pain points to concrete changes, sequenced so the highest-impact, lowest-cost fixes came first. Developers still build the html templates — that didn't change. What changed is the everyday path: for the large group who just find and download, a searchable list, clear version status and a form with the meaningless fields removed cut the friction, the errors and the frustration that showed up across every interview. A role model (user/editor/admin) keeps each group to the access it actually needs.
Result
Comprehensive evidence
A ranked backlog
Every recommendation scored on one matrix: user value, business value, cost, problem frequency.
A phased, hand-off-ready spec
Split into 3 iterations so value ships early.
What this case shows
Research-to-design in one pair of hands
I run research myself, so I hold the full context and waste no time on handoff.
Mixed methods
Qualitative interviews plus quantitative log analysis, to see not just what the problem is but how large it is.
Pragmatic prioritisation
I ship value in iterations, not one giant redesign that stalls for lack of resources.
contacts
I'm open to UX / product design roles