Early Testing, Faster Insights

Introduction

When my role changed to Product Design Lead at Zeigo by Schneider Electric, I inherited five live products and four contracted designers. On paper, the design function existed. In practice, it wasn't functioning as design.

Product managers were producing wireframes — sometimes full hi-fi mockups — and handing them to the design team to replicate in Figma. Research meant sharing prototypes with potential clients to gather feedback instead of observing how users actually interacted with the experience.

The cost wasn't immediately obvious. Features shipped, roadmaps moved, but development time was spent building things that had never been tested against real behaviour. The moment anything proved wrong after release, it almost never got fixed.

My role was to change that. Not by imposing a new process from above, but by demonstrating a different way of working on live initiatives — then creating the conditions for it to scale.

My Role

I was responsible for design quality and design process across the full Zeigo portfolio: Power, Activate, Hub, EAC, and Network. I managed four contracted designers placed through an external agency, all of whom were already embedded in the existing structure when I arrived.

Doing that meant introducing a methodology neither the designers nor the product managers had worked within.

I introduced the process in two stages. With product managers, I didn't run workshops — I paired with them directly on their next live initiative and worked through the process as we went. Abstract documentation rarely changes working habits; executing on something real does. With the design team, I ran workshops that clarified accountabilities: designers were responsible for the quality and integrity of the design work, not the PM. That shift in ownership was the foundation everything else depended on.

The frame was direct: hard work produces screens; skill produces better screens. Neither compounds. What compounds is a system — one built on research, validated assumptions, and repeatable process. Each initiative through it makes the next more accurate — the team draws on accumulated evidence rather than starting from assumption each time. The design team wasn't being asked to work harder or develop better craft. It was being asked to operate differently.

Some product managers went further than I expected, running their own experiments and completing their own analysis sessions. What didn't follow naturally was cross-functional collaboration. Without my active involvement in bridging the two, designers and PMs tended to operate as separate functions — or revert entirely to the previous arrangement. Sustaining cross-collaboration without a facilitator remained the hardest part.

The Problem

Every product in the portfolio shared a common pattern: ideas arrived from business partners or product management, requirements were written, screens were designed, features were built. Design sat at step three — after the problem was already framed and the solution already implied.

None of the five products had any evidence of user testing. Research meant showing clients polished screens and gathering their reaction. That is not research — it is validation-seeking. Opinion on a prototype tells you whether something looks plausible; watching someone attempt a task tells you where the actual problems are.

The result was a team built for speed, not quality. The consequences weren't marginal — 88% of users are less likely to return after a poor experience, and 79% will switch to a competitor if usability fails them. Designers were capable of more. They simply weren't being asked for it.

The Cost of Getting It Wrong

The instinct when discussing development cost is to think in time — how long a feature takes to build, how many sprints it consumes. That is the wrong frame.

The real cost of a feature isn't the time to build it — it's the complexity it introduces into the product. Complexity adds noise for users: more states to navigate, more paths that can go wrong, more things that have to be explained or learned. It adds maintenance burden for engineering. And it compounds — every feature that ships unvalidated makes the next decision harder, because it has to work around what came before.

Most of that complexity is invisible before a project begins. The business case for a feature rarely accounts for it. A wireframe doesn't reveal it. It surfaces during delivery, in edge cases and technical dependencies and user confusion during testing — but by then the investment is already committed and the direction is hard to change.

The second cost is timing. A wrong assumption discovered before development begins is almost free to correct. The same assumption discovered after a feature ships is rarely corrected at all — not because the team doesn't know it's wrong, but because there is no appetite to reopen work that has already been marked done.

This is the argument the methodology is built on. Not that design makes products look better, but that surfacing wrong assumptions before development begins is the single highest-leverage activity in the product lifecycle.

The Framework

The methodology starts from one premise: product decisions should be driven by observed user behaviour, not assumption — not what we think users need, or what a business case proposes, but what research confirms they actually do and why. Everything that follows keeps that premise in place under delivery pressure — when the easier path is to skip observation and proceed on instinct.

The Maturity Cycle

The methodology runs on two parallel layers. The first is the Maturity Cycle — the continuous practices that keep every product decision grounded in research. The second is the delivery scaffold, described in the next section, which provides the structure it runs through.

Neither works without the other: a delivery process without the Maturity Cycle produces features built on untested assumptions; the Maturity Cycle without a delivery structure produces insight that never reaches production.

The Maturity Cycle is built from three practices — Modeling, Context, and Output — with Research sitting continuously at the centre validating all three. These aren't phases; they're disciplines that run across the full lifecycle of an initiative, revisited and refined until the value of an idea is clear enough to act on.

You model users and update those models when research contradicts an assumption. You refine your understanding of context when observed behaviour doesn't match what was mapped. You test outputs and return to modeling when a prototype reveals a gap in your understanding of the user.

Research is not a phase that precedes design — it is what keeps the other three honest. It runs throughout: user interviews, usability sessions, analytics, behavioural observation. The method matters less than the discipline. Decisions are grounded in what was observed, not what was assumed.

Modeling translates research into a shared understanding of who the user is — their context, motivations, and constraints, described clearly enough for the whole team to work from. A primary persona anchors every design decision; secondary personas are considered but never at the expense of the primary experience.

Context captures what the user currently does before any solution is introduced — behaviours, goals, frustrations. The proposed design is then compared against that baseline. The question isn't whether the design is good; it's whether it's better than what the user does now.

Output gives the experience a tangible form. Early in a cycle this means prototypes light enough to test quickly — enough fidelity to reveal whether an assumption holds, no more. Documentation follows as the design matures.

One distinction worth making explicit: output is not the same as outcome. All three elements contribute to outcomes — better decisions, validated ideas, products that work for users. Output is the vehicle for getting there: something prepared to test, to share, or to clarify thinking. Conflating the two is how teams end up optimising for deliverable quality at the expense of decision quality — producing polished artefacts instead of useful ones.

The Maturity Cycle is not a sequence — it is a loop. When a prototype surfaces a gap in your understanding of the user, you return to Modeling. When experiment findings contradict the context map, you revise it before proceeding. Progress is not measured by moving forward through the elements; it is the point at which iterating no longer changes the answer.

Product Milestones

The layers combine to advance a product through four maturity stages: Concept, Alpha, Beta, and Live. Each milestone is not a handoff — it is the output of a full cycle of the Maturity Cycle running through the delivery process.

At Concept, the idea has been framed and the core assumption identified. An initial user model exists, a scenario has been mapped, and early design thinking has begun. The team has a shared understanding of who the user is and what problem is being tested — before anything is built.

At Alpha, the highest-risk assumptions have been tested through experiments. A prototype has been in front of real users. The story map has been revised against what was observed. What gets into alpha is what survived that process — not the original idea, but the version of it that held up under scrutiny.

At Beta, the product is in the hands of real users under real conditions. The Maturity Cycle continues — research now includes behavioural data from actual use, modeling is updated against observed patterns, and output iterates on what the beta surfaces. Requirements for the next release are informed by what beta revealed, not what was assumed before it.

At Live, what has been validated across all three preceding stages ships. But the process does not stop at release. Design efforts persist after launch — refining, iterating, and responding to what live usage reveals. The difference between products that improve over time and products that calcify is whether the Maturity Cycle keeps running after the feature ships.

A Design Process in Practice

The delivery scaffold — Idea → Frame → Story Map → Experiments → Requirements → Sprint → Design QC → Release — was never run end-to-end on a single initiative at Zeigo. What the portfolio provided instead was a set of real projects where different stages played out, each one showing what the methodology produces when it's applied. The examples below are what actually happened across Network, Learn, EAC, and Hub — and what each stage revealed when it ran.

None of these stages demands perfection. The process is a structure for building common understanding — a shared view of the user, the problem, and the proposed direction that the team can work from and return to. Artefacts vary in fidelity accordingly: some exist as FigJam ideation, simple enough to sketch and discuss in a session. Others were developed into more sophisticated prototypes when outcomes justified it. Many weren't revisited at all. Whether something is taken further depends entirely on what each stage reveals — and whether the direction it points to is still worth pursuing.

The thread connecting these examples is simplification. The smaller an idea can be broken down before development begins, the higher the quality of what ships — because simplification is how hidden complexity becomes visible before it becomes expensive.

Idea and Frame

On Zeigo Network, an initiative arrived as a DIG — a Decarbonisation Initiative Guide: a fully guided platform experience covering learning content, data pricing, and solution provider matching. Comprehensive in scope, but attempting to solve three problems at once.

Rather than take the DIG as a brief, I paired with the product manager and brought in business development partners who understood the market. Together we worked through the personas — not as a documentation exercise, but as a genuine attempt to understand who was going to use this and why.

BD partners grounded them in commercial reality rather than designer assumptions. The framing question was simple: where does the business model actually live? The answer was the matchmaking mechanism — the moment a company found a provider that matched its need. Everything else in the DIG was supporting structure around that core exchange.

That reframe changed what the project was — not because of delivery pressure, but because examining the idea before designing it revealed that most of what had been proposed wasn't addressing the actual problem. Without that examination, the DIG would have been built in full.

Story Map and Experiments

On Zeigo Network's Learn module, the story map traced the full journey of where Learn interacts with users across the product — not individual screens, but every touchpoint across the whole experience.

Mapping at that scale makes something visible that screen-level design never could: where the experience actually connects, and where it doesn't. The approach draws on Jeff Patton's User Story Mapping — specifically the discipline of mapping end-to-end before cutting scope, so that what's removed is always noise around the core problem rather than the problem itself.

From the full map, scope is cut. Everything that doesn't directly bear on the user problem is stripped away, and supporting wireframes emerge alongside — giving the remaining concept a testable form. The reduction isn't a compromise; it's the point. A smaller, clearer slice makes the value of an idea visible in a way the full picture doesn't.

On the DIG, the story map confirmed what framing had already suggested. When we traced how a company was actually trying to identify and engage a solution provider, the friction concentrated in one place — articulating what they needed clearly enough for a provider to respond usefully. The learning content and pricing data were useful context, but they weren't addressing that breakdown. They were noise around the problem, not the problem itself.

Experiments then tested the stripped-back slice. The protocol is deliberately light: define the assumption, build a prototype, test with five people, document what was observed — not what was said.

The output of a session isn't a rating or a preference — it's a record of behaviour. Where did users hesitate? Where did they go wrong without realising it? Where did they succeed in ways the design didn't anticipate?

Observed behaviours are grouped to surface patterns — things that recur across participants and point to something structurally true about how the user interacts with the concept. Each pattern carries an action: what to change, what to test again, or what to remove.

On the DIG, that process produced the Solar RFP: a focused feature that tested the matchmaking model before the full DIG was built. Removing everything that wasn't the core mechanism made the value proposition clear enough to test, and the test gave the team the evidence to sequence what to build next — rather than commit to building everything at once.

Requirements and Sprint

Requirements written before testing codify assumptions. Written after, they codify what has been validated. That timing difference changes what requirements actually are.

On Zeigo Network's Learn module, Figma acted as the living reference point for every Jira ticket the BA formed. Product, design, and BA worked together to groom the backlog, reviewing each ticket against the designs before it was accepted for development and story pointed. The Figma–Jira plugin kept the link between design intent and technical specification visible throughout — not as documentation after the fact, but as the shared artefact the team worked from.

Sprint is led by technology and the product owner. Design's role is to be present at kick-off to communicate intent and available when questions arise. On Zeigo EAC, the allocated designer joined standups during active cycles — not to manage delivery, but to be reachable when a development question needed an answer in the moment rather than via a ticket two days later.

Design QC and Release

On Zeigo EAC, the designer was given access to recent releases to compare against the original designs. What emerged was a consistent pattern: small details missed during development — spacing, states, edge cases — that had accumulated unnoticed. None was individually critical. Together they represented the kind of design drift that makes a product feel inconsistent in ways users notice without being able to name. It was also the stage most likely to be skipped under delivery pressure — and the one that generates the most post-release debt when it is.

On Zeigo Hub, a brand migration project arrived not as a new idea to be framed, but as an existing system that needed to be understood before anything could change — making analysis the natural starting point.

Using Cursor AI, I built tools to analyse token and colour usage across the product. What surfaced was a system without consistent pattern: colour values applied inconsistently, tokens used interchangeably where they shouldn't be, no clear inheritance structure. Cursor generated tables that mapped each usage instance and allowed drill-down to exactly where each pattern appeared in the product. From that analysis, a migration path took shape toward the new design system — from observation of what existed to a clear plan for what it needed to become.

What passes QC ships. Analysis continues after launch, but in my experience the appetite to revisit a shipped feature is close to zero — regardless of what the data shows. That's the honest argument for everything that comes before it.

Reflection

The methodology described here is not a finished system. The hardest part to sustain was not the process itself — it was the cross-functional discipline the process depends on. When designers and product managers worked without overlap, modeling became a designer artefact rather than a shared reference, and experiment findings stayed within one function without changing the decisions of the other. Both sides understood the framework; neither consistently applied it together without facilitation. Building that collaborative habit into the culture — rather than depending on my involvement to bridge the gap — is the unfinished work.

Design QC is the other thing I would approach differently. Getting agreement in principle is straightforward; getting it to happen under delivery pressure is not. Earlier alignment on what constitutes a release-blocking design issue — not just a quality concern, but a functional one — would have made it less negotiable when schedules tightened.

Every initiative arrived from business partners or product management — design never surfaced its own. Making the methodology work well on incoming briefs was the immediate challenge. Getting it to generate its own ideas is the harder, longer-term one.

The title names the underlying argument: test early, surface insights faster. The earlier a wrong assumption is found, the less it costs to correct — not marginally, but by an order of magnitude. Hidden complexity caught at the framing stage costs almost nothing to fix; the same complexity found deep in a build rarely gets fixed at all. Everything described here is in service of that.

How AI Is Changing This

The methodology doesn't change. The Maturity Cycle — research grounding decisions, modeling updated as evidence accumulates, outputs tested before they're built — remains the same regardless of what tools are available. What changes is the speed of certain steps within it.

The biggest shift is in synthesis. The observation itself still needs to come from people: watching users, gathering baseline data, capturing what colleagues and those closest to the work actually see. That part can't be delegated. But taking that raw material and forming it into patterns and insights — synthesis that previously required the team to work through session recordings together — is now much faster with AI assistance. Transcripts are summarised, patterns surfaced across sessions, gaps identified that a single reviewer might miss. The research loop compresses without the observation being replaced.

The second is prototyping. AI-assisted tools can produce something that looks and behaves like a working product far faster than a Figma prototype — and that changes what an experiment can be. A prototype that feels real surfaces a different class of problem than a wireframe does.

But this comes with a tradeoff. A wireframe is deliberately low-fidelity because low fidelity isolates the assumption being tested. When a prototype looks and behaves like a real product, the test surface expands — participants respond to things beyond what's being tested, and separating signal from noise becomes harder.

There's also a pull toward overperfection. Because the tool can keep iterating, you find yourself adjusting prompts to get something that looks more finished than the test requires. That pursuit works against the core discipline: test small, test fast, move on. Being more restrained about what a prototype needs to be — just enough fidelity to reveal whether an assumption holds, no more — is harder when the tools make more fidelity effortless.

The third is the handover. As development teams adopt AI-assisted coding tools, the expectation of what gets handed over is changing. A prototype that functioned as a lightweight experiment isn't always sufficient as a development artefact — teams need something they can use their own tools against, something that connects to the architecture already in place. That places more burden on the design team: prototypes have to be more complete, more integrated, more considered — which runs counter to the principle of keeping early-stage experiments fast and disposable.

What AI doesn't change is the judgment underneath. It can compress the time between observation and insight, and between concept and testable prototype. But it can't decide which assumption is worth testing, or whether the problem has been framed correctly in the first place. Design-as-decoration doesn't disappear when AI arrives; it finds a new form — more output, faster, with the same absence of thinking underneath.