I was talking to (at?) @bee today about specs and how Shape Up seems to be advocating for a compromise position. I pulled the relevant bits from my Shape Up notes:
- Aim for in between words and wireframes – so maybe a 0.4 on the spec-trum? [PS, wait, this is just for shaping; later they get to the pitch, which i think is further along the spec-trum.]
- Shaping = rough, solved, bounded – and it should happen in a proverbially smoke-filled room, like with a couple people at a whiteboard.
- Appetite is the inverse of an estimate. An estimate maps a spec to an amount of time. The idea of appetite is to decide how much time an idea is worth first and then shape the spec to fit. Aka fixed time, variable scope.
- Breadboarding (as in a breadboard in electrical engineering): define the key elements without worrying about how the final thing will look visually.
- Components of breadboarding: Places (screens, dialogs, menus), Affordances (buttons, fields – things the user can act on), and Connections (how the affordances take you between places) – this makes for very lightweight/flexible spec’ing
- Fat marker sketches: Like literally a fat marker, or set the pen size to a large diameter if you’re using a drawing app. The idea is that if you’re designing something inherently visual then breadboarding doesn’t work but you still want to eliminate unneeded fidelity in the design. Why? To keep yourself from jumping ahead to too much detail at too early a stage in the design process.
- Designers and implementers will take everything in your mockup as a directive. Stay at the right level of abstraction so they don’t interpret details as directives when you didn’t intend them to be.
- Aiming not for a spec but for boundaries and rules of a game that can play out in countless ways.
- Before a project is shaped enough to bet on, it should be de-risked, ie, have a tight confidence interval on how long it will take.
- Walk through use cases in slow motion.
- Ask questions like what assumptions you’re making about how things fit together, whether it requires new technical work you haven’t done before, etc.
- Anticipate hard decisions that could trip up the implementors and make them in advance. (I think this also fits into the idea of finding the sweet spot on the spec spectrum.)
- Don’t give your team a tangled knot of interdependencies and ask them to disentangle it as part of implementing the project.
- Mark things out of bounds, aka Joel Spolsky’s “non-goals” as part of a well-written spec.
- As part of shaping, run things by experts on the team (making clear that it’s just being shaped, not in the pipeline).
- Ask the experts what risks they can identify. Invite them to a whiteboard and show them what you’ve shaped so far. You’ll either get validation of your approach or have found things to consider as you go back to shaping.
- Write up the pitch. That includes elements of solution, patches for rabbit holes, and fences for what’s in-bounds. Now you can decide whether to bet on it. The pitch also lobbies for resources and solicits wider feedback. Or at least captures the idea for the future.
- Shaping means sketching the solution. It’s not ready to bet on if it isn’t shaped.
- Here’s where the spec-writing comes in. It needs good writing that make people grok it. But still not fully to 0.5 on the spec spectrum – no wireframes or high-fidelity mocks.
- Leaving out some detail prevents boxing in the designers/implementers and prevents bike-shedding.
- But need more detail than the hand-written breadboards from the shaping period – those have a “you had to be there” feel. [there are screenshots with examples of finding this sweet spot above].
- Add a disclaimer in the pitch that, for example, the vertical line divider is not meant as a directive. Clarify how much latitude the designers/implementors have.
- Include visual detail to the extent it’s needed to sell the concept.
- In the fat-marker sketches, use different colors to distinguish material parts of the sketch from annotations that describe it – object vs meta.
So, yeah, some excellent stuff there, I think. And a lot of it is arguing exactly for why spec-writing is so important and why we should do way, way more of it. Just that they’re imagining their audience as megacorp managers or something who go way overboard with spec’ing so they’re all “no specs, just pitches” but what they call pitches are far to the right of where we normally are on the spec-trum.