Future-Ready Content

The future is flexible, and we’re bending with it. From responsive web design to futurefriend.ly thinking, we’re moving quickly toward a web that’s more fluid, less fixed, and more easily accessed on a multitude of devices.

As we embrace this shift, we need to relinquish control of our content as well, setting it free from the boundaries of a traditional webpage to flow as needed through varied displays and contexts. In the words of futurefriend.ly’s Brad Frost, “get your content ready to go anywhere because it’s going to go everywhere.”

But don’t unlock the shackles just yet: our content is far from future-ready. When extracted from the carefully designed pages on which it lives today, most web content turns into undifferentiated text, its meaning lost as it spills into any container you give it.

We can do better. Rather than accept these “content blobs,” as Karen McGrane calls them, we can embrace meaningful, modular chunks that are ready to travel.

This is a content strategy problem, true. But listen up, designers, developers, and UXers: you’re not excused just yet. This job takes editorial, architectural, and technical knowledge.

This is a project for all of us.

Preparing for structure

Most conversations about structured content dive headfirst into the technical bits: XML, DITA, microdata, RDF. But structure isn’t just about metadata and markup; it’s what that metadata and markup mean. Before we start throwing around fancy acronyms, we need to get closer to the content itself, creating a framework for making smart decisions about its structure. Only then can we tackle technology in meaningful, useful ways. So hang on—this part’s important.

1. Get purposeful

You’re already designing sites with both user and organizational goals in mind, right? Great. Now you need to translate those goals to a smaller scale, applying them to each type of content you have—like blog posts, articles, rotating features, or product descriptions. To do this, you’ll need to be able to answer questions like:

• How does this kind of content support the overall site goals?
• Why would a user want it?
• What is the organization accomplishing by publishing it?
• What does the organization want the user to do with it?

Just as it’s critical to establish site goals before launching into design decisions, you have to know what each type of content is intended to accomplish before you can make decisions about how you need to treat it in different contexts. Otherwise, how can you ensure that content keeps doing its job as it flexes and twists to meet the needs of each device it’s displayed on?

(Now, if you realize your content isn’t accomplishing anything, or you don’t know what kinds of content you’re dealing with, you’ve got a bigger problem on your hands. Before getting friendly with the future, go cozy up to your client or boss and figure out what matters.)

2. Get micro

All right, you know why the articles or recipes or limericks or whatever kinds of content you’re dealing with exist. Good, because now it’s time to get even more granular, breaking these content types down into their core elements.

The specific elements you’ll need to consider will vary greatly depending on the type of content you’re working with, so start by identifying all the content chunks you can find in a given type of information. These could be things like titles, teasers, body content, ingredient lists, reviews, pull quotes, excerpts, images, videos, captions, related articles, bylines, directions, addresses, and many more.

Take a recipe for asparagus, fingerling potato, and goat cheese pizza from the popular site Epicurious, for example.

Recipes are a pretty common type of content, so you may think you’ve got this one figured out already: title, ingredients, directions. But look again, and you’ll see a whole universe of interconnected elements contributing to this single piece of content:

• Title
• Publication Attribution
• Publication Date
• Byline
• Yield
• Teaser Description
• Image
• Ingredients
• Preparation
• Wine Pairings
• Ratings
• Reviews
• Main Ingredients
• Cuisine Type
• Dietary Considerations
• Related Recipe Collections

An information architect or content strategist sure comes in handy in determining these attributes, but everyone on the team needs to be fully engaged—because you’ll need these chunks to make major decisions about how content will respond to changes in device and display.

3. Get meaningful

Understanding which content chunks exist is just the start. Now you need to understand why each one matters to the whole—and how much it matters. This allows us to make decisions about how content is organized, prioritized, and displayed for different screen sizes, contexts, or purposes.

You can begin to do this by considering:

• How does this element contribute to the content’s purpose?
• What meaning is lost if this element goes away?
• What relationships exist between this element and the others?

If this were my project, I’d do some hefty research into organizational goals, current content use patterns, and user needs well before getting here. But, for example’s sake, we’ll work with assumptions. Since Epicurious is a publisher, let’s assume it wants to increase page views to bump advertising revenue. Since it’s a recipe site, let’s assume users are there to find something suitable to cook.

This scenario could translate to a content-level goal like, “recipes should be compelling, specific, and connected—so users want to make them, can easily tell whether they meet their needs, and ultimately want to visit additional Epicurious content.”

As you hold that goal up against these content elements, some interesting questions emerge:

• Removing all those related items may seem like an easy way to reduce clutter for small screen sizes, but will that decrease the number of total pages a user visits?
• If we make sidebar content push below main content as the screen size narrows, will users be frustrated at wading through ingredients to get to the recipe’s rating?
• What would happen to users’ interest in the recipe if we removed the image?
• Does a title, if displayed elsewhere without its teaser description, tell the user enough to be meaningful?

These are difficult questions to answer. Wine pairings may be extremely compelling for the aspiring sommelier, and entirely unappealing for a teetotaler. Ingredients may be a critical first stop for someone with food allergies, but secondary to someone without.

We may never be able to anticipate each user’s personal preferences, but the more we understand the relationships between information, the more the compromises inherent in any design decision will be clear—and the better prepared we are to make tough calls.

For example, in many responsive designs, sidebars are immediately pushed beneath main content for smartphone-sized displays. But is this always the right answer? Here, ratings, reviews, and main ingredients give readers an at-a-glance means to evaluate the recipe, and pushing this information below the ingredient and preparation sections could make them all but useless.

That’s the thing about adapting content to varied layouts: each case is different. One-size-fits-all rules about how content should react are unlikely to serve your many content types—which means they won’t serve your users’ needs or your business goals either. And as more devices and technologies emerge, you’ll need to develop new rules and make new compromises as well.

Good thing is, we don’t need a crystal ball to start taking action. We can begin today simply by improving the ways our content is stored.

4. Get organized

The future is sexy; content management systems are not. And yet, your CMS may well be what’s standing between your carefully considered content and its ability to travel. Think about the elements we’ve identified and the relationships and priorities that define them. Are the CMSes you’ve worked with ready for this level of content? If so, you’re in the minority. The rest of us have some work to do.

One organization that’s taken great strides to future-ready its CMS is National Public Radio. Back in 2009, NPR launched a methodology it calls Create Once, Publish Everywhere. With COPE, each story is entered into a set of discrete fields within the CMS, then made available via an API to multiple platforms—such as the NPR website, device-specific applications for iPad and iPhone, the NPR music site, and local NPR affiliate stations’ sites.

NPR’s CMS supports a variety of content elements, but only four are required: a title, short slug, longer description, and date line, says Zach Brand, the head of technology for NPR’s digital media. Additional attributes—like images, audio, or bylines—are all optional. Once in the CMS, the story is distributed via API and ultimately published using various combinations of elements determined by the needs of the platform on which it’s being published.

If we want systems that can handle this kind of modular, fast-moving content, it’s time we get cozier with our CMSes—and the people who develop, integrate, and customize them. Armed with knowledge from your in-depth analysis, you now have the tools to embrace a strategic approach to content management, which will help you to:

• Ensure those focused on CMS features and capabilities understand your content and what it’s intended to accomplish.
• Explain the types of content you’ll need and what elements they require, much like NPR has defined the attributes of its stories.
• Understand your CMS’s possibilities and limitations, and collaborate on how to deal with them.
• Ease your technical team’s burden by providing them with thoughtful, specific direction to inform the CMS’s requirements.

This groundwork will serve you well even if you’re just managing a basic website, but as you begin to share content across more devices and channels, it becomes critical. With a CMS that’s organized around modular, meaningful chunks of content, you’ll be ready to create rules for how that content should bend and shift—and have the systems in place to actually implement them.

5. Get structured

There’s a reason this article didn’t begin with a primer on XML. Technology can’t help you make good decisions; it can only help you implement them. But content elements must eventually become code, so even if writing markup isn’t your job, we could all stand to get more comfortable with the tools out there to do it.

Structured content isn’t new. Technical communicators have been pushing DITA (Darwin Information Typing Architecture) for years—and there’s nothing particularly futuristic about it. Based on XML, a markup language that gives content components an inherent meaning when displayed beyond their database, DITA authors and publishes technical information in content modules—small pieces of information designed for reuse and categorized according to topic. [1] Designed by IBM to manage the company’s own technical content, it’s most widely used for things like help documentation.

Many technical communicators insist DITA should be the web’s standard structuring approach, but it’s never quite caught on. It’s also not the only way to do it. HTML5 now supports semantic markup through its microdata extension, which goes beyond traditional presentational tags and allows you to mark up content with standards-compliant, semantically rich HTML. [2] Of course, HTML5 itself is still a working draft, and it’s unclear whether microdata will gain widespread use—or offer enough specificity to suit our content. For example, late last year, the “time” element was removed in favor of the more generic “data.”

There’s also Schema.org, a microdata-based approach launched in 2010 by Bing, Google, and Yahoo!. Designed to create a common language across search engines, Schema.org arranges microdata into taxonomies of content types that start broadly and branch into ever-more-specific elements. Critics, however, point out that Schema.org is a closed system: the search engines tell us which structures matter, rather than allowing content owners to define them.

Many people are passionate about which of these approaches is best, and why everyone else is doing it wrong. I’m not one of them. Fact is, we may be a long way from a definitive markup method, and none of these currently supports all kinds of content, anyway. Use the one that makes the most sense for your project right now—and in fact, that could mean not even worrying about markup yet.

Giving life to structure

What matters much more than markup is the work we put in to get there: the rules and relationships determined through analyzing content closely and caring for its message and purpose. After all, “semantic” connotes meaning—typically, the meaning of language. Whatever markup language you use, it’s not semantic unless it pushes meaning forward—which is why you can’t start with markup; you end with it.

This, I think, is why structured content has often been written off as too technical and utilitarian for the mainstream web crowd: because we’ve left the editorial side, the experiential side—the part that lends content life—out of these conversations.

This needs to stop. Future-ready content isn’t about becoming an XML expert or assuming microdata will solve your problems. It’s about seeing structures through the lens of meaning and storytelling, and building relationships across disciplines so that our databases reflect this richness and complexity.

We don’t have all the answers, but we do have a clear place to start: with our content itself. As we break our content down, analyze its elements, and document the relationships that turn those elements into a meaningful whole, we can begin to create and manage content in a way that endures, wherever the future leads us.

Technology will change. Standards will evolve. But the need for understanding our content—its purpose, meaning, structure, relationships, and value—will remain. When we can embrace this thinking, we will unshackle our content—confident it will live on, heart intact, as it travels into the great future unknown.

Audiences, Outcomes, and Determining User Needs

Every website needs an audience. And every audience needs a goal. Advocating for end-user needs is the very foundation of the user experience disciplines. We make websites for real people. Those real people are able to do real things. Everyone is happy.

But, it’s not really that easy, is it?

The issue, of course, is that we cannot advocate for those whom we do not know—or, even worse, those whom we assume we know. So we go to the source: we interview, we learn, and we determine who, exactly, these mystery users are. In doing so, we answer the two most important questions of the discovery stage: who are our audiences, and what do they want from our website?

Then—and only then—can we begin the process toward better content.

Defining the process

End users are a funny thing. They begin as amorphous blobs of assumed stereotypes. As we learn more about them, they become more refined. They develop characteristics and quirks. The more we learn about the end user, the closer we get to a sort of Pinocchio scenario: they become Real Users!

The process of creating Real Users is what we at Blend call our Audiences and Outcomes process. It happens before any other part of the project, and is based on C. David Gammel’s book Online and On Mission, in which Gammel pushes the need to identify and prioritize audiences before you develop any strategy.

In this case, Gammel defines an audience as:

Any group of people with some measurable characteristic in common which influences how relevant and significant they are to your specific outcomes.

Likewise, Gammel defines an outcome as:

A measurable change, action or behavior that you wish a visitor to take or experience.

In other words, just stating a goal is not enough. Outcomes must be measurable, otherwise they’re not goals—they’re aspirations. Without considering how an outcome will be measured, we cannot accurately represent the benefits—or the viability—of a user outcome.

Finally, we use audiences and outcomes to create user personas. We use these personas until the project is complete. Because we can’t run every decision past a field of actual end users, we rely on personas to do the work for us. They become our friends. We refer to them by name in meetings. It would all be very weird, if it wasn’t so necessary.

If you’re confused about how this differs from your standard discovery meeting, with people meeting in a room and answering questions and all of that, the answer is: it doesn’t. Not really. You may already do something like this without being so deliberate, or you may define audiences and outcomes elsewhere in your process.

That’s cool. We’ve found that tackling audiences and outcomes at the very beginning makes our content inventory more relevant (by allowing us to pair pages with audiences) and saves a step in our qualitative audit (by giving us context for content needs).

What’s more, it clarifies our goals from day one. This clarification is important. For example, if we’re building a site to sell mail-order diapers, we can’t just say, “We’re building a diaper delivery site, and mothers will come to the site to buy diapers, and so let’s start writing copy.” I’m not a mother. And if I was, I’m certainly not EVERY mother. I know damn well that fathers and other caregivers will come to the site, too. So if I move forward with the diaper-buying mother stereotype in mind, I’m doing a disservice to a giant percentage of the site’s users.

We are not the audience. We can only assume what our user thinks. Which is where the audiences and outcomes process comes into play, allowing us to narrow down who the user REALLY is through stakeholder input, persona development, and persona confirmation.

Buy-in: everyone wants to play

These proxies serve an added purpose: they help us get buy-in and help us back up assumptions. Erin Kissane sums it up perfectly in The Elements of Content Strategy, when she says:

The personas or other user proxies that you or your colleagues have created are the best backup you could hope for. Return to those tools when you need to validate opinions—yours or someone else’s.

By pulling stakeholders into a room and getting them to talk about their product, their audiences, their issues, etc., we’re giving them a way to buy in. No longer is this a consultant-driven process—it’s a company-driven process, where the consultant serves more as facilitator than dictator. As I’ve mentioned before, we don’t have all of the answers, and we do our clients a disservice by assuming we do.

When stakeholders get involved early, they are less likely to hold things in. They’re also less likely to object to changes in their content or process because, after all, we’ve all agreed on our audiences.

So, how do we do it?

The audiences and outcomes process

Let’s assume that within your methodology, you define audiences and outcomes at the very beginning of a project. It’s how we throw a project into context. It gives us a high-end view of who we’re dealing with and provides background for the qualitative content audit. It’s a “getting to know you” period of two or three weeks, broken into three steps:

• Step 1: The discovery meeting
• Step 2: User interviews
• Step 3: Project deliverables: audiences, outcomes, and personas

The discovery meeting

There’s one goal: to get this group talking. Invite a small number of people—five to seven—and make sure someone from the front line is there. Ask them to let go of preconceptions. If an executive is present, make sure they don’t take over the conversation.



From your side, make sure you have two people. One will lead discussion, the other will document the discussion and provide an extra brain to ask and answer questions.

The meeting should be an open forum for discussing the website’s needs and goals. Schedule no more than an hour, but don’t be surprised if it goes a little longer. Begin the meeting by introducing everyone, introducing the process, and explaining how it fits into the overall site plan.

Bring big markers and whiteboards and anything to get ideas up in front of the group. Then, make two huge spaces for the following headers: Audiences – Outcomes.

Then it’s time to start asking questions.

The questions

These are the questions that we use at Blend to define audiences and outcomes. They aren’t law. In fact, we’ve never made it all the way through this list. (Note: you’ve probably seen some of these questions asked elsewhere. Of course you have—we created this list, like any good list, by stealing and adapting ideas for our own use.)

Audiences

• Who do you feel are your site’s audiences?
• What are the demographics of these audiences?
• How comfortable with technology is this audience?
• Who is currently visiting the site? What makes their visit a success in their eyes? In yours?
• Who else is competing for their attention?

Outcomes

• What do you want to persuade your audience to do?
• What assumptions do you make concerning your audiences? Example: do you assume your audience is of a certain socioeconomic group, or that they are familiar with certain aspects of your organization?
• What drives your business, and how does your audience help achieve positive results?
• What metrics do you want to keep track of?

Company voice

• What is your company’s ultimate mission? (Not a mission statement, but a more organic, real-world one-sentence answer to “Why do you do what you do?”)
• What message do you need to get across?
• What is the company’s voice and personality?
• What has worked in the past? What hasn’t worked in the past? What were the stumbling blocks?
• What attributes does your company have that helps to gather attention—i.e., “Our company is nationally known,” “Our company employs former movie stars,” “Our company is well respected in the field.”
• What topics can we take advantage of? Example: if you are an automobile manufacturer, are there government rebates we can promote?
• What topics are off limits?

Methods

• How do you currently communicate with your audiences? How often? (Related: can we have copies of your past materials?)
• Who creates the content?
• How does your audience prefer to communicate with you?
• What other functionality will you need?

Content management

• What is the current content workflow?
• Who currently creates content?
  • Who will write it in the future?
  • Who approves content?
  • What stumbling blocks are in place that make it difficult for the content to get published?
• Who in the company connects with customers most naturally?

As you push your way through a group’s initial fear of discussion, new questions will flow naturally. The specific questions aren’t necessary, as long as you remember to:

1. Ask the client who their audiences are and what those audiences want.
2. Listen for clues that expose secondary audiences.
3. Dive into those clues. Make them work. Ask follow-up questions. Get people talking.

To create an extremely basic example, imagine we’re doing a meeting with a fictional airline: On-Time Air. After a very general discussion, we’ve got this written on the whiteboard:

Audiences:

• Passengers
• Airports

Outcomes:

• Find accurate flight information
• Book a flight easily
• Learn about baggage fees
• Locate gates and flight times

Digging into the audiences, we ask what else passengers look for. One person mentions that, yesterday, someone asked for a chart depicting the airline’s on-time percentage. This may not be a high-level outcome, but it reminds us that when something newsworthy occurs, the press may look for information on the airline. When a potentially damaging article is about to come out, it’s the airline’s policy to let its employees know ahead of time. What about new employees? What about future employees? How do they apply?

As you can see, this line of thinking led us to three new audiences (the press; new and future airline employees) and three new outcomes (finding company news and information, looking for explanations on the airline’s problems, and locating job applications).

What’s more, we can start to see sub-audiences: employees could be separated by type (pilots, front-line staff at airport desks, those who take phone reservations) or by status (new, potential, veteran). What about the separation between a current passenger—those who have tickets, and a potential passenger—those looking for tickets? Some audiences will share outcomes. Both a pilot and a current passenger may be looking for related or identical information.

NOTE: You’ll notice that those last groups of questions aren’t really audience/outcome related. That’s okay. We’re opening up here, and your stakeholders will be in the mood to talk. This gives us a chance to grab a little extracurricular research. Taking Tiffani Jones Brown’s Making Things Hard post a step further, we’re making things easier by asking hard questions at a time when the client is more receptive to those questions.

User interviews

The initial strategy meeting is designed to help determine whom the site is for and the goals that need to be addressed; in other words, the meeting shapes the audiences for the site, as well as the desired outcomes related to each audience. The next step is to talk to actual site users to determine whether these audiences and outcomes are accurate.

This happens early in the process for a reason: we need to know who the user is, and we want to use their opinions throughout the project. So we ask our clients for a list of contacts, and we talk to past customers. Or, we solicit opinions from a related industry group. Regardless, we ask questions.

For example, if we’re talking to an audience of building managers, we could ask:


• How do you secure funding for a project?
• How many companies are you required to look at during a bid?
• Who provides post-build service for a project?

But we could also ask questions that help gauge an audience’s personal and technological habits:

• What kind of mobile phone do you use?
• Where do you live and how large is your organization?
• How often are you on the internet for non-work purposes?

Then, we compare their needs and perceived outcomes with the ones our client mentioned. If they match, then awesome. If not, even more awesome: time to bring it back to the client and say “This is what people want.” We’re already learning, people!

Project deliverables

Whether we like it or not, a huge part of content strategy is delivering documents, and the audiences and outcomes process is no different.

First, prioritize each audience and assign numbers to each user outcome. Because every audience could make a case for being the most important, it’s up to you and your client to determine which audiences are really the most important. Not only does this provide a handy cheat-sheet for solving design hierarchy problems (think: should our home page focus on existing members or new members) it also helps you determine which personas will get more space at the theoretical persona table.

(Not to mention: these numbers will come in handy during content auditing, where you can match content with goals. Saying, “Outcome 3.2a” is a lot shorter and easier than typing out the entire outcome.)

You might need to split some audiences into more manageable categories. These “sub-audiences” share the same overall goals as the parent audience, but feature some additional needs and goals.

For example: A physician’s website may have three major audiences—referring physicians, patients, and staff. Patients could be further split into three categories: new patients, current patients, and family members of patients—all three will have the same overall goals as the patient audience, but with additional goals dependent upon further classification.

Giving the document structure

In the beginning, the structure of the audiences and outcomes document might look like this:

1. Introduction
2. Summary of findings, including user interview findings
3. Audiences and outcomes (example below)

Audience 1: Customers

Customers are those who are either thinking about purchasing an airline ticket or who have already purchased an airline ticket. They are the main source of income for the airline, and represent the airline’s most important audience.

We can split customers into two distinct sub-audiences: potential customers and current customers.

Sub-Audience 1.a: Potential Customers

Potential customers are those who have yet to purchase a ticket. They’re visiting the site because they’re interested in traveling, and may be researching either current ticket prices, flight schedules or both. Their mindset depends on context—they could be voluntarily researching a trip for leisure, or they could be locked into a trip and simply need the cheapest or best flight.

• 1a.1 – Find and compare flights by price, date, and flight details.
• 1a.2 – Purchase desired flights with little resistance.
• 1a.3 – Locate and understand flight rules—check-in time, weight restrictions, etc.

Sub-Audience 1.b: Current Customers

Current customers are those who have already paid for their ticket. For the most part, they are no longer comparing prices—they’re on the site to confirm existing flight information or make changes. Research at this point has shifted from discovery to confirmation.

• 1b.1 – Access flight and ticket information.
  • 1b.2 – Contact On-Time Air for flight changes or questions.
  • 1b.3 – Locate and understand flight rules—check-in time, weight restrictions, etc.

Notice that both potential and current customers share the outcome “Locate and understand flight needs.” This is common. Audience desires always overlap, though there can be differences in how we measure these outcomes.

Speaking of measurement…

Making things measurable

Because outcomes should be measurable, we need to bring analytics into the mix. Determining these metrics helps us understand what’s important to the site and, more importantly, how we determine whether a content plan is working as imagined.

We’ll take our original document framework and add these metrics to the desired outcomes. For example, for desired outcome 1b.1 above, you may say:

• 1b.1 – Access flight and ticket information.
  • Metric #1 – Lower page views per task.
  • Metric #2 – Fewer customer service calls for flight and ticket information.

You can see that there are two avenues to measure better access to flight and ticket information. One is to measure how many pages a user goes through before finally finding the information. The other is to track customer service calls to see if the number of calls for flight and ticket information decreases.

Much like the outcomes themselves presented some level of overlap, your metrics will overlap as well. Don’t worry. That’s normal.

Erik Peterson’s The Big Book of Key Performance Indicators is a good place to help determine which metrics to use for each outcome.

Project personas

With metrics in place, the next step is to create personas for the major audiences.

The persona process has been well documented by nearly everyone, it seems. At Blend, our three favorite resources are these:


• An Introduction to Personas and How to Create Them by Step Two Designs focuses primarily on intranet personas but is filled with helpful reminders for even the most seasoned persona creator.
• Context in Content Strategy: Personal Behavioral Context by Daniel Eizans will help you to develop context within each persona.
• The “personas” tag on User Interface Engineering’s site, is home to Jared Spool & Company’s research on personas.

The number of personas you create depends on the number of unique audiences you’ve determined. In the case of On-Time Air, let’s say we have six unique audiences, one of which is the 1.a: Potential Customer. We would then create a persona that represents a potential customer:

Martin Hunt

Age: 46
Occupation: Architect
Family: Married with one child (19)
Education: Architecture degree from St. Cloud State University

Habits: Martin uses the internet every day, but has never been a heavy user. He relies on aides for most of his online information and research, and spends a good chunk of time answering email, but outside of that he’s a novice. He has a Facebook account and has signed up for Twitter, but has never posted. He has a Blackberry.

Assumptions: Martin is wary of the unofficial nature of bargain travel sites like Kayak.com and Priceline.com. He prefers to order tickets directly from the airline. Because he lives in Minneapolis, he must often fly Delta, but he is increasingly interested in On-Time Air’s direct flights from Minneapolis to Orlando and Minneapolis to Las Vegas.

Martin doesn’t care about price if the difference between two airlines is close—he’s more concerned about how comfortable he’ll be on the flight. He values relationships, and assumes the airline best positioned to win his business will be the one that does the best job of selling a unique experience. At the same time, he has already racked up a considerable amount of airline miles with Delta.

“I would rather fly comfortable than fly cheap, but I won’t accept an exorbitant price.”

Naturally, the details will be different depending on the project. And remember: personas are made of real people. All that questioning and interviewing you did earlier in the process? That helps inform and define your personas. For now. Until you do more interviewing and your personas become stronger and more agile. Better cooks, even.

Look at the personas you’ve created. Do they accurately represent the outcomes you’ve determined? In writing them, have new outcomes turned up? Go back to the beginning and make sure everything levels out. Your audiences and outcomes determine your personas, and your personas should validate your audiences and outcomes.

You can do one of two things in terms of deliverables—you can add these to the Audiences and Outcomes document, or you can present them on their own. We feel that they are so closely tied to audiences and outcomes that we include them in that document.

Next steps

With your audiences and outcomes in place, you no longer have any excuse for not knowing what your project’s goals are. The document informs the content audit, where you can begin assigning relevancy to every page on an existing site. Every piece of content on the site should relate back to a specific outcome, and if not, it needs to be reviewed for relevance.

From there, the audiences and outcomes will help you choose participants for user interviews and user testing. Find a group willing to help you through the entire process, and you’ve got a valuable resource for not only testing prototypes, but also for performing card sorts, confirming IA tree testing, and serving as a de facto advisory board on the subject.

Finally, the audiences and outcomes help remind you what really matters in web design and development: the end user. We place an overview of a project’s audiences and outcomes at the beginning of every wireframe, style guide, and specifications document. Doing so gives us easy access to our user’s needs. After all—without the end user, we’d have no one to impress from here on out.