A Case For Outside-In Design
summary
Argues that design starts from external interactions so bounded contexts and services emerge from needs, not speculation; uses concrete workshops and tools — product box, impact mapping, functional mapping, mockups (Balsamiq) and Swagger — to turn goals into features, then into vertical slices and APIs. Cites work for a music startup targeting ~40 million users and an e‑commerce client serving 87 online countries and 100+ stores. Recommends cadence (product box ~biannual, impact mapping per milestone ≈3 months, functional mapping monthly) and growing domain models with outside‑in TDD.
AI-written summary · about
chapters (28)
- 0:00Intro
- 0:31Design
- 1:41Bias
- 3:26How does it work
- 6:59Operational architectural biases
- 8:23Direction of design
- 10:53Design techniques
- 11:47Perspectives
- 13:11Frontend vs Backend
- 15:08Architecture Macro Micro
- 16:47Distributed Systems
- 20:24Design is a means to an end
- 21:13Domain driven design
- 21:37Design from outside
- 22:29Product design from outside
- 25:03Product box
- 25:51Omnichannel
- 28:20Investors
- 28:50Impact Mapping
- 29:50TechCrunch Award
- 30:56How would they contribute
- 35:01The next level
- 35:48An example
- 36:37Catalog
- 41:30Checkout
- 48:56Outside in TDD
- 50:44Moving Forward
- 51:32Brain Dump
related talks
01h 01mDesigning for complexity
05mIntervista
50mDomain Prototyping or Design Is How It Works
27mDesigning Even Larger (JavaScript) Applications
51mUXDD: A New Pragmatic Methodology for Domain Modeling and User Experience.
30mBlending Product Thinking with Architecture
43mGood Fences Make Good Neighbours
37mHow They Work Better Together: Lean UX, Agile Development and User-Centered Design