Wait what? How to Enhance your Responsive Process with Content Questions

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 - 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 ﬂip 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! Justiﬁable, 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 because we had done
this exercise.
!
FRIENDS. That is a conversation w 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.
!
2) Also remember: 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.
!
This is a very much a 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 ﬁelds. Things like “short
& funny” and “don’t include the author in this field”.
Remind authors in the edit page what the ﬁelds are for, where they’re
being used, maybe even include example content.

!
Use really speciﬁc labeling for all your content types and ﬁelds.
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
workﬂow. Trigger-based workﬂow
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 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
workﬂow 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
ﬁrst 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.

Wait what? How to Enhance your Responsive Process with Content Questions

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (9)

Similaire à Wait what? How to Enhance your Responsive Process with Content Questions

Similaire à Wait what? How to Enhance your Responsive Process with Content Questions (20)

Dernier

Dernier (20)

Wait what? How to Enhance your Responsive Process with Content Questions