Versions of this talk were presented at Artifact Conference, Content Strategy Summit, NERD Summit, and Tag-IT.

Full Transcript

I’m a Content Strategist. I came to content strategy through back-end development - PHP, server administration, and CMSes. I’ve worked on a lot of responsive projects, from big corporate sites to cute local organic farms. And I know not every project has the budget (or dare I say the need) for a full-time content strategist. But that doesn’t mean you can ignore content. It just means, you - the designer or developer - need ask the content questions.

Some of this will feel familiar, because you’re already doing strategy. Strategy is about thinking things through, keeping an eye on the big picture. You’re already doing that with Design & Development, so we’re expanding the questions to cover content as well.

Responsive Design is a great excuse for getting people to pay attention to their content. Because they care about mobile users. That’s why they’re doing responsive in the first place. Everyone’s all jazz-hands about mobile.

That tiny phone screen makes the best scapegoat:

  • “We need to format this content more cleanly, because: tiny screen.”
  • I think we should get rid of this section (that no one reads) because: tiny screen.”

You can totally take advantage of that. I am giving you permission to channel some of that mobile excitement about your projects into spending time on content questions. I promise: it will pay you back 10-fold.

I’m going to go over content questions you can work into your existing process in the three different phases of a project: Definition & Discovery, Design & Development, and Post-Launch. We’ll start with Definition & Discovery.

In the very beginning of a project, your fundamental issue is that most clients don’t understand the importance of content. We all tend to be very focused on features, and very distracted by shiny things. Part of what you need to do to show the benefit of putting effort and attention and budget on content.

Questions to explore during Definition & Discovery are: What’s the content going to do on this site? Where’s it going to come from?

Those are pretty broad questions; so let’s talk through a framework for exploring them. I like running an exercise in User Journey Mapping.

This is a great exercise for kickoff, or early in a project. It’s also very flexible, and you can easily tweak it to double as a design exercise, or a jumping- off-point for a features discussion.

Let’s say the client is a Party Supply Company. Give a your group a very specific customer scenario like “Alex wants to rent a bouncy castle for his son’s 5th birthday”. If it’s a big meeting, divide them into groups and give each group different scenario.

We’re going to map out the entire user journey. Post-its are the best tool for this.

Start with some anchor points in the process, like:

  1. Decision to get a bouncy castle
  2. Checkout button
  3. Castle delivery

Fill in all the customer steps along the user journey. They don’t need to be universal steps; this exercise works better with specifics for one user rather than generalities So remind your team that they don’t need to explore every possible path. Just focus on this one path. The reason for starting with some anchor points is to give them a sense of scale. Otherwise it’s pretty common that 75% of the way through their time they’ll have only just covered the first part of the story.

Once you’ve got steps for the full journey, identify each decision point in this user journey where sale could be lost. These are places where, during the buying process, if the user is confused or annoyed, they might give up, and say “SCREW IT. We’re going to ChuckECheese.”

Outline those post-its in red Sharpie. Make them obvious. (Did you know that federal law requires all kickoff meetings to use a red sharpie at some point in the process? It’s true. Be safe out there.)

Then zoom in on each decision point, and ask: What information could you give the user to tip their decision in your favor? For example: if the decision point is What size bouncy castle should I get? There are a lot of factors, like weight limits and the maximum number of kids, and features like slides and climbing walls. That can get pretty complex. What kind of information could make that decision easier?

Maybe something like a table that laid out the different features in a matrix. Put content that exists above the line, and content that they would need to create below the line.

As you go through each of these decision points, you’re going to end up with a full user timeline, and you’ve just walked your stakeholders through exploring a bunch of ways that content - not features or shiny widgets - can help users through their site.

Some content they’ll identify doesn’t exist yet, and they’ll have to decide if they want to put the effort in to produce it.

Other content already exists, maybe on their old website, or in brochures or other media. Your client will also say, “Hey, we already have some if this! We will send it right over.” And now — you’ve got a new problem.

Responsive design accentuates some really common web content problems. Namely: there’s too much content, it’s poorly formatted, there’s way too much content, and it’s really poorly formatted.

The questions to ask ourselves here are: How can they not see that this content is really terrible? And what can we do to help?

Here’s the thing: they can’t see that this content is terrible. They don’t see. Not because they’re not smart, or they have no taste. This is just not their medium.

They run a party store, or an animal shelter, or a clothing company, or a bank. They do not have lunchtime discussions about webfont kerning.

This tiny screen is not their workspace. It’s yours. They hired you to help them get this right.

So you can’t just tell them what’s wrong: “This is too much text.” That is not helpful. You have to show them. Fortunately! One of the easiest ways to show them is also incredibly effective.

Code up a super-simple HTML page. If you have some design language decisions settled, add in their logo and use their palette, just to make this feel like a really simple version of their site. Then, paste in text they’ve sent you. Just do a straight copy of that About Us page that’s a single 400-sentence paragraph. So you make this simple page, then send them the link.

And ask them, “Please check this link out on your phone.” This is a rich time for nudging:

  • “On a small screen, this feels like a lot of text to scroll through!”
  • “Maybe this could be trimmed down.”
  • “This could be divided into sections to help people find their way through it.”

In context, showing this content on a small screen, it’s easier to see how the wall of text is a terrible experience. So let’s say you show them the wall of text, and they get it. They cringe. “Yes! This needs to be better!” OK, good. How can we help them make it better?

Books! As with so many things, the answer is books. The Elements of Style, by Strunk & White, is a great place to start. It’s more about language, and being straightforward and clear in your word choice. It’s about not using jargon, and is very focused on writing clearly.

Letting Go of the Words, by Ginny Redish, is more about structure and formatting. It’s got great information about how to break up long text with headers, when to use lists and tables, and is really focused on writing for the web.

These are both great books to flip through - you don’t have to read them cover-to-cover. They’re also full of great before/after examples, so they’re not just telling how to write better, they’re showing you. You might consider starting your projects with these books, so your clients don’t feel like you’re making a judgement on their content (even though you totally are) partway through the process.

Alright, so we’ve gone through a discovery phase, and now it’s time to move into design and development.

“Too much content” sometimes means format like a wall-of-text, but sometimes means you have a lot of individual pieces of content. Some of these pieces are just straight-up useless (I’m looking at you, Letter from the President!). But sometimes they’re all good, legit pieces of content! Justifiable, and useful and still — So much content.

The questions to ask ourselves here are: What order should the content go in, and is there content we can hide on a small screen?

Let’s tackle the first question. If you’re building a site that’s responsive, that pretty much means you’re going single column on the smallest screens. This is a great opportunity to figure out what content is the most important. What deserves to be at the top of the page?

When I know my content chunks - nav, upcoming events, author bio - I do an exercise with my client that I call: The World’s Most Boring Wireframe.

Take all those chunks, put them in a single column. You can do this in HTML or something like Omnigraffle, but this is another exercise I like with post-its. Work through the content with your client. What’s the point of this page? What should be at the top so the user can get their job done? Play through variations, and figure out what works.

This seems lame, right? Like: duh - yes, thank you, I will do my job and put the content in the right order.

I had a call from a client couple weeks ago (for an ecommerce-y kinda site) and he told me he’d been able to defend our design decisions to his executive team because he understood the information hierarchy we’d worked out in this exercise.

FRIENDS: that is a conversation with ornery executives that I did not have to have. In my book, there is no bigger win. There is a larger benefit to teaching clients the whys and hows of your decisions.

So you’ve worked out the basic wireframe, and you’ve got an order for the single column. Now you’re working on a layout for a larger screen. And the source order really doesn’t match. Maybe on the small screen this orange div lives above the main content block, but on a small screen it’s going to be off on the top of the sidebar.

Now, this is a simple example - you could fix this with straight CSS, or something like the regions polyfill. You “could” do anything with CSS, but at some point: you’ve got better things to do with your time. Those crazy kids at Filament Group have built us a nice little solution to this problem: AppendAround.

AppendAround is a little JS doodle that lets you declare different potential locations for chunks of content in your source code. You declare a few places in the source that this orange block could be displayed, and then the script moves your code to a particular spot, based on breakpoints.

If you find yourself using it extensively? Explore why your information hierarchy is so different from small-to-large screen; that may indicate some sort of larger underlying disconnect. This is a great little script, and one of those places where a little JS can save you hours of CSS time.

This brings us to the Big Question: Is there content we can just hide on a small screen?

Seems like an obvious path, right? Small screen, less content! But of course, people on small screens don’t want less information. They don’t want a cropped experience.

But!!!! The screen is really just very tiny. So, sometimes you have to hide content.

I see two common patterns:
#1: Hiding content behind a “Read More”. On a big screen, you show whole article body. On a smaller screen, you show 1st paragraph and a Read More that expands the text. It’s not a bad way to go.

There are a couple of things to remember, if you take that path.

  1. Show content by default, then hide it with JavaScript. That way if the JS loading freaks out, the content is still there. If you hide it with a display:none in the CSS and rely on the JS to change that, there’s no way for a broken JS person to get to the content. The whole page is still being loaded (pictures, text, etc). Be mindful of page weight. Just because you don’t see it doesn’t mean it’s not being downloaded.

  2. Truncation. Something like: where you normally display the whole teaser, show just the title on a small screen. If you’re going to truncate, make sure content structure and editorial decisions support truncation.

In a full teaser, these titles are cute and funny. But by themselves?? This first one [“Spring for a Party!”] is uselessly vague, and the second [“Colorful Rubber Orbs of Joy”] is straight-up creepy.

Truncation, by itself, is not a content strategy. It has to be combined with structural & editorial rules to make sense. Before you make the design decision to truncate, put your strategy hat on, and start to think through what truncation will mean for site users and for your site maintainers.

Maybe, if you’re going to truncate the display, you decide: all the titles need be practical. Very functional, but maybe a little boring. These post titles [“New Store on Spring Street”, “We Have Party Balloons”] just lost some of their fun & style.

Maybe…we go halvsies: a fun version for when you’re showing the title with a teaser and picture, and a descriptive version for when the title is shown by itself. This could be a good solution! But now you’ve altered your content model - you’ve got two versions of the title. You have to ask: Is there author budget and skill to support writing two separate titles? If there’s legacy content, is someone going to go back and create new titles for the entire backlog?

This kind of thing comes up a lot: this intersection of editorial & structural content questions. It’s very tempting to try to solve this stuff with a clever CMS feature, like “Conditional form fields” or “We’ll reuse the categories from the event calendar”.

Every structural choices has an editorial effect. At the smallest level: you’re changing the way people will create content for the site. At a larger level, you may actually be messing with someone’s job description. You may entirely change their responsibilities, or make some of their work completely obselete. And let me tell you, people get antsy about that kind of thing.

This brings us to post-launch. This is a bit tricky, because the kinds of questions that come up during post-launch, you really need to be thinking about during discovery and development. We have a very preventative mindset here.

Questions like: When do new events get added to the calendar? Who’s writing the next blog post? What’s this field for, exactly?

I am a huge fan of building a lot of training and help into the authoring experience.
What does that look like? If you build in a CMS: install a nice admin theme, and pare down what people can potentially break in the backend. You can do that through roles and permissions, and by doing things like setting up quick links so they don’t have to dig to find their common tasks.

Build a content guide into their CMS - not a writing guide, but an explanation of their content types, what each field is for, where it’s displayed, and so on.

Keep in mind that at the time the site launches, there is a good chance that you, the developer, are the only person who has a complete understanding of the content types and relationships on their site. You want to transfer that knowledge, so customize help text on fields and edit pages, and include style reminders for fields.

Things like “short & funny” and “don’t include the author in this field”. Remind authors in the edit page what the fields are for, where they’re being used, maybe even include example content.

Use really specific labeling for all your content types and fields. If you’re building out an Author biography, name the field “Author Name” not “title”, and “Biography text” instead of “body”. Build in all the help you can for your authors.

You’re also going to need to start discussions about ongoing content creation. A classic approach here is the editorial calendar - “We post to Facebook on Mondays, Twitter every other Thursday, and Newsletters go out on opposite Tuesdays.” This can work well if the client has dedicated editorial staff, whose job is explicitly to create website content. An editorial calendar works much less well if Alice from Accounting is now being tasked with writing a blog post every week. If content creation is being tacked onto existing employees, who already have full-time jobs, it’s not going to turn out well.

I am a big fan, instead, of a trigger-based workflow. Something happens internally at the business, and it sets a series of events in motion. For example, let’s say our Party Supply company now offers a petting zoo for rent.

  1. List in the website catalog
  2. Next day: tweet a photo
  3. Day after that: Facebook story
  4. Day after that: Facebook and twitter again w coupon
  5. Friday: send out a newsletter

It’s like a Rube Goldberg machine of content work, sparked by an internal trigger. These can be much more manageable, because the web content is being tied to existing processes, and makes a lot more sense to employees than something arbitrary like a calendar.

Post launch questions also mean starting these conversations with your client: who adds new content? Who removes old content? What’s the workflow for getting stuff on the site?

Now, it is very easy to feel like this is not your job at all. All this stuff: content reuse, editorial guidelines, publishing calendars? “I built the website. These questions are about running the business.” Fair enough, I get that. But we’ve all launched sites, where you go back a year later, there’s still just that first post: “Welcome to our new blog!” I can’t call those sites successful. If no one pays attention to the content, the website fails.

Putting some of your attention on content - the same way you put some on typography, some on colors, some on custom illustrations - makes for a better site.

Your clients will be happier because their site is more effective and working better for them. You’ll be happier, because the work is so much more satisfying when you are building things that people use and enjoy, and you know you’re solving beyond the most immediate problems.

Remember that you’re being asked to build a responsive site because they want to reach the mobile user. So you don’t need to create the excitement - it’s already there. You just need to divert a little bit of that energy towards answering content questions.

Thank you!