The IA Summit (and information architecture) enters adolescence

The first IA Summit was held April 8-9, 2000, in Boston, MA, and was titled Defining Information Architecture. Now, fast forward to this year’s 13^th IA Summit held April 3-7 in Baltimore, MD, in which the Summit entered the awkward teen years against the slogan “Observe Build Share Repeat.”

Taking the slogan to heart, a number of Summit workshops, sessions, keynotes, and discussions focused on reframing information architecture as a practice and as a field. Granted, IA is closer to 40 in chronological age (many date back to Richard Saul Wurman’s 1976 declaration “I am an Information Architect,” though personally I subscribe to Andrea Resmini’s Brief History timeline), but it is also experiencing adolescence thanks to a rapidly transforming digital landscape that makes puberty seem pretty innocuous. Consider, for example, the proliferation of:

• Big data and open machine readable datasets (e.g. DATA.gov, and AWS Public Data Sets)
• Content syndication, especially approaches like COPE (Create Once Publish Everywhere)
  • Plus increased use (and occasionally understanding) of taxonomies and metadata
• Free and open-source:
  • Blogging and content management systems like WordPress
  • Content management frameworks like Drupal
  • Design tools like Twitter Bootstrap and hosting services like GitHub
• HTML 5 and CSS3 with their improved capabilities especially around design and media
• Mobile devices and technologies
• Responsive web design in its various approaches and permutations

Like a teen whose body is changing faster than it realizes, so too is information architecture stretching and growing and developing. But information architects (at least most of them) have gone through puberty and should be able to adapt their practice and usher their field through this tectonic change.

Remaking information architecture

Coming of age is always difficult. It requires patience and introspection. It is uncomfortable, unpleasant, awkward, and is in many ways unending. But, it offers a unique opportunity to remake and improve information architecture in the face of change and to prepare for the next tools, technologies, and even modalities altering both the digital and physical landscapes.

This means making hard choices and invariably suffering missteps and setbacks. But when the IA community comes through it, it’ll be older and wiser with a better understanding and control of its body (the practice and field of information architecture). Then IA can start realizing the unmet potential of its youth. So what is the path ahead?

Define information architecture not as a concept, but as a practice and a field

For me, the highlight of the 2013 IA Summit occurred before the opening keynote. It was the pre-conference workshop, Academics and Practitioners Round Table: Reframing Information Architecture, moderated by current Information Architecture Institute president Andrea Resmini. The all-day session consisted of 30+ information architects working to identify the requirements that would lay the foundation for a common language, grammar, and poetics for IA.

While the proceedings of the workshop will be published in the Journal of Information Architecture, the real work will begin when the larger community comes together to define and formalize itself. This necessarily includes:

• Defining what is and is not information architecture
• Identifying and documenting the major IA schools of thought
• Mapping out and understanding how IA relates to sibling (such as usability, information design), parent (such as architecture, library science) and extended-family (such as psychology, linguistics) fields
• Agreeing on a basic timeline for information architecture’s intellectual history, including formative events that pre-date the emergence of the field as well as key technological and cultural events that shaped it
• Codifying information architecture best practices and developing standards around key artifacts
• Formalizing the requisite background, training, skills, and certifications for practitioners and then defining the various roles within IA, noting which overlap with other fields and how

Here it should be noted that individual IA practitioners, organizations, and programs have made strides in addressing the above. But until there is a confluence from across the information architecture community, these will be little more than outposts in the wild and may even promote schisms within the community.

Accepting some basic truths about the practice of information architecture

The larger discussion around remaking information architecture also includes coming to consensus around some important concepts that every information architect needs to understand. These are discussed in my April 17, 2013, Aquilent (my employer) blog post 2013 IA Summit Themes but are summarized here:

• You cannot control device usage. Device usage will change and evolve faster than we can keep up, and it is a fool’s errand trying to predict or determine how users access content.
• You cannot control content. Syndication and content reuse ensure that content takes on a life of its own, so it’s essential to understand and leverage taxonomy and metadata.
• You cannot control meaning. It is not inherent or discrete and can’t be turned on and off; information architects can only share meaning and should consider a meaning-first approach.
• To serve the users you must serve the content. Understand and leverage syndication, promote content longevity and usefulness, and consider targeted, accidental, and future audiences.
• Sometimes you’re the architect, but often you’re the builder. We cannot always do dramatic and innovative work, but remember, the best information architecture is invisible.

There are, of course, many other concepts that are essential to the practice and field of information architecture will be identified and defined as its adolescence continues.

The time is now…

With the IA Summit turning 13 and information architecture in a time of adolescent turmoil and transformation, it seems clear that the timing is right to define and formalize both the practice and field of information architecture.

Heading into the 2014 IA Summit, members of the community need to open their minds and roll up their sleeves for the difficult, awkward, and emotional work ahead. And they should do so knowing that once information architecture enters its adulthood, it will open up new world of influence and opportunity.

Put another way – and paraphrasing B&A founder Christina Wodtke – be bold, take risks, and fail spectacularly. Now is the time to clearly define and state the communities’ vision for information architecture then set out to realize it.

Wait, I thought, I have both my iPad and my laptop in my backpack.

I felt ridiculously conspicuous pulling out either just to check Google Maps. Between the two, I chose the iPad. It’s smaller and it has 3G. However, I felt as if all my fellow passengers were reading my giant screen along with me.  There’s a reason, I realized, that I’ve been observing commuters on their phones or slightly larger Kindles, but seldom whipping out their iPads on trains, bus stops, or speed walking through the city.

The iPad hit the market about three years ago, quickly becoming disruptive by creating a user need where there previously was none. 22% of U.S. adults now own a tablet. Given that it looks and acts like a larger smartphone (minus the obvious calling feature) and that there are apps, it’s easy to classify it as a mobile device. And that’s probably true – the iPad is more mobile than, say, your laptop.

However, as an app developer or a brand that wants its presence on the device, the larger question remains. Do you design for users on the go? Or do you focus on a more in-depth user experience? What is your content strategy? After three years of usage, we have data and opinions to support multiple points of view.

Mark Zuckerburg famously stated that the iPad isn’t mobile (Parr, 2010). Jakob Nielson’s report suggests that iPad users don’t use their iPads in truly mobile situations, and those that do take their iPads away from home tend to use them in more relaxed situations (Nielsen, Budiu, 11).

Where does that leave your feature offering and user flow?

I design mobile apps for Cars.com. After several years, countless usability sessions, and app design for three platforms (Android, iPhone, and iPad), our design team came to the realization that we should not necessarily think of it as design for mobile, but as design for tablet, or even more broadly: design for touch.  And when it comes to interaction, this is certainly true. The iPad shares the same interaction model as other touch devices. Our content strategy, however, has had to shift after trial and error.

Our apps are built primarily around the assumption that users are searching for cars. On top of that, since they’re doing so on a mobile device, they’re also interested in contextual tasks, which include finding dealers who stock those cars, contacting those dealers, and test-driving the cars. This basic flow was positively reviewed in the app marketplace for both the iPhone and Android apps. Thus, when the iPad app was developed, we had employed the same content strategy. We also focused a large effort on creating an in-app map feature, assuming users would be using it on the go.

After conducting user testing, I realized the following:

• About 20% of our users have WiFi iPads instead of 3G. This meant that all the contextual features we were considering, such as on-the-dealer-lot and on-the-go usage would be available only to those who either have a 3G iPad or access to a free WiFi.

• iPads were generally a shared device. Spouses and families typically had one per household, and therefore no one person carried it with him or her at all times.

• The largest iPad use case was on the couch, in front of the TV. In this case, iPads replaced laptops for consumption of information, such as browsing the web, or more cognition-heavy tasks such as researching a product. This is different than a laptop, which is still turned to for creating, or a smartphone, which is used for contextual and hyper-local information, such as finding the closest dealership or grocery store. This is also the reason why Josh Clark recommended considering the “belly zone” when designing the navigation for your app and avoiding putting controls on the bottom (Wroblewski, “Design for Mobile: iPad Design Tips”).

Given all the arguments against the iPad being mobile, where does this leave content strategy? All evidence points to the fact that you should design for touch but consider content differently. Think of it as a touch device that is used in one place. As you plan your content strategy for an iPad app, consider the following.

Focus On What You Do Best

It’s tempting to cram in many bells and whistles into this highly visual device. After all, the graphics are at the foreground and Apple’s design guidelines extensively instruct us to let the user interact with the content, not the chrome. The content, however, should be what your brand does best. Focus on your core user path and keep the flow simple and fairly linear, at least in the beginning.

For example, our initial app at Cars.com primarily allowed users to research new cars. We designed for large graphics and minimal content, thinking that we were meeting iPad users’ expectations. Our users, however, expected to find listings of cars, not just research, because that’s what our brand is known for. Their expectations didn’t change simply because they were using an iPad. We re-focused on search, which is what we do best, and our ratings improved greatly.

As you consider content, pare down features that are essential to your brand and develop one solid user flow. Often, your core user flow is an obvious one. We leveraged analytics to understand how consumers used our regular site on their iPads prior to making changes to the actual iPad app. After all, a significant portion of traffic to our site comes from iPad devices. This provided insight on what specific features from the site can be customized in the native app for a better experience.

Consider The Funnel & The Couch User

If you have a cross-channel brand, consider the consumer journey through your brand. For example, for us at Cars.com we’re always thinking about the consumer’s shopping funnel. When people first begin their search for a new car, they may perform high-level searches, research, and comparisons. As they get lower in the funnel and near their car purchase date, users turn to their smartphones for activities such as locating and contacting dealerships.

Since we’ve established that people use their iPads on the couch, we now aim to design primarily for the couch user. Our iPad tasks focus more on the initial search, with research features folded into the main flow, and we spend less time worrying about location-based services. Our secondary and tertiary flows, however, include map features and geo-location because it is still, after all, an iPad.

Sync Across All Channels

50% of U.S adults now own either a tablet or a smartphone, and many own more than one. This has major implications on how and when users consume information across the same brand. For e-commerce, for example, one-quarter of visits to e-commerce sites occur from mobile devices, however all but 15% return back to their laptops to purchase. For us in the automotive industry, 79% of new vehicle buyers use the Internet to research their vehicle purchase. While virtually all of them use a desktop/laptop at some point, nearly 30% use multiple devices.

That means, depending of where they are in the shopping process, users can ostensibly be searching for cars on their laptops at work, checking listings on the iPhone during the commute, and comparing cars in front of the TV on their iPads at night. This doesn’t mean that we should necessarily replicate all tasks and flows equally across all devices. It does, however, mean that the user experience should be seamless.

Figure out what your users are doing on each device and provide syncing capabilities across channels. On Etsy, for example, where 25 percent of the visits but 20 percent of the sales come from mobile devices, the site syncs items in the shopping cart, favorite items, purchasing history, and conversations with sellers.

For Cars.com, this means that when users save their favorite listings or dealers, they are expecting to see the same saved items whether they are on their Android phone, laptop, or iPad. It’s perfectly fine if the iPad is only used on the couch, as long as when the user is ready to head to the dealership with their smartphone in their pocket, the same information they had saved on their iPad the weekend prior is available at their fingertips. If there is any difference in the information they see, it should be contextual to the user’s mobile needs and mental model.

With smartphones, that means taking into account location and urgency. For example, seeing a dealership nearby on a smartphone can include such data points as sales and service hours, and whether they are open now. In another instance, availability of listings can show in order of proximity to the user’s current location.

What About Other Tablets?

The iPad may have started the trend, but other tablets are certainly catching up. Now, just over half of tablet owners report owning an iPad. Nearly half own an Android-based device. The Windows 8 tablet has recently entered the market, and so has the iPad mini. What are the implications of these newcomers?

In addition to whether a device has cellular service, price and physical size ultimately factor into the users’ decision to take a device on the go. From my experience with the Surface Windows 8 tablet, its physical size alone may preclude it from becoming a mobile device as well. In addition, Windows is advertising a physical keyboard attachment. While this may be convenient, the keyboard definitely places the tablet closer to the laptop realm and may not necessarily be very portable. It weighs in at two pounds, according to Microsoft’s website, which is heavier than the iPad. The tablet is also expensive and is only WiFi for now.

The iPad mini, however, is smaller, lighter, and has a cellular data plan option. Like smaller Android tablets, it’s relatively less expensive, which makes users more inclined to bring it along when they’re on the go. This could mean, however, that your apps on these smaller tablets resemble more of the smartphone app experience rather than the larger tablets, at least in terms of the tasks users conduct.

Iterate Often

Whichever features you decide to release, the app marketplace is dynamic and provides a direct pipeline into user feedback by way of ratings and reviews. With the pressure to keep the app fresh in the marketplace, it’s tempting to add more features.

For example, GateGuru from Kayak initially delivered its promise to show airport information and flight status. However, more and more features were added to the point that users are now questioning whether it’s even the same app.

As mentioned above, we experienced something similar with our Cars.com iPad app. The first release of our app did not meet users’ expectations because it didn’t deliver what our brand promises: the ability to locate car listings. The app ratings and reviews certainly reflected that, and we worked quickly to ameliorate our standing with the app marketplace to add listings in the next iteration.

Conclusion

Listen to your users and always check whether the new features are desirable. As you first release an app, start with your core competency and consider the features that are essential to your primary user path. As you iterate and add more features from your business and product road map, take into account what users are saying. You may find yourself adding or sunsetting features based on how and where people are using your app. Mobile or not, the tablet market is here to stay and, directly or indirectly, users will tell us what features to build next.

Suggested Reading

• The Explosion of Mobile Audiences: A growing mobile landscape
• Wroblewski, Luke “Design for Mobile: iPad Design Tips” 2010: Notes from a Josh Clark presentation
• Retailers Try to Adapt to Device-Hopping Shoppers: Google, eBags, eBay, and Mod Cloth struggle with device synching
• Parr, Ben. “Mark Zuckerberg: The iPad Isn’t Mobile” Mashable.com: Next Question
• Nielsen, Jakob and Budiu Raluca. “iPad App and Website Usability” 2011: Results from a study
• 2012 New Autoshopper Study: Tablets and Smartphones Are Used by One in Five Digital Auto Buyers
• Mobile Marketing Trends, Insights and Best Practices: Slides from eMarketer Webinar

Down at the bottom of the screen was a little window where you could type simple English-like commands – things like go to card 2 or beep. Once you’d mastered those, you could add them to your buttons or trigger them at certain times, creating real interactivity. Pretty soon I was making little games and utilities. It was the coolest thing ever.

HyperCard’s Home Stack: Pure Nostalgia

HyperCard came with something called the home stack that opened when you first launched it. I looked at it and thought, This isn’t very useful. It shows up all the time but it doesn’t do much. So I made a better one. It included various utilities, and of course a rock-paper-scissors game. I made packaging and convinced the local Mac store to sell it for $7.

It sold two copies.

Since then I’ve worked on products with more than twice as many users, but the story remains the same. This isn’t very useful. This doesn’t serve people’s needs. Let’s make a better one.

In college I discovered a career for what I did: user interface design. And though the title has changed over the years – user experience designer, interaction designer, product manager, product designer, founder – the motivation hasn’t. Technology is confusing and doesn’t meet people’s needs. I want to fix that.

Eat Your Vegetables

These days, it’s fashionable to talk about audacious ideas. Paradoxically, it’s also popular to focus on ideas that can be built in a month.

In a post last year, Paul Graham listed Frighteningly Ambitious Startup Ideas and spawned a bumper crop of companies (though my favorites, Bring Back Moore’s Law and The Next Steve Jobs, don’t seem to have much traction). Wired’s cover story for February was 7 Massive Ideas That Can Change the World.

But I can’t help thinking we’ve skipped our vegetables and gone straight to dessert. We are insinuating ourselves into more and more of people’s lives, yet we haven’t managed to meet their needs in predictable, understandable, let alone enjoyable ways.

I watch people using their devices and I cringe. They get their single-click and double-click mixed up. They open an email attachment, update it, and then can’t understand why their changes aren’t in Documents. They try to set up iCloud and end up creating three Apple IDs. They miss out on all the useful things technology can do for them, lost in a sea of complexity, confusion, and techie-centric functionality. These things were supposed to be labor-saving devices, right?

Make no mistake: This is our fault. To begin with, we’ve created ever-more-inconsistent expectations over time. Consider single- vs. double-click. Easy, right? You single-click to select, double-click to open. Unless it’s a webpage. Or Apple’s column view, where selecting and opening are the same thing so it doesn’t matter. Well, for folders; for documents, it matters.

Anyway, it’s really easy to tell if you’re in a webpage or not so you know which convention to use. Just look at the top of the screen, on the left. It should say Firefox, or Safari, or Chrome. Oh wait, you’re on Windows. Look at the top of the window. No, the frontmost window. See, it has a bigger shadow than the others. Oh wait, you’re on Windows 8? Well, are you in Metro or not? Oh wait, they don’t call it Metro anymore. I forget what they call it. Do you see a lot of colorful flat boxes? What were you trying to do again? Hey, where are you going?

You may think I’m overcomplicating things for effect. I’m not. It seems simple to you because all that stuff is already in your head. When you switch from GMail in a browser, to Outlook on Windows, to Mail.app on Mac, you know which conventions change. You have what designers call a mental model, rooted in years of experience and history, that allows you to make the right call. Most people don’t – nor should we have to.

And these interaction details are the tip of the iceberg. We do a disappointing job of understanding what people outside our bubble are trying to accomplish. Let’s be honest: We mostly make products for ourselves. Later, when they’re successful, we start wondering how people use them. We do user studies and surveys and ethnographies and then ignore the results because it’d be expensive to fix and besides, they’ll figure it out, right? I mean, we did. We lack the comprehensive understanding we’d need to make real, substantive change, to make products that are both usable and useful.

Downward Arrow

Therapists sometimes use the downward arrow technique with their clients. It starts with the apparent problem and proceeds through a series of “why” questions to the underlying issue:

Client: “I get nervous speaking in class.”

Therapist: “Why do you get so nervous?”

Client: “I’m worried that I might say something stupid.”

Therapist: “And if you did?”

Client: “I would be so embarrassed!”

Therapist: “Why? What would be so bad about it?”

Client: “It would mean I’m not good enough.”

And so forth.

Product design requires a similar process: start with a design or feature question and dig down until you find the assumptions that underlie it:

Me: Why do you ask for a user’s password every time he downloads a free app?

Imaginary Apple Guy: For security.

Me: What do you mean by security?

IAG: Well, if someone gets hold of your phone, they’d be able to install apps without your permission.

Me: And what would be so bad about that?

IAG: The apps could do malicious things with your phone.

Me: But doesn’t Apple sandbox apps and review them for malicious behavior?

IAG: Sure, but a maliciously-installed app could connect to your Facebook account.

Me: And is the risk of that happening when your phone is stolen worth requiring a password for every install?

Note that the point isn’t to make me look smart, or simply to reveal flaws. By the end of that (fictitious) exchange, we’ve gone from an ill-defined concept (“security”) to a specific question that deals in user needs.

The Product Mantra

To answer such questions we need the fundamental, defining goals of our product. Who is it for? What purpose does it serve? It’s impossible to evaluate trade-offs otherwise.

When I was at AOL our illustrious head of Consumer Experience, Matte Scheinker, introduced the notion of a product mantra: a clear, concise description of your product. Critically, it must be specific enough to disagree with.

Using my own to-do app, Stky, as an example:

• 

  Stky

  Mantra A: Stky is a to-do app for naturally disorganized people. It keeps overload in check by having you reprioritize each day’s tasks anew.

• Mantra B: Stky is a productivity app anyone can use. Unlike its competitors it keeps you in control of your tasks and on top of your life.

Both mantras are accurate. But only Mantra A is specific enough to disagree with. Do disorganized people need a to-do app? Is daily reprioritization too much work, especially for such people?

Mantra B could describe nearly anything.

Now, suppose I’m deciding whether to add a new feature to Stky: multiple sticky notes. You could have your Work sticky, your Home sticky, maybe a Stuff to Read sticky, and the like. Seems useful, and certainly I’ve had users request it. Let’s hold it up to our mantras:

• Using Mantra A: Do we want to add additional management overhead to an app for disorganized people? Probably not. And if the sticky represents our daily list of priorities, doesn’t adding multiple stickies break the whole paradigm? Probably. So maybe it’s not a good idea.
• Using Mantra B: Well, multiple stickies means more control, right? And lots of people want it, and we want a product anyone will use. So I guess it’s a good idea…along with nearly any other idea.

Even better, this exercise almost forces us back into downward arrow. Why do users want multiple stickies? What are they trying to accomplish? Is that deeper goal consistent with our mantra? If so, is there another feature that would meet their need in a way that fits the product better?

Asking why and writing a mantra won’t magically give us insight into our users. But it will force us to form hypotheses, which can be tested against evidence in the world around us.

And the constraints we create via those hypotheses allow us to make choices. Because the great products, the ones we revere, are invariably the work of product teams brave enough to make choices. We marvel at Apple’s clean, usable design. We call it simplicity but it’s not that: It’s knowing what to keep and what to leave out and having the guts to disappoint some of the users all of the time and all of the stakeholders some of the time. Many of us already know that, but we can’t bring ourselves to choose when push comes to shove.

None of this is a substitute for user research. We still need usability tests, ethnographies, brainstorming sessions, click data, bucket tests, discovery, and all the rest. But in the absence of clear hypotheses and specific questions, user research is a little like the proverbial tree falling in the forest. Research tests our assumptions and tells us where we’re right or wrong; it doesn’t tell us what to build.

This isn’t the kind of audacious problem we solve all at once…nor do we have to. Every product that actually makes someone’s life better is a piece of the solution – not just for the life it improves, but for the designer who’s inspired by it, the team that decides to one-up it.

Make no mistake: This is hard stuff. It requires tenacity, and bravery, and empathy. It requires observing how people live their lives, and then handing them products that aren’t at all what they asked for. It needs more user-centered ways of doing bug triage and structuring development workflow. But as technology becomes everyone’s ever-more-constant companion I can think of no greater or more worthy challenge.

When I renamed my blog last year, I created a tagline: “We make stuff, for people.” It was meant to be funny, sure, but also to encapsulate everything I’ve said here. Technology is meaningless without people; yet, as technologists, we’re prone to forgetting that. We end up debating strange, empty questions. Does the world really need another photo sharing service? Is skeumorphic design good or bad? Is Ruby better than Python? None of it matters on its own.

It’s important to make stuff. But it only matters if we make stuff, for people.

This elevated focus on UX ideas and concepts will require informed engagement with several high-level topics that emerged in 2012. This article discusses five of the themes that we expect will have relevance into 2013.

1. UX in the C-Suite

2012 was the year that UX Design crashed the C-Suite. The appointment of Marissa Mayer as Yahoo’s CEO, and the emphasis on her background in user experience as a prime reason for this appointment, is one of several examples of increased awareness, at the highest levels of corporate management, of the importance of user experience to the success of a company’s products or services. These developments suggest a growing understanding that UX is not merely a tactical part of a product development process mainly driven by inward-facing operational strategies or broad, quantitative market analysis. Increasingly, successful companies maintain a sharp focus on the experience, broadly construed, of their end consumer from the earliest formation of product strategies through their design, development, and launch.

Another indication that language and ideas around user experience are gaining traction is the surprising appearance of skeumorphism (basically an interface that mimics a similarly functioning analog item) in the mainstream media. The New York Times discussed the concept in the context of a management shake-up at Apple that may herald a departure from the “real world” design style preferred by Steve Jobs (but apparently disliked by many design authorities inside and outside of Apple) towards a minimalist aesthetic that is consistent with Apple’s hardware design. Whatever software design direction Apple ultimately selects, the popular discussion of the business impact of this decision is likely to inspire other corporate leaders to ask themselves how an improved user experience could help them achieve their business goals.

2. Multi-Context UX Goes Mainstream

Lines that could once be neatly drawn between mobile and desktop experiences continued to blur in 2012. With more and more people accessing content from multitude of devices — often at the same time — people have come to expect a seamless and consistent experience from site to site and from device to device. A variety of techniques, technologies, and philosophies are at the UX designer’s disposal at a time that some consider the “post-desktop era”.

With mobile browsing continuing to grow in the United States and worldwide, it makes sense for designers to focus on getting the mobile experience right. “Mobile first” encourages designers to start with a small screen, focusing on key interactions and content prioritization. “Mobile first” may not always be the right approach, but by starting on a small screen, solutions to complex design problems can often be revealed.

“Progressive enhancement” is not a new idea, but has gained momentum lately thanks to responsive design, HTML 5, and CSS3. Progressive enhancement starts with a useful experience as a foundation, adding more complex functionality only if the browser or device can support it. Similar to “mobile first”, progressive enhancement ensures that the base experience is solid before adding in additional bells and whistles.

It’s been two years since Ethan Marcotte coined the term “responsive design”, and in that time we’ve seen more websites that adapt to a user’s screen size, orientation, and device. We’ve seen some excellent designs, including Smashing Magazine, and the newly launched Mashable. Responsive design does not always make sense, and a responsive website cannot necessarily replace a native application. As responsive design matures, we will see more innovative techniques and best practices.

It is still difficult to predict a person’s context. We may know what kind of device or screen size they are using, but we won’t know where they are. We should be prepared for them to switch back and forth between devices frequently, and know that they expect seamless transitions and a consistent experience across all channels. And people don’t distinguish between disciplines – the difference between UX designer and visual designer may be important to us in the industry, but in the end we are all contributing to the user experience.

3. Increasing Importance of UX in Product and Service Development

The growing importance of user experience design was evident in industries like health care. We believe that this area will continue to boom in 2013 and beyond.

More practitioners and UX-focused agencies are starting to specialize in healthcare research and design. Companies in the health vertical are increasingly seeking out specialized UX help. Rising stars like Patients Like Me, Massive Health and ZocDoc are revolutionizing myriad aspects of the health care experience. Each of these organizations is strongly rooted in UX culture. ZocDoc even won an Interaction Award for 2013. Conferences like Healthcare Experience Design continue to flourish and books are beginning to appear. Look for Peter Jones’ Design for Care which should appear sometime in 2013.

4. Agile UX Design and the Lean Startup Movement

The evolving relationship between UX design and the Agile and the Lean Startup movements was another important trend in 2012. UX practitioners continued to grapple with their role in Agile development processes.

Early this year, Jared Spool wrote:

“Agile development is no longer a fad–it’s the way people are getting software delivered… Our old methods no longer suffice, as they are too bulky and slow for the demands of the Agile process. Instead we need to come at our work with a renewed introspection of everything we do.”

UX practitioners have heeded the call: the NYC Agile Experience Design meetup group has more than 1,500 members with nearly half to them joining in 2012. San Francisco’s Lean UX group has about 1,600 members.

A related movement, which is similarly UX friendly, is the Lean Startup “school” that recommends a “build, measure, learn” feedback loop. The Lean Startup principles boldly declare that a Lean Startup should develop a minimum viable product (MVP) to begin the process of learning as quickly as possible.”

Designing for MVP is a radical departure from the perfectionism we have seen in traditional UX design. Doing UX in Agile fashion means backing off on documentation and traditional processes to become more iterative and nimble. It means having the courage to let something go when the design is “good enough,” knowing it can be adjusted in future iterations.

Many UX designers have seen positive results when integrating UX design into Agile development. The focus on results over processes and documentation is invigorating. Adjustments include: writing user stories; becoming less sentimental about deliverables; attending standups; and participating in testing, implementation, design and strategy at the same time. While the relationship between Agile and UX is uneasy at times, the consensus in 2012 was that the combination is a win for users and product development organizations.

5. Visualizing Data, Big and Small

Although the collection and interpretation of data isn’t a new trend, 2012 brought a new creativity and aptitude for mining data sets of varying sizes to expose patterns and develop insights – and a variety of compelling examples of how the meaning of data patterns can be visualized. Most notably, the strategic and predictive value of data analysis was a potent theme in the runup to, and aftermath of, the 2012 presidential election. Obama relied on “data-driven decision making” in fundraising and campaign strategy planning and Nate Silver famously used aggregated polling data to predict the election outcome with striking detail and accuracy.

In parallel with this new understanding of what we can learn from data, figuring out how to present it in creative and understandable ways has become a high priority. The New York Times, in particular, published a host of compelling data visualizations and information graphics around the election (the NYT graphics department tweets their work here) that illuminated election issues with greater clarity.

Mark Newman of the University of Michigan provides a great example from the election cycle. The standard red-state / blue-state map, the “traditional” visualization of election data depicts a deeply divided country and stark correlations between geography and political persuasion.

However, adjusting the map to account for population sizes, a finer grain (counties rather than states), and a gradient to depict party lines, the story is more nuanced.

Like most buzzwords, “Big Data” is casually invoked in disparate situations, and the difference between what constitutes big and small data is fuzzy and probably not that relevant. But what is meaningful from a UX design perspective about this discussion is the correlation of data patterns with underlying human behavior – and the strategic value of the data in predicting future behavior. In 2013, expect to see a greater emphasis on the collection and analysis of data, big and small, as a way to improve user experience.

Conclusion

Now that the UX “seat at the table” has opened up, we’ll need to be prepared to discuss the developments and business impact of our discipline at a strategic level. Some major themes emerged in 2012, and we look forward to following and participating in the development of these themes into 2013 and beyond.

My work involves helping people to understand how to best plan circumstances in which users are engaged and satisfied with their experience. Yet, I do not call myself a user experience designer.

I am an information architect. I work on clarifying information and the structure it should take to best enable understanding. I create maps, controlled vocabularies, diagrams, flows, hierarchies, and statements of truth to facilitate groups towards a goal. I do my own research. I use interviewing, contextual inquiry, and usability testing most often.

• I am not an interaction designer. I do not explore, define, and refine the interactions that a user has with an interface and/or service.
• I do not code, or render what a user will actually “see” through visual design.
• I am not a content strategist. I do not extend structures and derive templates in order to propose governance and process flow for the creation of new information and the retiring of old.
• I have done all of the above at one time or another.

I don’t think it is worth arguing about whether you can or should have a job in which you do all of these things. But I fear that the widespread adoption of “User Experience” has had adverse effects on the clarity of our process. It has made concepts like information architecture, content strategy and interaction design harder to explain, to teach and ultimately to learn about. In my humble opinion this umbrella is obscuring others’ view of our reality.

Our hindsight is clear, but our foresight is clouded

I am afraid that there is a shortage of specialist jobs, and it isn’t because those specialities aren’t needed. I believe it is because the value of those specialities, and the impact of not considering each carefully, is in too many cases not clearly called out to our clients and partners.

A simple test of this is asking, “If a UX fails, which part is to blame?” Is it a problem with the information architecture? The interaction design? Or maybe the content strategy? Maybe it is indeed all three or none of those three. Maybe it was badly produced or written? Maybe it has technical issues? Maybe the branding is off or the marketing didn’t drive the right people to do the right thing?

In picking apart an experience, the differentiation of terms suddenly offers tremendous value of focus. In focusing on a specialty we don’t need to throw the baby out with the bathwater. We suddenly have lots of dials to play with in formulation of a strategy for improvement.

Our process is being reduced

In my experience when “UX” is the term sold-in, the resulting project plans are less likely to reflect the points at which various specialities will be relied upon to progress the team. Often prescribing a stacked to the gills list of tasks reduced to the nebulous “Design the User Experience” on the Gantt chart. The makers of these types of plans leave it to “UX Designers” to divide the time they have amongst the various specialities of a “UX” and arrange their time against it.

If you have a great generalist who is also a great salesperson, this model can work well. But more often I fear that we are putting our industry in a bad position by generalizing when communicating about these specialities with others. I hear designers say “I’m doing the UX” far too often when describing the value that they bring or the part of the process they are in.

The worst case scenarios result in teams jumping right to wireframes, prototypes and documentation. I see far too many UX designers that have become wireframe machines.

This approach is directly contrary to the truth of how things get made properly:

1. You must define the why before the what.
2. You must define the what before the how.

In other words, defining a solution before you understand the goal and prioritized requirements is often a wasted effort and a distraction. Whether you define everything on your own and work through the various specialities required is really not my point at all, my point is that these questions and these specialities are always needed and in some cases they are answered by different people.

Our specialists are struggling

I work primarily on large scale, systems-based projects. I am good at the defining the Why and the What. But when it comes to defining the How, I prefer to work with others more dedicated to that craft. Sometimes the user experience designers I work with struggle to understand and champion the value of information architecture. Sometimes they feel like I am taking away their fun. But in moments when they need the information architecture to be clearer, they are able to demarcate it clearly and ask me for what they need. After a few of these moments the process gets easier for all of us and consensus is more easily reached.

Why would I ever have to defend the value of IA on a team of like minded umbrella dwellers? Why do I see important steps skipped in favor of moving right to defining the How so often? I don’t think it is because I am working with the wrong people. I think it is because our industry has a long history of land grabbing of titles, processes, deliverables, and value.

Our road has been paved over by many, and driven over by many more

In the past year I have been told to change my title to product manager, design thinker, strategist, service designer, interaction designer and of course user experience designer.

The convergent nature of this industry has made our road a hard one to name, and I respect that deeply. But I don’t think the right strategy is giving up on naming it, stealing a name, or settling for a name that doesn’t quite fit.

I think this is about hunkering down and creating consensus. We need to define ourselves and our value. We need to learn to sell ourselves and the expertise of others under this umbrella. We need to remember what it is like to not understand these concepts. We need to create ways of explaining what we do that make sense outside of our silo. Lastly and maybe most importantly for our own sustainability as a field – we need to give permission to generalists to specialize.

These are important steps forward as we continue to become a legitimate field of practice. Our students, clients, heroes, and our peers deserve these levels of truth.

Our future is bright

Regardless of what you call what you do, it is a great time to be alive and contributing to this time of our industry. My greatest hope is that this is still fun to talk about when it is all said and done.

I am an information architect. One day I may be something else. For now, I see a need, and I want to keep on filling it.

A couple of years ago, I was asked to speak about “design thinking” at a web conference. The conference-speaking part was nothing new, but the topic certainly was. With the “design thinking” wave having just recently peaked, I had yet to even come up with a clear definition of the term. So I accepted the challenge and went about the business of putting a wrapper around the idea so I could map it to our work as strategists and designers.

What I found was a bit of a joke. The few snake-like definitions I was able to charm out of the depths of the interweb with magical flute-playing were no better, no worse, and no different than definitions of “interaction design,” which were in turn no different than definitions of “problem solving,” which we as a species have been doing since the dawn of humanity. So what was the big deal about design thinking? Well, the big deal was that some designer douchebag decided one day to rebrand “user experience,” presumably to bring his agency a few new dollars. Leader of IDEO or not (I’m talking to you, Tim), rebranding a profession for no good reason is not a noble nod to semantic precision, but an exercise in self-importance.

Besides this, it bothered me that those among us who spend our time fighting the good design fights were acting like we had nothing better to do, as if the world would solve its own problems while we were over in the corner deciding what to call our particular brand of ice cream. And it was at this point that I decided I no longer gave a fuck.

It doesn’t matter one bit what you name the band, it matters how good the music is. The reputation you build around the name will outlive even the stupidest, most drunkenly attempts at a moniker cool enough to guarantee future rock god glory.

And most importantly, while we were all busy debating syllables and word pairs, the world at large caught onto the moniker we’ve been using all along. On a near-constant basis these days, the term “user experience” is used by people whose expertise is in raising kids, or selling insurance, or milling sugar. It’s used by people who have no business even knowing what “user experience” means. It appears in dinner table conversations. It appears in write-ups about apps, devices, and gadgets galore. It’s in magazines, on television, and online.

“User experience,” as a term, is weak, ineffective, and inaccurate. But although I am among the many in our profession who believe this sad title we’ve assigned ourselves becomes less potent with each utterance, I happen to also believe we should guard it with our proverbial lives. “User experience,” like it or not, has become a household name. And the best chance any of us has at legitimizing a profession that invariably begs further explanation and qualification is to make it as easily recognized and banal as “carpenter” and “motorcycle mechanic.”

“User experience” either is or isn’t the best term to serve as the concrete beneath our careers. And we either give a fuck or we don’t. It’s our choice.

Let’s stop talking about what it’s called and start solidifying the world’s understanding of it. Some people build cabinets. Some fix motorcycles. We design sites and apps. It doesn’t matter how we do it. It matters how easy it is to accept that it’s real, it matters, and is a sound career path to describe when you meet your girlfriend’s parents over Thanksgiving dinner.

Fuck title debates. “User experience” has momentum. Let it roll, and get back to work.

So what is UX?

Let’s talk instead about two kinds of people:

At the end of the day, there are those people who will go quietly about their jobs, perhaps grumbling about not having a “seat at the table.” These people may have also been taught the right way to do things. Then, there are others who–regardless of their titles or position–will stand up and say, “Wait a minute, why are we doing it this way?”

What sets these folks apart is a relentless curiosity.

They are the people who ask all the “what if?” and “why not?” questions. They disrupt processes when the process isn’t paying off. And they defy decisions, when the decisions don’t make sense. They may be subversive, but their goal isn’t subversion. Rather, they care. About the experience being designed for, and the people who will have to live with these experiences.

They care because of another vital quality: Empathy. They care about people. It’s not all about the paycheck for them. They care about what is created, because people will be affected, influenced, hindered or helped. They care about the business, people served by that business, and ultimately the world. They are curious, have empathy, and are vocal, which puts them in an interesting position.

Regardless of their appointed position, those who care will be found at the center of all that is designed, built, served, or otherwise experienced by people. These people will care about load times in browsers as well as long lines at the grocery store. They care about the details that make or break an experience: remembering a name, when someone on hold is transferred to another representative, or fixing the out of place pixel because, well, it matters.

They care about solving the real problems. And to be clear, they care about the business that enables these experiences. No customer=no business (and vice versa). Because they care about all of these details, they don’t fit neatly into an existing business unit. And they don’t even want their own business unit. They’d rather cut across silos, and grin at the magic that happens when people collaborate across disciplines.

These people have been around, long before the term “UX.” And these people will still be around, long after UX has either died out or hardened into a certifiable profession.

I am one of these people. I design experiences. Or I design for experiences, if we must mince words. I don’t do this because I was trained to do so. I do this because I must. I am a User Experience Designer. Or whatever they’re calling it these days.

The wireframe people are designers who don’t design. They don’t make mental models, or do card sorts, or task analysis. They don’t write specs, and they certainly don’t do graphic design! They carefully do a collection of wireframes they then hand to “the designer” who hands it to the engineer. And the engineer, if he’s lucky, has a product manager who did all the interaction design work in the specs. And if he’s less lucky, he does it himself. No wonder many engineers view everyone except the graphic designer as essentially useless. Too often, they are. The wireframes people often call themselves user experience designers.

And forget stealing syllabi! Everywhere I looked classes taught Omnigraffle and touted the wonders of wireframes. No wonder the world was filling up with wireframe people.

So, to paraphrase the Grinch–who I was feeling like–“If I can’t find a user experience designer, I’ll make one instead!” I had a template in my mind of what I thought a user experience designer should look like. I had seen a new generation of designer I liked and hired every time I could.

They were medium-agnostic, code-fluent, and user-centered. They didn’t draw hard boundaries between information architecture and interaction design, and they flowed easily from task analysis into interface. When they did make wireframes, it was on whiteboards in conversations with engineers or as sketches in notebooks to clear their heads. I think of them as Mythic Designers because they would have been called unicorns by the specialists.

But even if these designers are rare, they do exist, just as family practice doctors still do in a world of cardiovascular surgeons and neurologists. These generalists do everything pretty darn well. They make good sites. They might not be the best people to call on if you had to build a Photoshop or a New York Times; complex interaction or massive content stores deserve the special skills of interaction design and information architecture. But if you are a startup, and you can hire one person, you want a real user experience designer. Just as when you don’t feel very good, you just want a doctor who can help.

But I was naive. You can’t make someone capable of designing a user’s experience in twelve weeks. I almost killed my poor students as I pressed five hours of lecture on interaction design into two, pounding them with conceptual models and use cases, activity-object models and task analysis. I knew I was teaching a foundations class and I would do nothing justice, but I kept trying. They wanted to learn Omnigraffle, I said no. They wanted to do wireframes, I told them wait. A student said, “I have never gone this long without designing anything,” and I despaired. They had designed task flows, use cases, site maps, conceptual models, and the basic social structure of their projects; and they thought they had designed nothing?

And then she said, “I’m so glad. We never get time to get our heads around our projects.”

And I got hope. I relented. My TA is going to run a workshop on Omni. I’ll teach them the fundamentals of interface design next week, in the guise of wireframes. Perhaps I’ll even start teaching them one way of doing something instead of three.

It has made me think that maybe the wireframe people wanted to do good design. And maybe they were given so little time to work, it was all they could do to choose between a multiple select list and radio buttons. And maybe they just needed to be taught some thinking tools and classic techniques. Perhaps what they really needed to be taught was to have faith in themselves, so they would demand the time it takes to make something worth making.

Ten years ago, they’d have been called web designers. In a sane world, we would have called them product designers. They chose their own name, user experience designers. And we old farts who have been designing forever need to help them, so they all can be called Mythic.

That’s right! I said it. For us (designers, information architects, interaction designers, usability professionals, HCI researchers, visual designers, architects, content strategists, writers, industrial designers, interactive designers, etc.) the term user experience design (UX) is useless. It is such an over generalized term that you can never tell if someone is using it to mean something specific, as in UX = IxD/IA/UI#, or to mean something overarching all design efforts. In current usage, unfortunately, it’s used both ways. Which means when we think we’re communicating, we aren’t.

Of course there is UX for us

If I was going to define my expertise, I couldn’t give a short answer. Even when UX is narrowly defined, it includes interaction design (my area of deep expertise), information architecture (a past life occupation), and some interface design. To do it well, one needs to know about research, programming, business, and traditional design such as graphic design as well. Once, to do web design you had to be a T-shaped person. This is defined as a person who knows a little bit about many things and a lot about one thing. Imagine a programmer who also understands a bit about business models and some interface design. But as our product complexity grows, we need P and M shaped people–people with multiple deep specialties. To design great user expereinces, you need to specialize in a combination of brand management, interaction design, human-computer factors and business model design. Or you could be part of a team. The term UX was welcomed because we finally had an umbrella of related practices.

Of course, we don’t all belong to the same version of that umbrella. We all bring different focuses under the umbrella, different experiences, mindsets, and practices. While we can all learn from each other, we can’t always be each other.

But trouble started when our clients didn’t realize it was an umbrella, and thought it was a person. And they tried to hire them.

It isn’t about us

If there is any group for whom UX exists now more than ever it is non-UXers. Until 2007, the concept of UX had been hard to explain. We didn’t have a poster child we could point to and say, “Here! That’s what I mean when I say UX.” But in June 2007, Steve Jobs gave us that poster child in the form of the first generation iPhone. And the conversation was forever changed. No matter whether you loved, hated, or could care less about Apple, if you were a designer interested in designing solutions that meet the needs of human beings, you couldn’t help but be delighted when the client held up his iPhone and said, “Make my X like an iPhone.”

It was an example of “getting user experience right.” We as designers were then able to demonstrate to our clients why the iPhone was great and, if we were good, apply those principles in a way that let our clients understand what it took to make such a product and its services happen. You had to admit that the iPhone was one of the first complete packages of UX we have ever had. And it was everywhere.

Now five years later, our customers aren’t saying they want an iPhone any more. They are saying that they want a great “experience” or “user experience.” They don’t know how to describe it, or who they need to achieve it. They have no clue what it takes to get a great one, but they want it. And they’ll know it when they see it, feel it, touch it, smell it.

And they think there must be a person called a “user experience designer” who does what other designers “who we’ve tried before and who failed” can’t do. The title “user experience designer” is the target they are sniffing for when they hire. They follow the trail of user experience sprinkled in our past titles and previous degrees. They sniff us out, and “user experience” is the primary scent that flares their metaphorical nostrils.

It is only when they enter our world that the scent goes from beautiful to rank. They see and smell our dirty laundry: the DTDT (Defining The Damn Thing) debates, the lack of continuity of positions across job contexts, the various job titles, the non-existent and simultaneously pervasive education credentials, etc. There is actually no credential out there that says “UX.” Non! Nada! Anywhere. There are courses for IxD, IA, LIS, HCI, etc. But in my research of design programs in the US and abroad, no one stands behind the term UX. It is amorphous, phase-changing, and too intangible to put a credential around. There are too many different job descriptions all with the same title but each with different requirements (visual design, coding, research being added or removed at will). Arguably it is also a phrase that an academic can’t get behind. There aren’t any academic associations for User Experience, so it’s not possible to be published under that title.

Without a shared definition and without credentialed benchmarks, user experience is snakeoil. What’s made things even worse is the creation of credentialed/accredited programs in “service design” which take all the same micro-disciplines of user experience and add to it the very well academically formed “service management” which gives it academic legitimacy. This well defined term is the final nail in the coffin, and shows UX to be an embattled, tarnished, shifty, and confusing term that serves no master in its attempt to serve all.

“User experience design” has to go

Given this experience our collaborators, managers, clients and other stakeholders have had with UX; how can we not empathize with their confused feelings about us and the phrase we use to describe our work.

And for this reason UX has to go. It just can’t handle the complexity of the reality we are both designing for and of who is doing the designing. Perhaps the term “good user experience” can remain to describe our outcomes, but user experience designer can’t exist to describe the people who do the job of achieving it.

Abby Covert said recently that the term UX is muddy and confusing. Well, I don’t think the term “user experience” is confusing so much as it’s a term used to describe something that is very broad, but is used as if it were very narrow. There is a classic design mistake of oversimplifying something complex instead of expressing the complexity clearly. UX was our linguistic oversimplification mistake. We tried to make what we do easy to understand. We made it seem too simple. And now our clients don’t want to put up with the complexity required to achieve it.

Now that the term has been ruined (for a few generations anyway), we need to hone our vocabulary. It means we can’t be afraid of acknowledging the tremendous complexity in what we do, how we do it, and how we organize ourselves. It means that we focus on skill sets instead of focusing on people. It means understanding our complex interrelationships with all the disciplines formerly in the term UX. And we must understand that they are equally entwined with traditional design, engineering and business disciplines, communities, and practices as they are to each other.

So I would offer that instead of holding up that iPhone and declaring it great UX, you can still use it as an example of great design, but take the simple but longer path of patiently deconstructing why it is great.

When I used to give tours at the Industrial Design department at the Savannah College of Art and Design (SCAD) I would take out my iPhone and use it to explain why it was important that we taught industrial design, interaction design, and service design (among other things). I’d point to it off and explain how the lines materials, and colors all combined to create a form designed to fit in my hand, look beautiful on my restaurant table, and be recognizable anywhere. Then I would show the various ways to “turn it on” and how the placement of the buttons and the gesture of the swipe to unlock were just the beginning of how it was designed to map the customer’s perception and cognition, social behaviors, and the personal narrative against how the device signalled its state, what it was processing, and what was possible with the device. And I explained that this was interaction design. Finally, I’d explain how all of this presentation and interaction were wonderful, but the phone also needed to attach a service to it that allows you to make calls, where you can buy music and applications and that the relationships between content creators, license owners, and customers.

At no time do I use the term “user experience.” By the time I’m done I have taught a class on user experience design and never uttered the term. The people have a genuine respect for all 3 disciplines explored in this example and see them as collaborative unique practices that have to work intimately together.There is no hope left in them for a false unicorn who can singularly make it all happen.

Obviously I don’t stand alone in finding the term useful, or at least useful enough. Yet we find ourselves endlessly discussing this and and other terms for what we do … trying to describe what we do … disagreeing vigorously … and at the same time complaining about getting mired in an argument about semantics. Can’t we just get on with the work?

I don’t think we can. We cannot get past this argument about language just yet because I don’t think we really have an argument about language. We have an argument about what we do, a genuine and profound disagreement.

Looking at where the term “user experience design” comes from, and how we actually use it, I have a proposal for what we can take it to mean: design which includes interaction design but is not only interaction design.

People who think of interaction design as just one among many UX specialties may consider that a surprising overextension of that specialty’s relevance; I hope to show why it makes sense.

Trouble with the definition, not the word

I don’t much care which words we ultimately choose. Yes, it would help to use language which no one could mistake or confuse, but we cannot seem to find that and don’t strictly need it anyway. Consider the ugliness and inappropriateness of the term “industrial design.” We understand it not because it suits what industrial designers do, but because we already understand what industrial designers do and can attach the name to that generally understood meaning.

In “user experience design,” we don’t have that. We lack a clear meaning to which we can attach the term. Until we find one, the grumbling over names will continue.

Grandiose UXD

Some people like the grand implications of the term “user experience design.” They include anything where one plans what experience people will have, including not just websites but interior decoration and customer service scripts and theme park rides and kitchen knives.

I feel uncomfortable with the language of “user experience design” because I don’t think we need a name to describe all of those things. At that point, why not just “design”?

Looking back at how we came to talk about UXD in the first place, that large world of design problems didn’t give rise to talk of “user experience design.” The web did.

The web gave us UXD

The term “user experience design” came as a response to the shock wave created by the emergence of the web. For most people in the field, “user experience design” means, in practice, “design for the web … and other stuff like it.” So what is the web like?

Some people with a background in graphic design tend to think of web design as visual design plus a bunch of other Design Stuff. For a long time, a lot of web designers made a binary distinction between visual design and information architecture, effectively defining IA as “all the Design Stuff for the web which isn’t visual design.” These days, most define IA more crisply than that, distinguishing between information architecture as the organization of content and “interaction design” as … well … that gets a little tricky.

For some web designers, I suspect “interaction design” represents the frontier of web design as IA once did; having accounted for visual design and information architecture, “interaction design” means, in practice, the design on the web which ain’t either of those. Others have a more specific conception of what constitutes “interaction design.”

Interaction design

Over in the software development universe, people have long discussed “usability engineering” and “human factors” and “user interface design” and a host of other names for the same essential work. All of those terms have their problems: philosophical, rhetorical, political. You can locate me in the era and tradition I spring from by knowing that, in circles where I can expect people will understand me, I still prefer to call myself an interaction designer rather than a UX designer because I consider it a more usefully precise term.

When one encounters a computer, or a device, or any other system which has software in it, one enters into a dialogue with that system, a cycle of action and reaction. This includes both cycles of action between individuals and the system itself, and also cycles between different people as mediated by the system. Inter-action: action between people and systems, action between people and people. Systems containing software involve categorically more complex interactions than anything else we make, which gives those systems a unique character that calls for a distinct design discipline. Hence “interaction design.”

Back in the late ’90s the term “interaction design” got tangled up rhetorically because traditional advertising and design agencies used the term “interactive media” to describe the brochure-ware they made for the web.

More recently, many people have taken “interaction design” to mean only the pick-and-shovel work of wireframing and specifying workflows, not the fundamental product or service definition which lies behind the specific interaction behaviors.

Once upon a time I wanted “interaction design” to become the term which included all of this work defining new interactive systems. Things didn’t go that way.

Disciplinary distinctions

Interaction design. Information architecture. Visual design. Information design. Social interaction design. Service design. We have people who find these disciplinary distinctions very useful, believing that they represent well-defined types of work with reasonably well-developed methods. We have people who see talking too much about these distinctions as territorialism and semantic games that get in the way of just doing the work. Some among those have a deep skepticism that these distinctions mean much at all: compared to the classical disciplines of graphic design, industrial design, et cetera, we do not — and perhaps can not — have well-established methodologies for the new problems which designers face today. They talk in terms of a kind of open-ended design sensibility and developing an eclectic toolkit of specific techniques.

We should not minimize the differences between these philosophies. When we do, the disagreement displaces itself into discussions of language. Rather than ask what “user experience design” really means — a question with no answer — we should ask instead what problem we use it to talk about.

“User experience design” creates an uneasy truce

The term “experience design,” originally proposed by people who rejected disciplinary distinctions, has acted to paper over the disagreement.

These early advocates saw “experience design” as a way to name a new era in which the old disciplinary distinctions between design problems had broken down and become less relevant. They talked excitedly about UX design in its grandiose sense.

Then Jesse James Garrett drew his famous diagram of “The Elements of User Experience,” name-checking several different classes of design problems and suggesting a way of looking at their relationships, writing “user experience” in large letters on the diagram as a name for the whole. People who valued disciplinary distinctions could look at the diagram and see them represented there. People who wanted to transcend disciplines could look at the diagram and see the implication that each lived as part of a greater whole, incomplete on its own. So that diagram exemplified conversations which brokered an implicit truce under the banner of “user experience design.”

But we still need to understand and talk about This Thing That We Do, and we still do not agree about it. If UXD means “Designing Stuff like the web” we have to ask what we mean by “like the web.”

Interactive systems, not just the web

The 800-pound gorilla that is the web confuses our thinking. Web-ness per se did not produce the need which gave birth to the term “user experience design.” It didn’t come from people making simple websites with static pages, it came from people making web applications. And now we see it adopted by people making desktop software and mobile apps and more. What do those have in common? The network? Static websites involved the network … and we also see people talking about UX design for stand-alone desktop computer applications. So no, the network does not unify these UXD domains.

Software ties these things together. The Thing The Web Is Like is software, and in fact that statement says it backward. Better to say many things derive their nature from software, for example the web. What makes software special? What makes it different from the artifacts created with industrial design? From the images created with graphic design? From websites of static pages?

Interactivity.

More than just interaction design

One might call this focus on interactivity chauvinism on my part, since I come from interaction design.

Let me underline that I do not claim that interaction design constitutes the most important component of all UXD. Let us recognize service design and information architecture and visual design and social interaction design and all the other specific design disciplines we employ in solving UX design problems. Indeed, let us notice that in many cases other design disciplines outweigh the importance of interaction design in solving a UXD problem.

One may have a big retailer’s website and mainly need information architecture to organize the vast set of pages and visual design to make the pages appealing and aligned with the brand, with just a little bit of interaction design for the search and purchasing tools. One may have a member service process for an HMO which involves sophisticated service design and classical graphic design for communicating to members and just a little bit of interaction design for things like appointment setting tools.

I don’t want to make interaction design dominant over UX design but I do want to name it as essential to UX design. The presence of interaction design usefully defines “user experience design.” The term “user experience design” did not emerge from an encounter with the need for service design, information architecture, visual design, social interaction design, or any of the other problems we talk about in the UX design world. It emerged from the encounter with complex software behaviors and the interaction design challenges they present.

It makes no sense to ask what “user experience design” really means; it means whatever we use it to mean. We can ask what we need it to mean and how we already use it. I submit that we need a term for “designing systems that include interaction design”. And we already use “user experience design” to mean that now.

If we could agree on that, I might stop feeling so bad about calling myself a “user experience designer”.