This book is great.
Principles of Shaping
- Shaping work needs to happen at the right level of abstraction. Wireframes are too much and words are too abstract. You need the right balance of both.
- When the scope isn't variable, the team can't reconsider a design decision that's turning out to cost more than it was originally worth.
- When the scope is too vague, the team doesn't have enough info to make proper trade-offs.
Properties of shaped work:
- It's rough: folks should be able to know by looking that it's unfinished. It should leave room for designers and programmers to apply their own judgement and expertise.
- It's solved: despite being unfinished, shaped work should be well thought out. The work shouldn't be specified down to the individual tasks, but the overall solution should be spelled out. Open questions and known rabbit holes should be removed the reduce risk.
- It's bounded: shaped work should indicate what not to do. There is a specific appetite—or amount of time the team is allowed to spend on the project.
- shaping is creative and integrative.
- shaping is primarily design work—viewed from the users perspective. It should define what the feature does, how it works, and where it fits into existing flows.
- shaping requires you to be technically literate—at least to the point that you know what's possible.
- shaping is also strategic, because it requires you to think critically about the problem. What you're trying to solve why it matters, wand hat success looks like? What customers are affected? What is the cost of doing something else instead?
Steps to Shaping
- Set Boundaries:
- Rough out the elements: sketch out a solution—an idea that solve the problem within the boundaries established.
- Address risks and rabbit holes: find holes or unanswered questions and call them out to prevent the team from getting stuck or wasting time.
- Write the Pitch: Once shaped, produce a formal write up that summarizes the problem, the constraints, and the solution.
- figure out how much time the raw idea is worth and how to define the problem.
- if we don't stop and think about how valuable the idea is, we can all jump too quickly to either committing resources or having long discussions about potential solutions that go nowhere.
- an appetite is a time budget for a standard team size (e.g. small vs. large batch). This is not to be confused with an estimation. It's a creative constraint on the design process.
- "good is relative" based on how much time you want to spend and how imporatnt a particular solution is.
- narrow the problem by replacing "what could we build" with "what's really going wrong?" What's driving the request? At what point does someone's workflow break down and cause them to request a certain feature?