My approach: end to end research and design ownership

Because the launch date was fixed and could not be moved, I had to sequence my research methods carefully, working before and after launch rather than delaying the product to do discovery upfront. Each method was chosen deliberately based on what it could answer at that point in the project.

Stage 1: Heuristic Evaluation

Before launch, I carried out a heuristic evaluation of the portal against Nielsen's ten usability heuristics. I chose this method because it does not require participants and can be conducted quickly and independently, making it the right tool for a pre-launch context where there was no time to recruit and run research sessions before the go-live date.

The evaluation gave me a structured, evidence based view of where the portal was likely to cause problems for residents before a single user had touched it. It identified issues with navigation, error handling, and content clarity that I documented and prioritised. This became the foundation for everything that followed.

Stage 2: Usability Testing

After launch I planned and conducted seven usability testing sessions with residents. I chose usability testing at this stage because I needed to validate the heuristic evaluation with real users in context, moving from expert judgement to observed behaviour. The heuristic had told me where problems were likely to exist. Usability testing told me which of those problems residents actually encountered, how they responded to them, and which were causing the most friction.

Sessions were conducted both remotely and in person to account for the digital diversity of the resident population. Participants were recruited across a range of digital confidence levels, from residents comfortable with online services through to those with low digital confidence who may rely on the council's assisted digital support. This was important because a portal that works for digitally confident residents but fails for those with lower confidence is not an equitable service.

The usability testing validated the findings from the heuristic evaluation, confirming which issues were real barriers and not just theoretical concerns, and surfaced additional problems that only become visible when you watch a real resident try to complete a real task.

Stage 3: Staff Interviews

I conducted interviews with housing staff to understand the service from the inside. I chose this method because staff who work with residents day to day carry a layer of knowledge that resident research alone cannot surface, they know what residents phone up about, where residents get confused, and what problems arrive at the front desk that never make it into a digital feedback form.

Staff interviews also helped me understand the emotive dimension of the service. Housing is not a neutral transactional category. Staff described residents who were anxious, confused, or distressed when contacting the council about their homes, and this shaped how I framed the subsequent co design work.

Stage 4: Prioritised Backlog and Roadmap Input

Using the combined findings from the heuristic evaluation and usability testing, I created a prioritised backlog of issues and improvements, ordered by impact on residents and feasibility for the team. I chose to structure findings this way because the team needed something they could act on directly within their sprint cycle, not a research report that sat to one side of the delivery process.

I worked with the team to input these findings into the roadmap and sprint planning, ensuring research was directly shaping what got built next rather than being treated as a separate workstream.

Stage 5: Co Design Session

The final stage was a co design session using blue sky thinking, bringing together 21 residents and 7 housing staff. I chose co design at this stage because the project had launched without any requirement gathering from residents or staff, meaning there was a significant gap in understanding what people actually needed the portal to do beyond the 20 tasks that had been replicated from the legacy system.

Blue sky thinking was the right technique here because I did not want participants constrained by what currently existed. I wanted to understand what residents and staff would want if they could design the service themselves, freed from the limitations of the existing system. This generated ideas and priorities that would not have emerged from usability testing alone, which is inherently focused on the existing product.

Including both residents and housing staff in the same session was a deliberate choice. Housing services sit at the intersection of resident need and staff workflow, and a portal that works for residents but creates problems for staff, or vice versa, will not deliver a good service. The session also created space to surface the emotive needs that sit around housing tasks but are not directly captured in a product backlog, the anxiety of waiting for a repair response, the difficulty of navigating a system when you are already stressed about your home.

The findings from the co design session were used to influence the product roadmap, ensuring the next phase of development was shaped by what residents and staff actually wanted rather than what the team assumed they needed.