In this installment I propose a need for, and an example of, a model for UX architecture. Models allow us to discuss a system without specifying particularities about the system. This is important if we want to understand how the system can be put to good (or better) use. Models also allow us to look at the relationships among various systems, again to improve their operational efficiency, or to determine allocation of resources.
Throughout this series, I’ve looked to Architecture to inform UX architecture. Architecture’s political and strategic positioning, its established processes and shared understanding among professionals provide a rich history to mine. Further, the Architect’s position as a “point person” on projects, assisting the Owner in navigating difficult and risky projects, makes that role invaluable in the bricks-and-mortar context. Architecture is so well established that businesses don’t question the need for an Architect (even if they don’t completely take advantage of the many ways an Architect can serve them). Architects don’t need to sell Architecture. As a result, Architects are free to use whatever models and approaches they would like. UX architecture doesn’t share this privilege: UX architecture is an emerging discipline that must work hard to insert itself into business and new product development processes.
A Standardized Model for Architecture
Architecture can’t help UX architecture in providing a standardized model for the discipline. It’s not that Architecture doesn’t have a standardized model, it’s that it has hundreds of different models, many of which don’t map well to UX architecture. On the other hand, there are long-standing Architectural models that have become part of the UX architecture literature. The “BTU” diagram (Business, Technology and User), introduced in the prior article and well known throughout the user-centered design community, hearkens back 2000 years to the Roman engineer/architect, Vitruvius. Vitruvius, author of the earliest surviving discussion of architectural theory and practice (see: The 10 Books on Architecture), suggested three core Architectural principles : Utilitas – Utility (or Commodity), Firmitas – Firmness (or Soundness), and Venustas – Beauty (or Delight) that map directly to the three circle Venn diagram.
As helpful as the BTU model is, it is too abstract for our stakeholders in the enterprise: they can’t immediately see what actions to take, or determine the cost/benefit of alternative courses of actions. This model is excellent at establishing the relationship among key players (business/marketing, technology/engineering, users/design), and for that reason, I continue to use it as an introduction to the concept of UX architecture.
Until UX architecture is as ingrained in our business culture as Architecture has become, we will need to turn to other sources for models. Software architecture is one possibility, as it has been around for at least 50 years.
Software architecture refers to its deliverables as “views,” such as: Functional/Logic view, Code/Module view, Development/Structural view and so forth. These are different facets of the software system but they aren’t the model we seek. For that we look to SW architecture’s notion of “view model” —an arrangement of views into the architecture. (How ironic is it that the center of this diagram—”system and environment”—is rendered as a set of buildings?)
But let me step back a moment and offer a couple of definitions of software architecture. Here’s one from Wikipedia:
Software architecture refers to the fundamental structures of a software system, the discipline of creating such structures, and the documentation of these structures.
ANSI-IEEE 42010 offers a detailed definition, excerpted here by Daniel Dvorak:
Architecture is the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.
Both of these definitions refer to systems and their description. But I’m particularly drawn to the second definition’s inclusion of the words principles governing its design. As I’ve written previously, Architecture isn’t design on steroids. It’s fundamentally a meta-design activity: it is the design for a systematic approach to design; not just one design, but handfuls of designs.
The IEEE 42010 standard provides this UML diagram of an Architectural Description (now bear with me, but the AD is a meta-meta-thing – it describes the system by which we can describe an architecture…phew!).
Okay, so that’s a little geeky, but just look at the words in the boxes to get a sense of what an architecture must address: “system of interest,” “stakeholder,” “concern,” “Architecture Viewpoint.” An architecture must contend with externalities for it to be considered an architecture.
Maybe Software Architecture Isn’t the Best Source
After digging into the world of Software architecture to see if there were good models to use, I came away feeling less than satisfied. I like that an architecture serves stakeholders and must address their concerns. I like that an architecture must have a point of view. And I really liked the notion of a “view model.” I liked the idea of a model that provides faceted “views” into the experience. But I couldn’t find any imagery that captured these visually as opposed to logically (as the UML diagram above does).
If Software architecture isn’t a good place to mine models, perhaps Information Architecture can help. A quick google image search turned up lots of flow charts and UML diagrams (similar to the one above), pyramidical hierarchy diagrams and a twist on the three-circle Venn diagram, with the circles being labeled: User, Content and Context.
None of those were very satisfying. Personally, I still appreciate Jesse James Garrett’s “pancake diagram” as a reasonable model for Information Architecture.
This is a pretty good model. It shows Strategy at the base, including User needs. As it proceeds vertically, each plane becomes more and more concrete: Scope must fall within Strategy, Structure within Scope, and so forth. In this version of the diagram, product design is placed side-by-side with information design. It’s not bad. We can imagine overlaying roles and responsibilities (product manager, e.g), operational units (marketing, e.g.) and other externalities onto the model to help situate it in the broader contexts of product, service or business.
But Maybe IA Can’t Help Either
As much as I like this diagram, it still doesn’t quite turn the corner of a view model for me. For one, Information Architecture is buried inside the framework. The view model should be about the architecture. And secondly, it doesn’t meet the IEEE description of an architecture: it lacks a place for a point-of-view. This is a key part of any architecture. It must account for different possible points of view, even if a specific architecture only abides by one point of view. I call that missing piece “principles.”
So, having failed to find an image from other disciplines, what else is there but to make something up, right? I offer the following as my sketch of a UX architecture. I call it the Puzzle Piece framework, or, to remember it easily, the “PQRS” model.
In the next installment, I’ll delve into each piece in detail. Here I’ll provide an overview of the model itself.
The Puzzle Piece Framework
It’s obviously a jigsaw puzzle, each piece locked into the others and surrounding the experience, which is, as it should be, at the center of the architecture. All pieces should be touching all other pieces, but that would require a 4th dimensional tesseract, and we humans don’t do well with those. So, imagine that all pieces influence all others.
The filled in pieces are the UX-focused elements: the design philosophy, the quality attributes, research results and models, and the design specifications and deliverables. In the corners are the folks we work with outside of the UX discipline: product marketing, program management, finance, engineering and strategists. Oh, and the business leaders.
This framework describes an architecture rather than a design, in that it prescribes what needs to be in any given design, without providing any details or specifics. This model applies to an architecture for the intelligent drinking glass just as much as it applies to a transactional website. The model is as concerned about the relationships among the stakeholders (both internal and external to UX) as it is about deliverables within each piece.
From the previous installment, I mentioned Peter Morville and Jeffery Callender’s list of UX deliverables they published a few years back. This model collects those deliverables, not as a treasure hunt through the forest (as Peter and Jeffery offered) but as an organizing schema. We can now group UX deliverables based on their purpose, their “point of view,” and their relationship with one or more stakeholders.