Inntrig

Overview

Inntrig is a tool for running WCAG accessibility audits without the spreadsheets. I led the UX, research and product structure over a focused two-month engagement, working alongside an engineer to take it from problem to a build-ready design. The goal was simple to state and hard to do: make an audit feel like one continuous document rather than a stack of forms.

The problem

Accessibility audits live in spreadsheets and form-builders. Auditors juggle one row per WCAG criterion, evidence sits in screenshots scattered across folders, and project owners chase status by email. The work itself is rigorous, but the tooling hides it. Nothing tells a delivery team where they are, what is blocking sign-off, or what they have already passed.

User research

I ran interviews with accessibility leads, in-house auditors, and the delivery teams they hand reports to, then mapped how an audit actually moves between them. Two themes kept surfacing. First, criteria knowledge is uneven: auditors hold deep WCAG context, the teams reading the reports often do not, and meaning is lost in translation. Second, the same checks get redone every quarter because evidence is never centred anywhere, it only lives in whichever spreadsheet was last emailed around. These two findings drove every structural decision that followed.

Personas

Three audiences sit at the centre of the product. They need the same audit data but each cares about a different slice: the auditor running the assessment, the delivery lead working through the findings, and the product owner watching for sign-off. The personas kept later design decisions honest about who each screen was actually for.

User journey

From kicking off an audit to handing a report to the delivery team, the journey crosses a handful of distinct surfaces. Mapping it end-to-end made the gaps obvious, especially the weakest moment in the whole flow: where a finding is supposed to become a fix.

Wireframes

With the journey mapped, the wireframes concentrated on the four interactions auditors return to most: working an audit screen by screen, drilling into a single finding, slicing reports by criterion, and keeping a bird's-eye view across projects. Each set below is one of those flows.

User testing

I tested the wireframes with the two groups they had to serve: auditors who would live in the tool every day, and delivery leads who only ever see the output. Walking auditors through the audit-detail and sidebar flows surfaced where the screen-by-screen rhythm broke, and confirmed that treating the audit as one continuous document, not a sequence of forms, matched how they actually work.

Testing the reports and criteria drill-down with delivery teams was the more important check, because that is where the translation problem lives. Watching them read findings cold showed which language landed and which needed plain-English framing, and it validated the drill-down as the moment a finding becomes a fix. Those sessions reshaped the reports view and the criteria detail before any visual design began.

Visual design

Visual design is still in flight. The first screens are taking shape against the wireframes, holding the same principle throughout: the audit reads as one continuous document, not a sequence of forms to fill in.

Where we landed

Early walkthroughs with auditors confirmed the structural calls. The work feels less like data entry, and the audit holds together as a single document rather than a stack of forms. The product's shape is settled enough to keep building against with confidence.

What's next

Finishing the remaining screens, hardening the reporting flow, and a round of testing with delivery teams reading reports cold, the real measure of whether the translation problem is solved. From there the focus shifts to evidence capture and import paths for organisations already part-way through their own audits.