What Are We Saying?! Reviewing Content in Context

We all know the standard model for developing sites—and content: take a brief, consider possible solutions (you can call this “ideation” if you like), mock them up (layout, design, copy), test, refine, test, build. Along the way, there are points at which our stakeholders—clients, or our boss or CEO—will approve things, which helps us ensure everything’s on track and everyone’s still clear about the project’s goals.

And we all know what happens when things go wrong: chaos, confused communication, and a failure to achieve the project’s goals to their potential, if at all.

No-one (that I know, anyway), would argue with this general approach as a solid way to get the process of site or page creation done.

The real world

The standard model assumes that everyone can get onto the same page to begin with, and then, that they can stay there. But sometimes, it’s only through the creative process that clients or bosses can get clear about what they want for their brand.

This can be frustrating, but it’s a fact of life. Ideally, you’d have the time and influence to get everyone to agree on the brief up-front, but sometimes it just doesn’t happen.

Recently, a client told me they wanted to reposition their business as more approachable. “We’re open!” they said. “We want to show our human side!” And a key aspect of the website redevelopment brief was to provide clear contact channels for customers to get in touch with the organisation. So the client happily agreed to a Who’s who? section on their Contact page, knowing that customers were frequently confused as to who did what, and who they could speak to about specific issues.

But when we presented the mockups to the CEO, he crossed out the individuals’ contact details: all that was left was each person’s picture, their name, and their formal title. Not much of a “contact” page, right? So much for being open and approachable!

Digging deeper

This piece of feedback was just one of many that, taken together, revealed that the clients’ lofty user-centric goals were not at all aligned with their operational capabilities, or their marketing desires.

All these elements had been flagged in the brief, but it was only through the process of working out how to communicate them that the client was finally forced to recognize how they fit together for the organisation itself. At of course, it was only once they were clear that we could be clear.

As an example, when we asked if we should just remove the “Who’s who?” section entirely, since it no longer served the purpose for which it had been developed, the client balked. They liked it because it made them look human and approachable. The fact that it was pretty much a waste of space as far as users were concerned wasn’t important. This piece of content was about looking approachable, not being approachable.

This is one of those clear cases where marketing goals clash with user goals. The solution? We dissected the content and looked at it in context.

Content in context

Each piece of content on a website needs to serve a purpose, and if that’s not a user-centric purpose, we’re wasting our time.

There was no point listing people on the contact page if the business didn’t want those people to be contacted. But the client was determined to keep that information on the site. The context was key, and on review, we decided that an About page would provide a better context for the denuded “Who’s who?” listing.

For the UX team, letting go of our understanding of this piece of content so we could “repurpose” it was necessary to address both user and client needs.

“But wait!” you cry. “How does that meet user needs? They still can’t contact anyone!” Repurposing this content as “About” rather than “Contact” removed the potential for frustration that users may feel if they found people’s names, but not their contact details, on the Contact page. But we needed to do more work to make the brand as practically “approachable” as the CEO wanted it to be.

One way we did that was by taking the contact form and putting it into the sidebar of every page of the site. A key goal of the project was to make contact channels accessible, and this was the client’s preferred channel.

But this work did more than just solve the immediate client/user goals conflict. By revisiting the context of each piece of content we’d planned in light of the client’s feedback, and refining the links between that content and client/user goals, we made each page of the site tell a more coherent story.

The service pages’ messaging shifted from “here’s what we do” to “here’s what we do, tell us about you.” The About page also told a clearer story for users: it identified the organisation’s purpose or mission and, through those profile shots, tied that work to actual humans. Effectively, it now says, “These people will get you there.”

Through this feedback process, and by looking at the context of the content the client wanted, we were able to better meet those communication goals of transparency and humanity by improving the user experience.

Many paths, one destination

It’s never ideal to be identifying client goals on the fly. But some clients are literally incapable of understanding their deeper motivations until they see something. And we need to be able to balance their and their users’ needs in that case just as well as when we’re using the standard model.

One way to do that is to look at the content or functionality the client’s providing feedback on, and understand if and how it can be used in a context and format that’s acceptable to the client and successfully addresses user goals. Do that well, and instead of seeing client and user goals as conflicting, you can use their commonalities to draw them closer together than you might ever have expected.

What do you think? How do you tackle those times when, halfway through a project, you find that the client’s deeper needs seem to disagree with those of their users? Tell us in the comments.

Win an Annual Membership to Learnable,

SitePoint's Learning Platform

  • OgbaOghene

    Really great article, it really underscores the importance of actually listening to project stakeholders while keeping user goals and needs in perspective.