Maithilee Natu — Product Designer

What is the reality for these ENGINEERS?

Imagine a phone being made. It has hundreds of parts, such as the camera, the battery and the radio, and every one depends on the chip inside. Miss a single requirement in that chip and the phone does not work, after thousands have been built, at a cost that can run into millions of dollars.

So before a chip ships, its engineers have to prove that everything the customer asked for was designed, built and tested. They organise that proof as a V-model.

The tool in this story is where engineers keep that record. It reads their documents, pulls out every requirement, checks each phase for problems and links each requirement to the tests that answer it. The engine already worked. The trouble was reading what it said.

THE PROBLEM

The current tool was clunky and buried the mental model these engineers think in. This made simple setup of tracing requirements feel like assembling a kit before the actual tool even started working.

MY ROLE

So my role was to turn a buried diagram into a workspace engineers could trust!

I redesigned an engineer-built tool into a workspace for chip teams: from finding the V-model on the first screen, to checking the proof behind every phase. I set the product direction, audited the existing flow, then designed and prototyped the project map, the status checks, the way phases connect and the traceability matrix.

CONSTRAINTS

An engine I could not touch.

Engineering had already built the checks and wanted them left intact. My job was to turn what the engine knows into something a person can read.

How engineers already work.

They have used the V-model and the traceability matrix for twenty years. If the main work had moved into an AI chat window, they would have had to give all of that up, and adoption was the real risk. So the familiar pictures had to stay at the centre.

THE AUDIT

The experience was broken

The V-model map was buried

The V-model, the one picture engineers think in, sat inside the assistant’s Function menu as one button among many. Choosing it opened a form that asked for a phase name before anything appeared.

SOLUTION

The map is the workspace. Navigation shrank to a slim rail of icons, so the map takes the screen, as in the image at the top of this page. Opening a project now means seeing the V-model, with the health of every phase and connector on it.

Redesigned project map with the Architecture phase selected and its panel open: Phase flagged, conflicts, duplicates and source coverage, then the requirements grouped by topic

Unclear distinction between phase health and connector health

Every phase reads Completed in green, including phases whose checks had failed. 2, a phase is only a count of requirements, and you cannot open it to see what they are. 3, a top bar of buttons of completely different functions compete with the map.

Hover or click a number to see what was broken there.

The original product screen: a crowded top bar of buttons, and a V-model where every phase box shows a requirement count and a green Completed label

SOLUTION

• Click a phase and the panel on the right opens at the phase level: its conflicts, duplicates and source coverage first, then every requirement, grouped by topic, with a Flagged filter.

• Click the dot on a connector and it opens the trace between the two phases that connector joins.

Reading the traceability across phases

The traceability matrix, the table an auditor actually reads, contradicted itself.

Hover or click a number to see what was broken there.

The original traceability matrix: rows of requirements with Architecture and Design result cells, where a Design cell reads Passed on a red background and the Trace column says Broke at Design

SOLUTION

A dedicated window for the traceability matrix with detailed data. Choose a phase and it becomes the starting point, with the others as columns marked upstream (before it) or downstream (after it). This pattern is similar to legacy tools which the engineers are used to.

ExplorationS

Where should health live?

On the border.

Turn a phase’s border red when it has problems. It is the obvious move, but the border already shows who made a link: dashed when the tool proposed it, solid when a person confirmed it.

CHOSEN

In a badge.

One badge per phase, and a border that only changes colour when you select a phase. Colour now means one thing everywhere: peach means needs attention, green means passed, red means failed. Everything else is grey, with one purple for things you can click.

How much control should connecting a phase show?

OPTION 01

Cut the controls

Pick two phases and press one button. Everything is checked, with no choice of scope.

OPTION 02

Keep five buttons like the original

The original setup: 5 options to choose from, then a checklist for whichever one you picked.

CHOSEN

One question, three answers

I had read the scope controls as clutter, but engineers genuinely need them. So the control had to stay. Ask which requirements to check, and offer the entire phase, selected files or categories.

DECISIONS

Key product decisions

Decision 1: Color means one thing

Peach means needs attention, green means passed, red means failed. Everything else is grey, with one purple for things you can click. Traffic-light colours are already in everyone’s head, so nobody has to learn them. My first version used orange six different ways at once.

Decision 2: The chat stays optional.

Adoption was the real risk: if the main work had moved into a chat window, engineers would have had to give up how they have worked for 20 years.

So the main work stays on the map and the matrix. Most of what the AI does happens behind the scenes, checking, comparing and flagging, so my job was to show what is happening and what is breaking, using signals people already know.

SOLUTION

New flow to increase product adoption and usability

01 / Add a source document

Attach the spec to the Requirements phase, and the requirements are pulled out of it automatically. Checks for conflicts, duplicates and source coverage run straight away, so the phase shows its health before anyone opens it.

02 / Connect phases

03 / Catch conflicts early

Open a flagged phase and its three checks sit at the top. It shows exactly what broke: here, two requirements that disagree on a timing value. A phase is green only when it has earned it.

04 / Set up the right arm and connect it to the left

Open a flagged phase and its three checks sit at the top. It shows exactly what broke: here, two requirements that disagree on a timing value. A phase is green only when it has earned it.

05 / Follow every requirement in the traceability matrix

Every requirement is followed across connected phases in one table, with the same status colours as the map.

06 / Export the RTM

Export the requirements traceability matrix (RTM) in one click. It’s the file an auditor receives, and it reflects every check in the project.

Impact

The product has not been released yet, so there are no usage metrics to report.

BEFORE

The flow was too confusing for our customers’ engineers to follow, and too confusing for investors to follow too.

AFTER

The redesign drove product adoption across 3 enterprise customers, who signed evaluation agreements with us, including 1 in Japan. The clearer flow also helped boost investment in the upcoming Series A round. The numbers cannot be disclosed.

Unvalidated hypotheses

HYPOTHESIS 01

Engineers read each badge correctly and do not mistake Phase passed for “the whole project is fine”.

HYPOTHESIS 02

Borrowing the matrix structure from familiar tools lowers the learning cost.

HYPOTHESIS 03

An optional chat panel is enough to get people to try the AI.

HYPOTHESIS 04

Tracing a finding to its evidence is faster than on the original.

How I would validate it

Task success.

Can they finish the task without help?

Time to find a failing phase.

From opening a project to naming the phase that is broken.

Reading statuses correctly.

Can they say what each badge means, and what it does not?

Tracing a finding to its evidence.

Can they get from a flagged item to the requirement and source passage behind it, unaided?

Reflection

A status is a claim. It should say what it measures, who made it, and what would change it.

I nearly repeated the original’s biggest flaw twice: first with the border, where one signal would have meant two things, then when the matrix quoted a different coverage number than the map. The fix was structural: one source of truth, shown three ways.

Trust is built from familiar signals.

In an AI-assisted tool, people trust what they can read the way they already read the world: traffic-light colour, the V-model and matrix they have used for years, a badge that says what it means. Show what the system did, what a person decided and what is still unknown, and keep the person’s usual way of working in front of them.

← All work

Next project →