Process · The Brand Operating System
The Brand Sprint is the engagement. A diagnostic week, five working days in the room, and an operating model that holds after Bttr. leaves. Each day resolves one layer of the stack · inputs, decisions, deliverables, all explicit.
The week
Day 0 · Pre-sprint
A one-week run-up. Bttr. ingests the existing brand surfaces, codebase, audience research, and decisions already made. Stakeholders complete a short pre-read so day one starts at decision, not discovery.
Day 1 · Core
Stakeholders in the room. We force the positioning, audience, and promise decisions that usually take months of circular review. The output is a Core that downstream work can inherit without relitigation.
Day 2 · Verbal
We translate Core into the verbal system as rules · voice principles, a naming model that scales, and a message hierarchy mapped to where decisions get made. Pressure-tested against real surfaces, not mood boards.
Day 3 · Visual + Motion
Identity, type scale, color roles, layout grammar, and motion principles. Composable rules, not a static guideline PDF. We apply them live to the surfaces that matter so the system survives contact with reality.
Day 4 · System
The brand compiled into infrastructure. Design tokens, a starter component library, and the bridge into the engineering stack. The day the brand stops being a document and starts being enforced by default.
Day 5 · Governance
Ownership, contribution, and change. The protocol that determines whether the other five layers are still true in eighteen months. We leave the team with a working system and a way to keep it true.
What the team leaves with
Positioning statement, audience model, narrative spine
Voice principles, naming framework, message hierarchy
Identity system, type scale, color roles, image direction
Motion principles, transition primitives, easing library
Design tokens, component library, Figma + code parity
Ownership model, contribution process, change protocol
After the sprint
A recurring cadence where the brand operating system is reviewed against new surfaces, new products, and new teams. Cadence depends on growth rate · monthly for early-stage, quarterly for enterprise.
A defined way for any team to propose a change to the system · what they bring, who reviews, how it gets merged. Without this, the system fragments the moment the second team arrives.
The system ships in versions, not edits. Each release has a changelog, a migration note, and a deprecation window. Teams know what changed, when, and what they need to do about it.
Instrumentation on adoption · which components are used, which surfaces are off-system, where the next defect is most likely to surface. The system reports on itself.
Start
The system is built in a week. The advantage runs for years.
We design, build, and run digital systems for the science, aerospace, and biotech industries.