Taming the prototype monster

Joining a fast-moving project is always a challenge. When I took over for the outgoing designer on a project back in May, I was faced with a prototype that covered multiple user scenarios, had intricate Javascript routing, and was made up of a huge number of files.

While I wasn’t a novice – prototyping in code is part of how we work, and I’ve completed our internal NHS prototype training – deep front end coding isn’t the primary focus of my role. There was no time to rebuild from scratch with a simpler prototype, nor could I let complex Javascript monopolise my time when I needed to focus on the knotty design problems.

To solve this, I have been working with GitHub Copilot to untangle a complex codebase, automate repetitive design tasks, and build confidence and coding knowledge. 

AI pair programming for prototyping

When inheriting a prototype containing lots of variables and complex logic, just finding where a piece of data lives can be a mammoth task. Working with GitHub Copilot has supported me to:

• Locate variables: Where I can ask something like: “Where are patient numbers defined and referenced?” Copilot then scans the prototype repository and points me directly to the exact file and line numbers.

• Handle complex logic: Where I can describe a scenario, like creating a new preset user scenario that relies on multiple dynamic variables. Copilot then sets up the foundational logic for me.

• Understand any ripple effects: Where Copilot can help me map out how making a change in one place will affect different user paths, preventing me from inadvertently breaking anything.

The following examples expand on each of these scenarios.

1. Variables in design system components

To keep our services consistent and accessible, we build prototypes using design system components and repeated patterns across different user journeys. When a design decision changes, this can mean updating that pattern or component across every single page where it appears. In a large prototype, that usually requires hunting through dozens of files, copying snippets, and swapping out code manually on page after page.

Recently, I needed to swap out a details component for the NHS Expander component. Instead of doing it manually, I first prompted Copilot: "Change the details component to the official NHS expander component.” It scanned both our repo and the NHS Design System site, and made the exact code swap while keeping all of my original content intact. I then instructed it to update other specific instances of the details component.

While this is all something that could easily be done manually, utilising Copilot to do so significantly sped up the process, saving me time that I could use elsewhere.

2. Tackling complex states in an appointment view

One of my favorite use cases for Copilot was building a complex calendar component for an appointments view. In our prototype, users needed to be able to navigate backward and forwards through a week, but only within a strict date range. On top of that, certain days needed labels like "Yesterday," "Today," or "Tomorrow," while others used dates.

I gave Copilot a hyper-specific prompt detailing these logic rules. It quickly generated the updated logic across multiple connected files – a task that I would have not had the knowledge to accomplish by myself.

3. Investigating and handling errors

Even with the help of Copilot, a complex prototype is bound to break or encounter errors at some point. 

When an error happens, I have been able to copy the terminal error into Copilot, and ask it: "Hey, I'm getting this error. What does it mean and how do I fix it?" Copilot then walks me through the troubleshooting steps it is taking and suggests a fix before applying it.

This is not only very efficient, but has meant that I have been continually learning how errors are being resolved, improving my coding knowledge. 

Parting thoughts: When does a prototype become too complex?

As useful as Copilot has been in helping me work with this prototype, it leaves me with a bigger question: Did our prototype need to be this complex in the first place?

Prototyping early in code serves an important purpose. In public sector service design, prototypes of varying fidelities allow us to test realistic end-to-end task flows, evaluate content comprehension in context, and have meaningful technical conversations about data requirements long before building production ready software.

But in large-scale services, code prototypes frequently cross an invisible threshold from helpful research artefacts into nearly full-blown web application territory.

I’ve found that tools like GitHub Copilot are brilliant for bridging skill gaps and building confidence under pressure. But relying on AI to survive a codebase shouldn't replace the core design discipline of keeping our artefacts simple. Copilot helped me tame the prototype monster this time, but moving forward, the goal should always be simplifying our tools so we can spend less time wrestling with code and more time designing for users.

This post reflects my personal experience using GitHub Copilot as an interaction designer on an NHS service at TPXimpact. TPXimpact is not affiliated with, sponsored by, or endorsing GitHub Copilot, and other AI pair programming tools are available.