[UPD 2025] Exploratory notes from 2020
It seems like my UX basics are covered, so let’s go look for some actual product design mindset.
I’m at a point where I’ve grown tired of our local “just do it fast and by yourself” approach, but haven’t yet learned how to do it the “proper,” western way. So what’s the required minimum for big-market product teams in Berlin or San Francisco? Design sprints seem popular — let’s see why.
I accidentally found the most hilarious English-language design podcast. Jake and Jonathan is one of those informal shows where you can relax and be entertained while listening to smart people ramble about their daily “kitchen” problems — instead of the over-formal usability conference talk that feels like a college class.
Behind the silly facade are two successful product design leaders casually dropping great ideas from deep experience. And, surprise, one of them wrote the design book I hadn’t finished. Good reason to get back to it…
The book’s premise is simple: read it and you’ll see the process that saves time and helps teams develop new products and features at places like Slack, Google, Blue Bottle Coffee, etc.
The process is called a design sprint. Almost certainly you’re confusing it with regular engineering (Scrum) sprints — but the idea isn’t that different. In regular sprints we set moderate goals and tasks for a few weeks. In a design sprint we try to unblock a hard product problem in one week. The book is very specific about the timebox.
The author gives a clear checklist of what to do, when, and with whom to attack your most burning problem — design, documentation, or product direction in general. Common thread: test with real users as soon as you can. The team gets in one room for five days, communicates differently, builds fast, and learns from quick user sessions.
The whole book could be fit into a small picture:
Design Sprint schedule:
Monday — review and map the problem.
Tuesday — switch from problem to solutions.
Wednesday — finish sketches and notes, agree what to test, and document each potential solution in detail. Only execution remains.
Thursday — build a realistic prototype/mockup.
Friday — test the prototype with users.
“Well, feels like I already do most of this at work.” — Sure, but the devil is in the details
While it reads like a retweet of fundamental software processes, it’s more than that. The book asks your team to clear a whole week, turn off gadgets, and follow a strict schedule to focus on one specific goal — which makes it reasonable to expect outsized results. The author brings plenty of inspiring stories.
Big companies with too many complicated processes sometimes want to feel small again. They want it so much that the author makes a living just by talking about design sprints. And his co-host (from the podcast mentioned above) runs a whole fancy agency in Berlin and flies their team across the world just to tell people how to do it. Now I understand why.
Right now I'm just borrowing pieces — Map becomes our Monday where I frame the problem and pull references and data; Sketch turns into two quiet days of solo drafts; Decide becomes a mid-week team review; Prototype is Thursday's polish into a clickable flow; Test is a Friday unmoderated run (or a handoff to our UX researcher) so we've got insights by Monday. Our cycles are scrappy, so I wouldn't pitch the whole ceremony for every feature — I save it for big, ambiguous bets or when alignment/exploration gets stuck. When the stakes and team size line up, I'd love to run the full week.
#buysprint 😸