Shape it before you design
The skill nobody teaches junior and mid-level designers, and the one-page framework I made from Ryan Singer’s Shape Up.
Mid-year, things were going to shit. I’d been working with AI for over a year and building a lot with my bestie Claude, but nothing felt set. I was switching context constantly. Feeding it the same context again and again. And somewhere in there, I’d stopped noticing how many decisions I was handing over.
It came to a head on a timed project: a hard deadline, so much I could build, and no clear sense of what was actually worth building.
I was frustrated. So I stopped, and reflected. Two things came out of it, and they’re why I’m writing this. I think they’ll help other junior and mid-level designers, especially those in lean teams and startups with a lot of autonomy.
With great power comes great responsibility.
You can do so much now. That’s a problem. Every idea feels one prompt away, so we redesign things because it’s exciting, polish things nobody asked for, and miss deadlines chasing perfection.
I wanted to go back to pen and paper: do the thinking myself, and automate only the parts I want automated. But first I needed to know how much work there actually was, and what was worth doing at all.
Why would somebody pay me $120k?
Everything is a business decision, including hiring you. A company isn’t paying you $120k because you’re a great designer. They’re paying for your skills to improve their business.
Really think about it. The feature you’re polishing, the redesign you’re pitching, the extra week you’re asking for: each one costs the company time and money, and each one is a bet that it will pay off. If you can’t say why it’s worth it, it probably isn’t.
So what am I bringing to the table? Does the user need this, or is it just exciting? How much time is it worth? With AI, designers are turning into product people, and this is how product people think.
One book solved both.
Junior and mid-level designers have always struggled with this. Nobody’s gatekeeping it; it’s just hard to explain. Well, one guy kinda did: Ryan Singer, in his book Shape Up.
It’s a simple exercise: be conscious of how you shape and scope the work before you start. Here’s what I took from it, and why it matters even more with AI.
Know the problem. Write one story, not a list of features: who’s stuck, where, and what they do instead today. One clear story is also the best brief you can give AI. Hand it a list of features and it will happily build all of them.
I start every project with one line: for [user] who [problem], in [appetite], I’ll build [solution], and I won’t [no-gos]. If I can’t fill it in, I’m not ready to design.
Set the appetite. Decide how much time it’s worth before you design. A small fix, or the whole six weeks? Fixed time, variable scope. When AI makes everything possible, the appetite tells you what’s worth doing, and that’s a business call, not a design one.
If it doesn’t fit, I cut scope, not add time.
Rough out the shape. Don’t jump to wireframes. Breadboard the flow with words and arrows, or a fat-marker sketch. This is the thinking part, so do it yourself, on paper, before you open Claude or Figma.
Find the rabbit holes. Walk one user through it in slow motion, start to end. Write down anything new, anything you’re guessing at, any decision you keep avoiding, and settle it now. AI will happily dig into a rabbit hole with you for hours.
Name the no-gos. List what you’re leaving out on purpose so it fits the appetite. A no-go isn’t a failure; it’s a decision. It also stops AI from helpfully adding scope you never asked for.
Build the core first. Make one small, core piece fully work, design and build together, before the edges. Get the scariest part over the hill early: uphill is still figuring it out, downhill is just doing it.
Finish on time. Compare down, not up. This is the part nobody talks about.
Is it better than what users have today? Then it’s done.
Only add time if what’s left is a must-have and all downhill.
Steal my one-pager.
Shape Up is written for PMs and founders. I boiled it down to one page. I now use it for every project, and I want you to steal it. Swap the words in [brackets] and you’re shaping.
01 · The problem
When [user] tries to [task], it breaks at [moment], so today they [workaround].
- One story, not a list of features
02 · The appetite
This is worth [days / weeks]. If it doesn’t fit, I cut scope, not add time.
- Decided before I design
- Small fix, or worth the whole time?
03 · The rough shape
They start at [place], use [button / field], and end up at [place].
- Where does it fit?
- How do you get to it?
- What are the key parts?
- Where does it take you?
04 · The rabbit holes
The part I’m least sure about is [risk]. I’ll settle it by [plan].
- Needs something we’ve never done?
- Guessing how the parts fit?
- Hoping a design exists we can’t come up with?
- A hard decision to settle now?
05 · The no-gos
To fit the appetite, I won’t [no-go] or [no-go].
- Left out on purpose, not forgotten
06 · The build
I’ll get [core piece] fully working first, and [scariest part] over the hill early.
- Scopes mapped; nice-to-haves marked with ~
- Could we ship without it?
- Core, or an edge case?
- Do users already live with this problem?
07 · The finish line
Is it better than what [user] has today? Then it’s done.
- Compared down, not up
- Only adding time for a must-have that’s all downhill
In one lineFor [user] who [problem], in [appetite], I’ll build [solution], and I won’t [no-gos].
This is version one. Tell me what works and what doesn’t, and I’ll keep iterating.