A Mockup Is a Product Promise

Household context connects a task to calendars, money, and the decision behind it. A month after building those connections, I had to check whether Sivella could do the things its own screens now claimed.

The immediate problem was a new button on the marketing site: “See a live day.”

It was a good button. It gave the page movement and offered a concrete way to understand a household operating system. I asked how it worked.

It did not work. The design had invented it.

We decided to build a scripted day walkthrough. That was the right call for this feature, but it exposed a larger problem. The redesign covered the dashboard, tasks, calendar, kitchen, money, history, onboarding, chat, and marketing pages. Each mockup contained small, plausible improvements. Some matched the product. Some stretched an existing capability. Some described features that did not exist.

A polished screen makes all three look equally real.

The pattern had appeared before the redesign.

At the end of June, an implementation audit found that Sivella’s site marketed budget intelligence the product did not yet have. The Today screen showed a budget summary. Underneath, the system had no budget goals, upcoming-spend model, or tradeoff analysis. The product also described calendar-aware task placement while tasks and availability still lived apart.

We built those systems. Budget context gained real goals, forecasts, and tradeoff data. Task placement began checking free time and workload before suggesting when a task could happen or who might take it. The work made the existing product language true.

Two weeks later, the redesign created the same kind of gap in smaller pieces.

Designers fill gaps because users need the gaps filled

Sivella has a lot of connected surfaces. A task can depend on a calendar. A meal suggestion can depend on the pantry. A household decision can create an expense. The interface has to make those relationships understandable without showing the entire data model.

When a designer sees a missing bridge, they tend to draw the bridge.

That is how useful ideas appeared during the redesign: snooze a task until tomorrow, show a kitchen reminder inside the day view, summarize history entries, add topic badges, explain safe work-calendar sync, and give chat a cleaner composer with familiar Enter and Shift+Enter behavior.

None of these ideas were wild. That made them dangerous to overlook. A button that says “Tomorrow” looks like a minor UI detail. It may require a task service change, recurrence rules, timezone handling, an API update, optimistic state, and tests.

The mockup compresses that cost into one small control.

Copy can invent features too

Buttons are easy to audit because they look interactive. Product copy makes quieter promises.

“Sync your work calendar safely” implies a real boundary between work details and household availability. “See a live day” implies a walkthrough with a beginning and an end. A kitchen card that says an item will run out soon implies a prediction based on purchase or restock history.

Each sentence tells the user what the system understands.

During the Sivella sweep, I asked for a list of features that the redesign had introduced but the product might not support. We traced visible claims and controls through the frontend, API, and stored data. We also checked the earlier implementation audit and the claims already present on the marketing site. The resulting list became part bug report, part roadmap, and part copy edit.

It was the kind of shared, changeable project state I had been arguing for in A Roadmap Is a Working Surface. The difference was that the roadmap now began with visible promises instead of feature labels.

Some promises were removed. Some were rewritten to match current behavior. The useful ones became implementation tasks.

A truth audit belongs in design review

I now want a truth audit beside the usual visual review.

For every meaningful control or claim, ask:

1. What does a user expect to happen?
2. Does that behavior exist today?
3. Is the underlying data available?
4. What happens while it loads, fails, or has no data?
5. Does the same promise hold on mobile?

This catches more than missing features. It also catches fake completion states, dead buttons, sample data presented as live data, and a polished desktop interaction that collapses on a narrow phone.

The source list matters. Marketing pages, support articles, implementation audits, design files, and the running product can each describe a different version of the same feature. Reviewing only the latest mockup misses promises the team made weeks earlier.

The audit needs to happen before implementation starts. Waiting until browser QA makes the missing behavior feel like an engineering mistake, even when the code was never asked to provide it.

Good mockups can pull the product forward

I do not want designers to limit themselves to the current implementation. Sivella improved because the new screens showed better ways to move through the product. The “See a live day” idea was worth building. The chat redesign fixed both the visual hierarchy and the keyboard behavior. The missing-feature audit found small changes that made the product match its own language.

The useful discipline is to label the promise.

A mockup can mark an interaction as live, planned, or illustrative. A product review can decide whether to build it, cut it, or change the copy. Engineering can then estimate the real behavior instead of discovering it inside a finished screen.

This also keeps marketing honest. A feature grid should describe what a user can do after signing in. Aspirational ideas belong in a roadmap or a clearly framed preview.

Sivella’s redesign gave the product a stronger visual system. It also changed the design review. New controls and claims now get marked live, planned, or illustrative before implementation starts. That small label makes the hidden roadmap visible while there is still time to change it.

Building with AI: I set the product boundaries and reviewed the running flows; AI produced much of the redesign and the first implementation passes. That speed made plausible controls cheap to invent, including controls with no complete data path behind them. The response was a truth audit that traces every visible promise through stored data, service behavior, failure states, and browser checks.

What the audit found

The truth audit started with 49 browser captures: 19 public pages and 30 authenticated-app views across Serenity and Focus, desktop and mobile. Thirteen focused reviews then traced visible controls and claims back through the Next.js components, Django endpoints, and stored fields.

That process separated a few very different findings which a screenshot would have flattened together:

• “See a live day” had no implementation behind the marketing button;
• snooze moved a task's due date, but a cached DailyCuration snapshot kept it in Today's grouped list;
• routine generation could make the same snoozed task appear to return;
• the chat composer did not match its stated Enter, Shift+Enter, and Cmd/Ctrl+Enter behavior;
• kitchen reminders and history topic labels existed as plausible UI ideas before their complete data paths were verified.

The snooze case is a good example of why the audit includes behavior. The first backend fix correctly excluded future-dated tasks, yet the visible bug remained because the GET returned an old daily snapshot. A second pass found the cache as the real choke point and invalidated it inside the snooze service. Three tests now cover plan exclusion, routine regeneration, and cache invalidation.

I checked the task and planner behavior, then repeated the snooze flow in the running product. That combination mattered: the first service fix was correct, but only the live route revealed that the cached daily snapshot still returned the task.

Visible promises now become owned work or honest copy before users have to discover the gap. Every substantial control is labelled live, planned, or illustrative. Anything labelled live needs a data source, an interaction path, and a failure state I can reproduce in the browser.