Deepwork
- Deepwork
- Product
- Me + a few designers
- Users
- A few days
- Timeline
- Just me
- Team
Project Overview
Deepwork hands you a believable product brief and walks you through six stages before you're allowed to design anything: understand, investigate, frame, explore, decide and review. There's no account, no backend and no AI; everything you write stays on your device. I designed and built it on my own, first for my own practice, then shared it with a few designers.
Designer and builder
I owned it end to end: the thinking model behind the stages, the brief generator, the interface and the working code.
I solve too fast
In UX coaching I kept getting the same note: I jump to a solution before I've understood the problem. Fast, AI-assisted, code-first work makes it worse, because a polished screen hides the thinking that never happened. Knowing it didn't change the habit, so I built a place to practise the slow part.
- What do I know?
- What the brief actually says, sorted from what I'm only assuming.
- What should I ask?
- The questions that uncover what the brief left out.
- What's the real problem?
- One framed problem before a single solution.
Practice needs a new problem every time
Exercises from books run out, and repeating a brief turns into remembering answers. So briefs are generated: industries, products, roles and problem types are combined, unbelievable combinations are rejected, and difficulty shapes the rest. The same seed always gives the same brief, which is what makes a shared daily challenge possible.
The coaching drills were about separating observation from hypothesis, so that became the first stage: every claim goes into 'the brief says this' or 'the brief doesn't'.
Design Opportunity
How might we make slowing down feel like progress instead of friction, so a designer actually practises framing before solving?
Six stages, one problem
6thinking stages before the first screen
A messy brief, every time.
Each practice starts from a generated brief that reads like a real assignment, with the daily one shared by everyone. Or paste the assignment you're actually working on.
First, what do you actually know?
Every claim goes into one of two piles: the brief says this, or it doesn't. It's the observation-versus-hypothesis drill from my coaching, turned into a sort you can't skip.
Good questions unlock what the brief held back.
Each brief hides a few facts. They only come out when a question reaches for them, so a sharp question is rewarded with real information and a vague one isn't.
One problem, in your own words.
Before any idea, you say who is affected and what stops them, written as a problem definition, a user need, an opportunity, a user story or a hypothesis that can be proved wrong.
Three genuinely different approaches.
Not three versions of the same idea: better information, a changed workflow, or a decision taken away. Each one is named and described before any of them is chosen.
Every choice costs something.
You commit to one approach and name what it costs before you defend it.
Then, how did you actually think?
An honest self-rating, then an audit of the session: what the brief was holding back, how many questions landed and where the time went.
Key Learning
- Structure beats advice. I'd known 'understand before solving' for years; a Continue button that stays disabled is what changed the habit.
- Local-first made it honest. With no account and nothing leaving the device, people write what they really think, not what looks good.
- Generating briefs instead of writing them was the right call: endless practice, and the same seed gives everyone the same daily brief.