Architecture and User Experience, Part 8: Exploring Ecosystems of Use

I argue, in the initial articles of this series, that a UX architecture exists. I argue that it is akin to Architecture itself even if UX architecture doesn’t share the strategic position of its older and more established relation. I’ve also suggested that UX architecture will eventually get a seat at the strategy table because otherwise the costs will be prohibitive. Enterprises will either be replaced by competitors that leverage UX in their strategies, or they eventually evolve to leverage UX themselves.

With the business and operational contexts sketched out in the prior set of articles, I turn your attention to UX architecture methods and deliverables. In this installment I discuss how UX architecture is an act of exploration and creation, more than simply documentation. I begin with a quick guide to innovation.

Ideas, Inventions and Innovation

Necessity is the mother of invention; Innovation is the monetization of invention.

Ideas are cheap. Or so we’ve been taught. It’s true for many of us: we can sketch ideas all day long. I had a friend once. He used to call himself the “6-Up” guy, after the popular soft-drink, 7-Up. He’d see a product in a catalog, or a store and say, “I thought of that two years ago. Sheesh. I could’ve been rich!”

The problem here is that ideas aren’t all that difficult to generate. And if you’ve thought of it, likely 10,000 other people have as well. That’s not to trivialize them completely. Ideas are the starting point for any new endeavor, so there’s definitely value in generating them. But it’s well established that ideas don’t pay the bills. We can’t patent them, we can’t trademark them, and we can’t really copyright them.

So we move up the food chain a bit and look at inventions. Now, inventions are pretty nifty, because they embody real stuff, based on ideas, but involving some kind of solution. If you’ve spent any time at all in R&D labs, you’ve felt the wonder of looking at marvelous new things that have sprung into the world. Much of the time you can trace the invention back to its original idea: the inventor, or more likely, team of inventors, can tell you about the moment the idea appeared: over lunch while they were playing a card game, or when they had trouble trying to get an otherwise simple task done.

The invention is a tangible thing, even if it’s just a bare-bones prototype or proof-of-concept. Inventions cross a threshold; they speak to us about plausibility, not just possibility. And of course, they can be quite valuable: the team can file patents and other legal protections; the organization can begin to think about how to leverage the thing to its advantage.

It doesn’t take much to come up with ideas, but inventing something usually involves considerable investment of time, energy, trial and money. When the costs of inventing are reduced, inventors generate a lot more of them. Just look at the explosion of software applications. The tools for creating new software have become so cheap and easy to use, the bar to entry in publishing applications is much lower today than it was ten years ago.

But an invention isn’t an innovation. In fact, the cost of moving from invention to innovation is often substantially more than the cost of moving from idea to invention. Innovating is really hard. Making a marketable product or service is very different from making a proof-of-concept invention. An innovation must account for all of the stages in the Lifecycle map (that I introduced in the prior article). The technical capabilities now become just one gear in a complex machine. An innovation must not only make money, it has to turn a profit.

And all sorts of inputs go into determining whether an invention will make enough money over its lifespan to turn a profit. These inputs include: adoption rates, sales projections, competitor responses, market growth, technology disruptions, cost structures and even the financial and business models themselves.

The stuff that keeps Product Managers up at night is how reliable any of the data are that go into those inputs. Take adoption rates and sales projections as an example. If the new thing is only marginally different from an existing thing, then those inputs could be pretty close to accurate. But if the new thing isn’t like anything the enterprise has sold before, the PM has to look at data other than past experience. Sometimes that leads to primary research, such as pricing studies, feature/function trade-offs and other statistical methods to get insight into how much new prospects (new to the enterprise) are willing to buy and at what price.

UX Architecture and Innovation

Okay, so what does any of that have to do with UX architecture?

Let’s go back to that Lifecycle map, showing all of the touchpoints:

It turns out a UX architect performs the very same research for a UX architecture that Product Management needs for product definition. (The reverse isn’t true, however. PM research may not benefit UX architects. The two disciplines approach research in very different ways: the UX architect is looking at user behavior, the PM is looking at buying behavior. Rarely does buying behavior influence use, but the reverse is almost always true: usage behavior influences buying behavior.)

So, here’s where the rubber begins to meet the road: as UX architects go about their business of understanding an emerging ecosystem of use, they provide valuable information to others in the enterprise. That information isn’t limited to Product Management. As I’ve mentioned in prior articles, that information may have massive strategic value beyond a specific product or service. Organizations that have figured this out are getting double the value from their UX research: not only is it helping explore emerging ecosystems of use, it’s informing business strategy in general.

How to Explore an Ecosystem of Use

So what does a UX architect do to explore these emerging ecosystems of use? There are dozens of techniques, but almost all of them boil down to a few common elements:

• Interacting with (interviewing, observing, engaging with) real users in their current contexts of use
• Offering artifacts (prototypes, diagrams, stories) for users to respond to
• Analyzing (finding commonalities, themes, vocabulary, implied needs in) the users’ stories and reactions
• Conceptualizing (creating new diagrams or artifacts ) from the analysis
• Testing those concepts with users

The key here is to work with real people, in their contexts. There are no ways around it. When you’re working in a completely new context of use, exploring a new ecosystem of use, you need to reduce or remove as many other variables as you can. The “cleanest” experimental design (the one with the least distracting variables) is to visit your presumed users in their current contexts and have them explore your presumed notions. Any other experiment will introduce confounding elements.

That’s not the way research (whether market or user) is typically done.

Indirect Research vs. Direct Observation

Consider a typical light-weight market research effort: call a few folks up and ask them a bunch of questions over the phone. It’s cheap and easy to execute. But it’s often the least informative method for understanding a new context of use. What questions would you ask? What would the answers mean? Here’s an example.

Imagine you’ve been asked to improve the experience of people getting from home to work. (Supposing for the sake of this example, these folks work outside their home). Imagine you’ve been asked by the marketing department to help them craft a survey of 100 such people.

Consider just a few of the questions you might have to ask:

1. If you drive a car to work:
   1. Do you take the car keys off a hook, out of a bowl, or do you keep them in your coat or bag?
   2. Is it parked outside your home?
   3. When you open the car door, do you slip your briefcase in the back, on the passenger seat, or the trunk?
2. What sort of bag do you carry your things in?
   1. A purse or handbag
   2. A backpack
   3. A briefcase

Those may sound stupid, but they’re not too different from many of the questions I’ve seen in marketing surveys or telephone interviews. If you were trying to figure out an ecosystem of use that bridged across all of those touchpoints in the Lifecycle map, you’d have to ask hundreds of such detailed questions. But because you’re looking into a new ecosystem, how do you even know what questions make sense to ask? There are other problems with asking these types of questions, notably, that people don’t recall details very well. Asking them to recount their micro-interactions from memory doesn’t result in accurate data.

Now imagine the alternative way I proposed above: select a few key individuals from your target population of interest. Accompany them on their way to work for several days. Along the way, potentially offer a completely different experience for them consider. At the end of those sessions, you will have 1000s of data points to work with, imbued with meaning and rich with possibilities. Unlike a standardized phone interview, this research doesn’t know what the questions are in advance. And you don’t know, in advance, what value the answers will have. It’s research after all. You’re not supposed to know the answers going in. You discover the answers by interpreting the data.

In the language of statistics, that data is valid, meaning it actually happened; you witnessed it and recorded it directly. It’s not likely reliable, meaning, you can’t predict this information applies to anyone other than the folks you observed. That’s okay, because that’s not the purpose of this research. The purpose is to understand valid, real patterns of use and reactions to proposed changes in the current ecosystem. From that understanding, UX architects craft ecosystems of use addressing problems and opportunities inherent in those use patterns.

An Ecosystem of Use

But wait a sec. What is the “new ecosystem of use?” Is this about observing people in their current context, or intuiting how they would behave in a new context? It’s both.

Consider why you’re going through the trouble of observing a bunch of folks going to work. It could be for any number of reasons:

• You’re designing a mapping system for commuters
• You’re designing a car entertainment system
• You’re designing rain protection gear
• You’re designing a new community

For each of those cases, the observations you make will have very different implications. You’ll likely hear and focus on very different aspects of your individuals’ commute to work. Even if you record the discussions and video record the action taking place, you will frame the data very differently just based on the new ecosystem of use you’ve set out to understand.

This is the first step in creating and exploring emerging ecosystems of use: understand your prospective users in their natural habitat.

The second step is to immerse them in a new context of use and understand how it differs from their usual context. “Differ” might mean “improved” or it could mean “degraded.” It doesn’t matter at this point, because we’re just trying to understand prospective users’ reactions, one way or another, to our proposals.

Conclusion

UX architects must work with real people in their contexts to understand their goals, motivations, desires and emotional responses. If we are to design experiences that are delightful (or frightening or whatever) we need to understand what delight (or fright) means to our targeted audience. That same information is valuable to the business at large: knowing the goals, motivations and desires of targeted customers doesn’t just make for a better product experience, it informs strategic decisions about all future products.

A UX architecture provides much more than insights into prospective users and their reactions to proposed ecosystems of use. As the previous articles have discussed, a UX architecture must also provide an “operations manual” for the organization, along with a vision and specific design patterns. One of the challenges UX architects face is communicating these to organizations that may not share a language of design or UX. In the next set of articles I detail the kinds of documents and deliverables UX architects must provide and how they need to communicate them to their organizations.