Cut toFrame 0304
Home
NotesNov 20259 min readNo. 06
How I price design and build work
Day rates, fixed scopes and why I stopped quoting by the screen.
Words byMara Voss
Start with the decision, not the screen
Most product work stalls because nobody has written down what is being decided. Before I open a design file I write one sentence: what should a person be able to do after this ships that they can't do today? If the team can't agree on that sentence, no amount of polish will save the project.
Then I list what we already know, what we're guessing, and what would change our mind. That one page usually saves a week of meetings.
Design in the material
Static mockups are good at showing how something looks and bad at showing how it behaves. Loading states, empty lists, long names, slow networks — those live in code. So I move into the browser early:
- Sketch the flow on paper until the steps feel obvious
- Build a rough version with real data, even if it's ugly
- Design the details on top of something that already works
- Put it in front of a real person before it's pretty
The prototype is not the product. It's the cheapest way to have the argument you were going to have anyway.
Keep the system small
A design system earns its keep when it removes decisions, not when it documents every possible one. I start with tokens — colour, type, spacing, radius — and the handful of components the product actually uses. Everything else waits until it's needed twice.
This is the kind of token file I hand over on day one:
:root {
--ink: #111113;
--paper: #F2F2EF;
--accent: #22C3EE;
--radius: 10px;
--space: 8px;
}Naming matters more than values. If a developer can guess a token's name without looking it up, the system will get used.
Ship, then listen
Launch is where the useful feedback starts. In the first two weeks after a release I watch session recordings, read support tickets and sit in on at least one sales call. The fixes are usually small — a label, the order of two steps, a default that was wrong — and they matter more than anything in the original spec.
- Measure one thing that tells you people got value
- Fix the top three frictions before adding features
- Write down what surprised you, and share it with the team
The short version
Decide first, design in the real material, keep the system small and treat launch as the beginning. It isn't a method so much as a habit — and it's the one that has made the biggest difference to every product I've worked on.
NotesNov 20259 min readNo. 06
How I price design and build work
Day rates, fixed scopes and why I stopped quoting by the screen.
Words byMara Voss
Start with the decision, not the screen
Most product work stalls because nobody has written down what is being decided. Before I open a design file I write one sentence: what should a person be able to do after this ships that they can't do today? If the team can't agree on that sentence, no amount of polish will save the project.
Then I list what we already know, what we're guessing, and what would change our mind. That one page usually saves a week of meetings.
Design in the material
Static mockups are good at showing how something looks and bad at showing how it behaves. Loading states, empty lists, long names, slow networks — those live in code. So I move into the browser early:
- Sketch the flow on paper until the steps feel obvious
- Build a rough version with real data, even if it's ugly
- Design the details on top of something that already works
- Put it in front of a real person before it's pretty
The prototype is not the product. It's the cheapest way to have the argument you were going to have anyway.
Keep the system small
A design system earns its keep when it removes decisions, not when it documents every possible one. I start with tokens — colour, type, spacing, radius — and the handful of components the product actually uses. Everything else waits until it's needed twice.
This is the kind of token file I hand over on day one:
:root {
--ink: #111113;
--paper: #F2F2EF;
--accent: #22C3EE;
--radius: 10px;
--space: 8px;
}Naming matters more than values. If a developer can guess a token's name without looking it up, the system will get used.
Ship, then listen
Launch is where the useful feedback starts. In the first two weeks after a release I watch session recordings, read support tickets and sit in on at least one sales call. The fixes are usually small — a label, the order of two steps, a default that was wrong — and they matter more than anything in the original spec.
- Measure one thing that tells you people got value
- Fix the top three frictions before adding features
- Write down what surprised you, and share it with the team
The short version
Decide first, design in the real material, keep the system small and treat launch as the beginning. It isn't a method so much as a habit — and it's the one that has made the biggest difference to every product I've worked on.
NotesNov 20259 min readNo. 06
How I price design and build work
Day rates, fixed scopes and why I stopped quoting by the screen.
Words byMara Voss
Start with the decision, not the screen
Most product work stalls because nobody has written down what is being decided. Before I open a design file I write one sentence: what should a person be able to do after this ships that they can't do today? If the team can't agree on that sentence, no amount of polish will save the project.
Then I list what we already know, what we're guessing, and what would change our mind. That one page usually saves a week of meetings.
Design in the material
Static mockups are good at showing how something looks and bad at showing how it behaves. Loading states, empty lists, long names, slow networks — those live in code. So I move into the browser early:
- Sketch the flow on paper until the steps feel obvious
- Build a rough version with real data, even if it's ugly
- Design the details on top of something that already works
- Put it in front of a real person before it's pretty
The prototype is not the product. It's the cheapest way to have the argument you were going to have anyway.
Keep the system small
A design system earns its keep when it removes decisions, not when it documents every possible one. I start with tokens — colour, type, spacing, radius — and the handful of components the product actually uses. Everything else waits until it's needed twice.
This is the kind of token file I hand over on day one:
:root {
--ink: #111113;
--paper: #F2F2EF;
--accent: #22C3EE;
--radius: 10px;
--space: 8px;
}Naming matters more than values. If a developer can guess a token's name without looking it up, the system will get used.
Ship, then listen
Launch is where the useful feedback starts. In the first two weeks after a release I watch session recordings, read support tickets and sit in on at least one sales call. The fixes are usually small — a label, the order of two steps, a default that was wrong — and they matter more than anything in the original spec.
- Measure one thing that tells you people got value
- Fix the top three frictions before adding features
- Write down what surprised you, and share it with the team
The short version
Decide first, design in the real material, keep the system small and treat launch as the beginning. It isn't a method so much as a habit — and it's the one that has made the biggest difference to every product I've worked on.
FRAME 10 — Contact
Have a project? Let's shoot.
Studio 1 · Rec
Tell me what you are making. I reply within a day with next steps and a rough plan.
Booking now forAvailable for work · Nov 2026
Next start dates
FRAME 10 — Contact
Have a project? Let's shoot.
Studio 1 · Rec
Tell me what you are making. I reply within a day with next steps and a rough plan.
Booking now forAvailable for work · Nov 2026
Next start dates
FRAME 10 — Contact
Have a project? Let's shoot.
Studio 1 · Rec
Tell me what you are making. I reply within a day with next steps and a rough plan.
Booking now forAvailable for work · Nov 2026
Next start dates
That's a wrap.
Thanks for watching to the end. Say hello, I read every message and reply within a day.
Write to mehello@maravoss.design