CASE STUDY — PRODUCT DESIGN

SIGNAL — The Decision Nobody Wrote Down

A record for the trade-offs engineering makes and design never sees.

A system that captures critical design and engineering decisions at the moment they’re made, preserves the context behind them, and resurfaces them before they disappear.

ROLE

Product Designer

What I Built

Problem Validation · Flow Design · Clickable Figma Prototype

PLATFORM

Figma (design-tool prototype)

CASE STUDY — PRODUCT DESIGN

SIGNAL — The Decision Nobody Wrote Down

A record for the trade-offs engineering makes and design never sees.

ROLE

Product Designer

PLATFORM

Figma (design-tool prototype)

What I Built

Problem Validation · Flow Design · Clickable Figma Prototype

ost of the time, when what ships doesn't match the design file, nothing went wrong. An engineer hit a real constraint and made the right call to solve it. The decision isn't the problem. Its disappearance is. SIGNAL is a small, tested idea for keeping that decision visible to whoever runs into it next.

✣

This Isn't a Detection Problem

The trade-off usually gets settled in one conversation between a designer and an engineer, and nothing about it ever makes it back into the design file. Six months later, someone new joins the team and "fixes" a workaround that was solving a real problem, and the original bug comes back. Or a designer proposes something already tried and ruled out, and a whole review meeting gets spent re-litigating a decision that was already settled.

The trade-off usually gets worked out in a quick conversation between one designer and one engineer, and then nothing about it makes it back into the design file.

Six months later, someone new joins the team and "fixes" a workaround that was actually solving a real problem, bringing the original bug back.

Or a designer proposes something already tried and ruled out, and a whole review meeting gets spent re-explaining a decision that was already settled.

Three Decisions the Evidence Forced

Record, Not Detect

Every engineer I talked to rejected a tool that flags these trade-offs as bugs. The decision already gets made informally. What's missing is the record, not a detector.

Timing Matters More Than Visibility

Two designers told me, independently, that a note left in the file goes invisible within days. The fix isn't a louder note. It's showing the information only at the exact moment someone's about to act against it.

Documentation Must Be Optional

Every entry gets saved automatically, with an optional note, never a required one. A required explanation is exactly what people skip under deadline pressure.

✣

What They Actually Said

"90% of the time production doesn't match Figma, it wasn't a mistake — it was a consciously negotiated engineering trade-off... Having a bot flag intentional decisions as 'bugs' creates friction where none needs to exist."

— Rajesh K., Engineering manager, async interview

"By day three? It's basically wallpaper... a small text string in the inspector panel is practically invisible."

— Priya I., Product Designer, async interview

What Changed

Stopped trying to catch problems automatically. Started designing to keep a record instead.

✣

Key Flows

Nothing Yet. → 2. Someone's about to repeat the old trade-off.

What happens

A designer tries to switch on the exact option that was already ruled out.

Why it matters

It's the clearest way to catch the exact moment someone's about to repeat a decision that was already made.

The Moment of Choice

What happens

The system shows what was already decided: who, why, and when.

Why it matters

This replaces a note nobody would keep reading with information that shows up exactly when it's needed.

What Happens After an Override

What happens

Choosing to go ahead anyway is saved automatically: who, and when, with room for a short note if they want one.

Why it matters

Requiring an explanation is exactly what gets skipped when a two-minute decision would take fifteen minutes to write up.

What Happens After Standing Firm

What happens

Choosing to leave things as they are gets saved the same way.

Why it matters

Without this, only "go ahead anyway" would leave a trace. Standing firm would look identical to a decision nobody ever questioned, and the exact problem this project exists to solve would quietly come back.

✣

Why the Flow Looks This Way

Nothing here is a queue or a review process. It's a decision, made once, that stays visible for whoever runs into it next. This is what survived two rounds of being wrong: first, that this should catch problems automatically, then, that a note in the file would be enough. What's shown here only appears at the exact moment someone's about to go against it. Going ahead and standing down are treated as equally valid, because nothing in the research said one was riskier than the other. This isn't about judging whether a past call was right. It's about making sure nobody makes it twice without knowing it was already made once.

Nothing here is a queue or a review process. It's a decision, made once, that stays visible for whoever runs into it next.

This is what survived two rounds of being wrong: first, that this should catch problems automatically, then, that a note in the file would be enough.

What's shown here only appears at the exact moment someone's about to go against it. Going ahead and standing down are treated as equally valid, because nothing in the research said one was riskier than the other.

This isn't about judging whether a past call was right. It's about making sure nobody makes it twice without knowing it was already made once.

What this shows

Who decided, why, and when.

What this deliberately leaves out

Severity, ownership, and review status.

✣

Flow Validation

This wasn't tested in a formal usability study. It came from six real conversations: three engineering managers or engineers, two product designers. The flow changed shape twice because of what they said, not because of what looked good on paper. Every engineer rejected the first idea, flagging things automatically. Both designers rejected the second idea, a passive note. What's built here is what survived both.

This wasn't tested in a formal usability study. It came from six real conversations: three engineering managers or engineers, two product designers.

The flow changed shape twice because of what they said, not because of what looked good on paper.

Every engineer rejected the first idea, flagging things automatically. Both designers rejected the second idea, a passive note. What's built here is what survived both.

✣

Why This Project Matters

This started as a much bigger idea, something closer to a full system for keeping every team in an organization in sync, with shared timelines and a shared "decision layer." That's not something you can build, or properly test, in five weeks. So it got cut down to one component, one trigger, one person's decision. Trading the version that sounds impressive for one that could actually go in front of real people and take real pushback. It changed shape twice because of what those people said, not because of what looked cleanest on a whiteboard.

This started as a much bigger idea, something closer to a full system for keeping every team in an organization in sync, with shared timelines and a shared "decision layer."

That's not something you can build, or properly test, in five weeks.

So it got cut down to one component, one trigger, one person's decision. Trading the version that sounds impressive for one that could actually go in front of real people and take real pushback.

It changed shape twice because of what those people said, not because of what looked cleanest on a whiteboard.

Future Opportunities

The Redesign Case Isn't Covered

Right now, the system only notices when someone directly changes the one thing a past decision was about. It doesn't catch a designer building something related nearby without touching that exact thing. That's a real gap. It gets named here instead of glossed over.

The Durable Fix Is Out of Scope

Two designers suggested the more durable fix: bake the constraint into the component so the disallowed option never appears. That's a design-system project. It's out of scope here, and it's the right long-term move.

Credits

Independent project, July–Aug 2026. Design and research original; conversations conducted with real engineering managers, engineers, and product designers.

← Work

Back to Work

Next Case Study →

SIGNAL — The Decision Nobody Wrote Down

SIGNAL — The Decision Nobody Wrote Down

This Isn't a Detection Problem

Three Decisions the Evidence Forced

Record, Not Detect

Timing Matters More Than Visibility

Documentation Must Be Optional

What They Actually Said

Key Flows

Nothing Yet. → 2. Someone's about to repeat the old trade-off.

The Moment of Choice

What Happens After an Override

What Happens After Standing Firm

Why the Flow Looks This Way

Flow Validation

Why This Project Matters

Future Opportunities

The Redesign Case Isn't Covered

The Durable Fix Is Out of Scope

Back to Work

Perfect Properties