Architecture and User Experience, Part 9: Communicating with Stakeholders

Throughout this series, I’ve been using Architecture (bricks-and-mortar Architecture, capitalized) as an analogy for UX architecture (lower-case). Because Architecture has “had a seat at the table” for hundreds of years, perhaps we can learn from its success and apply those lessons to UX architecture, thereby increasing UX architecture’s strategic value. In the next installments, I turn to more tactical concerns: the deliverables and processes required to execute on a UX architecture. In this piece, I discuss how different stakeholders require very different deliverables. I also discuss how Architecture and UX architecture differ in terms of stakeholder understanding about the desired outcome.

Awhile ago, when I was Principal Architect, User Experience at Tektronix, I began working closely with a Product Marketing Manager. Soon after I arrived at the company, he took me under his wing, making it a point to introduce me to the key players in the organization. He welcomed me with authenticity and a sincere desire to have me as a partner. He was quite open with me about his ignorance regarding UX architecture. He said:

“I’ve been thinking about our product development process and I’ve realized, quite some time ago, that I needed an architect. Here’s the way I look at it: I’m the homeowner and I know I need a kitchen, a bathroom, a couple of bedrooms, a dining room and so forth. So, I tell my engineering team what I need, and they go and build it. But the problem,” he continued, “is that they want to reduce the cost of building my house, so naturally, they put the bathroom inside the kitchen, because that’s the least expensive thing to build.” He smiled, self-deprecatingly, “I know that’s not right, but I can’t specify a way to prevent that. I’m talking to the drywaller about how to design my house!”

“I get where you’re going,” I responded, “but you’re a little off on the analogy. You’re not the homeowner, the user is the homeowner. You’re the developer, and you’re not worried just about one house, you’re worried about the entire development of houses. Your job is to figure out what types of model homes to build, how many of them and at what price. Your job is to figure out who the homes are supposed to be sold to. You’re right about the engineering teams: they’re job is to craft the least cost, optimal solution.” He was nodding and smiling. “And the user,” I continued, “unfortunately, can’t tell you what they want (except to suggest they might need two bedrooms, a kitchen and a bathroom). They don’t have any better idea than you (or your team) about the best arrangement of rooms to make their living experience as desirable as possible.

“So, yeah,” I agreed, “you need an architect. Someone who can hear what you need from a business perspective, hear what the users need to make their experience desirable, and who can work with the technologists so the thing can be built inside your cost structure.”

Architectural Pre-Design

Architects are expected to understand the contexts of the project prior to creating a design. They review or commission:

• Site studies
• Urban context studies
• Project budgets
• Transportation studies
• Codes
• Program analysis
• Life-cycle cost analysis
• Affinity Matrix
• Space / FAR analysis
• as well as any special studies such as soil, cultural context, historic significance and so forth

Architects spend considerable time researching each of these contexts for the proposed building (environmental, legal, operational and behavioral). They make multiple site visits, identify buildings of a similar “type,” engage engineering specialists and meet with city officials, neighbors and potential occupants.

Are there equivalent deliverables in UX architecture?

UX Architectural Pre-Design

Just as Architecture is more than the sum of its pre-design research, UX architecture is more than a summary of its research results.

A partial list of UX architecture deliverables could include:

• Persona definitions
• Work flow modeling
• Artifact analysis
• Social network analysis
• Physical space analysis
• Affinity diagrams
• Power / Status relationships diagrams
• Collaboration dependencies
• Scenarios
• Journey mapping
• Systems analysis
• Competitive analysis

Each of these activities require substantial amount of research. Just as with a new building, many of these activities are unique to a specific project. Very few can be borrowed from past work. These two architectural domains require pre-design efforts to identify externalities to a design.

Does that mean a User Experience architecture is merely the identification of key externalities resulting from an intensive research
process?

No.

Just as Architecture is more than the sum of its pre-design research, UX architecture is more than a summary of its research results. Pre-design research is not the architecture, but it is the foundation for an architecture. It also contributes to stakeholders’ “go/no-go” decision. Owners, the key stakeholders in Architecture, depend on pre-design research and its results to make informed strategic decisions. This has not been the case for UX architecture. Businesses building products have been very slow to adopt UX as a strategic input into their go/no-go decision.

Perhaps Architecture has succeeded because:

• Owners are familiar with Architecture since it has been around for thousands of years
• Owners recognize the strategic value of Architecture because of its costs
• Architects provide business-relevant data in their pre-design deliverables.

Or, perhaps UX architecture has yet to succeed because:

• UX architecture has only recently emerged; business schools are only now offering design thinking in their curriculum
• Product managers and business strategists have only recently been exposed to UX as a competitive advantage
• UX pre-design research has not been framed in the language of business.

Until UX architecture is integrated into the business as Architecture has, UX architects must do several things simultaneously: craft the architecture, communicate the vision of the architecture and create a sustainable process for delivering architectures.

Exploring where Architecture has been successful with business stakeholders may provide opportunities to improve UX architecture’s strategic position.

Communicating with Business Stakeholders

Many Architectural firms specialize in delivering pre-design services. Owners will include the results of these services in their pro-forma business case. Renderings of the proposed building might decorate the presentation, but they don’t add much value at this early stage in the process. Owners need to see the numbers, constraints and recommendations from the research to identify business and project risks.

In the context of UX, in the past, Usability Engineering (UE) or ethnography consultants delivered pre-design research. UE research focuses on user capabilities and needs; ethnographic research is broader in scope, looking at contexts, relationships and culture, alongside specific user-focused data. Historically, both were written in an academic style. These data were compelling from the user experience perspective, but they rarely made arguments about the business’ needs. As a result, many businesses couldn’t take those data and apply them directly to their strategy.

Both business and UX leaders expressed frustration with the entire process. Business stakeholders complained they would wait months for results that had no concrete, actionable recommendations. UX researchers expressed frustration at the lack of recognition for their discoveries: clear opportunities to address user needs that the business could leverage.

This gap between business expectations and UX research efforts has been well documented and lamented for several years. Pundits have called on the UX community to better understand their audience: deliver results that business leaders can use. That’s all well and good, but (as I’ve written in prior articles in this series) the business has to come at least part way: if you need UX to deliver strategic impact, establish UX research at a strategic (rather than project) level.

UX architecture must take those research efforts and convert them into meaningful, concrete proposals and recommendations that feed into business and product strategies. Naturally UX architects can’t do that unilaterally: they must collaborate with product managers and other strategists for the architecture to make sense. In those organizations that recognize the value of UX, leaders from both sides enjoy collaborative efforts and the results that come from such work.

But that’s only half of the story; UX architecture binds the user experience to the business and to the technology delivering the solution. Once again, historically, pre-design research has not been intuitively obvious to the technical teams, and they have complained about the lack of actionable information in the pre-design deliverables. In communicating with technical teams, maybe Architecture can provide some guidance here as well.

Communicating with Technical Stakeholders

Architects work with technical teams throughout the building’s lifespan, but collaboration is especially important during the pre-design phase of the work. Architects rely on soils engineers to determine structural considerations, water abatement and potential seismic impacts on the design. Structural engineers assist in cost analysis of early-stage concepts. Energy consultants provide input into potential life-cycle costs of conceptual designs. Pre-design research with technical stakeholders improves the accuracy of early-stage budgeting, but equally important, reduces the likelihood of designing something that literally can’t be built at all.

UX architects recognize the need for early-stage collaboration with technical leads such as enterprise architects, software leads, DBAs and the like. For enterprises that are not familiar with UX, however, collaboration among these disciplines is not baked into new product development processes. In such organizations (and they are the norm, still as of 2017), UX architects must take the lead in setting up the meetings, establishing a collaborative working relationship and ultimately institutionalizing the process.

But even when the organization is open to the idea of collaboration (and again, this can be hit-or-miss or highly dependent on the individuals within the enterprise), the technical teams likely don’t have much experience with UX. This makes them very different from their Architectural counterparts. In the Architectural world, structural engineers, soils engineers, HVAC consultants, etc., all understand a common language of building. The Architect is ultimately responsible for speaking the language of the specific consultant (e.g., if the discussion is about a structural system, the Architect will not spend a lot of time addressing the cultural heritage of the design). Still, the consultant has experience with the multiplicity of Architectural concerns.

So, the analogy breaks down in two ways:

1. Collaboration between UX architects and technical teams in early pre-design research isn’t baked into the product development process and
2. In the rare cases where collaboration occurs, technical teams aren’t necessarily trained in the art of UX

But maybe technical engineering teams are not like the supporting engineering teams in Architecture. Perhaps a better analogy is that engineering teams are like contractors, responsible for executing on the building design. Here again, the analogy breaks down. Architectural contractors can quickly comprehend the pre-design information (such as site, building type, codes and zoning) and how those will impact the cost of construction. In some cases, contractors are part of the pre-design research team to reduce the risks of poorly conceived execution.

Not so for most technical teams in the UX architecture context. Most cannot envision the costs or impacts on the desired outcome simply by reading Personas, work models and other pre-design information. Merely providing the results of UX research without making that research concrete is insufficient for most organizations. And most glaring, how many enterprises expect the technical team to participate in pre-design research?

As a result, the onus is on the UX architect to deliver meaningful and actionable deliverables to the technical team that bridge the needs of the users with the technical details for instantiating the UX.

A Model for UX Architecture

Architecture is so massive, so invasive and so old, that practitioners and theorists have never agreed on a standardized model.

What are the parts and pieces of a User Experience architecture? How do they fit together into a comprehensible whole?

A little while ago, Peter Morville and Jeffery Callender posted an article highlighting a list of User Experience Deliverables. The list is wonderful, including many of the items I describe above, along with several design deliverables distinct from research and analysis deliverables.

Perhaps these deliverables are the UX architecture. Maybe we just need to provide stakeholders with the deliverables on this list, and they’ll be able to take the actions they need to do their part of the job.

Unfortunately, that’s not the case.

For many of the same reasons I discuss above, stakeholders aren’t prepared to take the UX pre-design deliverables and make sense of them. Further, the pre-design deliverables don’t hang together as a coherent whole: they are constituents of an architecture, but they aren’t enough to be the architecture. Finally, they are only the pre-design deliverables—many more elements, beyond the pre-design research, comprise an architecture.

As Morville and Callender suggest at the end of their article, the vast number of deliverables constitute the proverbial trees blocking the forest. The UX deliverables are often for UX practitioners to help themselves understand the problem and illustrate the design. But as I’ve discussed at length, here and in prior articles, UX architecture must speak to the other stakeholders in the organization for it to be effective, strategic and usable.

Morville and Callendar recognize the need for a model of a UX architecture, but they don’t go so far as to offer up one. Instead, they suggest a “treasure map” metaphor to help guide UX practitioners through the forest of deliverables.

So, we need a model—an organizing framework to situate stakeholders and the UX team within the UX architecture. The model also lets us talk about the UX architecture as a thing without having to immediately offer its parts and pieces. A UX architectural model can be situated within other components of the product development process and strategy. Leadership can look at how the model interfaces with other disciplines to inform decisions outside of the UX discipline.

Throughout this series, I’ve looked to Architecture to inform UX architecture, so it would be great to find an Architectural analog for a model that we could re-purpose. Here Architecture fails us. Architecture is so massive, so invasive and so old, that practitioners and theorists have never agreed on a standardized model. Perhaps we can appropriate models from other architectures (lower-case), such as Software architecture or Enterprise architecture.

In the next article, I’ll propose a model for UX architecture, taking a page from other disciplines to inform its construction.