By Andrea Ames | Fellow
Alyson Riley | Member
This column explores the strategic aspects of information architecture and the tools to equip information architects (IAs) for success. Topics will address the business, strategy, user experience, and implementation of strategic information architecture, including organizational, content management, and tactical considerations. Send your comments, questions, and suggestions for future articles to thestrategicia@pobox.com.
In prior Intercom columns, we addressed mobile, multimedia, social media, and business value, all in the context of strategic information architecture. In the January 2012 issue of Intercom on information architecture, we discussed business value yet again and also information models. All of these topics cover dimensions of what we believe to be the nucleus of strategic information architecture: the information user experience, or information experience. Rather than dip into the various facets of user-centered information architecture, in this column we attempt to tie those threads together to directly address information usability and experience as a central responsibility and value of the strategic information architect (IA).
We haven’t tried to be subtle about our belief that strategic information architecture is the source from which all information experience waters flow, but we know that for many technical communicators, this is an uncomfortable thought. Picking up from our assertion in the mobile column:
"But I’m a technical writer, information developer, information architect, content developer, ," we might be thinking, "not a user experience designer." We argue that we are, and always were, designing the information experience, no matter what you call us.
In that column, we made the point that mobile is driving a revolution in our focus as technical communicators. While mobile is driving the revolution, it’s a revolution that started about 20 years ago with the emergence of HTML and the World Wide Web. When the Web allowed lots of people access to large amounts of non-linear, hyperlinked, online information, technical communicators began a migration from the back of the crowd to a more prominent position. When the Web became an application delivery platform, and the design of those applications evolved from terse desktop user interfaces into information-rich interfaces, the real revolution began. In the mid-1990s, Andrea began a rant that would become a personal mission, teaching, presenting, and writing on user-centered embedded assistance, information usability, and career paradigm-change topics. Around the same time, Alyson began her career, asking the question, "how come all this cool stuff is so hard for normal people to use?"
Just because the revolution started 20 years ago doesn’t mean that it has to take another 20 years to complete! This revolution must play out on several fronts, and we must be the revolutionaries driving those fronts forward.
The User Experience of Information
Traditional thought separates the user experience (UX)—sometimes understood very narrowly as interaction design—from content, typically pictured as documentation, such as books (or PDFs) and online help. When we consider a given software product, for example, it’s clear that several components dramatically affect the user’s experience with that product, some of which transcend what our community has traditionally consider to be that product’s "user interface," such as the evaluation and purchasing experience.
Occasionally, IAs perpetuate this artificial separation. In our multimedia column, we proposed an alternative (Figure 1) to Marlana Coe’s human factors metaphor for technical communication, which illustrates that there’s potentially a lot of unnecessary noise between the user and the message you are trying to communicate.
We might then think that the experience encompasses the content; the constituent layers of "packaging," including presentation, delivery, and navigation between the content and the user; and the user’s world (Figure 2).
Because the current information user experience includes so much more than our content (and its constituent "packaging"), we must take a broader view when we consider a model to describe a human factors, usability, or user experience metaphor for technical communication. Users or readers are accessing our content in bits and pieces from a wide spectrum of publishers and delivery channels. In addition, today’s readers evaluate that information in the context of collaborative community content. A better model (Figure 3) reflects not only the variability of the experience but also the fact that the experience is one of many intertwined and overlapping experiences encountered in the user’s world—an ecosystem of experiences encountered as the user focuses on one task or another across a range of tools and information.
In this ecosystem, content still has presentation, delivery, and navigation dimensions, but (hopefully!) the user seamlessly encounters those aspects of the content as they use the content—so seamlessly that they’re practically unaware when they do so. We believe that a transparent, facilitating "interface" layer to the content is ideal. In the best ecosystems, those dimensions of the content facilitate that seamlessly integrated experience across our content and content developed by the community. In other words, content is the constant—presentation, delivery, and navigation can and should be adapted based on user need or context. Whew! That’s a lot to expect! Especially when we consider the additional customization and personalization that today’s users are starting to expect from modern information experiences.
Now that we’ve envisioned an entire ecosystem, let’s map the key components of the information experience to a paradigm that we’re all familiar with: the user experience. Simply put, if we think of information as a product—our product—then we can create an easily understood mapping to the key components of user experience. UX is a large, complex discipline, but at the risk of offending UX practitioners, we propose that UX is composed of four key components (Figure 4):
- Content: the labels and other kinds of text found in the user interface.
- Visual design: the page or screen layout, icons, color schemes, and skins.
- Interaction: the many elements used to facilitate the user’s ability to accomplish tasks with the product or service.
- Function: the underlying algorithms provided by our partners in engineering, programming.
Going back to our human factors metaphor for technical communication, content and its dimensions map well to the four user-experience components (Figure 5):
- Content: the content!
- Presentation: the visual and information design of the content and any user interfaces associated with delivery mechanisms (such as white space, subheadings, color themes, and any visual elements required by the delivery mechanism).
- Navigation: the various elements needed to facilitate a human user’s ability to access content and complete a content-related interaction (find, read, reuse, share, and so on), including structure and organization.
- Delivery: the functional mechanisms—such as hover help, contextual help controls, and information delivery applications—that enable user interaction with content.
We acknowledge that the boundaries between the components of the information experience world are more gray than those of the UX world. Our world is less "neat" than UX. However, IAs are concerned with the same issue as our friends in UX: the usable convergence of function, interaction, visual design, and (above all for IAs) content. Although we’ve focused on the design aspect of UX thus far, if we consider the other phases of a comprehensive UX process, we can map the development of the information experience to analysis and validation, as well. The components of the experience map and the process maps.
The bottom line: IAs are the user experience practitioners responsible for the usability of information and the experience in which that information is used. Our work both mirrors and integrates with the work for which our UX colleagues are responsible—that is, product usability—and together, we drive the experience in which our products are used.
Roles, Careers, and Professional Development
If it is true that IAs are the user experience practitioners responsible for the usability of the information and the experience in which that information is used, what does this mean for the IA role on a product team, the IA career, and professional development on the IA career path?
The IA role is an interesting question—we could write an entire article about it, and we touched on the strategic IA role in our first column. In this context, however, reconciling the IA role and the UX role is challenging, and we believe that it should be handled situationally. For example, many IAs—particularly in Web design contexts—are UX practitioners, and in their minds, IA is a UX discipline. In our work context—that is, enterprise technical product documentation—IAs typically emerge from the information development (or technical writing) discipline, not UX. In reality, staffing the IA role is about skills and aptitude, not where you came from or your status on a documentation team. Consider these examples:
- Example 1: Your team has a UX practitioner who is skilled in information-related techniques, such as progressive information disclosure and navigation design. Great! You’ve got an IA who is responsible for the information user experience.
- Example 2: Your team’s technical writer is masterful with detail and skilled in communicating complex concepts simply, but she struggles with ambiguity and the big picture. Great! You’ve got yourself an excellent technical writer, but not a good IA.
- Example 3: Your team’s IA commands a solid knowledge of UX methods and practices, over and above skill in structuring information. Great! You’ve got yourself an IA who is responsible for the information user experience and not just navigation or content structure.
- Example 4: Your team’s UX practitioner really understands user interaction techniques but lacks information architecture skills. Great! Time to go find an information architect!
When it comes to career and professional development, we’re not going to pull any punches. If you’re in technical communication—writer, editor, tactical information architect, strategic information architect, whatever!—you need to build solid IA skills and become at least semi-expert in UX methods and practices, particularly user-centered processes like scenario-based development and interaction design. Bring together the practices and methods of UX and apply them to information: scenario-based information development; progressive information disclosure; information use, content, and access modeling; and information user testing. Remember: Consider your content your product! Your future depends on it.
Conclusion: It’s All Experience
The thing is, we’ve never really understood the (occasional) rift between UX and IA. Yes, we focus on different things, but it’s all UX. Or maybe a better way to put it is this: it’s all experience. All of these fabulous new information technologies—particularly some of the innovations we’re seeing in mobile environments—continue to blur the lines between read vs. do, see vs. touch, consume vs. produce. These technologies continue to blur the lines between the various facets of the user experience. Everything our users see, do, and touch; every shift in their understanding and awareness; every change in their behavior that comes to be—it’s all part of the experience. And that can make it hard to distinguish who does what (a necessity in corporate life).
In our perfect world, we envision a kind of collaboration that starts first with ideas and only later moves to implementation. In this world, the UX practitioners and the information architects sit down together and define ideas first: How do we want to change the user’s experience? Is that new experience a doing thing or a knowing thing—or both? And what’s the best way to implement that experience? Sometimes a knowing-related need is best executed by doing (an interaction object), and sometimes a doing-related need requires knowing (an information object).
In reality, many of these decisions are made before the work even begins, because the UX architect and the IA do not define the ideas together first. By the nature of their defined roles, they jump straight into implementation: "I’m going to start designing the panels; you start designing the help system."
By focusing on the core ideas first and defining those ideas from the user’s point of view, requirements emerge for doing vs. knowing and for the best way to drive user success: "Will an action or some information help the user best?" In all situations, it’s just experience—whether the content of that experience is implemented as a doing thing or a knowing thing, or more likely, some combination of the two.
The point here is that interaction and information are both facets of the same user experience. Of course presentation and delivery vary between interaction and information, but the modern user doesn’t see the line between function and content that we technical communicators do. All they see is: "Did I get what I wanted, or did I just get close to what I wanted?" Interaction, like information, is a user experience. Don’t fear this pressure to expand your skills into the world of user experience architecture! You’re already working in that space, and many of the core concepts and skills are transferable. Embrace this idea of integrated interaction and information experience—it’s the key to relevance tomorrow.
References
Ames, Andrea, Alyson Riley, and Deirdre Longo. Mobile: The Crucible for Information Strategy (The Strategic IA column). Intercom (April 2012): 29–31.
Ames, Andrea, and Alyson Riley. Multimedia as a Strategic Element of Information Architecture (The Strategic IA column). Intercom (September/October 2011): 24–26.
Ames, Andrea, and Alyson Riley. Architecting the Social Information Experience"(The Strategic IA column). Intercom (June 2011): 26–29.
Ames, Andrea, and Alyson Riley. Introducing The Strategic IA (The Strategic IA column). Intercom (May 2011): 24–25.
Ames, Andrea, and Alyson Riley. A Note from the Editors. Intercom (January 2012): 4–5.
Ames, Andrea, and Alyson Riley. Helping Us Think: The Role of Abstract, Conceptual Models in Strategic Information Architecture. Intercom (January 2012): 26–29.
Coe, Marlana. Human Factors for Technical Communicators. New York: John Wiley & Sons, 1996. Print.
