Selected story 02 · Systems / Product ownership

The design was approved.
The rule wasn’t complete.

The design was approved.

The rule wasn’t complete.

Three days before release, a late edge case exposed something bigger than a screen defect: the behaviour underneath an approved design had never been fully defined.

HMI

Cross-functional alignment

Validation

Direction approved · Delivery pending

MY ROLE

HMI Product Owner

UX / Product design

FOCUS

Risk judgement

System validation

Delivery leadership

STATUS

Direction approved

Delivery next

CONTEXT

Complex HMI

System

Multiple capability

Variants / Suppliers

THE STORY IN 20 SECONDS

I protected delivery without ignoring the risk — then built the evidence to change the decision.

I protected delivery without ignoring the risk — then built the evidence to change the decision.

An edge case appeared only days before release. The evidence was too weak to justify stopping delivery, so I kept the release moving while opening a parallel investigation. That investigation separated the new uplift from an older behavioural gap, exposed missing system definitions and validation steps, and led to a revised HMI direction, new dynamic validation and documented process changes.

An edge case appeared only days before release. The evidence was too weak to justify stopping delivery, so I kept the release moving while opening a parallel investigation. That investigation separated the new uplift from an older behavioural gap, exposed missing system definitions and validation steps, and led to a revised HMI direction, new dynamic validation and documented process changes.

Evidence established

Previous and revised behaviour compared dynamically.

Direction agreed

Revised HMI response agreed, with a defined path for system work.

Process strengthened

Missing guidance and validation steps captured in the Body of Knowledge (BoK).

01 · The decision before the diagnosis

We had an issue. We didn’t yet have enough evidence to call it a defect.

We had an issue. We didn’t yet have enough evidence to call it a defect.

The easiest reactions were opposite extremes: change immediately, or ignore it and ship. Neither was responsible.

OPTION A

Stop and change immediately

High disruption, with no confirmed root cause and no proof that a rushed HMI change would make the behaviour better.



Highly certainty required. We didn't have it.

THE DECISION

Protect delivery. Investigate in parallel.

Keep the committed release moving while actively reducing uncertainty — validate the behaviour, identify the root cause, then decide with evidence.


Keep the committed release moving while actively reducing uncertainty — validate the behaviour, identify the root cause, then decide with evidence.



delivery protected. Risk still owned.

02 · Separate the problems

The uplift wasn’t the root cause.

The uplift wasn’t the root cause.

That distinction mattered. Without it, we could have “fixed” the wrong project and damaged a direction that was already performing well.

01 · Check the new uplift

Confirm whether the issue was introduced by the current work or merely exposed by it.

02 · Compare the current HMI

Inspect the approved interaction and its assumptions against actual system behaviour.

03 · Look backwards

Trace the behaviour into the previous UX definition and identify what had never been fully specified.

04 · Look beyond one screen

Check capability variants, supplier differences, edge cases and the validation process around them.

03 · Three teams. Three answers.

A design debate wasn’t going to solve a system question.

A design debate wasn’t going to solve a system question.

Human Factors, System and Architecture initially disagreed. I brought the discussion back to the current HMI, previous HMI and actual system behaviour.

HUMAN FACTORS

Keep the current design.

The existing design remained defensible from the usability perspective they had reviewed.

SYSTEM

Change is required.

The interface needed to represent the available behaviour accurately across variants.

ARCHITECTURE / DELIVERY

The HMI team needs to decide.

The ownership landed with us — without a single source of truth underneath it.

04 · Build the missing evidence

The investigation moved from opinion to behaviour.

The investigation moved from opinion to behaviour.

We checked system capability, HMI assumptions, previous definitions and real dynamic behaviour — including support from another team to inspect rig / simulation evidence and edge cases.

We checked system capability, HMI assumptions, previous definitions and real dynamic behaviour — including support from another team to inspect rig / simulation evidence and edge cases.

CAPABILITY COMPARISON

Different suppliers supported different behaviours.

WHAT WAS MISSING

The design had been reviewed statically. The behaviour was dynamic.

DYNAMIC VALIDATION

We finally compared the behaviour, not just the screens.

05 · The root cause

The screen wasn’t missing a polish pass. The behaviour was missing a complete rule.

The screen wasn’t missing a polish pass. The behaviour was missing a complete rule.

What looked like a late visual defect was the visible result of several older gaps lining up at once.

What looked like a late visual defect was the visible result of several older gaps lining up at once.

06 · Fix now without designing ourselves into another corner

One problem needed three horizons.

PHASE 01 · MUST FIX

Correct the immediate HMI behaviour

Resolve the highest-priority mismatch with changes that can realistically land inside the current delivery constraints.

Approved direction

PHASE 02 · MUST FIX

Resolve remaining presentation / sizing gaps

Follow with the additional HMI work that needs more asset or component support.

Planned into delivery

PHASE 03 · LONG TERM

Fix the underlying system / UX definition

Carry the remaining behavioural gaps into the next fundamental version rather than forcing a fragile local workaround now.

System gap identified

07 · Change the process, not only the screen

The investigation is now part of how we work.

The missing steps have been captured in our design knowledge base, and the validation gap has already been addressed on the revised design.

capability first

Confirm what the underlying system and variants can actually support before locking the HMI behaviour.

Dynamic validation

Review changing states and edge cases, not only static screens and ideal paths.

Document the rule

Capture missing behavioural guidance in the BoK so the next designer does not have to rediscover it.

07 · Change the process, not only the screen

The investigation is now part of how we work.

The missing steps have been captured in our design knowledge base, and the validation gap has already been addressed on the revised design.

capability first

Confirm what the underlying system and variants can actually support before locking the HMI behaviour.

Dynamic validation

Review changing states and edge cases, not only static screens and ideal paths.

Document the rule

Capture missing behavioural guidance in the BoK so the next designer does not have to rediscover it.

08 · From evidence to agreement

Once the evidence was clear, the debate changed.

Once the evidence was clear, the debate changed.

The revised direction was agreed across the broader review. The question was no longer whether the issue existed — it became how fast we could responsibly land the fix.

09 · Mobilise

Agreement came late. Delivery still needed structure.

Agreement came late. Delivery still needed structure.

With less than a week left, I switched from investigation to orchestration: align the squad, secure design-ops support, split the work, close asset dependencies and plan the remaining delivery.

NOW

Squad alignment


Bring every contributor onto the same problem definition, decision and priority.

NEXT

Parallelise work


Create the required tickets, split ownership and remove unnecessary waiting between teams.

DEPENDENCY

Asset integration


Make sure the revised solution and 3D / component dependencies land together.

3-DAY PLAN

Protect the finish


Keep the final implementation focused on the approved behaviour instead of reopening the design.

10 · OUTCOMES

A stronger decision. A stronger way to reach it.

A stronger decision. A stronger way to reach it.

The design direction is agreed, dynamic validation has been carried out, the missing process has been documented, and the remaining system gap has a future path. The final proof point is simply whether the approved behaviour survives implementation.

WHAT THIS PROVES

Approval is not proof that the underlying behaviour has been fully defined.

Approval is not proof that the underlying behaviour has been fully defined.

After release, this section will record delivered behaviour, whether the intended response survived implementation, and the confirmed outcome.

Protect delivery without hiding risk

Not every late concern justifies stopping a release. The job is to reduce uncertainty fast enough to make the right call.

Turn disagreement into evidence

When credible teams disagree, inspect the system, behaviour and constraints instead of picking the loudest opinion.

Fix the system around the design

The strongest outcome was not only a revised HMI. It was a better validation rule for the work that comes after it.

HMI Product Owner / UX designer

Delivered 2026

Duration 1 year, 3 months