How an Information Architect & Content Strategist Co-Conquered a Rapid Redesign

Originally published at www.eightshapes.com on September 18, 2011.

I recently participated in a project that offered a good opportunity to partner with a content strategist. Though I’ve been in the business for more than a decade, this was my first content-rich design project after becoming more involved with content strategy.

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.