Read on Twitter
Lately, before I start breadboarding or fat-marker sketching, shaping looks like this: a list of things the system should do.
This technique goes all the way back to this 2004 piece: https://37signals.com/papers/introtopatterns/
The difference is we're clearer on what "bits" are: they're functions.
This technique goes all the way back to this 2004 piece: https://37signals.com/papers/introtopatterns/
The difference is we're clearer on what "bits" are: they're functions.
Breadboards or fat-marker sketches later fill in the space on the right.
The list on the left is never perfect or comprehensive. Sometimes by sketching on the right I see things missing on the left. That's "flipping spaces" — from what it should 'be' to what it should 'do'.
The list on the left is never perfect or comprehensive. Sometimes by sketching on the right I see things missing on the left. That's "flipping spaces" — from what it should 'be' to what it should 'do'.
Items on the left are in no logical order. They're in the order I think of them. ~ means nice-to-have, not necessary.
Identifiers allow me to make placeholders on the right side without spelling everything out at once in a single sketch.
Identifiers allow me to make placeholders on the right side without spelling everything out at once in a single sketch.
Items on the left can compose. For example it may be that a single function on the solution side should satisfy S1, S4, S5, and S6 because of interdependencies. When I design a piece of solution on the right I can label that (S1 • S4 • S5 • S6). Mapping needn't be one-to-one.
That composition maps to what the old 2004 piece called "chunks."
Seen as a value-network, it's a question of where to draw the boundaries between problems that have to be solved as interdependent pieces and which can be solved as modular pieces.
Starting to populate the right side...
Defining spaces where some functions can happen. Discovering questions along the way.
Note how different this is from a wireframe. Shows the unknowns and holes. Mixture of requirements and solution. Communicates a whole thought process, not just the output.
Note how different this is from a wireframe. Shows the unknowns and holes. Mixture of requirements and solution. Communicates a whole thought process, not just the output.
Sometimes we see the "middle" of a piece of design first, and draw it.
Othertimes we don't know the solution but we do know the walls around it—what it should do and not do, where it might fit in. Then we draw the walls for it and leave the middle to fill in later.
Othertimes we don't know the solution but we do know the walls around it—what it should do and not do, where it might fit in. Then we draw the walls for it and leave the middle to fill in later.
More questions arising, presenting trade-offs. About to make a call and then all the red will go away.
Wishing the tool for doing this would record all intermediate states to "play back" all the decisions and revisions to explain the concept later.
Wishing the tool for doing this would record all intermediate states to "play back" all the decisions and revisions to explain the concept later.
Stubbing G2 and G3. The concept starts to get sharper.
(Reminder: I don't know if we'll actually build this. This is shaping, not betting.)
(Reminder: I don't know if we'll actually build this. This is shaping, not betting.)
Finished shaping. Broke out into six main systems, two of which are flagged nice-to-have (~) in case there's too much work for the appetite.
The above is work product, not a presentation.
The presentation will take the form of a pitch, which walks through the concept in a narrative form and makes the case for betting on it.
The presentation will take the form of a pitch, which walks through the concept in a narrative form and makes the case for betting on it.
