Build the working method the product needed — written principles to decide by, a design system to build from, and a documentation format that survives a feature past its release.

The two chapters before this one describe what got designed. This one describes how, and it's the part of Cervello that outlived the product for me personally: everything I do in regulated banking now started as a habit formed here.

These were written at the start, to settle arguments before they happened. Two of them are ordinary; two take a real position.

Seamless. Design the journey as a funnel with no leaks — every step leads somewhere, nothing dead-ends.

Defensive design. Always be looking for what could go wrong next, rather than designing only the path where everything works.

Security over usability. When experience matters, security is the target and usable design is the way there. On a platform that eventually controls physical devices, a smoother screen is never worth a weaker one. This principle is what produced the sign-up decision in the previous chapter — refusing to confirm whether an email is registered, at the cost of a small convenience.

Context over consistency. It's better to be right than consistent. This is the one I'd defend hardest. Consistency is a means, not an end — and treating it as an end produces interfaces that are uniformly wrong. When a situation genuinely differs, the design should differ with it.

Both of those positions show up again years later in banking: refusing to let a shortcut weaken a compliance record, and giving the same underlying data two opposite presentations because a customer and a bank officer read differently. The vocabulary changed; the principles didn't.

Before anything was drawn, each feature was written as an idea card: the problem, the value proposition, the capabilities required, and — the part usually skipped — its restrictions and limitations, stated up front.

Naming what a feature won't do at the moment it's proposed is what stops scope from being discovered halfway through building it.

Rough wireframes came next, deliberately rough. Their purpose is to move an idea out of your head and onto paper so the idea itself can be judged — not the visual design of it. A polished screen invites feedback about spacing when what's needed is a decision about the concept.

Handoff wasn't a file drop. Visual design was abstracted into components and sorted into three explicit groups:

Existing components — already coded in the design system; reference them and reuse.

New components — genuinely need to be built.

Generic style guide — the rules that apply across everything.

The value of that sorting is that it makes cost visible before estimation. An engineer reading it knows immediately what is assembly and what is construction — rather than discovering it mid-sprint.

This is the piece of method I'm proudest of, because it isn't a deliverable — it's a format.

Every feature gets one document that follows it from first idea through post-release iteration. Thirteen sections:

Summary · Problem definition · Targeted persona · Solution · Value · Validation · Description · How it works · Scenarios · Pre & post-requisites · Acceptance criteria · API documentation

And every iteration is added as a thread inside the same document rather than a new file.

That single rule is the whole idea. The usual failure isn't that teams don't document — it's that documentation fragments: a spec here, a ticket there, a decision in a chat thread nobody can find. Six months later someone asks why is this like this, and the answer costs a week to reconstruct — or is rebuilt wrongly.

Keeping problem, solution, acceptance criteria and every subsequent change in one continuous thread means a feature's reasoning survives the people who built it. It reduces rework in design and in code, because the question that triggers rework — why does it work this way — has an answer with a location.

Two-layer documentation, principles that settle arguments rather than decorate a deck, a component library sorted by build cost, a record of why each decision was made — all of it started here, on a product for developers.

It is the same method applied later to a bank: business-facing documentation carrying story, alternatives and rationale, and a separate engineering handoff layer carrying grid, components, interactions and edge cases.

Cervello has no numbers I can show you. What it has is the method, still in use five years later — in a different industry, on different problems, under regulation the IoT product never had to answer to.