Working on some teaching material to help a wider variety of real-world teams implement Shape Up.
(Took inspiration from Kathy Sierra's work and replaced abstract iconography with more brain-tickling photos.)
A couple key ideas... 1) There's no single "bet." It escalates in rounds, like funding at a project level.
Framing the problem & biz value takes work. Someone spends a couple hours to frame this instead of that.
Ditto shaping. It takes time, and dedicating the time to do it is another small bet.
Feb 14, 2022 • 5 tweets • 1 min read
Another tool from rigorizing shaping: the language of "paths."
Eg. We want hot water for tea. Everyone discusses their favorite kettle. What's a different path? How about a hot water tap with a tiny sink?
Different paths have different parts to integrate, costs, outcomes.
Teams I'm working with lately use a shaping canvas, with slots for paths A, B, C from the start.
The language of paths lets anybody say "wait wait.. before we keep going deeper on this ... is there another way? Who's got a path B for this?"
Very often leads to breakthroughs.
Feb 14, 2022 • 4 tweets • 1 min read
Been rigorizing the steps of shaping so more teams can do it. One tool is "spiking."
Shaping sessions are live, fast, collaborative. Identifying paths, sketching out the parts. But then you hit an unknown.
Spiking is where one person puts their head down to answer that unknown.
Spikes can be technical: Does that data source provide what we assume? Does that API actually behave the way the docs make it seem?
Or visual: Where else could that affordance go so it doesn't overcrowd the nav?
Even legal: How would that change violate compliance?
Nov 9, 2021 • 6 tweets • 2 min read
To answer this, divide usability problems into:
1. Perceptual: Things like "couldn't figure out what to do next", "didn't know they could click that button..." etc.
2. Domain-specific: "We need a way to jump back because in the workflow this happens..."
In general, usability testing only catches type 1 perceptual problems. Because in those tests you take people out of the real world and assign them tasks.
Conversely, usability testing doesn't catch domain-specific problems because those only come up in real life real world use.
4 subscribed
