Is the iPad mobile?

Written by: Marina Lin

My Android phone died on the train when I was several stops away from my destination. I should have remembered where I was supposed to get off, but, like everyone else, I rely on technology to offload cognitive processes when I should be using my brain.

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 Content Conundrum

Written by: Christopher Detzi

rocks, intro image

As web designers and information architects, we often dismiss deep consideration of content when we design interactive experiences. By content I’m not only referring to the various forms of text (e.g., headers, body copy, error messages) but also imagery, graphics, and videos or audio that make up the full interactive experience.

Sure, we have a sense of what content is available, and we’ve likely considered it to some extent when creating flows, wireframes, and prototypes. But the design artifacts that we create represent only part of the overall user experience that we’re designing. The content that sits inside of our design framework is often the final arbiter of success, yet we sometimes diminish its importance and separate ourselves from it. The more we separate our design activities from content development, the greater the risk of design failure.

Recognizing The Problem — The Content Gap

There’s often an unsettling discrepancy between the stakeholder approved wireframes and visual comps and the actual product in production. What you see in those environments is sometimes a far cry from those polished wireframes and those shiny, pixel-perfect visualizations that were filled with placeholder content (such as lorem ipsum text, dummy copy, and image blocks). What you’re seeing in production environments now holds the real content. The imagery doesn’t support the interactions, is meaningless, useless, or worse, contradictory to the design intent. The copy, headers, and labels are unclear, too long, too short, or simply irrelevant.

What happened?

More than likely, that content was discussed, created, and iterated outside or separate from the core design review process and ultimately plugged into a content management system (or pasted into the code by a developer) much later in the development process.

The example illustrated in Figure 1 shows two examples of web content. The image on the left represents a screen shot of the approved design that was delivered to the production team. The image on the right is a screen shot of that same page taken from a functional test environment after the real content was included. As you can see, the experience breaks down considerably with the amount, type, and format of the real content. The information is more difficult to scan, the primary call-to-action has been pushed well below the fold, and the choices that users need to make are less clear.

These two screens show what the content gap looks like. On the left is the mockup next to what it looked like in production.

While this example highlights only a small portion of the overall web site, the problem manifested itself throughout the bulk of pages that made up this interactive experience. So what might be perceived as a small problem becomes a much bigger problem when considered across the entire interactive experience.

Exploring the Causes

These content gaps are both procedural and cultural within organizations. By procedural, I’m referring to the tangible processes used by an organization to design and develop a web product. Often times, these ‘processes’ are influenced by the organization’s values and overall culture. There are four common reasons why content gaps occur.

Flawed Processes

There’s undoubtedly a wide spectrum of web design and development ‘processes’ in use today. Most often, however, organizations use one that aligns more closely with either a traditional waterfall process or alternatively, an Agile one. In theory, both models have mechanisms built-in to eliminate and minimize surprises (including content gaps) but in reality, both tend to exacerbate the problem but do so in different ways. Rigid waterfall processes fail because they tend to segment activities and related roles. Designers often design totally separate from content ideation and development. Agile processes fail because they’re typically developer centric and move at speeds and iterations more akin to code production than to experience design and content development. The site is often being coded before the design or content are ever completed.

Content The Design(er) is King

We’re at a point now where usability is table stakes, and persuasion and message is necessary to differentiate products.

The value of most design projects is typically placed in the upfront design and strategy work. It’s here that the ‘big ideas’ are generated and explored. During this initial phase, are the right people involved in the design process alongside of us, exploring solutions? I’d argue that we rarely involve our content partners, even though we’re essentially creating a framework for communication and messaging. It’s here that content specialists thrive. We’d benefit from including those who specialize in communication, writing, persuasion, and instruction more directly. We might argue that as designers that we have those skills, but then we shouldn’t rely so heavily on placeholder content in our designs.

There’s a lot we can learn from traditional advertising here. In advertising, copywriters often drive the creative process. Their skills with communications and persuasive messaging are often unparalleled within an agency. We’re at a point now where usability is table stakes, and persuasion and message is necessary to differentiate products. In fact, some leading companies are beginning to recognize this change and develop tools and/or POVs on this topic (See Eric Schaffer’s article, “Beyond Usability; designing web sites for persuasion, emotion, and trust” and Forrester Research’s report, “Use Persuasive Content to Improve the Customer Experience”).

Design artifacts rarely include “real” content

I understand the need for lorem ipsum text and placeholder imagery. I am an information architect, after all. When working on an overarching framework for a web experience and creating a flexible design system, it makes sense to start with concepts and relationships, and to establish the right models and structures first. However, the more we start illustrating these concepts at the page level, the more we must concern ourselves with content and the overall message we want to create. By relying too heavily on placeholder text and graphics, we begin to communicate a level of reality that is problematic. It’s at this point in the process that the actual content should be considered and where our design deliverables should communicate these details.

Obviously, exploration of visual styles, hierarchy, and the overall visual language is crucial at this stage. That said, effective content to support those elements is absolutely essential for design success. The content works in conjunction with our visual language and style to help people move through and understand the information space they’re in. The more the design and content can be explored, iterated, and finalized together during this phase, the fewer problems we’ll encounter when the site goes live. Dr. Browyn Jones said it best in her 2007 article, titled Better Writing Through Design:

“Ideally, you should work with a writer from day one to design the voice of the copy in conjunction with the visual language of the site. And getting a writer involved early can help you solve lots of other problems—from content strategy issues to information architecture snags. Remember that writers are creatives too, and they are, in many cases, the keepers of the content your design ultimately serves.”

Lack of value assigned to content

When taken as a whole, the general perception is that content teams are production teams and therefore non-creative. Taken as a whole, content teams are typically highly focused on production and publishing issues. An unfortunate side effect is that these individuals are brought in much too late in the process, immediately playing catch-up, and trying to understand the bigger design decisions that were made. In many cases, the only information that they have to go on is a lot of ‘lorem ipsum’ or other placeholder content.

What Designers Can Do to Address these Problems

As a design community the first thing we can do is recognize the problem and want to fix it. I’d suggest that we look at it selfishly at first, realizing that if content fails, our designs fail. Period. There are a number of tactical things we can do with every project to mitigate the risks.

1. Rethink the need for specific content

Do you really need that introductory text? What about those thumbnail images? What will those elements really accomplish for your design? Are they necessary? Many of the content components we include don’t contribute to design goals or the users ability to perform a task. Simply remove those from the design entirely. The more concrete we are about what is and isn’t open for interpretation (or worse, misrepresentation) the fewer surprises we’ll see in those functional environments.

2. Explore Information Graphics & Visualizations

Take a step back from your designs and see what information can be communicated more effectively using visualizations and/or informational graphics. Let the user’s ‘scanning’ behavior work to your advantage. What can be communicated better with simple imagery than with text? How can that general concept be applied to your overall design paradigm? This critical extra step will improve and streamline the user experience. If you’re not the best person to create these assets, bounce your ideas off of the visual designers and production artists. Reviewing your own work this way will dramatically improve your design. As a bonus, the more perspectives you hear during this process, the better informed you’ll be to solve the design problem.

3. Write (some) content

If you can’t get a copywriter or content expert working with you from day one, spend some time writing draft content or sketching actual imagery and place it into your design artifacts. The goal isn’t to be perfect, but to communicate to stakeholders and partners the intent behind a particular content element or component. Bring the design to life and create actual content, headlines, text, instructions, headers, and imagery. Force feedback on those elements at the same time This will force you to think through the necessity of the content, the importance of the message, and force the same thought from your stakeholders. This means using lorem ipsum sparingly, particularly when designing critical web pages or elements that significantly impact the experience. Don’t rely on someone else to do it without first thinking hard about it yourself.

4. (Really) Collaborate with your content partners

The collaboration that we demand from developers should parallel those we have with our content partners: copywriters, strategists, production artists.

The collaboration that we demand from developers should parallel those we have with our content partners: copywriters, strategists, production artists. Often times, the content teams or copywriters are working with brand, marketing, or product teams on the creation of ‘final’ content. They understand what those teams need to accomplish and what they’re trying to communicate. Rather than have that process happen without your oversight, get involved early and often with these people and describe your vision, solicit their input, and ask for help clarifying your message and assumptions. This back and forth (like the one we expect to have with development) needs to happen with our content partners as well. Become friends with them. Remember, their skills at persuasion, messaging, branding, and simply overall writing prowess can only improve our designs.

5. Package real content with the visual mock-ups

Whether it’s visual comps, or a prototype, it’s important that whomever is responsible for creating and approving the content is actually involved with the visual designer and prototyper as they ‘package’ that deliverable. It’s impossible to fully evaluate the effectiveness of a web experience without having the content represented and under the same microscope as the design. Brand, product, and even training teams all have their own perspectives about what the content must communicate and are contributing to its development and we don’t want our design to fall apart once this ’collaborative’ writing process starts. Assign accountability to content upfront and place content professionals under the same creative deadlines you’re marching to.

There are a variety of tools and software emerging that can help you work with content. For example, Adobe InCopy hooks into Adobe InDesign. It’s just a matter of time before we start seeing integration points with Photoshop and other standard web design software and tools. But even without formal tools, the important step is that ‘real’ content is represented and tells a more complete story about the design you want to put out there.

Conclusion

It’s up to you to assess whether these content gaps are a problem in your design environment or not. Admittedly, this problem is more applicable to larger web sites and online businesses given variety of stakeholders (read: opinions). That doesn’t mean that these concepts don’t apply to the social web, or smaller marketing or micro web-sites. They do. It’s just that how critical this issue is depends on the size and scope of the website or application you’re designing.

This problem is common in many organizations (small and large). As a design community, we hold the power to 1.) change how we think about content, 2.) bring other roles into our processes, and 3.) change how we communicate with stakeholders and partners. Collaboration is what we strived for when developers shut us out, now it’s our turn to open up and let our content partners in and build even better experiences for our customers.

Content Strategy: The Philosophy of Data

Written by: Rachel Lovinger

Not that familiar with “content strategy?” That’s ok. It’s in my job title, and I struggle every time I’m asked what I do for a living. Many people have no idea what it means, but even more people bring their own (wrong) assumptions to the conversation. Usually they think it has something to do with writing copy. That’s not entirely false, but it’s kind of misleading.

The analogy I’ve been using recently is that content strategy is to copywriting as information architecture is to design. I find this analogy to be especially encouraging because six years ago, as the crest of the first wave of the web was about to break, people had no idea what “information architecture” meant either.

The irony of this communication challenge is that the main goal of content strategy is to use words and data to create unambiguous content that supports meaningful, interactive experiences. We have to be experts in all aspects of communication in order to do this effectively.

So, why has it been so hard for us to communicate what we do?

Perhaps the problem is that, because content is so pervasive, everyone thinks they know all there is to know about it. If you can read and write, you can make content, right? (Nearly 60 million blogs may prove that.) But the fact is, as interactive experiences become more complex, so does the nature of content. A superficial understanding of content isn’t going to cut it anymore. Content strategists in the digital age need to become data philosophers and explore the metaphysics of content, starting with the question “What is content?”

Everything is content

When we were developing a deep metadata system for the website of a national entertainment magazine, my colleague and friend, Chris Sizemore, would say, “Everything is content.” And I tend to agree.

Everything is content? What about design? Yes, it’s content. Structure? Content. Metadata? Also content. You probably expected a more incisive analysis than that. Well, how about, “Literally, everything is content.”

How did the need for detailed focus on content emerge in the heavily visually oriented field of web design? As website functionality has increased and web users have become savvier, sites have had to meet the demand for sophisticated interaction and more content to support it. But simply more content won’t do; it has to be accurate and relevant. It has to be meaningful.

There are many factors that determine whether something is meaningful, but the primary one, at least as far as web applications are concerned, is relationships. Is article Z related to the topic I clicked on? Show it to me. Is image B the same as the image I’m already looking at? For Pete’s sake, don’t make me look at it again! These and other subtle, dynamic, and complex relationships need to be expressed in precise ways that computers can translate into rules. As an example, let’s take the seemingly straightforward example of “sameness.” How do you determine when two pieces of content are the same?

You could say that every data record is unique and therefore distinct, but that doesn’t help us draw any kind of relationship between two chunks of text that are, in all ways, identical. So, maybe having exactly identical bytes makes two pieces of content the same. But, what about an article and a translation of that article? What about an image and a resized version of that image? To a reader, it looks the same, only smaller. How about a cropped version of that image?

The question “What constitutes sameness?” may seem somewhat academic, but it has very practical implications when you’re setting up a content management system (CMS). How you capture an article and its translation can make a huge difference in how that article is produced, published, and ultimately, used on the site. The way an image and its resized and cropped versions are stored in the CMS will likewise have a huge impact on both production and access.

Critical mass

If you’re presenting a very small amount of information you can (arguably) just put it out there and let people make sense of it.

stakeholder influence chart
A very simple website may not require much IA or content strategy.

Start adding more information and, pretty quickly, you’ll need to apply some structure to it to help people find their way around. This is where information architects come in, applying organizing principals and visual cues so that people can look at a site and quickly know what’s there, without having to think about it too much. If the information architect (IA) also happens to have an interest in words, she may carefully craft the labels that are used on the buttons and think about what sort of language best conveys the messages of the site. If she doesn’t have that interest or experience, this is a good place to get a content strategist (CS) involved. The CS will also work closely with the IA to make sure that the organization of the site makes sense and will be supported by the content that’s available.

stakeholder influence chart
A more complex site requires some organization

As we start to design and build websites with massively larger volumes of content, we find that often they’ve outgrown the ability of individuals to manually organize them. Now we need automation and complex algorithms to find that needle in the haystack. We need the content to include inherent meaning that makes sense to machines, for example, to support data-driven applications based on search, browse, and related links. A content strategist is the person with specialized focus on making sure that the content is meaningful and the site is designed to make the best use of it.

Time to get practical

So, when we’re done philosophizing (for now) and we’ve figured out who’s going to be responsible for the content, how do we go about infusing it with meaning?

To make content that’s relevant to people, we choose the words and sentence structures that will best contribute to achieving our communication goals. The voice should be based on a deep understanding of the intentions of the content creators, as well as the needs of the content consumers. This approach can be captured in an editorial styleguide providing guidelines and examples that will help others craft content and messages in a similar voice.

To make content more useful to machines, we structure it and define standard elements so that the content can be used and reused dynamically. We write taxonomies and add metadata so that the content can be identified more easily. We create relationships between content so that it has more context and can support a variety of complex functions.

To make content more efficient to produce, we evaluate and recommend solutions for creating, enhancing, organizing, and using content, including content management systems, metadata tools, search engines, and faceted navigation applications. We establish business rules and workflows that will optimize the use of these tools and systems.

To make content comprehensive, we determine content requirements for a site, inventory existing content, identify gaps, evaluate possible sources for additional material, and manage the process of getting that content into production. Given the right background or source material, we can write labels, overviews, or even longer content if needed.

And don’t be surprised if, in the course of doing these tasks and creating these deliverables, those old philosophical questions pop up again to complicate seemingly straightforward issues. Here’s another brain teaser for you: “What distinguishable qualities indicate that some content items will be as relevant in three months as they are today, while other content will be out-of-date in a few hours?” (Hint: There’s no single correct answer.)

Strategies for working with content strategy

If you are a content strategist,

  • Start asking yourself and your colleagues the difficult questions about content (e.g., “What is content?”, “What would make it more meaningful?”).
  • Open dialogs about how to generate more meaning in your content and how to determine how much is enough. Develop models for cost/benefit analysis.
  • Look at different content models and determine appropriate uses.
  • Explore some of the emerging tools that can help reduce the burden of content production. Invent new uses and requirements for these tools and tell the developers so that they can make them better.

If you work with content strategists,

  • Find time to philosophize with them about content. Have patience with discussions of issues that may not seem like they’re leading directly to solutions–sometimes this perspective is needed to come up with the ideal content approach.
  • Involve them in the project as soon as you start analyzing what the site is going to be. Don’t wait until the site is structured and designed and you realize that you need some content to fill the pages.

If you don’t work with content strategists, but you think you would like to,

  • Demonstrate to your organization how this kind of role could save time and effort, help avoid problems, and make your end product better. After the conclusion of any project, you can probably come up with many examples of “If we had only realized this before…” Base your case on the content-related examples and you’re halfway there.
  • If that doesn’t work, figure out who in your organization is most interested in the theory of content, encourage them to get metaphysical about it, and then bring them back down to Earth so you can get to work on the practical stuff.

Content strategy may not be fully defined or widely understood, but that shouldn’t stop you from doing it. Make time in your projects to deeply consider the content requirements, and the content philosophers in your ranks will rise to the occasion.

Better Content Management through Information Architecture

Written by: Masood Nasser
“To implement a successful content management system, we have to go beyond business process and technology and understand how the organization, as an organism, interacts with and uses its content.”

Everyone understands the business case for Content Management: Organizations drowning in information can’t learn from, act on, or leverage knowledge and resources trapped in assets that already exist. You lose the content’s value if you can’t find it to use it.

To solve problems like these, business often purchases a technology, assuming the former is a feature of the latter. In the content management world, we hear the same kinds of promises from IT stakeholders, again and again:

  • Our developers will provide forms that authors will use to update content online (and every one will live happily ever after).
  • We will use XML (and every one will live happily ever after).
  • We will buy This software from That vendor—off the shelf—and authors will use this to update content. We will customize These options to match our requirements. (And every one will live happily ever after.)

Unfortunately, business often confuses technology for the solution. Forms, XML, and software won’t manage your content. Neither will they help authors create content, nor do they help you leverage content for later use. When Content Management Systems go wrong – and they frequently do – you can end up with terrible nightmare scenarios:

  • Authors write content, and try unsuccessfully to use theCMS.
  • IT updates content in relevant format and uploads for authors to review. The authors make power point presentations with changes and mail them to IT.
  • IT reviews the PowerPoints and uploads the changes.
  • Authors approve the changes, and IT uploads the final version to the site.

To prevent these kinds of scenarios, we try to customize off-the-shelf systems or develop our own, but… IT and business, focused on issues with technology and business process neglect the system-wide ecology that governs how those technologies and processes will be used.

Four crucial factors govern the success of your content management system

Four crucial factors that govern successful CMSs
To implement a successful content management system, we have to go beyond business process and technology and understand how the organization, as an organism, interacts with and uses its content. Four factors are crucial to ensuring an organization can successfully manage its content:

  • Who will interact with the system? Who will create and manage the content? Also, who will need to find and use the content later?
  • What are we managing? What is mission-critical? What kinds of data do we need to manage?
  • How is the system managed? How is the content authored, approved, and managed? How does theCMS enable your business processes?
  • How is the content used? Who will use it, when, and why? How does this integrate with your Information Architecture?

Framing content management in this way helps move the discussion away from business processes and technology. Several familiar methods and tools can help organizations answer these questions and understand how content is created and managed into the system, as well as found and used out of the system.

Who uses your CMS? Authors, approvers, and users (oh my!)

One of the first steps in implementing a CMS should be to identify theCMS users: who will author and publish content? Gather data through user research and modeling.

Scenarios can reveal how the system will really be used, and personas can help business and IT better understand the goals, skill-sets, and motivations that directly impact how successfully the content management system will be used.

The following questions can be useful during user research:

  • What tools are used to author content? At one large research University, instead of composing content using the CMS’s forms, instructors copied and pasted existing content from old syllabi written in Word.
  • How is content authored? At a financial services consultancy, all content was painstakingly crafted by copywriters. In one city council campaign, content appeared as bullet points in emails (or on a whiteboard) that were translated and uploaded by (seemingly) random volunteers.
  • Do the authors and managers understand and use the information architecture? At a large development bank, authors rarely categorized content because they didn’t understand the interface (or its importance). Figure 1 shows a typical content administration screen. Do content authors and managers understand and use the interface?

cms_categories_edit.gif
Figure 1: A typical content administration interface.

Understanding how people use the content is equally important.

  • Who uses the content? In that city council campaign, the website was written for potential voters, but it was mostly used by reporters and precinct captains.
  • How do they use the content? At a large government agency, the system stored versions to help in production of final documents, but writers used stored versions to find examples to copy and paste from.
  • When do they use the content? One music publication published reviews of new releases as a stream of new content, but access was most common for users researching albums long-after they had come out.

    In addition to helping you better understand your users, personas and scenarios can help you test and validate how the effectiveness of theCMS

What are we managing? Handling mission critical content.

What data really needs to be handled by a CMS? In a utopian situation, the database can manage any type of data or content. In reality, it does not work that way. Content management systems usually do not handle all types of data effectively, so you must prioritize critical data and workflows.

  • Where does the content come from? Is it created in-house? Does it arrive in feeds from outside providers? At a large entertainment website, most content came from licensed feeds from outside providers, but in important cases, content was created by onsite editors.
  • What formats do you need to manage? Large enterprises typically manage office documents created, like Word or WordPerfect files. Do you need to manage multi-media files? PDFs? Flash? Implementing search or a decent taxonomy for these formats is a different ball game altogether, and many content management systems simply do not have the ability to manage them efficiently.
  • How often does the content need to be managed? It often does not make financial sense to manage content that is updated on an infrequent basis. Content management systems typically do not have the ability to present brand vehicles – like annual reports – in formats that are aesthetically pleasing and reflect the company’s branding. That job is best left to your creative and marketing team.
  • What content is most important? Critical tasks deserve special attention. Regardless of how frequently critical content tasks must be completed, their importance may require the system allow you to manage their content quickly and flawlessly.

Along those same lines, it may be better to handle a few types of content well, than to handle all types badly.

A broad inventory that lists types of content, sources, and formats can help you understand the potential scope of content you need to manage. Rating the importance of each type of content can help you prioritize what the system must handle, as opposed to what would be nice.

In the example above, handling annual reports might be nice, but managing product descriptions may be imperative.

Along the same lines, task analysis of both common and critical tasks at your organization can further illuminate types of content to focus on.

Conclusion

To implement content management system that really works, business and IT must think beyond internal processes and technology. If your organization keeps in mind the users who will interact with the content as well as the range of types of content, then your CMS is much more likely to succeed.

However, users and content are only the inputs that go into your CMS. Understanding the content lifecycle is the final missing piece. In part two of this series, I’ll examine additional design methods that can help illuminate the early content lifecycle—how the content is managed—as well as the content’s end lifecycle when it finally lands in the hands of end-users.