I've learned the lesson before, but I'm still susceptible to the trap — I'm trying to avoid falling in again.
We spent two years to gather data and model out the core skills of research practice in building the Research Skills Framework. I still find it comprehensive and elegant. Especially now, it offers a useful frame for exploring where research practices are shifting while the product development it supports is shifting onto new and uncharted technology.
But for all its charming comprehensiveness and elegance, it serves more as a reference tool than an entrypoint into a novel and helpful way of thinking. We built a pattern language (*see note) and fulfilled the goal of "building a research skills framework," but, during its development, had not come to grips with the critical questions: who was it for, how would they use it, and what would change when they did so?
We ran a workshop online at the UXInsight Festival (*see note) in 2020, which happened to be the first invoice I issued after Dave's Research Company was a functional financial entity. It went quite well, though the stronger exercises were built off of those we had already developed for data collection. The final modeled output of the RSF served more as an augmentation for the workshop content than a new direction.
The trap for frameworks is similar to the traps in product development: a lack of clear purpose or specific target for action. The thing itself, for the creator, is so interesting in its own right, it's easy to forge ahead without making sure the major play is grounded. The irony is that, in consulting and research projects, I have developed a nearly-intuitive feel for the abstraction and lack of concrete grounding when others are driving the work. It's a different animal when the work is your own.
I've seen it from the outside, as well. In Stockholm — January of 2017, cold — I was helping Majid Iqbal edit the near-final draft of Thinking in Services. I found his framework convoluted, comprehensive, and potentially powerful. As we debated the level of work required to bring readers into his thinking, I recall an obstinance and a resistance to simplification that baffled me at the time. Majid wouldn't back down — the framework was so tightly woven, wound up, and bound together, that any proposed compromise or reduction of its governing rules was felt as physical harm. If I have one critique of the framework as a whole, which I still find terribly elegant and unbearably comprehensive, it would be the insistence on global symmetry, instead of local symmetry and coherence.
Let's say that it wouldn't pass the table napkin test. I was still working to load my mind with Majid's framework after reading the draft two or three times over. As for the test, Dave Snowden says:
One of the golden rules of sense-making is that any framework or model that can’t be drawn on a table napkin from memory has little utility. ... Models with multiple aspects, more than five aspects (it's a memory limit guys live with it) or which require esoteric knowledge are inherently dependency models. They are designed to create a dependency on the model creator.
If you're following along in the last weeks and months, you've felt some of the meandering shifts in tone as I explore different ways of speaking about what I'm trying to explain. The table napkin test is proving helpful: the best entrypoint is the simplest, and I've almost been able to reduce everything important into five simple aspects.
This solves some of my problem. The sequential numbering gives us an entry point for explaining where to look when you're facing difficult product situations and forces an explicit reduction in what I can and should convey. My friend Andrew reminded me the last time we spoke that I still need to build clarity around transformation — what are people going to do differently, if they use your thing? — as that's the ultimate razor for choosing what's included, and what isn't. It's also the key for getting out of the comprehensive framework trap I've been teetering on the edge of. The framework doesn't need to encapsulate everything we've discussed so far about organizational games and complexity and the quality of moves. It only needs to serve as a way into that thinking, and a visual aid for the deeper theory.
Here's how I see the framework's primary use, right now: When you're working with struggling teams, leaders pushing bound-to-fail pet projects, and other potentially baffling scenarios, you need to snap your vision down to the specifics of the game behind the problem. You'll need to see enough of what the others see to understand what's driving their action. And you'll need to figure out what is preventing them from seeing what you do, so you can find leverage and ways to challenge those blocks. The framework is the lens for seeing those things. The table napkin version gives you five initial places to look at which are where most problems tend to emerge.
Other things of note
- *At the time, I had just re-read A Pattern Language, and began attending the Building Beauty reading seminars on the Nature of Order. I had most of Takashi Iba's books about pattern language, too. (Many good friends and family received a copy of APL during this phase.) I had also discovered Wardley Mapping as an interesting means to make sense of evolving activities and practices. Part of what sealed the RSF off from an audience-based purpose was my desire to learn how pattern languages and Wardley maps worked by using them for and seeing where they met.
- *UXInsight is in its 11th year. And if you're reading this in email, you have one more day to apply as a speaker — the deadline is October 13th. See here: https://uxinsight.org/ux-research-conference-festival/call-for-speakers/.
- After we ran the RSF workshop at UXinsight, I ported the digital workshop to a physical environment, running a similar one for UXLX in 2022. I printed loads of paper and did not think through every piece I had lost in moving from digital to analog. That one turned out to be the second-worst workshop I've ever delivered. There's always more to learn and improve on.
Until next time,
This is Dave's Monday newsletter for leaders in the product org: make good moves, help others play, reshape the game.
