Interactive prototyping: why wireframes often miss the mark

The National School of Healthcare Science (NSHCS) tasked us with creating a replacement trainee management system. Built using OutSystems, a low-code platform, the project has adhered to, and tracked all of its activity against, Government Service Standard, although we’re not building a transactional service. User needs have been central to every design decision, and prototyping and testing with users have been core to our process through both alpha and beta phases.

From the start, we were clear that we didn’t just want to build a newer version of the legacy system. We wanted to dig deeper and understand the underlying needs of our users — not just provide different ways of doing the same thing. This approach shaped everything we did, from the early sketches and static mock-ups to the co-design sessions we held with users from the school.

The legacy system had been in use for a long time, and with it came a rich collection of workarounds. Users had extended the system beyond its original capabilities, relying on spreadsheets, file storage, and email to fill the gaps. Our goal was to design a new system that would eliminate these workarounds, but we quickly realised that users found it difficult to imagine ways of working beyond the well-known and solid practices of the status quo.

As our understanding of the system’s needs developed, we noticed that users struggled to see beyond the constraints of the legacy system. Our static mock-ups, while useful in the early stages, were becoming less effective. There was simply too great a leap between the conceptual design we presented and the real-world changes users needed to review, tell us more about and embrace.

At this point, we realised that we had hit the limit of what static prototypes could achieve. Users needed to experience the system’s functionality in a browser. They needed to see how more efficient and effective processes would feel—how the system could eliminate the need for recording and tracking activity in spreadsheets and via associated workaround.

We’ve used prototyping in code before, but the constraints and learning curve introduced by OutSystems had initially made us cautious about rushing into full-blown interactive prototypes. By this time, however, we had learned enough to build an HTML prototype that allowed users to test our thinking more effectively.

The shift to an interactive prototype allowed us to address real-world functionality — especially around data entry, recovery, and manipulation. The new prototype helped users form a clearer mental model of how different sections of the system related to each other. This was a crucial step in helping them move away from the fragmented processes they were used to.

With the interactive prototype, we moved from thinking in terms of single pages to focusing on how different sections within those pages might behave under different scenarios. This felt like a transition from exploration to implementation that would generate meaningful feedback. For the first time, users were able to see not just what the system could do, but what it would do and how they could advise us to do it even better.

The impact on our research was immediate. The interactive prototype gave users a more realistic experience, leading to more detailed and actionable feedback. It reinforced our confidence in the overall design and build approach while confirming that the next phase of development should focus on details — such as specific use cases and the scope of the first release.

Our findings reinforced that users could now understand the system more fully, and it allowed us to refine critical features that would shape how the platform is rolled out in the future.

Building this replacement trainee management system for NSHCS has been an iterative process, driven by a commitment to user needs. The shift from static mock-ups to a more interactive prototype has been essential in bridging the gap between conceptual designs and real-world functionality. As we continue into the next stages of the project, we’re confident that the foundation we’ve built will provide a more efficient and effective system for the school, while eliminating the need for the workarounds that users have relied on for so long.