by David
Comments Off on UX Disciplines and the Creation of Experiences

UX Disciplines and the Creation of Experiences

I have been an information architect for 12 years, and a UX professional for 15+. This graphic is a quick summary of how I view the disciplines involved in the creation of a user experience.

As always, your input and feedback are appreciated, and may just shift my thinking on this subject.

click for a larger view

by David

Strategy, Tactics, and the User Experience

The notion of strategy vs. tactics is a bit messy. Before I dive too deep into the semantics in the form of a full blog post, I wanted to post the results of a little mental exercise. Working with the strictest definitions of strategy and tactics I built out a matrix with the definition of the terms, activities in each category, and the roles or disciplines that fit in them. I am beginning to think that everything I do is about some flavor of tactics. While I haven’t fully formed an opinion, the diagram below represents where my head is at the moment.

Feedback, comments, and dialogue would be most welcome.

click for a larger view

by David
Comments Off on Adobe Proto for iOS – 1st Impressions

Adobe Proto for iOS – 1st Impressions

I have been anxiously awaiting the arrival of Adobe’s iPad wireframing tool. Proto has been out for Android devices for a little while, and is now available for iOS.

Here is a collection of thoughts and impressions…


  • I love the Palm graffiti-esque drawing gestures. The gestures match the intended elements very well – an X for an image block for example.
  • The grid is a nice touch. I like that you can set the number of columns and the width of the gutters.


  • As cool as the grid is, it will not let you set a custom pixel width for the page itself. You are forced to select from a menu of widths: Web Layout (960px), Default Layout (992px), Tablet Layout (768px), Mobile Layout (320px), and Wide Mobile (480px). If I can’t set a custom width, I would have preferred Ethan Marcotte’s set from Responsive Web Design: 1200px wide screen, 1024px iPad wide, 768px iPad portrait, 600px kindle/nook portrait, 480 iPhone landscape, 320px iPhone portrait.
  • Automatically resizing fonts are a bit annoying. Well … really annoying. If I manually set the font size, then resizing the object should not change my settings.
  • Horizontal navigation bars with forced equal spacing for each item does not work if one label is longer than the others. I either need to make the bar too big or have the label truncated in the display.
  • You cannot designate a specific page in the nav bar as the current page.
  • There is no way to align elements relative to each other.
  • To group elements you use the icon on the top tool bar, but to ungroup them you use the local menu for the selected group.
  • Elements cannot be copied from one page to the next unless you duplicate the page.

I had to stop.

Yep. Proto kinda sucks. It does not have enough features to make it anything more than a UI sketch app. If I want to sketch, I will use Paper from 53 or UI Sketcher from Box UK. For higher fidelity wireframes it’s hard to beat OmniGraffle for the iPad or my second favorite Mocking Pad from accidental fish.

Why does Adobe release software that does not have the features and functionality that creative professionals will need to the most rudimentary tasks? They have stiff competition from smaller companies that are doing astounding work.

But truth be told, all of the wireframing tools for iOS are lacking in some areas. At least with OmniGraffle I can move the same file between my iPad and my MacBook when the iPad experience is lacking.

So sorry Adobe Proto … this version of the app gets an F. I just hope you fix it soon, so I won’t feel like I have lost $10 on a needless software purchase.

by David
Comments Off on Grounded Theory: An Introduction for IAs

Grounded Theory: An Introduction for IAs

In most research you start with a hypothesis and construct methods to test its validity.  But the goal of Grounded Theory isn’t validation. The goal is to accurately describe what is going on in a given context based on patterns in data.

Substantive Area of Interest

In the case of Grounded Theory, the context is called a substantive area of interest. Examples of a substantive area of interest include: online learning, a medical practice, watching a sporting event, and the like.

Let’s use “shopping online” as our substantive area of interest.

Collect Data

Data collection can include all manner of quantitative and qualitative data that is relevant to the substantive area, the actors within it, the challenges they face, and the behaviors they deploy to solve them. Data can come from interviews, participant observation, public records, the news media, etc.

Really, there is no limit, as long as it is relevant.

Open Coding

Open coding is the process of applying tags to the data. For example, if the data is in the form of field notes from an interview, the researcher will go through his or her notes line-by-line and write brief tags to identify key concepts. The codes act as identifiers that will facilitate the aggregation of these concepts into themes and sets of relationships. Eventually a theory will begin to emerge.


Writing memos captures this emergent theory. In the context of Grounded Theory, a memo is simply a brief piece of writing focused on some aspect of the codes, themes, and relationships. By sorting and aggregating the memos, the core category of the research will take shape.

For example, the core category in our study focused on online shopping may be “brand alignment” as it becomes clear that shoppers are looking for brands that fit their lifestyle.

Selective Coding

After the core category has been identified, selective coding begins. This means going back through the data to recode it based on the core category. Additional data may need to be gathered as gaps are encountered.

Using our example, we may go back and recode for expressions of brand awareness. We may need to set up a contextual inquiry to gather data on consumers’ relationships to different brands.

Now Read Up on the Subject

Glaser’s approach is to allow the core to emerge from the data. If a researcher studies the subject ahead of time, it may bias the analysis. Only after the theory emerges should the researcher study the existing literature and integrate it into the research.

Write It

After the literature review, all of the memos are sorted and edited in to a cohesive whole, supported by collateral material that supports the theory that emerged from the data.

Judging Grounded Theory

Because it is an inductive methodology, the criteria on which it is judged is not about validity. Glaser and Strauss identified four key concepts used to judge the results of the method:

Fit: How closely does the emergent theory fit with, and model, the behaviors within the core context of the research?

Relevance: Does the study capture and evoke the core concerns and challenges faced by the actors at the core of the research.

Workability: The theory accurately describes how the problems faced by the actors were solved, or could be solved.

Modifiability: The theory is flexible enough to adapt when new data is compared to the data gathered during the study.


Grounded Theory is a solid framework that allows for great flexibility in the collection of data. It harmonizes both qualitative and quantitative data. But the most attractive feature of Grounded Theory is its ability to identify the right channels for further study, and even for true quantitative validation.

Further Reading

The Grounded Theory Institute

Grounded Theory Online

by David

UX, IA, Strategy, and the Business Ecology

There is a growing trend in the UX community to dump the U or the whole UX.

Some see a return to the use of information architecture and information architect as the solution to the confusion and controversy that swirl around UX. I am beginning to agree … to a point.

I see the role of an information architect as being simple – make the complex clear. Yep, that is from Richard Saul Wurman. And while I don’t agree with everything he says, I can’t disagree with his definition of information architecture. Of course a simple sentiment like that needs to be unpacked and applied.

I believe that information architecture is only a viable discipline when applied to products or services where the communication of meaning through a symbolic system (language, iconography, etc.) is critical to a product or service. These products and services also fall under the discipline of interaction design as the operational partner to the information architect’s role focuses more on comprehension and flow than on function and interaction.

Products that are not primarily for the communication of meaning are more the realm of industrial design.

Increasingly products and services combine in both digital and physical forms. These require a mix of disciplines to model, plan, and build.

As for the U – the user … I go back and forth on that one.

In my opinion (my current one anyway) the user is an important aspect of the business ecology. And yes, I like the term “user”. People use our products and services. They are not always customers, they are not always consumers, but more often then not people use the things we make, or the services we provide.

In addition to the notion of use for all manner of products and services, an increasing number of them are dependent on code to function. The close association of “the user” with “software” was, at one time, a barrier for information architects that wanted to work on products or services that had a minor digital component, or none at all. Now the digital and physical world are so intertwingled (to borrow a term from Peter Moreville) that the close association of the user to software is a key advantage for us.

But I am open to alternate views on the U in UX.

But the X is critical. I agree with Peter Merholz when he says “user experience is strategy, not design“. In fact I see user experience strategy as begin a discipline above the creation of individual products or services. It is by its very nature a discipline that should look across all of the products and services offered by a business.

business ecology

click for a larger view


by David

Post IA Summit Thoughts on Experience and Context

After some deep conversations with Matthew Milan, Matt Nish-Lapidus, Andrew Hinton, Andrea Resmini, Karl Fast, and Joe Sokohl (as well as seeing presentations by Peter Moreville, and Peter Merholz), I have a new take on the experience/context dynamic.

First, the simple version …

The basic notion is that an actor (user, customer, consumer, etc.) operates within a context, and interacts with it either directly or mediated through code (since the device and the code are nigh inseparable, I have decided to just stick with code for now).

The interactions, and the effects they have, form the experience. The experience, in turn, affects the context. This system is truly dynamic with each part acting and reacting to all of the other parts.

Now let’s look at the larger version …

The actor is immersed within the context. He or she is constantly observing, orienting, deciding, and then acting (I will post about the OODA loop soon … I promise). Cultural elements (in the anthropological sense) move in and out of the actor’s context. Very few of the actor’s interactions are purely direct or purely mediated by code. In fact cultural elements, code, and the actor share a dance of sorts within the context.

A good example of that dance is found in the nature of place and space as explained in Andrea Resmini’s IAS12 presentation. In brief (and in Andrea’s words) place is where we pause, and space is where we move. Imagine a trip from your home to your favorite restaurant. During your journey you will pass many cues that tell you that you are on course – street signs, landmarks, etc. On another occasion one of those landmarks may be a place where you pause, but on this journey it is just a navigation marker.

The experience of the journey to your favorite restaurant is a series of interactions that move your context from home, to the car, to the journey, to the restaurant, to dinner with friends. All along the way we experience a constant flow of touch point interactions and changes in context.

So why call out code? As I have previously posted, code is becoming ubiquitous. It pervades all of the contexts that we flow through. And finally (and this is the key point) it is the material with which we IAs, IxDs, and UXers build our contribution to the experience and the context.

Later I will write more about the practical implications of this model, but for now I want to stay on the theoretical side in order to refine this a bit more.

by David

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.

by David
1 Comment

Experience + Context

When we talk about the user experience design or architecture, the term “experience” often becomes a source of contention. Some hold that it represents the innermost emotional response to stimuli, some claim it to be simply a means to filter that stimuli. In fact there are many flavors of experience, and many levels of nested meaning. For example, experience can refer to a body of gained knowledge and wisdom, and to the individual events that contributed to it. It is the ambiguous nature of term “experience” that drives much of the debate about “user experience”.

I believe that the narrow-term version of “experience” is most appropriate for use in “user experience design”. Merriam-Webster defines it as “the act or process of directly perceiving events or reality”, as well as, “the fact or state of having been affected by or gained knowledge through direct observation or participation”.

In both flavors of the Merriam-Webster definition we see perception and an event. In the case of user experience design the software is the object of perception, and its use is the event. What is not captured int his discrete definition of experience are all of the elements that surround and situate the experience. In other words – the context.

Sticking with Merriam-Webster, context is defined as “the interrelated conditions in which something exists or occurs”. All experiences occur within a context. They cannot be limited to just one part of the whole contextual setting.

Context is not a static concept. Conditions and setting change over time. Mobile computing increases the chance that the products we create will be used in a wide variety of spaces, and under all manner of conditions. This creates a challenge for us, but it is not one we cannot overcome.

More on that another time. There is still one level of complexity to add to the mix…

Experience also has a broad connotation. Back to Merriam-Webster – experience is also, “the conscious events that make up an individual life”. Each of those events has a set of nested pairings of experiences and contexts. I would argue that we each have a set of broad experience + context pairs that contain small pairs.

In each of our lives we have belonged to a number of cultural contexts. Each one has had a unique set of norms, its own language, and its own rules. We have work, school, family, hobby, and religious contexts each with its own set of conditions and settings. Each represents a different experience that provides “the conscious events that make up an individual life”. Each one of them is composed individual experiences and the contexts in which they occurred.

The as these experience + context pairs are rolled up into broader categories of life experience, the more difficult it become to purposefully craft them. The notion of designing the user experience gives way to an attempt to understand these broad experiences and create frameworks of designed elements to achieve an outcome. In other words, user experience design gives way to user experience architecture.


by David

So what about this “user experience design” thing?

This is my personal take on the subject. I present it as a response to the folks I mention here, but it is also an exploration that started twelve years ago when I first started my work as an information architect. Though what follows may sound very certain and definitive at times, let me assure you that my mind can, and will, change.

In the last few months a few people whose opinions I respect have argued that the notion of “user experience design” is problematic at best and meaningless at worst. Some have argued that it should be referred to simply as “design”.

In his critique of the term “user experience design” Bryan Zmijewski of ZURB wrote, “user experience can’t be designed. You can’t control the emotions, feelings, and experiences of the user”.

Humanity has been crafting experiences to effect emotions from time immemorial. If you have ever laughed or cried while watching a film, then your emotions have been controlled by an experience. So what about software? The work of B.J. Fogg and the Stanford Persuasive Tech Lab have clearly shown that technology can indeed be used to influence emotions, beliefs, and behaviors.

Zimijewski continues, “You can, however, understand them. As product designers, we shouldn’t think that we’re creating experiences. Our goal is to understand how users interact with our products so we can make them better”.

Understanding how a user interacts with a product is an exercise in understanding their experience. Making a product “better” is also an experiential exercise. We cannot objectively separate a design of a product from the experience of its use.

Adam Connor rightly points out that, “An individual’s experience when using a product is affected by just about everything that went into making that product: the decisions on what functionality to include, how they work, how they look, how they’re built. As such, it’s important to recognize that everyone who was involved in the product’s creation had a responsibility to optimize that product for the desired experience.”

In a response to Bryan Zmijewski’s post, Peter Merholz echoes Adam’s sentiment, “When you’re designing for user experience, you’re designing toward a desired outcome, the user’s experience, not a thing. If this is true, then user experience design would be the only form of design not defined by the medium, technology, or artifacts of its design, and that’s weird”.

I agree with Adam and Peter. However I believe that user experience does have a medium – culture and specifically the cultural context of use. Perhaps the real medium is simply context. I understand that this is not exactly a tangible and narrowly definable medium, but I see it as a medium nonetheless.

Andrew Hinton has been thinking and writing about this for some time now. His work in this area is truly excellent. I encourage you to dig into it at his blog, and eventually in his upcoming book on the topic.

For the purposes of this exploration I want to reference his take on context as a medium:

“In essence, we’ve created a new dimension, an information dimension that we walk around in simultaneously with the one where we evolved as a species; and this dimension can significantly change the meaning of our actions and interactions, with the change of a software rule, a link name or a label. There are no longer clear boundaries between “here” and “there” and reality is increasingly getting bent into disorienting shapes by this pervasive layer of language & soft-machinery.”

In their book Code/Space, Rob Kitchin and Martin Dodge argue that 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”.

In other words – software has become the context in which our culture operates. I believe that the study of anthropology holds the keys understanding the phenomenon that Andrew Hinton and Kitchin & Doge have described.

Anthropology has few sub-disciplines. The three most widely known are cultural anthropology, physical anthropology, and archaeology. Cultural anthropology seeks to understand culture through the study of behavioral patterns. Physical anthropology looks at human evolution, diversity, primate physiology, and population genetics as a means to understand culture. Archaeology studies our impact on, and the shaping of our physical habitat.

Among the lesser known sub-disciplines within anthropology is one which I believe has the most in common with user experience design – linguistic anthropology.

The Society for Linguistic Anthropology defines it as:

“… the comparative study of the ways in which language shapes social life. It explores the many ways in which practices of language use shape patterns of communication, formulate categories of social identity and group membership, organize large-scale cultural beliefs and ideologies, and, in conjunction with other semiotic practices, equip people with common cultural representations of their natural and social worlds.”

In this new cultural context with its information dimension, and with the emergence of code/space we now have new “patterns of communication” that are forming completely new ways to shape “social identity and group membership” that are creating a new set “common cultural representations” for our  “natural and social worlds”. And this change is being facilitated and crafted by us – the people that architect and build software.

In his 1976 work Beyond Culture, anthropologist Edward T. Hall observed that humanity’s evolutionary path is altered and accelerated by our own creations. He proposed the notion of extension transference as a way to explain this process.

He observed that human culture creates sub-systems that extend the original system, but also change the way we develop and progress. Spoken language was extended to a written form and suddenly writing and speaking became two parts of the same system and changed the way we communicate, preserve, and perpetuate our culture.

Human language was extended again when we began to create instruction sets for the machines we created (also an extension of tools we created). In 1801 Joseph Marie Jacquard used punch cards to instruct looms to weave cloth in specific patterns. In 1837 Charles Babbage and Ada Lovelace developed code for the Analytical Engine which would allow machines to perform complex calculations. Finally in 1943 the ENIAC coding system became the first modern programming language.

Each of these was an attempt to extend human language to communication with inanimate objects. They, in turn, would communicate back to us.  In this way programmed machines would become a vehicle for extension transference as they extended the capabilities of previously labor intensive systems that facilitated human activity.

For much of its existence the computer was seen as a means to receive answers to complex computational processes. Persistent memory, storage media, and increasingly better interface technology made personal computing a powerful tool. But it wasn’t until the advent of the Internet, the World Wide Web, and emergence of mobile computing that technology truly began to change our culture in a fundamental way.

Software is no longer simply a tool to help an individual with a complex task. Software is not just connecting people. As Andrew points out, our lives are immersed in the new dimension of information. As a result of this immersion we find ourselves in a time of great cultural change.

The software we create is fueling this change – this new extension transference – and I do not think we truly realize the impact our work has on the world in which we live, and on the lives of every person on this planet.

It is no wonder that our heads spin when we grapple with the very notion of user experience design.

Bryan Zimijewski expresses just how overwhelming it can be to try and address this new reality, “to truly be a UX Designer you have to be an expert in so many fields. That’s because the buzzword of User Experience Design covers too many fields: anthropology, psychology, graphic design, user research, communication design, usability and much much more. How can any one person really be an expert in all that?”

The notion that a single person can shape every aspect of a user’s experience with a product is clearly flawed.

The growing field of service design is an attempt to see the user experience in this broader context. But even in a broad-stroked holistic view of an experience (echoing Adam Connor and Peter Merholz) each component part still needs to be created with the user in mind. That creation process needs individuals who will shape each part to fit the whole. And the whole experience needs to be crafted to fit the context and needs of the user.

I believe that is the role for user experience practitioners, but I don not believe our discipline has matured to the point where that role is clearly understood, or well defined. As Bryan Zmijewski points out, to design a user experience requires an approach and a set of methods drawn from many disciplines.

To make this a reality we must not retreat from what seems an impossibly complex undertaking, as Bryan seems to suggest. Instead, we need to embrace that complexity to drive the evolution of our discipline.

I believe part of the problem is the notion that the experience is in fact designed. I firmly believe that the creation of a user experience is not an exercise in design. Instead, I see it as experience architecture.

I use the term architecture for two reasons. First, it reflects the nature of this new digital reality that behaves like a space – a space built on the semantics and syntax of code as well as language.  The presentation by Jorge Arango, Andrew Hinton, and Andrea Resmi from the IA Summit in 2011 covers that topic quite well, so I will refrain from digging into that here.

The second reason comes from a 2008 blog post by Seth Godin that captures the crux of the semantic tangle between design and architecture:

“I think architecting something is different from designing it. I hope you can forgive me but I think it’s a more precise way to express this idea.

Design carries a lot of baggage related to aesthetics. We say something is well-designed if it looks good. There are great designs that don’t look good, certainly, but it’s really easy to get caught up in a bauhaus, white space, font-driven, Ideo-envy way of thinking about design.

So I reserve ‘architect’ to describe the intentional arrangement of design elements to get a certain result.”

So just what the heck is experience architecture?  Currently user experience design has four key sub-disciplines: information architecture, interaction design, visual design, and content strategy.

Each of them focuses on a key aspect of software design. Information architecture is mainly concerned with structure and wayfinding with an eye towards communicating meaning and aiding comprehension. Interaction design focuses on the operational elements of software by shaping processes and the controls that form the heart of the user interface. Visual designers apply all of the rules of their craft to design both an esthetic experience, but also one that communicates the brand, and allows the user to quickly find the right navigational options, or the right controls to manipulate the software.  The creation, deliver, and management of content is the domain of the content strategist.

Collaboration between those four disciplines allows users to build the right connection with a product, understand it, operate it, and find the information they need, or achieve the task they set out to accomplish. But to Adam Connor’s point, that alone does not create an experience for the user, just a part of it.

This is where the experience architect comes in. I see the role of the experience architect as the one that takes the holistic view of the software experience, and how it fits with the brand, the business, the context of the user, the broader cultural context. In Seth Godin’s terminology, user experience architects do not design the elements of the experience; they create the intentional arrangement of design elements to get a certain result.

To do this, they must work with people throughout an enterprise – product teams, developers, technologists, marketing, operations, finance, and the executive team, in order to understand how the product fits within the full business context.  In addition the experience architect must conduct user research to fully understand the context of the users – their needs and goals.  Finally, they must also understand the competitive landscape.

With this knowledge in hand the experience architect can arrange the elements and situate the product in the proper context. It is then up to the IAs, interaction designers, visual designers, and content strategists to turn the vision in to a real product that can then be properly positioned within the holistic user experience.

Some of us have been doing this for years, and we have done it under different titles and job descriptions. Ours is such a young discipline that it has yet to define itself, its skill sets and methods, and even the roles of its practitioners. And to be clear, what I have articulated here is just my take on the subject. And I am sure that my view on this subject will change over time, and with your help.

I hope that through conversation with the fine folks in the UX community I can learn more, hear their critique, and reshape this vision of what we do. It is my firm belief that two brains are better than one, and the more brains we can get thinking about this the sooner we can push the boundaries and shape our craft.