The A List Apart Blog Presents:

Content-First Design

Article Continues Below

A few years ago, I started getting into video games like Katamari, Animal Crossing, and Borderlands 2. Their designs are astounding; each feels like I’m having a natural conversation with the game, and each introduces content in the moment I needed it. As a result, the game experience feels so dang smart, and I feel like a hero whenever I play.

Here’s an example from the very first minute of Animal Crossing. All you’ve done is started a new game.

If you watch it, you’ll see the game designers make assumptions about you so they can collect innocuous personal information in a conversational way. When their assumptions are wrong, they respond in a humorous way. No harm, no foul. Yes, yes, yes.

So I started wondering how the video game industry has mastered this art of interactive storytelling so brilliantly. Who are the people on their teams? What are they called? How do they work?

I started reading up on the history of particular games in development, which kinds of themes show up in forum discussions, and checked out job descriptions that Nintendo, Bethesda Games, and Gearbox Software used.

I learned a few interesting things

Game designers start with the story. What they add to the experience complements and builds on the core story; it doesn’t distract from the priority of “accomplish goal,” even when that takes a year longer than expected, as was the case with Journey, Sony’s award-winning game from thatgamecompany. (Journey doesn’t even have a single word as part of the main game story line. Unreal.)

They design for discovery—learning in the moment not only increases retention and engagement, but it’s delightful and emotionally empowering.

I also learned of a unique role that’s part of their design process; it isn’t “copywriter.” It’s called narrative writer, game writer, or story designer.

These are content strategists, and they’re responsible for designing the conversation between player and game.

Content as the product experience is par for the course in the video game industry. And since 60 percent of people (average age 30) play video games—and it’s an $82 billion industry that just keeps expanding into every interface imaginable—it’s to be expected that our web and mobile experiences should feel more like conversations.

So I started practicing what the video game industry preached (and what the advertising industry leaders like George Lois preached before them): start with the word.

I immediately changed my process. I started writing content on day one of projects I was involved with. Those included a mobile utility, magazine, and personal projects. They also included the Annie E. Casey Foundation (AECF) and Ben & Jerry’s site redesigns with Happy Cog, and User Interface Engineering’s conference and webinar content.

AECF, for example, was redesigning its website, which included an enormous amount of content. More than 20 stakeholders from various internal teams had their own set of requirements and goals for the new website. So at the kickoff meeting, we facilitated discussions around how well the content seemed to be meeting audience expectations by asking those stakeholders, “What are the top questions your audiences ask? What are their top complaints?”

That focused early discussions on the communication gaps we could solve with content. We then looked at “top content” and “time on site” data to qualify which pages in the existing experience were drawing the most eyeballs and interest.

What we found was AECF’s research reports were highly sought-after, but the content in those reports wasn’t surfaced in a way audiences could easily find or understand. So we started there in week one of the project, rewriting the research report page using real content from them. After we did one, we asked, “How would someone get here?” and “Where would someone go next?” as a means of determining which content to write next. Doing this enough times, over and over, meant a natural structure (IA) emerged.

This shift of working content first (conversation design) instead of structure first (system design) is how we worked for several weeks, all in a Google Doc, before we ever moved to layout and design. This approach also ended up reverse-engineering the conversation of the website—from most-sought-after content up and out—until we got to the homepage. By then, we’d already written all the content for other pages, so designing the homepage was loads easier.

The artifact we continually used through this process is called a content workbook, and AECF so kindly lets me share it in its naked state.

Working in this content-first way made for the most joyful and collaborative design projects I’d been involved in since starting my web career 12 years ago. They were iterative earlier on, focused on getting real content before trying to structure it (because designing for real content is real), and ended up leading me to join Capital One.

I never dreamed practicing content-first design and talking about it at a couple conferences would lead me to work for a bank. Especially one I knew nothing about. But the idea of creating jobs for people who get that content is product design, well that was too dang good to pass up. So now we’re growing a niche team of UX content strategists, sort of like our equivalent of the video game industry’s story designer.

Part of our process is working directly with designers and product managers to design conversations in plain text. We call them content prototypes, and they take many forms depending on the team and project.

Content prototypes

A content prototype is a Word document, text file, or Google Doc full of words that we can test with real customers to see if we’re speaking their language.

Designers and product managers can make them just as a content strategist or copywriter could. The goal of the prototype is to write the conversation we want to have with someone, then design an experience that best brings that conversation to life, no matter the technology. How to start:

  • Start writing what kind of conversation you’d have in real life if you didn’t have an interface yet.
  • Start writing.
  • Write.
  • And don’t edit. (That’s the hardest part.)
  • Keep writing. How the conversation should go will become clearer the more you write. (And the more you test with other people.)

For example, if we’re designing interactive experiences, we might create content prototypes using loads of if-then statements. (It’s like a Choose Your Own Adventure book: read some stuff, make a choice, see the corresponding story. Rinse and repeat.)

For example, this is a content prototype the product and design team created for Ideas, which suggests things to do, see, or buy based on your purchasing history.

Before launching the pilot in a few cities, the team wanted to A/B test some language for “Mary,” the persona they were designing for. But they already had an app designed and in regular usability testing. So they actually extracted the content from the design and put it in this Word document to isolate the conversation, then created a B version of that conversation. A few days later, they ran the test with real people. Here’s what Cary Feuer—a product manager on Ideas—said about it:

“Content prototyping FTW” seems like a pretty good tagline, eh?

More to come

We’ve got content prototypes for different kinds of projects at different stages of development, from scripts we can test on the street or in user labs, to content experiments we can deliver through email or SMS, or prototypes that capture the full (real) content across time and channels.

A lot of the content prototypes we’re creating at Capital One are for experiences that aren’t publicly available yet, but I’ll share them as I can in future posts. And hopefully you can get content at the table where you are. Content prototyping changes the way we work. It’s not a piece of real estate on a page. It’s not an asset. It’s experience design, after all.

15 Reader Comments

  1. Great ideas, Steph. Just wondering, your examples focus on websites, which are obviously content-heavy. How would you approach this idea for a more traditional Web app, especially enterprise apps that are not geared towards public consumption?

  2. Hey Steph, since you’re taking cues from the game industry for narrative design, it would be worth looking into common tools like Twine, which is a tool that allows you to quickly rough out branching narratives like the one you presented in Word. It builds up the interactive story via a simple graph composed of linked passages which you can then run through.

  3. @chris Thanks! Yep, this approach works especially well for designing apps, external and internal alike. We still write first (or separate the content from an existing design) to capture actions, microcopy, and journeys in plain text. Then prototype at a higher fidelity (or iterate on the design), and test it. We then iterate on the content and design together. And we also repeat this approach whenever we discover new paths people need to take or questions they need answered at some point in that experience.

  4. Thank you Steph for sharing! It excites me to see you articulate the relationship between games and content strategy. It’s something that crosses my mind all the time as a UX designer playing video games. At Barrel, the digital agency where I work, we’ve been experimenting with content-first design, starting projects with Google Docs outlining each page’s content and essentially trying to “wireframe” in text first. Love seeing your take on the content prototype!

  5. Hi Steph!

    Thanks again for posting this. As others have mentioned above, learning about this narrative writer gave me a ‘ah ha’ moment! As a product manager who relies heavily on user experience design, its insane not to explore and acknowledge the similarities between game design and application design (now and in the not too distant future).

    I have a question about this technique: Should content prototyping be used as a conceptual model similar to user flows (i.e. we are writing the story of what a persona should experience at a high level) or are they meant solely as a means to distinguish what content should appear in the system as a whole (and as one moves from lower to higher fidelity content prototypes, from system to individual pages)?

    Again, thank you! Really great article.

  6. Nice article Steph. At Citrix I pushed for a content out approach for the responsive redesign of our corporate intranet. It was amazingly helpful. Not the same process as what you’ve described but it was very effective at aligning everyone one the project.

    In fact Karen McGrane and Ethan Marcotte interviewed me about it and just posted the podcast today.

    We took it back one step before the content work and went through an emotion-driven goal writing exercise first. It was interesting to see how getting clear on the emotional outcome that a page’s content was intending to elicit influenced what was being written, and designed.

    In my upcoming book Responsive Experience Design (RXD) this is chapter 2, getting clear on goals is first. It’s the first in a 4 step method for designing great experiences across contexts.

    I’m looking forward to folding in your suggestions and trying out Twine.

  7. @dan Great question; it’s more of the latter.

    Since so much of our typical design processes stay high level and conceptual for weeks (months?), we get detailed right away to answer, “What’s the exact conversation we’re having with someone at this particular touch point?”

    For example, where a user flow or visual storyboard says [user pays bill], we’d write what someone should read — specifically — to “pay bill.” We do this enough times, and the conversation of our system begins to take real shape, from “Sign in with your username and password” [user signs in] through “All set, you’ve just paid $50 to Fairfax County Water Authority” [show confirmation message].

    By taking this approach, we also learn:

    * What [actions] seemed like a good idea at the storyboard level, but when it came to actually having something to say there, turned up empty. So that’s instant iteration or, at the very least, narrowing scope. Either way is a win.
    * As we create/edit/refine this detailed content, we begin seeing where we can consolidate the experience (e.g., two separate actions on the storyboard are actually part of one conversation). So we continue simplifying the prototype to be contextually relevant and naturally conversational.

  8. Designing for content is something that everyone should be doing. Too many people take a ‘bells-and-whistles’ approach, focusing more on the ‘cool’ elements of the package instead of the content of said package.

  9. Good Content is always helpful for very Blog site. you have suggest good ideas how to write quality content and you explained very useful tools. thanks for sharing. Please also advise how to get more traffic I have my new blog site, please advise some to get good amount traffic on my site?

  10. Amazing comparison of video games to make us understand the real scenario of content and designing part and on content prototypes. Your article is really content heavy and thanks for sharing.

  11. I recently discovered this article and it’s really helped me think through how we approach content for chatbots. I liked it so much, I just included it in a roundup of articles on content strategy for bots on my blog. Thanks Steph!

Got something to say?

We have turned off comments, but you can see what folks had to say before we did so.

More from ALA