Is the design medium software, context, or experience? Yes.

Imagine you are royalty, and you need to throw a grand ball. What factors need to be considered in order to make it a truly wonderful experience for all that attend? What instructions to we need to pass along to our seneschal in order for the whole event to come together perfectly.

The place needs to be perfect – both the location and the hall. The guest list is critical. It must be the right mix of aristocracy, nobility, and the famous. The hall must be decorated to fit the season. The season will also determine the appropriate fashion on display. The music must be perfect. Space needs to be provided to allow for conversation. What good is a grand ball if it does not generate a buzz.

If all of these factors come together just right, then the guests’ experience should be fantastic.

In this scenario it is very clear that a number of creative professionals are required to design the elements of the experience. It is also fairly clear that all of the elements need to be considered in relation to each other in order to bring them all together for the big day.

If this were a UX-centric project, we would be talking about the Elements of User Experience or a similar categorization (though Jesse James Garrett’s is my favorite). The qualities we would want it to embody would be like these from Peter Moreville. The both describe the digital embodiment of the experience quite well, but it seems to me that there is a missing dimension in both of them – the context.

When we use software, its use is always within a specific context – “the interrelated conditions in which something exists or occurs” according to Webster. The context is made up of other people, places, objects, information, and elements of time. All of these “interrelated conditions” are informed by our cultural forms, rules, norms, and relationships.

Unlike the grand ball, we do not have control over all of the elements of the context. When we shape software, we need to understand what the context could be (or should be). We then set out to create software that will naturally fit the context.

Or is it possible that we have more control than we think? Software is a medium through which users experience, and in some cases control, the contexts in which they live, work, and play. We can shape the experience of using the software, but we can also shape aspects of the context.

The line between code and our physical environments is becoming increasingly blurry. As Rob Kitchin and Martin Dodge point out, software in all of its forms is used to “mediate, supplement, augment, monitor, regulate, facilitate, and ultimately produce collective life” and “shape people’s daily interactions and transactions, and mediate all manner of practices in entertainment, communication, and mobilities”.

So code is having an impact on context. It is like water carving a shore line or a river bank.

But companies are not just shaping code into software for us to use. They are also providing devices, services, and processes that allow us to directly effect places, people, objects, and information. Code has allowed us to change the timing of an experience – people are increasingly shifting the times they watch TV programs, or watching on demand.

When users act and the software reacts, they are generating an experience within a context, and effecting some of the elements of the context itself, thus generating an experience beyond the software.

Unlike royalty, we do not have seneschals to rely on to arrange the perfect context, and thus ensure a fantastic experience when we use software. In my view, that is the role of the user experience architect.

The role of user experience architects is to understand the context, the culture, the user, and the desired outcomes of the software’s use. Then they help to craft and arrange the elements within the context in order to ensure that the users’ experience fit their goal, and the goal of the enterprise for which the software was created.

The medium of user experience architecture is the software, but also the context in which it is used, and the experience of its use.

experice, software, and context

One closing note: You might notice that I did not mention the boxes on the users’ side. For now you should check out Matt Milan’s presentation on The Information Architect and the Fighter Pilot. I’ll give you my take on the OODA loop later.

4 Comments

  1. This may seem bizarre, but my comments are visual.

    Context:
    * http://www.flickr.com/photos/austingovella/6833687092/in/photostream

    Experience:
    * http://www.flickr.com/photos/austingovella/6833687116/in/photostream

    Does that make sense? Haven’t really articulated it in words, yet.

  2. Interface is good, but not specific enough for what we do. A piano keyboard is an interface, but we don’t design pianos. I think what sets us apart is code. Yes, we need an object to interact with the code, but in the end it is the code that is our stock and trade.

    I also agree that there is a broad experience that we build over time, but there is also the focused experience we have as we interact with the context. The post just before this one addresses the odd nature of the term experience.

  3. Ubiquitous work makes relying on “software” problematic since half or more of the work entails hardware as well. You work in software, but others are working in hardware.

  4. True. And I agree that software is not adequate. I like the notion in the book code/space that there are coded objects, coded infrastructures, coded processes, and coded assemblages. All of this code is changing our lives and the spaces we inhabit in fundamental ways. I believe that our role is to shape the coded within the objects, infrastructures, processes, and assemblages. We will always craft the experience of the interaction with the code, but we don’t always need to shape the rest. We certainly need to understand them, because they are part of the context. We should have influence over their design, but they are not our primary concern.

    I firmly believe that what make UX different from industrial design, or product engineering is that our concern is the cognitive and social aspects of the experience, and the code … the software … is the primary facilitator of that experience.

    The software/hardware line is, in some respects, hard to define.

    But to go back to the grand ball example – the music and the dance are linked in a deep and meaningful way, but the composer of the music and the choreographer of the dance are not likely to be the same person.