How we turned an error list into a helpful resolution guide

By this stage, the vague reactions from the interviews had already been narrowed down with users into specific, concrete problems in their own words. The synthesis worked with that material: grouping the specific points, finding the patterns across users, and tracing each one to a cause in the system. That meant checking what users described against how the platform actually worked underneath

The interviews produced 30 specific pain points, grouped into clusters by theme. One example was an 'error copy' cluster — untranslated errors, empty errors with no description, and wording too complex to understand — which later went to a Technical Writer. Those clusters narrowed to different root causes that, together, explained why people let errors pile up.

Insights

The error count was inflated by the system itself

Every notification in the system was shown as an error, with no separation between a real error, an alert, and a simple notification. The same error was also listed once per room, or repeated several times per house, so a single underlying issue could appear dozens of times. The number everyone had been treating as a count of real problems was largely an artefact of how the system displayed them. The direction was to show each error type once and list the rooms and houses it affected underneath, so one action could clear it everywhere

Everything looked equally urgent

Not all errors mattered the same to users. The ones they cared about could pull a listing offline, block reservations, show wrong pricing, or touch country-specific regulations. Errors like a low-quality photo, a listing name that ran too long, or a few missing amenities sat much lower for them. The system gave no way to tell these apart, so a critical error and a cosmetic one appeared side by side. The direction was to turn error types into visible filters, so people could deal with what mattered first.

Fixing was slow, manual and demotivating

Seeing 500 or 1,000 fixes needed was simply demoralising. Users assumed it meant an enormous amount of manual work and decided it was easier to leave it as it was. Each error had to be fixed one at a time, which was unmanageable at their scale. The direction was bulk actions — applying the same fix across many rooms and properties at once. This one came straight from users. Several said, in their own words, that they wished they could solve one problem across all their properties in a single go.

Separating the problem into distinct causes made its shape clear. It touched different parts of the experience at once. These were the architecture of the error page, the wording of the errors, the lack of any prioritisation, and the manual, one-by-one process for making fixes. Each needed a different kind of solution, which is why no single change had ever resolved it."