July 9, 2009

Architecture and User Experience (Part 9: The Puzzle Piece Meta-model)

In the previous article, I had hoped to define User Experience Architecture in terms of Software Architecture. The idea was our engineering teams might be able to better understand us if our deliverables were defined in terms they recognize.

I’ve concluded the approach is fatally flawed for several reasons:

  • Software Architecture is an engineering discipline;User Experience Architecture is a design discipline
  • Software Architecture deliverables (UML diagrams and the like) have no analog in the User Experience domain
  • User Experience Architecture begins with fundamental research into a target user population; Software Architecture has no equivalent dependency
  • Software Architecture’s notions of interfaces, classes and patterns have weak or no equivalents in User Experience Architecture

Perhaps a better starting point is from the field of bricks-and-mortar Architecture.

In Architecture, practitioners are expected to develop several deliverables prior to creating a design:

  • Urban context study
  • Project pro-forma
  • Transportation study
  • Relevant code analysis
  • Site study
  • Program analysis
  • Life-cycle cost analysis
  • Affinity Matrix
  • Space / FAR analysis
  • Bubble diagram

All of these methods of mapping the contexts of the proposed building (environmental, legal, operational and behavioral) require time spent researching. They involve multiple visits to the proposed site, meetings with city officials, research into buildings of a similar “type,” discussions with engineering specialists and possibly meeting with neighbors and future occupants.

Are there equivalent deliverables in UX Architecture?

“Deep dives” into a target user community to witness work and play in situ such as I discussed in a previous article are similar to the Architecture research phase described above. A non-exhaustive list of deliverables resulting from a modest qualitative research project could include:

  • Persona definitions
  • Work flow modeling
  • Artifact analysis
  • Social network analysis
  • Affinity diagrams
  • Power / Status relationships diagrams
  • Collaboration dependencies
  • Scenarios
  • Quality attribute identification
  • Use Patterns
  • Relevant Design Principles

This list and the one for Architecture pre-design efforts both describe externalities to a design.

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


User Experience Architecture is more than a summary of the research results, just as bricks-and-mortar Architecture is more than sum of its pre-design research. Although pre-design research is not the architecture, it is one of the key deliverables on which stakeholders base their “go/no-go” decision.  Interestingly, stakeholders in the bricks-and-mortar domain do understand the relevance of the pre-design data. Not so for the UX Architecture stakeholders. No matter how obvious these data might be to fellow designers, they fail to communicate a compelling vision to business stakeholders who hold the purse strings and development stakeholders responsible for building the experience. One of the biggest challenges facing UX Architecture is how to deliver research results in ways stakeholders can understand and use.

Communicating a Vision to Business Stakeholders

Continuing the comparison to Architecture reveals other interesting distinctions. Many Architectural firms specialize in the pre-design services and deliverables I listed above. Often an owner will contract for these services to create a pro-forma business case for getting a loan or for identifying the ROI among other reasons.  While a pretty picture of a proposed building might help make the pre-design information concrete, in many cases this level of visualization is unnecessary: the numbers, constraints and recommendations based on the pre-design research are sufficient to identify whether the project is feasible: that it makes sense from a business perspective.

For several years, Usability Engineering has provided similar “pre-design” research services expecting business leaders to make similar pro-forma decisions on the feasibility of a project. Oddly, few businesses I’ve been a part of have been able to visualize the business potential based solely on user research results. Even a “pretty picture” won’t tip the scales in favor of moving forward with a proposed experience. Why can the bricks-and-mortar business managers see the potential where their software business equivalents can’t? 

Perhaps Architecture has succeeded because:

  • Architecture (and its myriad examples of specific buildings) has been around for thousands of years (so owners have inherent understanding of what a building is)
  • Building owners are better versed in the language of architecture than their software business counterparts
  • Architects provide business-relevant data in their pre-design deliverables, including: risk assessments, financial impacts, budgets, construction approaches consistent with a budget.

    Or, perhaps UX Architecture has yet to succeed because:

    • No amount of research will compensate for UX Architecture’s lack of standing in the business models of most companies
    • Business owners have few examples of excellent UX Architectures to learn from
    • User research data as provided by the User Experience discipline has been insufficient or inappropriate for business leaders’ needs.

    Communicating a Vision to Engineering Stakeholders

    On the engineering side of the equation, communicating a vision based solely on our research is equally problematic. Can Architecture provide an analogous model?

    If we imagine software engineering teams are similar to the systems engineering teams in a large scale architectural project (structural, HVAC, soils, electrical engineers, and so on), we can evaluate the relevance of the pre-design documents to the relative disciplines. Architectural engineering teams are very familiar with pre-design research deliverables. These supporting consultants take advantage of the data to help determine their initial scope of effort, risks, systems choices and more. Many times they will participate in the research activities as well since their expertise is often required. How many software engineers participate in UX pre-design research activities?

    But maybe software engineering teams are not like the supporting engineering teams in Architecture. Perhaps we should consider software engineering teams as the contractor in an architectural project (responsible for implementing the building). Here again the two disciplines have very different relationships to the pre-design research.  Where bricks-and-mortar contractors can quickly see how a particular site, building type, and other pre-design information will impact the cost and complexity of a project, software teams cannot envision the end-game based only on the user research results. In some building contracts, the contractor is hired to assist the Architect in doing the pre-design research. Again, how many software engineers participate at this stage of design?

    Regardless, merely providing the results of our research without providing concrete examples of how that research points to the future is an insufficient set of deliverables to communicate a vision; research results alone do not constitute a User Experience Architecture.

    Why User Experience Architecture isn’t Software Architecture

    If I haven’t hammered the point home enough, here’s a final nail in the coffin regarding Software Architecture as a model for User Experience Architecture. How many business stakeholders care about Software Architecture? How many business stakeholders use Software Architecture diagrams to support their business objectives? To what extent do Software Architects provide their analysis and design to individuals outside the discipline? To what extent does Software Architecture make or break a business model? Do Software and User Experience Architectures share a similar relationship to the business?

    Put in this context, the only thing these two disciplines share is the title.

    I am not suggesting the two disciplines aren’t intertwined. It is obvious to us (in the UX Architecture domain) Software Architecture is a subset of the user experience. Just as the engineering deliverables on bricks-and-mortar projects are folded into the overall architectural statement of the building, so too, engineering deliverables must be folded into the overall architectural statement of a company’s offerings.

    Similarly, as Architects have learned to communicate key information to building owners, so too UX Architecture is obliged to communicate to business stakeholders in ways they can understand and take action.

    A View Model for User Experience Architecture

    What are the parts and pieces of a User Experience Architecture?

    Recently, Peter Morville posted an article (with Jeffery Callender) attempting to highlight 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. Can we simply provide this inventory of deliverables as the description of a User Experience Architecture?


    The list of deliverables are constituents of a User Experience Architecture, but they do not provide a view model for the architecture. As Morville and Callender suggest at the end of their article, the vast number of deliverables constitute the proverbial trees blocking the forest. They create a “treasure map” as a description of the many different ways designers may reflect the experience, but they don’t provide an integrated model of an “architecture.”

    Just as Software Architecture is viewed through the lens of a Model or Framework, so too I view User Experience Architecture in the context of a meta-model. I propose the “Puzzle Piece” framework:

    In this Architectural model, the user experience is framed by four major categories of activities or deliverables: Design Principles, Quality Attributes, Models/Patterns and Design Language.

    In the next article, I’ll describe these pieces of the puzzle in greater detail. As a test of the framework, I’ll map each puzzle piece to the deliverables commonly provided by user experience designers, including those proposed by the Morville/Callender inventory.


Add a Comment

Please log in to leave comments.

Not a CHIFOO member? Taking part in our online discussions is a benefit of membership.
Join us!