June 4, 2009

Architecture and User Experience (Part 8: A Form of Software Architecture?)

I’ve spent several months making wild claims about the importance and strategic value of User Experience Architecture, especially for businesses seeking opportunities in new ecologies of use. But how do we communicate these architectures? What are the deliverables we provide to our stakeholders, clients and users that describe the parts and pieces of a User Experience Architecture?

In the last article I revealed how our internal stakeholders, often not trained in the art of design, will likely find our design-focused deliverables incomprehensible and unactionable. For User Experience Architecture to fulfill its promise, it must communicate the vision of the new ecology of use in ways stakeholders will understand. As with many compelling and persuasive proposals, the results of research may best be leveraged when they are transparent: integrating our research into the vision may be more persuasive than breaking it out as a separate deliverable.

I was talking with Brian Jamison, Founder / CEO of OpenSourcery a Portland-based custom software development shop the other day about User Experience Architecture when I had a flash. Software Architecture is a relatively easy concept to describe (even if designing a Software Architecture is anything but easy). Can we take a page from Software Architecture’s book and use it as a means of describing UX Architecture?

From Wikipedia:

The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships between them. The term also refers to documentation of a system’s software architecture. Documenting software architecture facilitates communication between stakeholders, documents early decisions about high-level design, and allows reuse of design components and patterns between projects.

That’s good. It has a lot of great terms like “system”, and “structure” and “components.” It talks to ideas of “high-level design” and documentation and especially the last sentence allowing “reuse” and “patterns.”

In the context of software engineering (or any system engineering domain, really), these are the underlying meanings of architecture: a kind of high level blueprint of system components that reveal design intent; a kind of “master plan” allowing individual developers to have a sense of what to do with their specific local piece of code.

In the world of bricks-and-mortar Architecture, this would be roughly equivalent to the master plan for a large campus or urban area.

For software engineering, the deliverables that describe the architecture are varied and are based on the notion of “views.” Indeed, the Wikipedia article suggests views “are analogous to the different types of blueprints made in building architecture.”  These include Functional/logic view, Code/module view, Development/structural view, Concurrency/process/thread view, Physical/deployment view, User action/feedback view, and Data view.  In fact none of these views look remotely like the things building architects produce, unless you are willing to stretch your definitions. I suppose we could imagine “Functional/Logic View” to mean “bubble diagram” (the arrangement of spaces in accordance to desired use), and “Development/Structural View” to mean “Structural Engineering Documents” (in which the structural members of the building are called out with associated structural equations), but beyond that there is virtually no relationship to building architecture deliverables.

What would the analogous components be in a UX Architecture? As I chatted with Brian, I thought about some of these architectural “views.” Any discussion of Software Architecture rapidly focuses on meta-constructs: frameworks, models and other means of framing the architecture rather than a direct description of the architectural components themselves.

For example, the figure describes the Reference Model of Open Distributed Processing (RM-ODP). It is a “view model” providing five different viewpoints into the system and its environment. (I think it’s a little ironic the center image is of high-rises, apparently meant to represent the architecture itself):

A better visualization of the deliverables of Software Architecture might be the diagrams used to describe each of those views. In this case a “collage” of UML diagrams:

UML Diagrams 

This is more like it! Lots of imagery and schematics and blueprint-like artifacts!

What would the equivalent diagrams be for a UX Architecture?

Here’s where things get a little foggy. In the most recent article, I suggested design depends on user-centered research. In spite of businesses hoping to “hire away” the problem (by hiring seasoned professionals who already are familiar with the problem space), the realities are each problem space may have curious and idiosyncratic opportunities leading to highly innovative and profitable solutions. If we don’t engage in direct research we run the risk of solving the wrong problem.  What is the equivalent to this research process in the domain of Software Architecture? I don’t know the answer, but I suspect there is no clean analog and I suspect here is where we diverge from our engineering cohort.

The flash of insight from my conversation with Brian centered around the notion of “patterns.” In my mind’s eye I saw how Software Architecture establishes various views into the system, decomposing the components from a high level down through software patterns ultimately leading to specific classes and interfaces. This description suggests the process of defining a Software Architecture is straightforward and mechanical. In practice the process takes multiple iterations, many false starts and a lot of imagination, qualities the process shares with User Experience Architecture. But beyond these general attributes (part of any large-scale definition effort), the two have very little in common.

For example, to the best of my knowledge there are no analogs to the notion of “patterns,” “classes,” or even “interfaces” in the context of User Experience. If the very definition of Software Architecture incorporates these concepts, and they don’t exist in User Experience Architecture, the two can’t be comparable. 

It appears to me then, using Software Architecture as the analogy to building a User Experience Architecture is fatally flawed, most likely because the two start from completely different assumptions: Software Architecture is fundamentally an engineering problem; User Experience Architecture is fundamentally a design problem.

In the next article, I will make another attempt at defining User Experience Architecture deliverables by starting with bricks-and-mortar architecture.


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!