Two basic activities
There are two basic activities in UX.
- Learn
- Make
You might call these “understand” and “design,” or “investigate” and “generate,” or whatever. It’s the same. There’s nothing fancy or proprietary about any of this. But you have to do both. If you learn and don’t make you are more knowledgeable but don’t have a solution to the problem. If you make and don’t learn you have a thing, but an indefensible one, with no way of knowing if it is any good.
You might learn to make making easier, or you might have to make some things in order to facilitate learning. You might alternate between learning and making. You might learn, make, make, learn, make, etc. But you’ll do both. Sometimes making just captures what you’ve learned in a form you can use later.
Yeah, this is basic stuff. Baby steps. Even so, some teams fail at this level.
Three “horizons”
I like to think of product delivery, and thus the work of research and design, in three segments or horizons.
Horizon one is the horizon closest to whatever we are hoping to ship soon. I call this the “detail” horizon. It involves creating workflows, selecting and laying out controls, defining behavior, formative usability testing, implementation support, and instrumentation. Most teams seem to do most of their work in horizon one. That’s an anti-pattern; without adequate attention to the other horizons, work in horizon one is poorly-supported, organizations aren’t learning, the designs are accidentally good at best and indefensible at worst.
Horizon three is the farthest out. In the third horizon we’re looking for problems we might solve for our existing or prospective customers, and proposing benefits that will address those problems. Call it the “benefit” horizon. Most teams leave this horizon to product managers and executives, though they shouldn’t. Executives especially can fall into the trap of leaping from horizon three to horizon one, or even shortchanging horizon three in an effort to get to horizon one quickly. Horizon three is learn-heavy, but there’s making in proposing benefits that the team may choose to deliver.
Between horizons one and three is horizon two. This is where we bridge the gap between a benefit and a specific design. I call this the “concept” horizon because there are many ways to deliver a given benefit, and we need to figure out some concepts and choose among them before getting into the details. I’ve witnessed very few teams that explicitly work in this horizon, and the quality of their delivery suffers.
I’m still chewing on this
One quibble I have with this “horizons” idea is that they aren’t numbered sequentially; for a given product you work in horizon three, then horizon two, then horizon one. But naming them works and provides a handy mnemonic for the overall workflow: “benefit, concept, detail.” That might be more powerful than speaking in horizons.
Surely there’s more
Yep. These are just the bones. Flesh yet to be written about:
- Specific learn and make activities in horizons one, two, and three
- How product, UX, and engineering should interact in each horizon
- Double diamond, single diamond, how many diamonds and how large
- Scaling the process up or down to be responsible the task at hand
- Other philosophical points important to this process