From Content Audit to Design Insight, by UX Mag, 3/20/2012

The project was a particularly good testbed since it was a small effort with clearly-defined scope. And after seeing so much chatter in the community about relationships between information architects and content strategists, I knew this project would let me experience it first-hand.

Project Background

The project entailed a rapid redesign of a content-centric web site. The design challenges were typical:

• Users didn’t understand the site structure or navigation mechanisms.
• Users couldn’t easily follow the existing content: it wasn’t scannable or chunked effectively.
• Content that users valued was either buried or missing completely.
• The site needed to be launched yesterday.

But while the design problems were straightforward, we had to answer the trickier “who’s doing what” questions before we could make progress.  The challenge was compounded since my colleague (the CS) and I (the IA) came from two different organizations and had never worked together.

Task Sharing FTW

Here’s what we did. First we identified all the required tasks and then decided who would “lead” them.  We communicated these responsibilities to the rest of the team, including the project manager and sponsor.  By starting with tasks, we ensured that the team was focused on activities and outcomes, not who was going to do it.  The resulting “wall of work” diminished any squabbling over individual ownership of specific things: there was a lot of work to go around.

Here’s a snapshot of the ‘assignment’ matrix we used:

After work started, we (the IA and CS) were highly collaborative–despite owning particular tasks–and often deferential to each other along the way.  If one of us had a useful insight, we always had an opportunity to share and see it integrated into the design. In short, we didn’t let our egos get in the way of getting the best product.

How you divide tasks on your project is up to you, but here’s how we did it:

IA took the lead, CS backed-up:

• Formulating and facilitating user research
• Clarifying platform capabilities and what could and couldn’t be done given functional limitations.
• Defining the information architecture & navigation model to use
• Defining the primary content types (eg, Article, Post, Course, Event)
• Laying out the content at the page level (after it was written) and all interface controls.

CS took the lead, IA backed-up:

• Stress-testing the information architecture based on actual content. (e.g. Can this structure work based on what we have and what we need?  Do we really need this page given the volume of content?)
• Mapping existing content to the new site structure.
• Identifying new content or content to be rewritten.
• Deciding on final navigation labels.
• Creating the call-to-action strategy.
• Writing the content (with consistent theme, tone, & voice).

Success Factors

In the end, the project released on-time and on-budget and with a very satisfied customer.  Obviously a big part of this was knowing what we needed to do and how to do it with the resources at the table. Task assignments aside, it was clear that a harmonious working relationship was more important than the team’s technical chops.

To that end, here are a few guidelines to help these roles work together effectively and fluidly:

1.  Define all of the tasks first, then assign task “leaders”.

Don’t attempt to define and assign tasks for IAs and CSs independently.  Instead, have at least one face-to-face planning session where you talk about all of the project’s tasks first, and then assign leadership. This may feel painful at first, but establishing the relationship and clearing out any uncertainties early on is healthy for the project and the ensuing collaboration.

2.  Make design decisions collaboratively.

Have as many “in the weeds” meetings as you can to discuss and decide on direction on both information architecture and content direction (instead of deferring solution and decisions to an individual after the meeting).  Work it out together right then and there.  Our navigation labels, call-to-action strategy, and info visualizations were several design decisions we arrived at collaboratively.

3. Loosen ‘role-based’ assignments in favor of individual competencies

Often a person’s role on a project is much less important than the knowledge that they bring from past experiences.  Acknowledging and tapping into these talents, insights, and experiences will elevate your conversations. Giving all the participants a voice in the design process results in healthy, productive teams and better products.

4. Check egos at the door.

Remember that even as you discuss task “ownership,” you’re all working toward the same goal.  And in the end, who does what is much less important than delivering a good product.  The minute it becomes about “what the [insert any IA/CS/UX book here] says you’re supposed to be doing” versus what the project demands, you’re off track.

Multi-disciplinary teams working collaboratively is quickly becoming the best only way to design good products.

Nearly 500 people converged on Minneapolis for Confab 2011, the first ever conference dedicated to Content Strategy. The good folks at Braintraffic put on a memorable event and did it with both substance and style. The diverse mix of attendees came thirsty for conversation and answers to questions like: What is Content Strategy? How do we do it? What do we deliver? How do we sell the value of our discipline? For you Information Architects out there, this should sound familiar.

I was excited to attend Confab. This excitement surprised my colleagues since I’m not a content strategist or a writer for that matter. I’m an Information Architect (or User Experience Designer, if you prefer). But I do recognize that changes are (always) afoot in our young profession. And the rise of new practices, techniques, and sometimes completely new disciplines is often a manifestation of that change.

Why Content Strategy? Why Now?

Content strategy is not new. Many of the practitioners have been doing this work for the better part of a decade. But in the keynote, Kristina Halvorson (founder of BrainTraffic and author of Content Strategy for the Web) asked the crowd rhetorically “why content strategy and why now?”. Her theory revolved around three ideas:

1. The rise in volume of content organizations need to manage
2. The proliferation of content distribution platforms (e.g. mobile), and
3. The professional web community’s struggle to figure out how to deal with the challenges this growth poses.

I agree with this, but also believe that the practitioners –often in the trenches of these challenges– have been thirsting for a community of practice for years.

On Content Strategy and User Experience Design

I came to the conference for a better understanding of how content strategy can help designers create better products and services. In other words, I wanted to learn how other people drew focus to content issues early on in the design process and so “avoid the 11th hour” sh*t stom” as Karen McGrane puts it. I’ve had my fair share of challenges with the chasm between design and content in many web projects, which is one of the primary ills that Content Strategy is anxious to solve. In fact, I wrote an article about it on Boxes and Arrows back in 2009 (see The Content Conundrum) and joked that it was my only claim to fame at Confab.

But what else did I learn? There were four themes:

1. The emphasis on cross-discipline collaboration.

Disney and Facebook spoke at Confab about their internal content strategy practices and the interaction they have with user experience design and development peers. In short, highly collaborative and engaged design teams is a no-brainer within these organizations. The speakers characterized it as virtually impossible to follow waterfall processes to create good user experiences since the practices are so inter-dependant. I agree. And while I (regretfully) didn’t attend Relly Annet Baker’s discussion (see: Love Thy Geeks: Working In and Amongst Web Teams), the backchannel revealed this to be a core theme in her talk as well.

Companies like Disney, Facebook, Apple (read: Apple’s Design Process), and many, many others are out there using just such a multi-disciplinary process. I think we’ve reached a tipping point. Multi-disciplinary teams working collaboratively is quickly becoming the best only way to create good products.

2. The importance of message & story

The three sessions that most stirred me spoke to message, story, experience and theme. Margot Bloomstein shared her thoughts on how to align stakeholders around the core messages they want to communicate through content and design (see: Message Matters). The client/stakeholder card sorting activity she demonstrated was a nice, creative use of a tool that Information Architects traditionally use to research user perceptions of structure. Margot opened my eyes to how organizations often need help aligning their own messaging. While I was left wanting more (how do we reconcile messaging with real customer needs? what are some tactical ways this plays out during a design process?) the session was a useful introduction.

Kim Goodwin’s talk (see: Storytelling by Design) dovetailed nicely with Margot’s. She spoke about the value of Design Scenarios as a way to move from a pure business approach to content to one focused on real user situations and needs from a product or service. This is a well-developed concept in the user experience design community, but questions from the audience implied that this was the first time many people in attendance had considered this approach.

Finally, Disney’s content strategy team spoke directly to the idea of marrying business imperatives with real user needs (see: Applying Disney Storytelling to Content Strategy). It’s no surprise that Disney is very methodical about creating stories and fantasy. What was surprising was how well they balanced that business imperative with real user needs. The result is a web product that sits squarely in the middle of the business goal / user goal spectrum and was evidence of the reality we all strive for.

It occurred to me that if we realize how to effectively marry the innate abilities that content strategists and writers have with telling stories and crafting message with the design and creative sensibilities of the IA/UX Designer, we could collectively get to a more holistic design concept faster.

3. The focus on results, not deliverables.

There were several moments during the conference when talk turned to the “deliverables” of Content Strategy. Many were cited but I did sense general discomfort and frustration among the community when talking about content strategy in these terms alone. The focus, they suggest, should be on the results and business value delivered from content strategy and not the “work products” being created in that process.

And while I agree, I do think that the rigorous discussion and debate on the deliverables of IA / UX helped the community wrestle with and rally around what it was we did everyday. And deliverables are still incredibly important, particularly as a mechanism to:

1. Create common understanding of a problem space
2. Crystallize and share abstract concepts and major decisions
3. Communicate progress toward a common goal

So the discussion about whether we need them or not is the wrong one to have. The key is to communicate and deliver whatever is necessary in the environment and culture you’re working in.

I think Sarah Marx Cancilla, Facebook’s first ever content strategist, demonstrated this idea quite well during her talk (see: Facebook Likes Content Strategy). In essence, Sarah arrived at Facebook with a large set of well defined tools, activities, and artifacts and was confident in her ability to put them to immediate use at Facebook. But she quickly realized that in a “Hacker culture” (an endearing term for what Facebook values and the overall culture in the organization) she had to toss much of that aside and figure out how to work effectively in that environment to deliver value quickly.

4. The overlap of design and content.

Finally, the last theme that emerged is that the challenges we face as content strategists are the same as those we face in design. While perhaps not stated explicitly, many speakers indicated that successful content strategy depends more on being at the table than employing a substantially different philosophy.

As I reflected on this theme, I realized that many of the things I think about design can also be said of content.

• Good [content][design] sits at the intersection of business value and customer need.
• Good [content][design] decisions are centered on real data (and insights drawn from that data).
• Good [content][design] tells a story and is user-centric.
• Good [content][design] is good business.
• You can’t create good user experiences if you separate [content] [design]from [content][design] and vice versa.

It’s no surprise then that I found myself at Confab. As I learned at the conference, ultimately content strategy and design share many common goals and challenges. It’s telling that many of the techniques, approaches we take to reach these goals and overcome the challenges are very much the same. The real test is how well we can collectively execute on a shared responsibility.

A Path from Design Vision to Reality

Part 1: Reiterate the problems

Design problems provide the source for all our projects. In fact, starting a new project requires our identifying and prioritizing those problems (for insights into how to do that, see my earlier post Discovery Wolves).  Between the kick-off and subsequent work, however, the articulation of project objectives gets lost. We sometimes forget to use these in the design review. Instead, we should use them to frame design recommendations and subsequent reviews.

What kinds of problems are there? As User Experience designers, our focus is the user, and addressing their needs. Those, however, are often coupled with business and/or content problems as well…

You can read the complete article at http://www.eightshapes.com/blog/2010/08/09/structuring-design-reviews-for-success/

As user experience designers, we understand the merits of engaging in a thorough, upfront review of the ‘space’ we’re designing for prior to putting pencil to paper.  In fact, we’ll insist on having time to deeply explore the business objectives, users, and environment we’re working in.  In recent years, however, we’re under pressure to prove the merits of an ambiguous discovery phase.  We are paid to design, after all.  With budgets tight, deadlines short, and expectations high, it’s easy to relate to client anxiety with ill-defined activities that end with deliverables that aren’t tangible and actionable.

Read the complete post at http://www.eightshapes.com/blog/2010/04/14/discovery-wolves/.

The funny thing was that the more I distanced myself from this ‘downstream’ process, the more problems that emerged when I’d stumble upon the design in test (or worse) production environments.  Now, I’m not suggesting that my lack of deep involvement getting the design actually built-out was the issue.  It was my lack of concern and assumption that my content partners just ‘knew what I knew’ about the design and they’d make it all work and fit together nicely.  That’s not always the case.  In fact, that knowledge gap is sometimes incredibly large.

The Content Conundrum explores the problem, why I believe it’s happening, and what we as a design community can do about it.  I hope you enjoy it.

Difficult Conversations in Creative Environments ~ IA Summit 2009