Process
A process with your sign-off at every gate.
Every project follows the same thirteen steps, and nothing moves forward without your okay at six of them. Design comes first, before any code.
What happens, and what you get.
- Understand
01Discovery
We talk about the business, the problem and the constraints. I review the current site if there is one, list what I find, and ask the questions only you can answer. One person on your side is named as the approver, so feedback does not arrive from five directions.
You get: A fact sheet and a short list of questions.
-
02Research
I look at what success means for this project, who else is in the space, and what people actually search for. This keeps the later decisions grounded in evidence instead of taste.
You get: A short research summary.
- Strategy
03StrategyYour approval
The plan for what the site says, to whom, and how pages connect. It covers the sitemap, the keywords each page targets, and what content needs to exist before design starts.
You get: A content strategy and sitemap for you to approve.
-
04ProposalYour approval
A written scope with a timeline and a price, based on the approved strategy. Nothing is built until you agree to it.
You get: A proposal for you to approve.
- Design
05Styleframes
I design three visual directions using your real content. They differ in mood, type and layout, so you are choosing between real options, not three tints of one idea.
You get: Three styleframes to react to.
-
06Direction approvalYour approval
You pick a direction, or combine pieces of several, and tell me what is wrong with it. That feedback is applied to the design system, not patched into a page.
You get: A chosen direction with your notes applied.
-
07RefinementYour approval
The chosen direction becomes full-page designs for the pages that matter. We go through as many revision rounds as it takes to be right before any production code is written.
You get: Full-page designs, approved.
- Build
08Build plan
Each page gets a brief, the design system gets written down as tokens and components, and the build is broken into pieces that can be checked one at a time.
You get: A build plan.
-
09Build
Development happens on a staging site you can open at any time. You see working software regularly, and tests are written alongside the code, not after it.
You get: A working site on staging.
-
10Content and reviewYour approval
Copy and images go into the real site and you review them there, where they actually appear. It catches problems that never show up in a document.
You get: A review link, and your approval.
- Launch
11Quality checks
Accessibility against WCAG AA, performance against Core Web Vitals, security headers and configuration, structured data, redirects, and testing across browsers and devices.
You get: A QA report.
-
12LaunchYour approval
A pre-launch checklist, the release itself, and monitoring while the site settles. You approve before it goes live.
You get: A live site and its documentation.
-
13Support
Two weeks of fixes and questions after launch are included. After that, ongoing care is optional and agreed separately.
You get: A support period.
Why the design stages come first.
Three real choices
The styleframes use your actual content and differ in mood, type and layout. You react to something concrete instead of a mood board.
Feedback goes into the system
When you say what to change, it is applied to the design system, so the fix shows up everywhere it applies.
Cheap to change, then expensive
Changing a design is quick. Changing a built site is not. The gates put the decisions where changes cost least.
How long does a project take?
It depends on scope, and the proposal states a timeline you can approve. The gates are there so that timeline is based on decisions you have already made.
What if I do not like any of the three directions?
Say so and say why. The feedback shapes the next round, and you are not charged for being specific about what is wrong. Often the answer is a mix of parts from two directions.
How many revision rounds do I get?
Refinement continues until the design is right. The proposal sets the expectations, and in practice a clear approver on your side keeps rounds short.
Can we skip stages?
Some projects compress them, but design before build and your approval at the gates stay. They are what keep the cost of changes low.
Does this work for a web app, not just a website?
Yes. Content and copy stages give way to product scoping and iterative delivery, and the design gates stay the same.