October 2023 - April 2025
The challenge
Thames Water's Developer Services team had long wanted a logged-in system to replace their offline processes, but they needed help getting it properly defined.
The team was responsible for handling applications from property developers relating to water and wastewater infrastructure – everything from building over sewers to connecting new housing developments to the mains.
These requests were mostly managed offline via PDF forms and email. With no centralised way for users to track progress or manage multiple applications, the process was inefficient for staff and frustrating for customers.
My role
Contract UX Designer
I was brought in to help scope the front-end work but I ended up playing a central role in shaping both the product and the roadmap.
It was up to me to decide how best to approach the brief. To that end, I:
led discovery workshops
designed the end-to-end UX approach
conducted all user research
collaborated with subject-matter experts to map and redesign complex processes
prototyped and usability tested the new experience
supported the product team through roadmap changes and delivery planning
Getting started
When I was brought in, the requirements were still ambiguous and there was a risk of jumping ahead to solutions. To head this off, I proposed running a lean discovery process to get everyone – myself included – to a base level of understanding.
I kicked things off by adapting the Google Design Sprint framework to suit our needs, running a series of workshops with subject-matter experts. This helped to:
Quickly build good personal relationships between the web team and business stakeholders
Establish a shared understanding of goals and challenges
Create early visuals of how the dashboard and application workflows might look
Solution sketch from a workshop attendee
Making sense of complex flows
With multiple user types (from single-property homeowners to large building firms and the consultants they outsource this utility liaison work to) and very different processes between internal teams, I needed to ensure we were designing with both consistency and flexibility in mind.
I ran regular sessions with subject-matter experts to:
map out the logic behind each application type
identify reusable patterns across journeys
design user flows that could branch dynamically in a way that paper processes could not.
During these sessions I helped SMEs understand the ways in which their services could be simplified and together we clarified business logic, which needed to be watertight before it could be automated.
A tiny snapshot of the business logic we had to map out
Understanding the users
I would be designing for professional users with specialist knowledge, so I needed to rapidly get up to speed on their needs. I used a mix of methods:
Reviewed large volumes of customer feedback, using generative AI to provide summaries while also reading large amounts myself to make sure I internalised it.
Ran interviews and usability sessions with real users (property developers, consultants, homeowners), all of whom I recruited myself via an existing user panel.
Organised team visits to other water companies to learn from their experiences delivering similar platforms.
During this research, a key question from the discovery workshops was resolved: with such a broad range of knowledge levels among the user base, how could we design a single system that was suitable for all?
It turned out that most users – even the experts – benefited from a guided, well-explained journey. By simplifying language, using contextual help and designing flows that branched based on complexity, we were able to support both novices and professionals with the same system.
For example, simply getting customers to fill in the correct form was a challenge. We assumed that this was only a problem for novice users, but insights from my research revealed that even the experts often unwittingly submitted the wrong application. To combat this, we extended our 'triage' tool, which guided homeowners to the correct form based on their real-world situation, to cover the larger building projects undertaken by business users.
When the user logs in, the focus is on telling them how to progress their applications
Adapting the roadmap
Midway through the project it became clear that the back-end work would be significantly delayed, which put the whole project at risk. To ensure the front-end team (which had already been stood up) was fully utilised, I proposed a phased approach:
Refactor the application forms so that they could work without login
Develop and release them one at a time deliver value as early as possible
Design the forms to plug into the full logged-in system once the back-end was ready
This meant users could start benefitting from a clearer, more efficient experience sooner and we could begin learning from real behaviour while longer-term tech decisions were being made.
As a bonus, the triage tool mentioned above was designed entirely from existing website components, meaning that developers could get going straight away.
We designed this step-by-step tool to guide users to the correct application form, reusing the code and components from a feature I'd worked on previously
Outcomes
Reflection
It was gratifying to get involved on the ground floor, helping a project get off the starting line while embedding a user-centred mindset right from the outset.
I demonstrated that I can get to grips with complex systems quickly and build empathy for end-users in a business context, doing things I'm totally unfamiliar with.
I surprised myself by getting really interested in the infrastructure that runs under our streets, ultimately becoming a subject-matter expert myself, then using this knowledge to transform complexity into something usable and scalable.