Finally, after almost a dozen articles, I’m prepared to discuss a framework for a UX architecture, what I’ve called the PQRS Model, or Puzzle-piece Framework.
To review, I’ve been mining Architecture (as in bricks-and-mortar) in the hopes of discovering ways to discuss UX architecture. Architecture has historically been strategic, no doubt because of its expense, but also because it encompasses so many life-safety and fundamental human needs. Until UX architecture crosses a similar threshold in its enterprises, it will remain a tactical player. That day is coming, for the same reasons Architecture crossed the threshold: enterprises can’t accept the costs of failure in bringing new products to market. Also, digital experiences are becoming ingrained in every day products, requiring a more comprehensive approach to their definition, design and delivery.
To self-consciously discuss an architecture, we have to go up one more meta-level: to the model.
Architecture fails me in providing a clear model or framework. The profession has been around for over 150 years; the discipline for many thousands. Over the course of its development, Architecture has spawned hundreds of different frameworks and models. Ask 10 Architects for a good definition of their profession and you’ll get 11 answers. As the “Mother of All Arts,” Architecture encompasses the entirety of human experience: hard science, humanities, social sciences, daily acts of living, the simple need for clean air, water and a place to sit. One thing almost any Architect would agree on: Architecture is necessarily complex and complicated, even if a specific building appears quite straightforward and simple.
In the previous article in this series, I turned my attention to other types of architecture, notably Software and Information architectures. I had hoped to use models from those disciplines to help discuss UX architecture. There too, I came up short, except for the idea of a “view model,” an artifact created for SW architecture. In essence, a view model specifies a set of “views” into an architecture to tease apart the different functions of the architecture.
But why so much focus on modeling at all? Why can’t we just describe the documents or “views” themselves and call it good? How do we benefit from having a model?
In brief, models let us talk about a class of things without getting into details about any one instance of a thing. This is important for a lot of reasons, but primarily to keep us focused on the high level patterns, relationships, commonalities and attributes of the class without taking the effort to describe all of the details for any given instance. SW developers recognize this benefit in creating object libraries. The more we can describe at the class level, the less we’ll have to worry about at the instance level.
The other important reason we use models is to help us understand whether any given instance is a good “fit.” When we discuss the appropriateness of a design, we have to do it in the context of its architecture. Without knowing the architecture in which a design was intended, we’re left with “best practices,” or opinion or taste. Taste and opinion are not easily measured, but more important, our opinions are immaterial if the design fails to achieve its primary (and secondary) metrics. Design decisions are made in much larger contexts, contexts in which the enterprise employs hard metrics. Unless taste is a key metric for our design, we don’t need to spend time discussing it.
For us to evaluate a design, we must agree on the evaluation metrics. Once we start discussing the metrics, we’re no longer discussing a design and instead are working at the architectural level. And to self-consciously discuss an architecture, we have to go up one more meta-level: to the model.
Phew. So, that’s why we need a model. So we can discuss architecture without getting into the messy details of any given architecture. We need an architecture so we can evaluate the fitness of a design for the contexts in which it was intended.
And, in case you’re still not convinced, I refer you back to Morville and Callendar’s Treasure Map of User Experience Deliverables. Once we start talking about UX architecture solely in terms of possible deliverables, we lose sight of the forest for the trees. Since that article was written, the Lean UX movement has declared deliverables to be problematic altogether.
But eliminating deliverables doesn’t eliminate an architecture! As the IEEE standard suggests, all systems have an architecture.
The question before us is, are we better off self-consciously designing our UX architecture or will we be okay letting it emerge organically? In more innocent and simple times, perhaps we could afford to let architectures and systems emerge (that’s debatable, but I can imagine it). Today, we need to craft architectures as robustly and as quickly as we can. We need to trade off resiliency with flexibility, performance and security. Too little consideration about the architecture and the design won’t withstand the environment we’re targeting; too much and we risk delaying execution, missing our window of opportunity.
The model I’ve sketched for a UX architecture is simple, straightforward and flexible enough to accommodate any targeted system. I use it with stakeholders (referenced in the corners) to have conversations about what kinds of deliverables they might expect or need, what parts of the process they are most likely to be involved in, and how the parts all work together to support the center experience.
There are six parts to the model: Principles, Qualities, References, Standards (hence “PQRS”), Stakeholders and The Experience itself.
Principles distinguish a design from an architecture. There are hundreds of design principles in the world. Designers regularly apply them without thinking about them. Mies van der Rohe’s famous “Less is More” principle speaks to design minimalism; using as few components as possible to deliver the design. This is a common principle in engineering; in fact it is the key driving principle for engineering: doing as much as possible with as few resources as possible.
Other famous principles include “Form Follows Function,” coined by Louis Sullivan at the turn of the 20th century. He referenced the natural world as a prime example of how structures evolve based on their function, their form derived from their purpose. These are two “modernist” architectural design principles.
From Lidwell, Holden and Butler’s excellent collection of “Universal Principles of Design,” consider a couple of others:
Or we could turn to Gestalt theory and use principles of “similarity,” “symmetry,” and “proximity.”
UX architects must choose a set of principles that make sense for their architecture. It isn’t entirely a free choice: users’ needs and expectations for their experience help architects choose one principle over another. During research, the architect keeps an ear open for those comments, choices or usages that suggest a desire for one kind of principle vs. another.
With that said, Principles is the most subjective piece of the PQRS model. Because there are so many principles to choose from, an architect will ultimately rely on her aesthetics, experience and training. Architecture (and design) is equal parts art, science and engineering, so the artist gets to play a part here. Choose your architect carefully, because they bring a point of view to the table.
The architect can only include a handful (at most two handfuls) of principles for the architecture. This is a second constraint (and opportunity) in considering Principles. Architectures with too few principles will feel restricted and diagrammatic; too many and they become difficult to rationalize or interpret. Creating an architecture is a design problem after all; one of the key variables is the set of Principles.
That is not to suggest that designers must abide by all of the Principles in the architecture, or that they aren’t permitted to use other principles in their designs. It’s just that the design will ultimately be judged by its fit to the architecture. If the designer applied the principles appropriately and applied appropriate principles, the design will fit best.
UX is responsible for users’ emotional response to the experience. For many enterprises, this statement is difficult to accept. Over the years, I’ve heard several challenges to the idea:
Engineering-driven enterprises often raise concerns, but financially-driven organizations are no strangers to these questions. Only marketing-driven organizations have fewer issues with the idea of designing for emotion.
The fact is, that’s what designers and Architects do. Their concepts and offerings are not just an arrangement of parts and pieces; they are imbued with emotional triggers…on purpose.
Enterprises that don’t resolve these concerns about emotional triggers get into trouble, architecturally. Experiences have emotional implications; the question is whether those implications are being consciously designed or left to chance. What are the desired emotional aspects of the experience? How do we answer that question to everyone’s satisfaction?
That last question turns out to be a lot easier to answer: direct research will tell us what users want, emotionally, from their experience. It’s part of understanding Personas; it’s a normal part of any in situ observation. When we see people reacting strongly (either positively or negatively) to an aspect of their lives, we can follow up to ask more in depth questions about that reaction. But more important, we have primary data to help our stakeholders understand what the users’ expectations are, emotionally.
Users’ desired feelings about the experience constitute one input into the Qualities puzzle piece. The enterprise’s brand constitutes a second input. In fact, many enterprises have invested far more money in (and attention to) their brand than they have invested in user emotions. Here again is where UX architecture influences broader strategic considerations (as discussed over and over again in prior postings in this series).
When user emotions are mixed into traditional brand research, the outcome is far richer than if either is pursued alone. But historically, user emotions have not been a part of a strategic brand effort (as opposed to customer or buyer’s emotions – very different folks). UX research, performed at the project level, may discover emotional needs in conflict with, or missing from, the brand promise.
The UX architecture makes user emotional needs a part of Qualities, capturing these intangible (and rich) drivers of the experience.
Qualities come in all shapes and sizes. Here are few common ones:
When we are commissioned to design for an industrial tool, “frustrating” wouldn’t be a desired quality. But if we’re building a game, “frustrating” (up to a point) is absolutely required.
Qualities don’t stand alone; they integrate into the Principles and contribute to the other puzzle pieces. An architect considers Principles in the context of the desired Qualities, and to some extent the reverse is true. After all, the same research drove both decisions. As the Puzzle Piece model suggests, all pieces connect to all others even if the two dimensional rendering of it doesn’t do it justice.
Enterprises face a tough question (whether they know it or not): “How do we conduct UX research?”
Except within the Academy, research is always “applied,” meaning enterprises conduct research to achieve actionable objectives. Non-academic enterprises can’t afford to “advance the human condition through increasing our understanding of the world.” Even businesses that believe in applied research view it as an expense to be controlled. This isn’t limited to UX research. I’ve heard complaints from market researchers that sound very similar to those from my UX compatriots. We are often asked to justify our research costs against downstream profits (or at least revenue). That’s an impossible request, by definition. (How can we predict the outcome of our research? Aren’t we exploring unknown territory?)
The approach I use minimizes the need to justify research expenses. I’ve tried to position research within the overarching product strategy effort, attaching it as a part of the UX footprint. It’s the cost of doing UX business. It’s not a “nice to have,” or “if we have budget.” It’s, “we must do research as a part of our practice.” (The implication is that UX as a whole receives a budget for a project, not UX research gets a budget and UX design gets a separate budget.) When budgets get cut, UX does less: less research and less design.
The model puts most of the research deliverables in the References puzzle piece. Some research deliverables are part of Principles and Qualities. References is one of the largest sections of the architecture. The References piece contains all of the artifacts and deliverables forming the basis for any design. These often include deliverables not associated with design at all. Consider again the results of research that change an enterprise’s strategy, or indicate it’s not worth pursuing a new product or service. Including these within the UX architecture assures that future teams will not pursue unwanted or unprofitable design efforts.
and much much more. All of the work involved in Goal Directed Design, Contextual Inquiry, ethnographic interviews, usability studies, and competitive analyses fall under this piece.
The References piece contains all of the models and data about the users and their desired experiences.
The Standards puzzle piece contains design deliverables. These can include:
and so on.
As with the deliverables in the other pieces, these deliverables are truly at the architectural level, meaning, every design would take advantage of them. However, unlike the other pieces, we would expect designers to create specific deliverables for their designs in addition to the elements in this piece.
For example, the Standards piece would provide a Visual Style Guide and Widget Library used by all designs. When a new design effort is started, the designer would use these elements as starting points for design reference. However, she may have to create specific deliverables such as wireframes, a site map or a sub-navigation schema to express the design.
When I first proposed this framework 10 years ago, I didn’t include Stakeholders in the model at all. Over that decade, I’ve come to learn how much an architecture both depends on and accounts for the work of UX stakeholders. As I’ve written in prior installments in this series, there are far more stakeholders affected by a UX architecture than just the UX team members. To increase the likelihood of its success, a UX architecture must account for stakeholders’ needs, perspectives, roles and responsibilities.
Because the model is rendered flat, it appears that each corner of the puzzle is occupied by a different set of stakeholders. While it’s true that some stakeholders care about some deliverables more than others, we shouldn’t limit stakeholders to one area of the model over another.
and on and on.
Naturally each of these will have varying degrees of interest in the various parts of the UX architecture. What’s important here is not just recognizing stakeholders as keenly interested in the UX architecture, but understanding and integrating their contributions to it. This recognition is key in two ways.
This second point doesn’t sound unreasonable…at first.
Then, when we take a deeper look it, it doesn’t sound right at all.
Consider SW architecture or Enterprise architecture as analogies. To what extend do Sales and Marketing folks care about (or even have time to dig into) the complexities of an Enterprise architecture? The notion that Stakeholders should influence a UX architecture only makes sense when the stakeholders actually are capable of engaging in UX architectural discussions.
What the enterprise must avoid at all costs is “design by committee.” A senior designer will always want input, feedback and collaboration with qualified individuals. But that same designer will not wish to engage in a war of “opinions.” When the stakeholder brings data to the conversation that influences the designer to consider a better alternative, everyone wins. But data is the key here.
So, although the list of possible stakeholders is quite long, the list of relevant stakeholders gets pruned pretty quickly when we apply the same rules afforded to the organization’s other architects. Your collaboration is highly prized when you bring data to a problem highly relevant to you.
Depending on where UX architecture is positioned, the number and type of stakeholders change. In any event, these stakeholders are not collaborators in the design of the architecture. They are influencers, counselors and in some cases investors. Ultimately the UX architect is responsible for the outcome of the UX architecture. On the flipside, for the UX architecture to get integrated and accepted across the enterprise, the UX architect must seek out stakeholder input, giving it the respect it deserves.
Which of course, leads us to the center of the model and the focus of all of this effort, The Experience.
Oddly, there’s little to say about The Experience. Within the UX architecture, everything supports The Experience without specifying what the experience actually is. That is, the UX architecture is agnostic to any given experience: it could be a smart-home device, a new phone app, an industrial tool or an urban plan.
The PQRS model provides a compact diagram to discuss the rich and varied deliverables, relationships and activities comprising a UX architecture. Hopefully you will find it valuable in your own work, whether as UX architect, designer, researcher or stakeholder.
So, to what extent does Architecture contribute to my thinking about UX architecture? As I hope you’ve gathered from these posts, quite a bit in some ways, and not so much in others. In terms of strategy, UX architecture aspires to achieve what Architecture has done: become an integral part of the enterprise fabric. In terms of operations and systems thinking, UX architecture is small (relative to Architecture). It’s still a young and emerging discipline in which we have the opportunity to explore a variety of models and arrangements.
But there are far more ways in which UX architecture isn’t Architecture.
Perhaps the most important difference is that Architecture is not an architecture. According to this article, when Brooks et. al first used the term “computer architecture” in 1959 they were referring to Architecture. The system they were designing was bigger and more elaborate than any that had come before. Later in their book Planning a Computer System they continued to refer to Architecture:
Computer architecture, like other architecture, is the art of determining the needs of the user of a structure and then designing to meet those needs as effectively as possible within economic and technological constraints.
We can see the Vitruvian principles here. And how remarkable that the user is very much a part of the definition.
Very quickly, however, later authors shifted the term to really mean system design. Architects don’t talk about their specific buildings in terms of “architectures.” There isn’t a “structural architecture” or an “HVAC architecture.” These are all systems within the building. And they don’t talk about their buildings as “architecture” either. You won’t hear an Architect say, “Why there’s an incredible Architecture,” pointing at a building.
Architecture is a much broader class than UX architecture, and as a result, it doesn’t help our conversation about UX architecture (or Information architecture, for that matter). Perhaps, as the built and digital environments merge, we’ll revise our vocabulary again, calling “architectures” for what they are: systems design. Maybe, when buildings become indistinguishable from the digital experiences that happen within, around and because of them, we can revert to the word Architecture without qualifications.
Let me know your thoughts. I’d love to hear how you’ve explored these same ideas. Maybe we’ll write a book about it. Stranger things have happened.