Cynefin for Designers
“When will it be ready?”
Product Development teams tend to hold together through a set of natural tensions–Product Managers have a focus on delivery; Scrum Masters have a focus on quality of process, and the natural tension between those two foci should produce an acceptable balance of pace vs technical debt. Another natural tension that exists is between that PM focus on delivery and Designers’ (whether UX or Visual) focus on quality of solution. Never is this more obvious than when a PM asks a designer when the assets will be ready.
For almost my entire career as a designer of one type or another, I’ve been pretty crap at estimating how much time and effort will be involved in delivering the design artefacts of a given product. Even now, my response tends to be “how long have you got?” and I’ll try to fit the best design process I can into that duration. The story we tell ourselves as designers is that design is fuzzy and iterative, design creates something from nothing, you can only constrain the time available, you can’t estimate design effort.
That’s a problem, and not just for PMs. That’s a problem for me, because I have serious issues with the way design gets equated with magic. When design looks like magic to stakeholders, it’s impossible as a designer to demonstrate value. Only when design is open and accessible, and we show how our creative disciplines work to deliver business value, can we get that seat at the table we’re always complaining about not having. So not being able to support the PM in their need for visibility is a huge problem for me.
Think of this another way; if we had the ability to properly estimate design effort, we’d have a clear answer for that question of “when will it be ready?” We could justify the elements of the design process that typically get smoothed away in the white heat of software delivery. What a virtuous cycle we could establish if we could both give visibility of what we do and set expectations about the relationship between design time and business value.
When in doubt, steal something that works.
Another story that designers tell ourselves is that we’re the bastion of creativity on the project, but I firmly reject this view. Not only should every team member be a source of creativity, we’re not even the only explicitly creative people on the team. Coders create. That’s literally all they do. And they’re sufficiently good at estimating creative effort that Agile’s primary metric of progress, Velocity, is actually a measure of how consistent their estimates are over time.
Nobody can predict the future, so developers have learned that the most effective way to estimate is to avoid trying to pin timings onto work. Instead, they assign “t-shirt sizes” according to the relative effort they perceive in each user story. Something trivially easy might count as an Extra-Small while a sprint-long slog would be an Extra-Large. Beyond this, they can assign something as “Too Big” or “Too Undefined” meaning more work needs to be done to break down the story into something actionable. A good estimation process gets to a consistent relationship between the amount of work accepted into each sprint and the amount of work delivered each sprint — consistency being far more valuable for estimation than numerical accuracy.
The key to making t-shirt sizing work is to have an understanding of the effort it will take to create something. A good proxy for effort is the complexity of a feature — a more complex feature (in development terms) will naturally take more effort to implement. Design effort and Development effort are completely decoupled, but it’s still true that a more complex feature (in design terms) will take longer to design.
It turns out developers even have a framework for estimating how complex a feature will be. I say we steal it.
Introducing Cynefin
Cynefin is a (deceptively) simple framework for assessing complexity. Invented by Dave Snowden, it’s been used in all sorts of fields from politics to healthcare. Oh and it’s not pronounced how you expect. You actually pronounce it K’nevn, although I think Dan North explains it best.
Cynefin works by sorting problems into five buckets of complexity, or domains (although the boundaries between the domains are soft and fuzzy). Each domain has some technical definitions and specific approaches which each deserve a more complete post, so for now I’ll just give an introduction.
Sat right in the middle of the model is the Disorder domain. This is where your unexamined features live. They could have large or small amounts of complexity, but because you don’t know that, what they really have is lots of uncertainty and risk. When something lives in the disorder domain, you’ll revert to your comfort zone when solving it. You want to get as many things as possible out of the disorder domain and into one of the others, because this gives you more visibility and different tools for approaching them. Absolutely do not start working on things that are in this domain or you’ll rapidly run into severe trouble.
Guess what’s in the Obvious domain. This is where known knowns live (bless Donald Rumsfeld for giving me one of the most-used terms in my professional vocabulary). This is the place to put problems that are so simple, so everyday, that trying to innovate or revolutionise them will only be counter-productive. Things like one-click unsubscribe processes and login forms, where there’s one accepted (if evolving) way to design them and anything else hurts usability. Obvious used to be called Simple, so you may still see it called that in other Cynefin resources.
Moving on we come to the Complicated domain. This is where known unknowns live. For example, when you need to add display advertising slots to your product, the specific layout of your page will make certain unpredictable demands, but there are patterns and rules of thumb we can use to simplify the process of integrating it. Interface widgets, alerting users to new functionality, error messages and such are all examples of requirements that generally fit into the Complicated domain.
Pay close attention to the Complex domain, because this is where design has the chance to prove itself. Complex problems are unknown unknowns: New things that nobody’s done before (or that you as a disruptor need to do in a better way). In the Obvious and Complicated domains, most of the problems you’ll be solving are about getting users into and through your product — those are the standard, repeatable approaches that everybody needs to implement. That leaves Complex problems as being the ones that differentiate your business: ie, they are probably where your business makes its money. These are the requirements that you need to approach with new knowledge and creative discipline, and you need to be open and transparent with the process of discovering and designing them because you won’t be able to explain them in terms of examples from existing businesses. In visual design, I’d say this is the domain in which you would develop the design system into which everything else will fit.
Finally, the Chaotic domain is where we find unknowable unknowns. In design terms this is the moment in a workshop where a senior stakeholder pulls a whole new set of requirements out of thin air, or user research shows that a pivot is required, or making a good decision relies on finding out the market’s response to it. In most industries, the Chaotic domain means that something is on fire and the first thing to do is put the fire out; in design we’re lucky that we aren’t usually quite so up against the sharp edge. Nonetheless, it’s important to recognise that when a Chaotic problem comes up, it has to be priority #1 to address it, otherwise it will continue to disrupt (or even invalidate) everything else you do.
In the Chaotic domain we’re encouraged to act first, in order to give us outcomes to guide our thinking for better solutions — sounds a lot like Lean UX to me (and implicitly gives us the guideline to save Lean discovery processes for the really important stuff).
Finally, there’s a fold between the Obvious and Chaotic domains. This is there to remind us how easily we can tip things over from simplicity to chaos — just as easily through complacency or overthinking.
How does this help with design?
In my opinion, the most important thing Cynefin does for designers is to show us where to focus our effort. We all want to make an impact on the world, but trying to reinvent the login form is a waste of effort, and worse it takes away resources from a place where we could have meaningful impacts on customer value and design practice.
Having a clearer understanding of the relationship between complexity and effort in the form of these buckets also opens up the potential of T-shirt sizing for design estimation. Obvious and Complicated requirements are probably atomic enough to go into sprints. We can even timebox requirements in those domains with confidence that we’re still delivering a good experience, and we can give the PM accurate estimates. All this serves to give the PM more confidence about their delivery schedule and puts design on a more equal footing with development.
Problems in the Complex and Chaotic domains require our full range of discovery tools; probing the problem with research, sensing solutions through creative discovery and responding with a well-considered design. I personally wouldn’t even put requirements that fall into the Complex and Chaotic domains anywhere near the sprint until they’re better understood, but it may be valuable to break your approach to them into tasks and t-shirt size the tasks, whether for sprint estimation or just general visibility.
In the general case, seeding the language of Cynefin into our businesses helps us frame useful conversations around design decisions — “The login form is an Obvious requirement, so we’ve just followed LukeW’s best practices. But for us, the date selector turns out to be Complex, so let me explain how we came to this solution…” This gives us a much more powerful, cross-disciplinary method for discussing where the business needs to create value for users and where hidden complexity has or might arise.
These are not the only benefits. Since I’ve been using Cynefin in my own work, I have a clearer idea of which tools to use when approaching new challenges, more understanding of which details to sweat, and a greater sense of how design work moves from the more complex to the less complex domains, which helps me get it across those boundaries faster and at higher quality.
We still can’t predict the future
Cynefin is a useful framework, but there is more than a grain of truth in what I said before about design creating something from nothing. At the beginning of a project, when you’re in discovery, you need to zoom out and use Cynefin at the 10,000ft view to identify places where you need research and ideation.
When you get down to later stages of the project, be wary of stakeholders taking estimates as deadlines. I’d always resist any attempt to break t-shirt sizes down into actual time estimates, especially when you’re just starting production of assets and still figuring out how fast you can go.
I’m standing on the shoulders of giants
A lot of the heavy lifting of understanding and explaining Cynefin has already been done for me by Liz Keogh, and of course without Dave Snowden’s giant glowing brain we wouldn’t have the model to work from. I also owe a debt of gratitude to selena hadzibabic and Darci Dutcher for their feedback on early drafts of this post. Any errors this article presents in interpretation are entirely mine, and any moments of genius understanding it prompts are entirely theirs.
Early days for Cynefin in design
I don’t know of many people using Cynefin like this, and I’d love to hear from anyone who does. Leave comments or tweet me at @sparrk.
