Design gets lost at the seams.

Discovery

A call about the work and your goals: what you’re trying to change, who has to use it, what’s already been tried, and what “done” looks like to the person who signs off.

We ask two key questions on this call that most first calls defer: who builds the thing and who can settle a disagreement without convening everybody. These two answers decide whether this is work we can do. When we can’t, we say so and point you somewhere better. This might happen, but it’s a far cheaper conversation now than in week six.

The person on this call is the person who does the work. Tom, SUPERBOLD’s founder, leads every project from the first call through handoff and is the one you’ll hear from each week. If part of a project needs a specialist, like motion or back-end development, you’ll know who they are and what they’re doing before they start.

• Fit assessment
• Rough range
• Rough timeline

Proposal & kickoff

A written proposal inside three business days: scope, phases, deliverables, schedule, fee, and a section listing what is explicitly not included.

The not-included list is just as important as the included list. “Out of scope” conversations happen on all projects, so writing it down while everyone is still optimistic helps avoid surprises later. One fixed fee against a defined scope, or a day rate where the work is open-ended. Anything added after signature gets priced in writing before it starts.

Once the agreement is signed and the deposit clears, we hold a kickoff where we confirm the schedule, agree on the working rules, and get access to what the research needs: analytics, support tickets, the codebase, and any existing design and brand files. The proposal gives a real start date, usually two to four weeks out depending on what’s already on everyone’s calendars.

• Scope of work
• Pricing structure
• Schedule
• Kickoff
• Change process

Research & audit

Before we design anything, we find out what you already have and how well it’s working. Depending on the project, that might mean going through pages or screens, talking to the people who build, sell and support the product, reading your analytics and support tickets, looking at how competitors solve the same problems, and talking to your users. For brand work, it also means collecting every place the current identity shows up and how competitors present themselves, and it ends with a short positioning brief everyone can agree on before anyone starts drawing.

The point is that every decision after this rests on what we found and less on opinions (ours included). On design system work, the audit often settles the argument by itself. Put every error message your product shows on one page, from the failed payment to the expired session, and the problem is obvious at a glance: half of them apologize and the other half blame the user. Nobody has to be talked into fixing it and a debate that could have dragged on for months is over in an afternoon.

We’ll write down where things stand today: conversion rates, task completion times, how many support tickets come in, and whatever the project is meant to improve. Without this, the most anyone can say at the end is “it looks better.” Well, we can do better: we can show what actually changed and help you take critical learnings into future projects. If those numbers aren’t tracked yet, we can set up the simplest version we can before design starts so there’s something to measure against later.

• Audit
• Baseline metrics
• Findings & direction

Foundations

The pieces that everything is built on: information architecture, type scale, color, spacing, tokens, naming, and core patterns. For an identity, this is where two or three distinct directions get explored in rough form and one is chosen before anything gets polished.

This is maybe the least glamorous phase, but it means the rest can go quicker. We do it early on purpose: in week two changing the type scale or the spacing is a quick edit and nobody has seen a finished screen yet to get attached to. By week eight the same change means reworking every screen built on top of it, and the question stops being what’s right for the product and more about what people have signed off on already.

• Information architecture
• Foundations
• Core components
• Direction sign‑off

Design

You see and participate in the design while it’s being made, not at the end. Every week we share where things are, unfinished parts included. We skip the big reveal on purpose: someone seeing the work for the first time, finished, is judging something they didn’t watch take shape, and the boldest ideas are usually the first to get cut.

Each major piece typically gets two planned rounds of feedback and one person on your side gathers everyone’s comments into a single set, so we’re never working from five opinions that contradict each other. For the trickiest screens we rapidly build working prototypes in the browser, at real sizes with your real content. A layout question that can go back and forth over slides for weeks usually gets answered in twenty minutes once everyone can click and tap through it.

For identity work, the chosen direction is refined into the finished mark, type, color, and the rules that hold them together, then tested on real applications like the website, packaging, signage, and a sales deck rather than a mockup of a business card.

• Component library
• Page and screen designs
• Prototype

Build & handoff

Either we build the front end ourselves or we hand the design to your engineers with documentation they can work from without having to call us: how each component is put together, how it looks across states (hover, error, loading, empty), when to use it, and how it handles the edge cases, like a very long name or a missing image. Those cases are worked out in advance, not discovered after launch (and slowing the build down).

For identity work, handoff means brand guidelines and production-ready files in every format your team and your vendors will ask for, so nobody has to email us for a transparent PNG.

Nothing is handed over until it has gone through the Build Test, our seven-question check for what usually goes missing between design and build. You can run it on your own work below. After that we stay on hand while your team tests and launches. The real measure of a system is whether your team can keep adding to it after we’re gone, not how good the files looked on the day they were approved.

• Documentation
• Build or handoff
• QA support
• Launch

After

After launch we can support in a few ways. Some clients keep us on a retainer to update the system, design seasonal campaigns, add new templates and plan the next rollout. Others don’t need us at all because the handoff did its job. Both are wonderful outcomes and we’ll tell you which one we think fits you rather than assume you need a retainer.

Either way, a few months after launch we ask to see how the numbers have moved against the starting point we recorded during research. That tells you whether the work paid off and it lets us show real results in our case studies instead of just pictures.

• Retainer
• System updates
• Post‑launch review