Architecture and User Experience, Part 5: Preparing for Success

In the past several articles, I’ve argued Architecture is a strategic element of the enterprise because it is risky (failures are costly), it impacts people’s lives and it is a fundamental human need. UX architecture, and its key component, UX strategy, aren’t nearly as strategic. I’m certain UX architecture will cross that magic threshold, but only after organizations suffer significant losses in their markets due to poor UX strategy and execution. Or, putting it in a positive light, organizations will embrace UX at a strategic level when they recognize their success is due in part to UX strategy and execution.

“Luck is what happens when preparation meets opportunity.” Although we’d like to think our successes are the result of hard work and skill, the truth might be more difficult to accept. Much of our success (and failure) depends on good fortune. But as Seneca suggested a couple of thousand years ago, we improve our chances by working hard. We need to be ready, in the right place and the right time, when fortune strikes. In this installment, I revisit and dig deeper into a couple of points I raised in Part 2. I close the strategic discussion of UX architecture by offering a few ways in which we can work a little harder and prepare a little more carefully so we’re ready when luck hits.

User Experience is Irrelevant

For many organizations, design remains a superficial activity; it isn’t viewed as a competitive advantage. In most enterprises, design is traded off against features, functions and cost.

Until recently, most people in product development believed user experience is a time consuming process adding cost and complexity to a project. Apple’s iPhone put a stop to that thinking, causing a mad rush by all sorts of enterprises to imitate, emulate or somehow reproduce what Apple had done. Because of success stories like the iPhone, managers have come to believe user experience design (or “design” generically) adds value to a product’s allure. In a few cases, organizations have leveraged design to add true strategic value, not just superficial seduction.

But for most, design remains a superficial activity; it isn’t viewed as a competitive advantage. In most enterprises, design is traded off against features, functions and cost. This is one of the key hurdles we’ll need to overcome for UX architecture to be a part of strategy. In deciphering the challenge, perhaps we can find a way to overcome it.

Organizations marginalize design using the following logic: “If the product (let’s use the MP3 player, as an example) can’t play (and store) music compliant with an MP3 standard, it doesn’t matter how sexy it looks or how seductive the experience.” That logic is reasonable at face value; an MP3 player experience has to play music in an MP3 standard.  That would argue against design being a strategic component. The argument goes on: “When the technology is no longer the key differentiator, we have to turn to user experience and design.” In other words, if the widget can’t perform its function, it isn’t competitive. Once all competitors offer the same performance, we need to differentiate on styling and user experience. In both instances, design and UX are subordinate to technology and functionality. This argument assumes design and UX are superficial to the product, applied “after” the technology is developed. And that assumes design isn’t an integral part of product definition and delivery.

The history of successful products suggests otherwise: the most successful product may not have the “best” technical solution. A fantastic go-to-market strategy, price-point, sales and distribution channel, and user experience design can all be the deciding factors behind a product’s success (or failure). Consider this paraphrase of the familiar Zen koan: If a product meets the technical standard, but nobody wants to buy it, was it successful? We ignore designing for real people at our peril. And designing for real people (users, customers) means UX and design is an integral part of the product development process.

Organizations that position design outside of the core development process operate on several outdated assumptions:

  • user experience design is somehow applied to a solution rather than being an integral part of the solution
  • product success depends primarily on features and technical specifications
  • the human-technology ecosystem is well understood and doesn’t change much
  • world-class user experiences are created in fundamentally the same ways as engineering- or market-driven products.

These assumptions (along with the perception of added cost) plague many organizations, whether large enterprises or startups. Even in the era of the Lean Startup, I’m surprised by the myopic focus on technical functionality in place of desired outcomes.

A Necessary Response

Graph from Bias & Mayhew, 1994, showing two opposing trends: from left to right a downward curve representing "number of possible design alternatives" and an upward curve "cost of change" - the x-axis is time (phases), the y-axis is alternatives/cost
Design alternatives vs cost over phases of a project. Graph adapted from Bias & Mayhew, 1994

Historically, UX thought leaders responded to these assumptions by focusing on cost-reduction.  Deborah Mayhew‘s pioneering and canonical work demonstrates how usability engineering reduces systemic cost using clear financial models. Applying usability principles and practices early in the development cycle is far cheaper than waiting until late in the game. This is a tried-and-true pattern, used across industries.

Another well-established financial model, life-cycle costing, makes an even more compelling case for bringing UX into the development process: the total cost of ownership by customers far exceeds the cost of development, marketing and upgrades. It’s a compelling argument but difficult to make. Convincing managers that their budgets should incorporate customer costs is a major challenge; budgets and financial models rarely include externalities. To side-step that challenge, practitioners such as David Siegel have proposed usability engineering is a risk reduction strategy, not cost-reduction.

These approaches are important and necessary to raise our work to a strategic level: they speak the language of finance. Necessary, but insufficient. We need the sizzle along with the steak. Architecture mixes in hard financial models with softer, less quantifiable outcomes such as prestige, ego and public good. So too, UX architecture must encompass both the financial and marketing goals of the company…not to mention the technical differentiators. When UX illuminates how the enterprise gains competitive advantage in its market, we move it from a technical execution discipline to a strategic discipline. There is long-standing precedent for this transition. In years past, Roger Martin’s case for Design Thinking and more recently, the Lean Startup’s ethic of action-first, are part of an emerging narrative of design as a strategic element of business.

Perhaps even more important (from the perspective of an organization trying to move up the UX maturity curve) is the cost of changing an enterprise’s operations. A spreadsheet showing reduced costs of development through rational application of UX must also model the cost of standing up the new process. These things don’t happen without investment, expense and failures along the way.

UX architecture must be viewed through these multiple lenses: financial, marketing and technical as well as operational.

Nothing succeeds like success

Nothing convinces a skeptic more than a successful outcome. Enterprises have been operating without UX architecture and strategy for most of their existence. Why should they suddenly need it now? That pesky iPhone again. Everyone seems to have gotten on the bandwagon, not just consumer toys and technology. Even dusty old industrial tools and IT operations dashboards are suddenly expected to be sexy. And of course, there’s been a tsunami of failures, mainly because crafting world-class experiences is hard. But also because enterprises thought they could sprinkle UX design like fairy dust rather than integrate it structurally into the way products are built.

Sure, nothing convinces better than a successful outcome, but that assumes we have the opportunity to shine. In a classic chicken/egg paradox, until we have access and opportunity, we can’t prove our worth, but we won’t get access until we’ve proved our worth. One thing we can count on: luck happens, and the harder we prepare and work, the luckier we get. Put another way, if we aren’t prepared when the opportunity arises, we will miss our lucky chance. And in most organizations we won’t be given a second chance.  So let’s pretend we’ll be given the opportunity, and let’s prepare for it.

How can UX architecture rapidly influence strategic planning in important and profitable ways? How can UX architecture point the organization toward higher profit, customer satisfaction and growth? Can we assist the business in getting to key metrics earlier and with greater confidence?

Agile, Strategy and User Experience

Most teams have applied (or at least explored) agile methods such as Rapid Application Development (RAD)Extreme Programming (XP), Rapid, Iterative, Testing and Evaluation (RITE) or Scrum to accelerate software development while simultaneously improving quality. And with Lean Startup and Lean UX, we’ve learned how to apply these same approaches to the design of products and business in general. Recently, the agile mindset has entered the board rooms. In her argument for a new way of doing strategy, Ruth McGrath describes an agile-like approach to business strategy: Transient Advantage. The eight parts of her Transient Advantage playbook sound a lot like the Agile Manifesto:

  1. Think about arenas, not industries.
  2. Set broad themes, and then let people experiment.
  3. Adopt metrics that support entrepreneurial growth.
  4. Focus on experiences and solutions to problems.
  5. Build strong relationships and networks.
  6. Avoid brutal restructuring; learn healthy disengagement.
  7. Get systematic about early-stage innovation.
  8. Experiment, iterate, learn

 

A graph showing time on the x-axis and returns (on investment) on the y-axis. The figure shows a trapezoid, its rising diagonal edge moving from launch through ramp-up, leveling horizontally through Exploit, then ramping down again through reconfigure and ending at disengage.
The Transient Advantage Wave. Graph adapted from McGrath, 2013, HBR

 

The key point here is that enterprises of all sizes and types (for-profit and non-profit alike, private or public) face shorter deadlines. The days of taking months to do strategic planning are long gone. Multi-year strategies can’t survive in the face of product cycles lasting weeks instead of months, quarters or years.

Strategists and leadership need a means of rapidly crafting, evaluating and revising strategies. While most strategists would claim their efforts are based on data and research, if they’re honest, they’ll admit they rely on intuition and gut feel, based on many years’ experience in their fields. But with external factors changing so quickly, those intuitions may lead them astray. They need a tool to rapidly sanity-check their most recent strategy or a freshly minted one.  They need to validate their proposed strategies against real-world conditions. To truly know whether a strategy will work, they need to spend time in the field, talking to the constituents most impacted by the strategy, observing “conditions on the ground” and immersed in the real world problems those constituents are trying to solve.

Rapid strategy development a la Transient Advantage requires both an agile mindset and a user-centric approach. Only by rapidly iterating on potential strategies, and using industry standard methods of constituent engagement, can strategists increase their confidence that the strategy they’re proposing will likely succeed. Similarly, UX architecture must be viewed as a series of experiments designed to “fail intelligently” to maximize learning and organizational evolution.

Artifacts from the future

One such agile technique is to present the proposed strategy to constituents, not as a part of slide deck, or in the spirit of selling it, but as an “artifact from the future,” or for those already familiar, Presumptive Design (PrD). It’s simple to describe, and it’s simple to execute but achieving the desired end result requires finesse.

  • Craft an artifact that represents the strategy. The artifact in this case is not a strategy statement or slide deck. It is literally some kind of object (a paper prototype, a found object…a physical artifact) that embodies the assumptions of the strategy. For example, if the strategy is to move into an adjacent market by expanding on an existing product or service, the artifact may be the actual product, or a journey map of the service.
  • Get the artifact into the hands of a few constituents most likely to be impacted by the strategy. Literally get it into their hands. Using the above adjacent market example, get a current product, as it is, into the hands of the users from the new market segment. In these engagements, the key is not to describe or sell the artifact, but merely to ask the constituent to work with it: use it, interpret it, describe how it will affect their work, their lives or their interactions with the organization. And you only need to work with a handful of people.

Read more about PrD to understand the subtlety and challenges of this approach; In brief, it’s fast, it’s effective and it’s really cheap. Conversations bear fruit at the strategic level even when the artifact is barely recognizable as a potential solution. PrD has shed light on strategic opportunities no one in the enterprise had taken seriously (or even considered). Imagine strategists taking only a couple of days to illuminate key opportunities they hadn’t suspected were in the realm of possibilities.

Reducing Risk, Increasing Opportunity

Who in their right mind would rely on a handful of data points from a biased selection of users to craft a business strategy? That’s exactly the point Roger Martin discusses at length in Design for Business; specifically he addresses “intuitive” or “design” thinking, vs. analytical thinking. Most organizations don’t rely on qualitative research in the strategy process at all, which according to Martin is a bad thing. That is, they miss the big picture opportunities because they’re frightened of relying on “unreliable” data. McGrath, Martin and lots of others, including me, suggest strategy outcomes are weakened by a lack of design thinking, or more specifically generative research. But how much investment in generative research is required to improve the chances of a strategy’s success (or reduce the risk of its failure)?

The left hand side of the UK Design Council's double-diamond diagram is shaded with two text callouts: "Identifying possible problems" and "Deciding on the problem"

The formula I use is the same whether we’re working at the strategic or execution level: between 5 and 10% of the projected cost of the effort should be invested in design and design research. On the development side of the equation, if the enterprise is projecting a five year budget of about $5 million, it should allocate about $250,000 over that same period for discovery, definition and design activities. On the strategic side of the equation, if the enterprise expects to spend $100,000 on research, consultants and the like, it should allocate about $10,000 for user-centered design research. In either context, the 5-10% represents money to be spent identifying the right questions to be asked or the right problems to be addressing.

Preparing for Success

We think (overly optimistically) that just doing good solid work should be enough; it should sell itself. But that doesn’t matter if we don’t also do the “meta-work:” we need to prepare the environment so that it understands what good solid work looks like. If you’re doing exemplary work (as defined by an industry standard), but your leadership has no means of evaluating that work (because the organization hasn’t adopted that industry standard), your work won’t be recognized. That’s a waste of everyone’s time and energy and it just sucks.

What I’ve argued in this lengthy installment is that our job as UX architects includes preparing the organization for a different way of innovating, whether that’s building products or delivering services. UX architecture uses the same user-centered processes found on the execution side of the Double Diamond Diagram, but it uses them on the problem-space side (the left-hand diamond), in service of strategy. This requires a change in culture and changing the culture in an organization is hard work. It takes patience, discipline and time.

But if we’ve put in the effort, then we’ll reap the rewards: all it takes is a little bit of luck.

This installment ends the overview of UX architecture and its strategic value to the enterprise. In the next installments I describe UX architecture’s deliverables, principles and key components.

Have you considered testing your strategy?

Phase II's leading-edge process, Presumptive Design, quickly tests strategies.

Get in touch to learn more.

Thoughts?