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.
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.