The Web Project Guide

FROM SPARK TO LAUNCH AND BEYOND

Corey Vilhauer & Deane Barker

A PRODUCT OF
Copyright © 2021 Blend Interactive

Published by Story Chorus

Although both the publisher and author have used

reasonable care in preparing this book, the information it
contains is distributed “as is” and without warranties of any
kind. This book is not intended as legal, financial, or health
advice, and not all of the recommendations will be suitable
for your situation. Professional legal, financial, and health
advisors should be consulted as needed. Neither the
publisher nor the author shall be liable for any costs,
expenses, or damages resulting from the use of or reliance
on the information contained in this book.
Table of Contents
Preface

Foreword

Introduction

SECTION 1: PLANNING

Know the Scope of the Project

Set Your Expectations

Form Your Project Team

Create a Project Plan

SECTION 2: DISCOVERY

Identify Your Audiences

Identify Outcomes and Expectations

Know Your Content

Gather Insight From Your Metrics

SECTION 3: STRATEGIC DESIGN

Develop a Strategy for Your Content

Organize Your Content

Model Your Content

Write for People and Machines

Develop the Graphic and Interface Design

SECTION 4: SYSTEM REQUIREMENTS

Know Your Integrations

Determine System Requirements

Select a Content Management System

SECTION 5: DEVELOPMENT

Plan for Hosting

Select an Integration Partner

Implement the Design

Implement the Back-End Functionality

Migrate and Populate the Content

SECTION 6: LAUNCH AND BEYOND

Test and Launch the Site

Plan for Post-Launch Operations

Maintain and Improve

Conclusion: The End of the Beginning

Acknowledgements
About the Authors

About Blend Interactive

Index
Preface
A Fountain in Old Town
By Deane Barker
I’m writing this from a coffee shop in the Old Town of
Stockholm, Sweden (in Swedish: “Gamla stan”).1 It’s full of
narrow, winding cobblestone streets, tiny alleyways, and
artisanal shops. You can wander for hours in abject wonder
at architecture from the 13th century, then stumble into
quaint little courtyards or bustling town squares. You can
point your camera in any direction and capture a postcard.

It’s also really easy to get lost.

I swear I’ve passed by the same stone fountain four times

now, but I couldn’t find it again if my life depended on it.

This is why I’m sitting in this coffee shop. The promise of

free wifi persuaded me to duck in, buy a cup and a croissant,
and spend a few minutes on Google Maps trying to figure
out exactly where I am.

Google Maps is great. It elevates you above where you are.

Instead of tight little streets, I can see an overhead view, with
my location clearly marked. I don’t get the nuance of
standing in front of that gorgeous fountain, examining how
the vines have grown over the façade and listening to the
water splash through it, but that’s not what I need right now.

The key is context, or “the circumstances which form the

setting.” From street level, I can look around and know my
immediate surroundings, but that information is useless
without a larger understanding of where I am in relation to
the overall structure that I want to navigate. After all, every
cobblestone street looks the same from up close.

I was the founding partner of a digital agency called Blend

Interactive. During my time there, I handled most of the
sales process, and I was a part of most of our inbound and
introductory phone calls. Blend has always specialized in
content management – that’s why people would initially call
– but no matter what specific topic we began a call with,
most conversations eventually turned toward questions
about the larger process. The transition phrase would vary,
but generally sounded something like this:

• “I’ve been asked to redo our website, and I’m not sure
where to even start.”
• “We’ve done some work on this already, but I don’t know
how far along we are, or how our current situation fits into
your process.”
• “Where do we go from here? We know where we need to
get to, but we’re not sure of the exact steps.”
• “Once the website is built … then what happens?”

A year after my first book was published — Web Content

Management: Systems, Features, and Best Practices — I started
putting together a talk entitled “Why Content Projects Fail.” I
gave this talk at various conferences seven times around the
world that year.

Among the points in it were these two:

1. Very rarely does a project fail for technical reasons.

2. You need to plan your project from the absolute
beginning to the absolute ending, and those two points are
much farther apart than you think.

In looking back, my first book really didn’t address these two

points at all. It was about the technical parameters of content
management systems and how they’re implemented, which
means it addressed only a small slice of a full project. The
true lifecycle of a project begins far earlier and ends far later
than what I covered in the book.

Indeed, one of the lines from my talk was:

Your project begins the instant someone in your organization

says, “You know, we really should do something new with the
website.”

Strict CMS implementation projects are easy by comparison.

The larger process is more vague, and too many people find
themselves completely adrift with no idea what stage they’re
in, how far along they are, or where they’re ultimately trying
to go.

Kind of like an American tourist who keeps wandering by

the same fountain.

Navigating anything – be it Old Town Stockholm or a web

project – is a matter of context switching. You need to
frequently switch between an overhead perspective with less
detail and a “feet on the ground” perspective where you can
absorb every last nuance.

It turns out that Old Town is actually an island. Its perimeter

is pretty clear against the water. From satellite view in
Google Maps, I can tell where I am compared to the larger
whole. I can see Old Town from edge to edge. I might lose
some of the details, but there’s no doubt that I can take in the
whole of it.

Armed with this information, I can set out again and stop
walking in circles. But, first, coffee.

On Writing a Book I Can Believe In

By Corey Vilhauer
I have a folder on my desktop that includes treatments for
three different books. One is a proposal to Continuum’s 33
1/3 series (now published by Bloomsbury) about Ween’s
Chocolate and Cheese, a seminal weirdo album from a seminal
weirdo band. (This one ended up being written, but not by
me. Instead, some guy named Hank Shteamer got the
honors.)

One is a series of completely unfinished and unrelated short

stories based on … (once again) the songs of Ween’s Chocolate
and Cheese.

The last book treatment is about structured web content. I

never wanted to write that one, really.

To be honest, I never wanted to write about work. I didn’t

know where I stood – where I could fit in, and who would
listen, and why I had the audacity to consider it in the first
place. I ran out a greatest hits of “imposter syndrome”
excuses and then dove back under my desk. I struggled,
because I had no confidence. I was scared of not doing things
correctly.

I found myself falling back to when I started at Blend, when

I was a fledgling strategist creating a content strategy
practice from scratch, and Deane — out of nowhere — threw
a lofty ultimatum my way: “You will give a talk at some
conference by the end of the year or you’re fired.”

To this day I assume he was kidding, but it didn’t matter. I

reached that goal — in 2011, I was invited to speak at Confab,
the leading conference on content strategy, and I found my
people. I found a group of people who did what I was trying
to do. I found the niche that so few of us ever find: the
balance between doing good work and doing satisfying work.

But more than that, I found out that I wasn’t the only one
who wondered where they stood.

I found that everyone is on a different spot in their journey.

For every person who has helped build a site, there are
hundreds who are just beginning and thousands who have
never even thought about it.

Now, as director of strategy at Blend Interactive, I’m often

the first person people talk to after the project’s been sold
and scheduled. I’m the person who jumps in with big
promises of hope and change pointing toward a magical
future on the web. However, as a part of that process, I’m
also the one who has to start setting expectations and
dashing dreams.

And I answer a lot of questions.

Nothing about a project plan makes sense when you first

encounter it. The larger an endeavor, and the greater the
number of moving parts, the harder it gets to know when
you’re being bamboozled. The gap between those who know
and those who don’t know is wide and complicated and,
honestly, a little scary for a lot of people.

I don’t think I’m being cute when I say “scary.” If you care
about your project being a success, you’re probably scared of
something.

For many, including those of us who have been through

dozens of successful implementations, a web project is a
frightening and overwhelming disaster waiting to happen.
It’s a different way of thinking – a different glossary of
terms, and a different model of concurrent processes. It’s
even a different idea of space, especially for those familiar
with a more traditional means of marketing and
communication.

So when Deane approached me with the idea for this book, I

knew this was something I could write. Not because it was
going to set the world on fire through some kind of
transformative paradigm shift, but because it was going to
help bridge some of that gap.

This book is designed to help people who are in charge of a

new project that lives outside of their domain, in a world
where things change all the time. People who just need to
know enough about the web process that they can make
informed decisions, sure, but also people who just need to
know they’re going in the right direction in the first place.

People who are tasked with creating an in-house team and

don’t know where to start. People who are joining larger web
development teams and need to know how they fit in.
People who are struggling to find their place in the industry,
who just know there’s a part of the web process that speaks
to them.

More than anything, we hope this will bridge that gap – to

bring the concepts and ideas of a web project closer to
reality.

You’re not going to come away knowing how to lead a two-

day discovery workshop, or spin up a Wordpress install. But
hopefully you’ll come away feeling more comfortable –
both with the people you are trusting to make your web
project happen, and with yourself. More comfortable, and a
lot less scared.

1 It was the Espresso House at Västerlånggatan 57. I thought it was a one-off operation, but when
I got back to Arlanda Airport I found another one. Still, the coffee was good enough that after I got
my bearings, I stayed to outline this introduction.
Foreword
By Karen McGrane, Partner, Autogram & Jeff
Eaton, Partner, Autogram
Jeff Eaton: Making a website has grown pretty complex over
the past couple of decades. For someone who has worked
inside of an organization, or who has specialized in one
discipline and only seen one part of the overall process,
understanding all the moving pieces can be overwhelming.
There are lots of discipline-specific resources, but there
aren’t many guides to the big picture — maps of the
territory, so to speak.

Karen McGrane: Back in my day, if you wanted to have

anything, you had to build it yourself. There wasn’t anyone
who could tell you how to do it … because nobody had ever
done it before.

One of the things that I love about this book — The Web
Project Guide — is that it orients people who are new to the
field. If I were a new project manager, this book would be
one of the first things I’d pick up.

Jeff: For twenty years, Deane has been writing intense

missives about the process of content management and web
publishing. In the CMS world, we joke that if you look into a
mirror and say “forklift migration” three times, Deane will
appear in the room with a blog post from 2006 that you
need to read. Corey, along the same lines, has put amazing
work into the iterative processes and cross-disciplinary
issues that make or break a web project.

Seeing the two of them collaborate has been impressive. The

result isn’t a training manual for CMS development or
content strategy or project scoping — it’s a map of the
territory you need in order to tackle web projects
successfully.

Karen: Yeah, what I like about the book is that it’s holistic.
One of the things that I’ve noticed over the past ten years or
so is that — compared to earlier days of the web — project
teams are larger and less integrated. There was a time when
one individual could understand a large chunk of what
needed to happen!

As the web grew, and project teams grew, and discipline

specialization really grew, that changed. The cross-
disciplinary perspective became very rare. I come from a
time when information architecture was seen as a holistic
user experience practice. Similarly, I think visual design was
also seen as a more holistic practice. People were expected to
have a foundational level of understanding about where
those different pieces fit.

Now, things are divided up because, hey, I’ve got my piece of

the puzzle to worry about! It’s no one’s fault — it would be
extremely difficult for anybody to truly get their arms
around everything that goes into modern website
development. But I don’t think that’s great for the web.
Having a better understanding of how all these pieces fit
together and why is really valuable.

Jeff: When I sat down for the first time to go through The
Web Project Guide from beginning to end, it occurred to me
that people will experience different things depending on
where they’ve been in the web’s evolution. Old school folks,
who saw that complexity accumulate bit by bit over the
years, will probably feel some warm, fuzzy recognition at
the bird’s eye view. People who are deep in a specialized
discipline or who are arriving fresh will get a better picture
of where their work fits in.

It’s one of the reasons I love the wealth of additional reading

that’s listed in each chapter. Project scoping and breakdown,
for example, isn’t something you can cover completely in
just one chapter. But you can get people over the Dunning-
Kruger hurdle, help them understand what they need to
know, and point them in the right direction.

Karen: I do a lot of work in the user experience and front-

end design space. People in those worlds often ask, “why are
we talking about content so much?” Or, when they hear “the
system won’t let us do that,” they don’t know how to find out
what that really means. Corey and Deane’s perspective
encapsulates decisions about content strategy, migration
planning, content management systems, and the
infrastructure decisions that will affect everything. There are
quite a few designers who’ll benefit from their perspective.

Jeff: What’s that saying? Wisdom is the fruit of past

mistakes? This book takes whole careers full of important
lessons and puts them right in your hands.

Karen: The Web Project Guide is great! It started as a website,

but now you’re experiencing a more tangible copy of it if
you want to have the physical object—

Jeff: —for highlighting, and hurling at coworkers!

Karen: Exactly. Sometimes you need a book that you can

smack into your hand while you’re trying to make a point.

Jeff: And this, friends, this is that book.

Introduction
What This Book Is About
This book is a broad survey of the entire process of
planning, executing, delivering, and maintaining a web
project. By “web project,” we mean something on the
spectrum of projects involving the creation, redesign, or
reconfiguration of a website.

A key goal of this book is breadth rather than depth. For

many of the steps we’ll discuss, dozens of complete books
have been written, and our goal is not to duplicate their
content. Just like a map gives you an overhead view without
nuance, this book will show you the major structures in a
project so you can get your bearings. We’ll leave it to others
to dig deeper into each step.

How This Book Is Organized

In The Design of Everyday Things, Don Norman’s book on
industrial design, he talks about “mental models,” which is
how a user thinks a device works. The usability of a device is
enormously influenced by how a user thinks about it – how
they assume it works.

One of the keys to making a device usable, it turns out, is to

improve the user’s mental model. To make it more clear. A
glimpse into the inner workings of something is key to
understanding how pulling lever A makes widget B do
something.

Our goal for this book is to impart a mental model for the
overall project process of building a website from the
bottom up. It’s less important that you absorb everything
from every lesson, and more important that you understand
the framework.

This book breaks down the project process into twenty-four

phases. They’re presented here in roughly chronological
order, but the process is only vaguely linear, so some phases
will occur out of order or at the same time as others.
Additionally, not every project is the same, so some of these
phases might not occur at all. Indeed, part of the process is
to determine what you actually need to do.

Each chapter is organized as follows:

• Summary: A few sentences describing what’s in the

chapter. Review these at the start in order to begin with
the total context in mind and understand the breadth of it
all.
• Does This Apply: Focusing on whether or not your
project needs to worry about this phase. For a start-to-
finish project, there’s a great chance that every chapter
will apply in some sense. However, this is not always the
case.
• Main Narrative: The main information of the chapter,
describing the phase in detail. We tried to keep this to
something that could be read in fifteen minutes. We may
or may not have succeeded.
• Inputs and Outputs: What you need going into – and
what you get coming out of – a particular phase.
• The Big Picture: A discussion of where this phase fits into
the larger process — the context of this chapter in the
larger web process – and where it fits relative to other
phases.
• Staffing: This examines the humans behind this phase.
What type of professional completes this work? Should I
outsource this?

Our world is often fueled by what you get out of an engagement, particularly what documents
can you show for the money you’ve spent. There is some value in this – documentation is
important for helping communicate and inform decisions, especially for those who aren’t
always in the room where it happens, but it’s also distracting when the benefit of a phase
might be more intangible.

That’s okay too! Be patient with this process. Understand that getting into a room and leaving
with actual direction is just as much of a deliverable as a PDF.

— Corey Vilhauer

On Adaption
The military has a saying: No plan survives contact with the
enemy.2

Digital projects are complicated. They have a lot of moving

parts happening both serially and in parallel. They combine
social, emotional, and technical aspects of your organization
and the people working in it. And they touch many different
groups, each with their own agendas.

Furthermore, there is no Grand Unified Theory of anything

in this industry. Remember that the web is only a few
decades old and still evolving rapidly — as are the processes
and best practices used to deliver it. The leading edge of any
industry is blurry and subject to argument, and no standards
are really settled until a technology or practice falls far
enough back from that leading edge that its evolution begins
to slow down.

Put another way: nothing is settled until it’s boring. If

something is exciting, fresh, and innovative, that only
guarantees that people will argue non-stop about the best
practices for implementing it. Thus, any book purporting to
show you “the process” is, by definition, simply one opinion.

The steps we outline in this book represent what we have

done to help bring some order to the larger domain and to
ensure the process remains as open and clear as reasonably
possible.

To execute on the lessons in this book, you’ll need to adapt

and set priorities. You need to understand the big picture,
know what’s on the critical path, and know what work can be
shortened or jettisoned entirely when the timeline gets tight.

No project is perfect, and the results are analog, not binary.

When you look back on a project, it’s not evaluated in terms
of “success” or “failure,” but rather on how close you got
along a spectrum toward some unattainable definition of
“perfect.” Some projects get closer than others, and you’re
often striving to simply cross some vague, self-imposed line
of results that justifies all the work.

In the end, your goal is to improve your current situation to

the greatest degree possible. Let’s get started.
2 The quote actually traces all the way back to Field Marshal Helmuth Karl Bernhard Graf von
Moltke, who said in 1880: “No plan of operations reaches with any certainty beyond the first
encounter with the enemy’s main force.”
 SECTION 1
PLANNING

Before the code, before the design, and before

the content, your site needs a start. A reason and
purpose. A spark. This spark might come from a
business goal, or from an unanswered need. It
might be because your existing site is old, or
because you’re branching into a new area.
Regardless of what that initial spark is, your web
project won’t just come together on its own —
you need to understand the what, how, and why
of your site, as well as who’s going to be on your
side through the journey.
CHAPTER 1

Know the Scope of the Project

SUMMARY
So, we need a new website? The easy question is, “Now
what?” The harder question is, “How did we get here?” Gain
buy-in on the reasons behind a new project, define the
problem in a way that gains traction, and avoid some early
red flags along the way.

DOES THIS APPLY?

Every chapter following this one was written, in part, as a
response to the universal desire for a new web project. This
is where it starts: a proclamation, a dream, a spark. It isn’t
whether or not this stage applies to the web process, it’s that
without this stage there is no web project.

“We need a new website.”

It’s the sentence that sets dozens of potential traps in motion.
It’s specific, yet frustratingly vague. It’s just five simple
words, but it’s the first step in what could end up being
months – years, even – of organizational turmoil.

Or, it could be the start of something brilliant. It could lead

to an increase in sales unlike anything your organization has
ever seen, or it could be the catalyst for a long-overdue
brand refresh.

It could be the best of times. It could be the worst of times. All

we know now is that there’s a lot to tackle. And that shouldn’t
come as a surprise: the web presence for your company or
organization is one of the most visible and important
communication channels you own, and taking the process
lightly is a surefire step toward disaster.

But how did we get here in the first place?

The Initial Spark

Though the machinations of decision-making might feel like
a signal from some far off place, web projects don’t come
out of nowhere. If you’ve been tasked with a web project,
there was an originating event or condition. This is either a
chronic issue percolating over time or an acute situation
(sometimes a catastrophe) that’s forcing change.

Here are some reasons we’ve seen for embarking on a web

project:

• A desire to change the underlying architecture of the

website. To move from on-site hosting to “the cloud,” to
switch hosting providers, or to use a programming
language or framework more compatible with the
 organization.
• The CMS (content management system), or a specific
version of the CMS, is no longer supported by the vendor,
and switching or upgrading will require a complete
rebuild.
• A desire to use or incorporate some technology into the
website – personalization or A/B testing, for example –
but it just can’t be done with the current platform.
• The organization would like to engage with an external
marketing firm or agency, but that firm has no experience
with the current CMS or programming framework.
• Personnel changes at the organization have brought in
new decision-makers with a different perspective of how
the website should perform.
• Visitors or employees continually complain of being
“unable to find anything.”
• The technical underpinnings or content architecture of
the website are dated, and there’s a lingering feeling that
valuable business content is being stored in such a way
that future retrieval and use would be difficult.3

Maybe one of these represents your project. (Bonus points if

you can claim more than one.) Situations like this are what
we call the initial spark. They are the key moment in which
opinion turns toward creation of a new web project. But they
rarely exist in isolation.

While these sparks are usually tied to web functionality,

many times they reveal other problems. People inside the
organization sense “blood in the water,” and they see the
impetus for change as an opportunity to improve other
areas.
Announcing that your CMS is no longer supported and will
have to be replaced might be met with groans from IT, but
cheers from marketing because “we never liked that thing
anyway.” Meanwhile, the finance department is saying “find
a cheaper one next time, because the subscription costs are
killing us” and the director of sales is thinking “maybe now I
can get a website I’m proud to show to prospects.”

Cognitive Fallacies and Biases

It’s comforting to think that humans are logical, rational
creatures … but we’re not. Our reasoning skills are
consistently poor and we have weird quirks that
influence us in ways we’re not aware of and would deny
if they were called to our attention.

These are collectively known as cognitive fallacies or

biases.

In a great book called The Art of Thinking Clearly, author

Rolf Dobelli catalogs 99 common such problems, many
of which you’ll see again and again in the context of
project decision-making.

• Survivor Bias (chap. 1): “I keep reading about the success

of this software in Forbes.” We’re exposed to more
successes generally because people expose failures less
often. When something fails or is just mediocre, it’s
often non-notable and no one is lining up to write
articles about it.
• Sunk Cost Fallacy (chap. 5): “We have so much invested
in the current solution. We’re not just going to throw all that
away.” If something isn’t working, then the amount of
money we have invested is not relevant to its future
 results. Keeping at it just means throwing good money
after bad, and sometimes quitting is exactly the right
decision.
• Confirmation Bias (chap. 7): “My project’s poor initial
results are just an aberration. Things are headed in the right
direction overall.” When we interpret data, we seek to
find themes which confirm our desires and
preferences, and we explain away data that does the
opposite. Negative results are rationalized as outlying
situations, not likely to repeat.
• Anchoring Bias (chap. 30): “Remember, we need a new
CMS because that’s what editors told us back when we
interviewed them.” We tend to latch onto the first
solution we see and use this as an “anchor,” preventing
us from stepping back and examining a problem
objectively.

It can be hard to see these situations because they’re so

ubiquitous that they (too often) seem like business as
usual. Look carefully, and ask hard questions when the
reasoning smells faulty. Do not identify a problem or
pick a solution without interrogating the situation from
multiple sides.

In the end, there’s rarely a single reason why these projects

start. There’s just an acute event or situation – a spark – that
kicks off the entire project, like a snowball down a hill. As it
rolls, it grows larger and larger, until it stops at the bottom
and lays bare dozens of reasons why the organization wants
to make a change.

The Role of the Website

Of course, it’s one thing to act immediately on a spark. It’s
another to take a step back and understand the landscape of
your potential web project. This often goes higher than the
web project itself, into the sometimes hazy world of business
goals. It also means understanding not just the reason for the
new web project, but the reason for the website itself.

First and foremost, understand that your website is a tool.

For most organizations, it’s a communication tool. It’s one (or
more) of dozens of connection points in an organization’s
outward appearance,4 which means it must be built to
function as such. A well-built, communication-focused
website places message and content at its core, and it is
responsible for delivering both within your organization’s
brand standards.

Websites are created for the following reasons:

• Information: Your organization holds some kind of

information – whether this is a definition of a process, or
a list of university programs, or maybe even your
company’s history – and you would like that information
pushed out to the world.
• Commerce: Your organization has something it wants to
sell. This could be widgets or fidget spinners,5 or it could
be something like professional services or streaming
video. Regardless, the end purpose of a commerce-
focused site is to get money from the person who visits.
• Entertainment: Think of this as “content as the end goal.”
Reading short stories, watching videos, or commenting on
the most recent Wrestlemania main event all fall under
entertainment. (And, of course, entertainment usually
exists solely to make advertising easier to sit through.)
• Persuasion: While this seems to go hand in hand with
 commerce, it can also persuade in a non-monetary way: a
political candidate’s website, a local initiative, or a non-
profit looking for volunteers all display characteristics of
persuasion without being explicitly tied to commerce.6
• Administration: Paying for your vehicle licenses,
applying for a job through an online job search
application, or registering your Nintendo account – these
are all ways in which a website can provide access to
administrative tasks.

Some sites focus on only one thing, like how a writer’s blog
might be focused only on providing entertainment without
any ties to advertisements or newsletter sign-ups – a true
vanity project. Most sites are going to focus on more than
one thing, like how a political candidate’s website both tries
to inform you about the candidate’s issues (information),
give money to the candidate’s campaign (commerce), and
ultimately vote for their candidate (persuasion).

Sometimes you end up with all five purposes, and then

you’re really cooking. For example, Netflix offers streaming
video (entertainment) for a cost (commerce) with sections of
the site focused on both convincing you to sign up
(persuasion) or on getting your service to work with your
smart TV (information) as well as facilitating your existing
account (administration).

Knowing the role of the website is more than just knowing if

it’s going to have a shopping cart or not. Websites and web
projects are made up of dozens – and, at times, hundreds –
of different layers and moving parts, each one building off
of the last, each one looking toward a final finished and
stable product. And this is the very base layer of the project:
what at its core is this web project hoping to become.
The spark is enough to get that snowball rolling. But whether
you run into any trees on the way down depends on whether
you’ve determined a proper path and purpose.

The Author’s Purpose

Does this all sound familiar? Given that websites are
ultimately a communication tool, it shouldn’t be a
surprise to see the concepts of “an author’s purpose” –
concepts we learn when we’re just kids struggling
through our first essay courses, which teach through the
acronym PIE that all writing should either:

• Persuade: Convey opinions in order to convince

someone of a specific side, such as a short debate
about why the school mascot should be a tiger.
• Inform: Provide facts and figures, such as a five-
paragraph report on the climate in Honduras.
• Entertain: Tell a story, such as how aliens came to the
school and ate all of the pizza.

Commerce (largely a form of persuasion) and

administration (a more tactile form of information) get
left off the list, probably because they’re a bit redundant
for middle school essay writing, but also because the
acronym “ACIPE” doesn’t really … spell anything.

Knowing Your History

Whether or not this is the first web project for you, it’s
probably not the first time the concept of a website or
functionality update has crossed the mind of leadership.

There’s history in every request for a new website or request

for new functionality. There’s history, and there’s politics,
and there’s organizational strife. This is not always bad. But
it’s always there, and it needs to be addressed early in the
process.

Ask Questions
We have a spark and we know the purpose, but we don’t
have the full picture. What deep-seated treasures are we
about to unearth? What old fires are still burning, and which
of them are going to flare up and cause complications?

We don’t know. In fact, in most cases, no one knows. As

organizations get older, the issues of the past – the fights
over logo design, or the reasoning behind certain navigation
terms, or the separation of departments – are lost. They are
scars with a forgotten origin; we’ve had that mark on our
arm since we were a kid, but we no longer remember how it
got there, and so we live with it and move on.

These issues compound over time. One small decision made

in a huff as a marketing director threw their hands in the air
with a, “Fine, we’ll do it your way,” can become a doctrine
that’s built upon for years, until no one can remember why
the decision was made in the first place.

So it becomes important to pull these decisions to the

surface, at least enough so we don’t run full speed, blinded
by the spark, into another failed project. One technique
that’s proven wildly useful in our content strategy practice is
actually devised from the automotive industry: The Five
Whys.
Developed by Sakichi Toyoda and adopted as a major part
of Toyota’s lean manufacturing model,7 the Five Whys
directs you to ask why – or, more specifically, “how.” A lot.

Asking why or how five times doesn’t seem like a lot, until you’re looking the director of
marketing of a university in the face and asking them to further drill down issues that they
live every day and frankly would just like to fix right now without all the philosophical games,
thanks.

— Corey Vilhauer

First, you define the problem.

Problem: We need a new design because this one always

looks broken.

Then, you ask why until you get further toward the source of
the pain.

• Why does it always look broken? Because there are too

many links at the top of the site and it breaks at certain
mobile widths.
• Why are there too many links at the top of the site?
Because we have to list all of our audiences at the top of
the site.
• Why do you need to list all of the audiences at the top of
the site? Because students, parents, and faculty all get
served different content.
• Why do they get served different content? Because we
have different departments that relate to each of those
different audiences, so they write their own content and
some of it overlaps.
… and on and on and on, until (often) we see that those
sparks are actually thrown not by the design, but by the
underlying governance model, or by an outdated site
purpose, or by an insistence on creating content unrelated to
the organization’s business goals. This may not change the
ultimate goal – a request for better product pages might still
be a request for better project pages – but it will give you a
lot of insight into why the spark shot off in the first place.

Heed the Red Flag

It might have been a surprise for Sue Hendrickson,
paleontologist, when she stumbled upon “Sue,” the largest
and best preserved Tyrannosaurus rex ever discovered, but
it wasn’t because she didn’t know what to look for. It was
immediately recognized and pounced upon.

“Anybody who had any idea what a fossil versus a rock (looked
like) would have seen it,” Hendrickson said. “There (were) a lot of
broken bones dribbling down (and) about eight feet up the side of
the cliff, there were three articulated vertebrae and a couple of
other pieces of bone sticking out.”8

Knowing what to look for when digging into the history

behind a new website will help you uncover more than just
some vertebrae or broken bones – ultimately, you may start
seeing some project red flags that are necessary to
understand and navigate as the project moves forward. Red
flags like:

• A project built around a new technology without

reference to an actionable business goal, or “I really think
we need to integrate with TikTok.”
• A mandate built upon a competitor’s new initiative rather
than your organization’s mission or vision, or “If ABC is
doing it, then we should be doing it.”
• A drive to change focus due to the vocal minority of a
specific department, or “Our sales team feels like a mobile
app is the best way to go.”

These red flags all have one thing in common: they are
reactionary. They are rooted in a desire in change for the
sake of change. They are real, and they are important to
identify.

But not all of these red flags can be avoided, nor do they
necessarily predict project failure. Instead, these are points
in which clarification of scope – and at times a narrowing of
purpose – needs to become the first order of business, with
increasingly managed expectations not far behind.

Red Flags for Stakeholders

Red flags don’t just come up within a project’s scope – they
also sprout up among the people who make up the
leadership of a project. Project Management for Humans, a
book by Brett Harned, goes in-depth with a list of red flags
for project stakeholders, including:

• Stakeholders or team members who have no interest in

talking about how the project gets done
• Stakeholders who invite everyone to everything
• Stakeholders who want too much in too little time

• Stakeholders with a tendency to gossip9

If you immediately see an overlap between this list and the

last, you are not mistaken. Red flags within projects occur
when red flags within people show their face.

The Project Charter

When we come down to it, we need to formally determine a
reason for the project to move forward – one that everyone
can agree on, one that can secure and maintain a starting and
ongoing budget, and one that can be embraced by leadership
as a real initiative.

This reasoning, and the document that forms around it, is

often called a “project charter.” A charter is the authorization
you have from the organization to spend money and task
resources in pursuit of an agreed-upon goal. This document
is less formal than a project plan, but it explains, in broad
terms:

• A description of the project

• The goals the project is trying to achieve
• A description of the budget, both in amount and source
(from whose budget the funds are being drawn)
• An explanation of project authority and accountability
• A description of the planned or assumed return on
investment
• Some expectation of schedule

Notice that we’re still very high level. There’s no discussion

of team members, implementation phases, or what content
management system we’re moving to (unless, perhaps, a
forced shift to a particular CMS is the only point of the
project). The purpose is not to outline every stage, but to will
the project into existence so that next steps can be planned.

Charter, Scope, and Plan … In Our Words

This and the next three chapters can feel a little loosy-goosy,
so let’s clear some things up about how this is organized.

We will often refer to three specific stages of project

planning: project charters, project scope, and a project plan.
While there is some discussion within the project
management world as to what these three concepts entail –
you’ve already read about the project charter above, and
you’ll encounter the scope and plan in future chapters – we
are not naive enough to believe every project is going to fall
into strict adherence.

In our experience, charters, scopes, and plans often blend

together depending on the makeup of the project, the
urgency of the project, and the level of familiarity and
comfort within the project team. The three form a spectrum
of project initiation. Instead of things, we see them as
framing devices.

• Project Charter: the formal (or informal) declaration that

a project is to begin, and what general goals that project is
designed to tackle. You are selling the project at this point,
in a sense, and as Simon Sinek points out in his book Start
With Why, a charter effectively communicates the why part
of a project. Without the charter, the scope and plan are
listless and directionless.
• Project Scope: what we are going to do at a section-by-
section level. For example, project scope could include a
list of templates to be designed, a list of technologies to
implement, or a list of requirements to meet. This is the
what part of your project – it tells us what to expect, but
 not necessarily how to reach it.
• Project Plan: how we are going to tackle the scope. For
example, the plan might include a list of sprints and
project deadlines, a manifest of who will work on the
project and what roles they will take on, or even a more
narrative list of requirements. This is the how part of your
project, and it tells us how to do it and why it matters.

We promised that items in this book would sometimes occur

independently (and concurrently) with each other. This is a
prime example of that. It’s not unheard of for a project
scope to depend on the project plan. It’s common for the
project plan to require tasks discussed in later chapters, such
as an inventory or discovery workshop.

Unfortunately, there is no perfect, correct answer. Whatever

works for you – whatever gets you closer to your goals – is
as correct as you can expect.

Note that specifying hard requirements in this document is

tempting but illusory. If all it took was writing things down,
we could decide we wanted every feature available by next
Tuesday, for $1.98. Wouldn’t that be lovely?

To recap, here are some questions to consider for this phase:

• What happened to cause this project to come about?

• Who is asking for the change? How far up the org chart
does the directive go?
• Where are your organizational points of pain?
Conversely, what are the business goals you would like to
bring about?
• What issues are hiding below the surface?
And, finally, when discussing a new project with a potential
customer, I always close a discussion with the same
clarifying question:

Six months after this project has ended, what has to have
happened for you to think the project was worth doing?

If you can only answer one question in this phase, make it

that one.

Inputs and Outputs

The only input to this phase is the mandate to get started.
Someone in your organization should have given the
directive to get the project underway, and you should have
some level of executive mandate or backing. Part of this
phase is documenting that mandate.

The output of this phase is an approved project charter,

which is a document that explains the scope of the current
project, the business goal, and where the mandate comes
from, and it may also include things like an available budget
or estimated schedule. This charter should be reviewed and
approved by the powers that control (1) the budget, (2) the
internal human resources you will need, and (3) the website
under scrutiny.

When this is done, you have achieved some organizational

consensus of what the problem is and some high-level
direction on how you’re going to go about fixing it.
Congratulations, this is a big step.

The Big Picture

This is the foundational phase from which everything grows.
You need to do this in some form before you do anything
else, but know that this might not be a formal process.

While a written project charter is clarifying and it gives your

organization a document to rally around, many projects
have been started through a series of informal conversations.
Those projects did this phase and ended up with a tacit
project charter of sorts – everyone sort of agrees on what
needs to happen and what the constraints are – but it wasn’t
codified anywhere, so there could be disagreements about it
later.

In fact, some projects are completed satisfactorily and only

in retrospect would the team realize they completed this
phase informally and without committing to it or formally
codifying the results.

Informality isn’t always wrong, but there’s value in writing things down – I was reminiscing
with a client about an almost decade-old project, and they brought up the four-page
“mission statement” that was written at the project’s inception. This was effectively a project
charter. They said:

“We kept that document around for years. Every time someone wanted to do something
screwy with the website, we pulled it out, waved it around, and said, No, we’re not going to do
that because it’s not in the plan!” Never underestimate the value of concretely proving a past
agreement.

— Deane Barker

Staffing
The spark could come from anywhere, but the research into
that spark – and understanding the history of why this
project came to be and where it might go – is going to lie
with some major stakeholder, and that research could
include anyone from a long-time employee to a former
board chair to the people who walk into the store every
week.

3 We call this “content debt.” Our friends at 18F can tell you more about content debt at
18f.gsa.gov/2016/05/19/content-debt-what-it-is-where-to-find-it-and-how-to-prevent-it-in-
the-first-place.
4 We can include intranets in this, as well. Even though they are not outward to a public audience,
they are used as a tool to push corporate level messaging outward to the employees of an
organization.
5 For those reading in the future, “fidget spinners” were things designed to make middle school
teachers seriously consider early and immediate retirement.
6 Haha, you mean to tell me there’s a political candidate’s website that isn’t at some point asking
for money? Yes, we know. We address that here in a second, just be patient.
7 “Lean Manufacturing.” Wikipedia, Wikimedia Foundation, 23 Dec. 2020,
en.wikipedia.org/wiki/Lean_manufacturing.
8 Wire, CNN. “Documentary about Field Museum’s Tyrannosaurus Rex Sue Airs Tonight.” WGN,
WGN-TV, 11 Dec. 2014, wgntv.com/news/tyrannosaurus-rex-sue-documentary/.
9 Harned, Brett. Project Management for Humans: Helping People Get Things Done. Rosenfeld
Media, 2017.
CHAPTER 2

Set Your Expectations

SUMMARY
What does it mean to get started on this project? Let’s set a
scope for what this project will include, as well as give some
thought to what “success” means – and your realistic chances
of achieving it.

DOES THIS APPLY?

Yes, for every project. Indeed, without knowing what needs
to be done, there is no project, and without communicating the
expectations of the project, there is no buy-in.

This phase might be done in varying degrees of formality,

but it will be done whether it’s the writing of a formal
document that takes years, or a quick meeting over coffee
where everyone “gets on the same page.” The larger the
project, and the more moving parts – especially external
parts – the more detailed the scope will need to be.
There is no greater representation of a project’s need for
solid scope and clear expectations than the Stonehenge
scene from the 1984 film This Is Spinal Tap.

The band – David St. Hubbins, Nigel Tufnel, and Derek

Smalls – are on stage in front of a dwindling, but still
adoring, crowd, belting a signature England-meets-sweaty-
spandex song about druidic rock formations.

Smoke fills the air as we reach peak show-metal: a bit of

stage magic as Stonehenge itself is lowered onto the stage.

But, not quite.

The set piece is only eighteen inches tall.

This Is Spinal Tap is a film filled with shattered egos and

miscommunication, but this comes at the climax, as
managers clash and the band comes to grips with its slow
decline. In the heat of everything, Nigel passed a sketch of
Stonehenge to a contractor, and (because the sketch lacked
any actual measurements) that contractor took the sketch
literally.

As leprechauns dance around their mini-model of

Stonehenge, the band looks at each other with confusion and
anger. The joke always falls on Nigel for writing down the
wrong height (“Nigel gave me a drawing that said eighteen
inches! Whether he knows the difference between inches
and feet is not my problem – I do what I’m told.”) But at the
risk of taking all the fun out of everything all the time,10 no
one really faults Nigel. We fault manager Ian Faith for
passing on clearly questionable information, and we fault his
contractor for acting on that information.
We fault the lack of effective scope, and we fault that
expectations were never discussed nor communicated in any
way.

A project often hinges on acceptance and approval of a

predefined set of expectations, going off the rails not
because a feature is broken or a timeline is missed, but
because there was confusion in those predefined
expectations. Which means once we’ve gotten through the
glow of the initial decision to do a web project, we need to
dive deeper into what that project will actually entail.

When we talk about expectations in this chapter, we’re

focused primarily on the expectations of your team
throughout the web project. We’re focusing on helping
people understand what’s happening, especially for those
who are (or consider themselves) stakeholders, including those
who may not be involved in the day-by-day process of
strategy, design, and implementation. We’re focusing on
keeping things transparent, because misunderstood
expectations are like very small Stonehenges: they will
always be there ready to trip you up.

Agree on What You’re Trying To Do

In the last chapter, we focused on the history and purpose of
the initial project spark – how we got to where we are. Now,
we need to start determining what that spark means. What
will this all entail? What do we expect of the team?

Over the next three chapters we’ll talk about the scope of
your project, the people you’ll need for your project, and
how to begin planning for work within your project. We
begin by looking at the various “layers” of a web project and
how they relate to business goals and the future state of the
website. The number of affected layers means a more
complex project, and the more complex the project the
more difficult it is to keep within a scope, which means we
need to really zero in on what we’re going to tackle. To do
this, we ask two core questions:

• What is the business goal?

• Where is your current pain?

Yin and yang, we can reach the two extremes of a project in

these two questions: what’s your ultimate, perfect scenario,
and what are the horrible things keeping you from that
scenario? Web projects are positioned as lofty end goals, but
are often embarked upon in an effort to remove or lessen a
source of organizational or procedural pain.

Just as business goals vary wildly, so too do the types of web

projects. When you consider the vast landscape of how to
approach your particular situation, the first thing you need
to do is agree on what you are trying to do. Are you just doing a
design facelift? A navigation reorganization? A CMS forklift
or “lift and shift?”11 Or are you doing a total rebuild from the
ground up?

What this scoping stage provides us with is a structure. It

tells us what we need to do: the layers of the project. It shows
us where we need to be flexible: the inflection points. And, it
helps us better understand what will make the project a
success.

The Stack Model

Every website has layers. Sometimes these layers relate to
technology, and sometimes they relate to people. For the
purposes of this book, we’ll call this “The Stack Model.” The
nomenclature derives from a project structured as a group
of disciplines and intellectual assets “stacked” on each other.
You start with strategy, then planning, then content, then
information architecture (IA), then user experience (UX),
then development, etc.

In this book, we’ll look at The Stack Model as follows:

• Design: The general page layout, color schemes,

typography, and media assets that give the site its brand
presence.
• Content: The words, images, video, and supporting files
that convey the information of the site.
• Information Architecture (IA): The organization of
content, manifested in navigation, labeling, index
structures, and search interfaces. (Search itself might be
considered its own layer, but we’ll include it in IA for
simplicity’s sake.)
• Content Management System (CMS): The technical
platform for managing the content of the website.
• Integrations and Aggregations: The external content and
functionality that plugs in to your CMS, such as API
integration or embedded social feeds.
• Analytics: The analytic tools (how you track) and
implementation (what you track) that provide data about
the usage of your site.
• Hosting and Infrastructure: The technical infrastructure
on which the site is hosted, either within your
organization or externally.
• Governance Model: The organizational roles,
accountability paths, and communication mechanisms in
 place to keep a team working together over time.

When looking at the above list, understand that, in theory,

anything in this list can be swapped for a new version
without changing anything else in the list.

We say in theory, because the very nature of complex sites

often causes a blur between layers. Yes, technically, you can
rework design within the same content structure, but often
there will need to be some adjustments just to get things past
a minimum viable product. Also, some of these layers
overlap, certainly. For instance, your CMS will be impacted
heavily by your hosting environment, and vice-versa.

Some projects use just some of the layers in this theoretical

stack. You might just be reorganizing the content on your
site to make it easier to find, for example, which would
involve some work on the content layer, the information
architecture layer, and, finally, forming content operations
to implement the changes. Your CMS might not change, nor
your hosting environment, nor your basic governance
model.

Other projects impact every layer, from top to bottom – the

“full stack.” Those can be the most overwhelming, pulling in
multiple different disciplines, all of which have their own
way of thinking. A full-stack project approaches things with
every possible avenue laid bare, which can bewilder teams
and leave them with “paralysis by analysis.”

Inflection Points
Thankfully – and we really do mean thankfully – nearly
every project has some restraints, even if it’s a from-scratch
full-stack project. There’s a saying that claims a project will
“flex” on at least one of three axes:

You can have it fast, cheap, or good. Pick two.

Hackneyed and trite as it is, this saying isn’t wrong. It points

out the three major axes of a project.

1. Schedule
2. Budget
3. Features

You can have two of the three, and the project flexes on the
third. It’s a game of project musical chairs – there are two
chairs, and three players, and when the music stops, the one
standing up becomes the inflection point.

It can be cheap and fast, but it likely won’t be good. It can be

good and cheap, but it’ll take a long time. And it can be fast
and good, but it’ll cost a fortune.

This model can actually be a good way for you to examine

your project and ask yourself where it flexes and where your
hard limits are. For example:

• “We are absolutely limited to spending $250,000 (rigid

budget) and it has to be delivered by the end of the year
(rigid schedule). I want to get as many features as possible
within those boundaries (flexible features).”
• “Our old CMS isn’t compatible with the new CRM project
that goes live on June 1 (rigid schedule), so we have to have
the new CRM integration (rigid features) by then, no
matter what the budget (flexible budget).”
• “We’re limited on available funds (rigid budget), but we
 still want a high-quality product (rigid features), so we’re
willing to take some of the development in-house, even if
it takes longer (flexible schedule).”

Logically, a project has to flex somewhere, or it would

quickly spiral out of control. If you have unlimited funds,
unlimited time, and want unlimited features, then you have
a project that will never end. Your desire for more and more
features would expand the budget and schedule infinitely.

Realistically, it’s most common for a project to flex on

features. Schedule and budget are normally firmer – no one
has unlimited time and money. More often than not, those
two variables are the constraints, and an organization is
looking to see what can get done within those boundaries.

In Design is a Job, author Mike Monteiro claims “A designer

solves problems within a set of constraints.”12 The same is
true in scoping (or “project design,” if there is such a phrase).
Your job is to take a long view of your pain points and
determine the best possible strategy for solving them within
a set of constraints defined by your organization. It might be
true that these constraints are determined by you, which
means your ability to not only communicate those
expectations but also stand by your decisions can make or
break the project.

Ultimately, these constraints are the “load-bearing pillars” of

your project. They are the first level of expectations we are
tasked with maintaining: the very basics. They are the walls
of our home, and from here on out any remodeling, interior
decorating, or room determination must happen within
those walls.

Defining Success
When we talk about success, we’re not necessarily talking
about key performance indicators (KPI) like time on page or
click-through rate or conversion rate. We’re talking about
higher level goals – goals that should pull directly from
those initial “why are we doing this” discussions.

For example, if the reason for this new project is …

There’s a desire to incorporate personalization into the website

… then the goal – and the success therein – will partly be

measured by our effectiveness in incorporating that
technology into the website.

If the reason for the new project is …

The CMS is no longer supported by the vendor

… then success will, in part, be measured by our ability to

choose and implement a new CMS that works for the
organization.

It’s all so easy! Except you already see the issues.

Expectations for success don’t always live independent from
each other, and they often depend on hidden successes that
we do not plan for. In fact, it’s necessary to separate the
concept of a goal from the expectations that lead to that
goal’s success.

Take our “new technology” example above. While we can

assume that making that technology work within the existing
site is an obvious goal, there are a lot of expectations going
unsaid:
• Expectation: This new technology will seamlessly
integrate with the current CMS.
Concern: Is this true, or are we implementing a complex
system of patches (and corresponding convoluted
workflow) to approximate effectiveness?
• Expectation: This new technology will streamline our
operations.
Concern: Does this new technology add work or
complicate the workflow of staff who may already be at
capacity?
• Expectation: This new technology will make us a more
successful organization.
Concern: We need to develop metrics to accurately
measure what we mean by “success.”

Expectations need to be addressed in the same way as the

initial project charter: by clearly stating the hidden
expectations and plainly defining a success metric. Listing
the hidden expectations helps us better define what the
project requires:

• Clear definition of how the technology will work within

the existing CMS (if it does at all).
• Documentation of how this new technology will fit into
existing process workflow.
• A definition of “success” as it relates to the tool’s
effectiveness.

It’s only by addressing the expectations of the project – and

by determining a realistic definition for “success” – that we
can ever really understand the full scope of a project.

Unrealistic Expectations
Most unrealistic expectations are due to someone not
knowing what they don’t know – they don’t understand that
what they’ve asked for is actually impossible.

It feels like a cop-out, but the truth is that with unrealistic

expectations, often the best you can do is:

1. Be clear that expectations are unrealistic, and say why.

2. If expectations cannot budge, then ask what added
resources can be allowed.
3. If none of this works, run away.

That last point is a joke, but only a small joke. There’s a bit of truth in the idea that unrealistic
expectations might be a symptom of a larger issue. You can try Five-Whying your way to the
real problem. Or, you can find something that can be the bad cop for you – “The CMS does
not allow for that,” or “We do not have the budget for it.”

— Corey Vilhauer

Communication and Documentation

Creating scope and communicating scope are two
completely different disciplines. One is focused on figuring
out what you want to do, while the other is interpreting what
you want to do in a way that other people can understand
without confusion. One is making a list, the second is
checking it twice (and also probably rewriting it and then
checking it a third time).

We mentioned the idea of a project charter in chapter one,

which turns the spark into a formal declaration of project
intent. This charter helps guide our decisions and help
others understand the purpose.

But now, we’re talking details. Now we’re starting to dole out
tasks and look for resources. Now we’re taking a pipe dream
and heading to Lowe’s to buy the pipes. With scoping, we’re
determining what exactly needs to be done.

The work included in communicating and documenting

scope depends on the number of moving pieces connected
to the project – and the degrees of separation between
project owners and the people doing the work. If you’re
doing a quick turnaround internal project, you can maybe
get by with a simple scope outline – what needs to be done
and who’s going to do it.

But sometimes you’re working with people from multiple

departments or even external teams. And, sometimes, a final
scope is not determined until you’ve gone through a formal
discovery and strategy process. For some, scope is handled
in stages – a scope for content, a scope for design, a scope
for development. For others, scope is required from the start
– a state-run university that requires a formal request for
proposal and bid process is going to need everything at once
in order to secure allocation for the next year.

Remember: websites are designed and built for

organizational goals, but they are often maintained by
people who had little to no say in those organizational goals.
The need for communicating scope in a way that makes
sense is paramount: buy-in on a project begins the second
it’s announced, and until things are explicitly described they
will continue to be pipe dreams.

Inputs and Outputs

Potentially, there’s a project charter as mentioned in the last
chapter. Often, this becomes the first point in which input is
collected from more than the high-level decision makers, so
input takes the shape of collected functionality needs, gripes,
research, examples from other projects, feedback from
customers, and dreams.

The output is a formal scope document that may or may not

include deeper details. This is not yet a project plan –
instead, this is a stake in the ground that clarifies the
different needs and expectations of the project.

The Big Picture

This stage is the natural next step after “we need a new
website” or “we need to fix a problem.” This is where the
problem is formally identified and the needs are
documented, and it leads directly into making sure the right
people and plan are in place to move forward.

Staffing
In our experience, this phase often grows out of another
consulting engagement. The organization has a lingering
feeling that something is wrong, so they engage an external
consultant to come in for an “evaluation.” That consultant
reports their view of what the problem is, and, well, we’re off
to the races.

That, of course, is just the impetus. To deliver on this phase

completely, you’ll need to have considerable input from the
organization. Someone likely above you will need to set the
terms of budget and schedule, and business goals need to be
agreed on by the major stakeholders.
This will involve a level of intimacy that can be hard to
achieve from the outside, but a good consultant can
concentrate on bringing people to the table and conducting
interviews to get at the heart of the problem.

Normally this phase would be completed by a key

stakeholder, often from the communications or marketing
department, or a project manager charged with oversight of
the project.

10 The never-ending curse of the consultant, really.

11 A forklift is a type of project where the underlying CMS is swapped for another, but nothing
else changes. The new CMS is templated to look the same as the old site, and all the existing
content is migrated to the new CMS.
12 Monteiro, Mike. Design Is a Job. A Book Apart, 2012.
CHAPTER 3

Form Your Project Team

SUMMARY
Web projects are shaped by the people involved in decision-
making. You can help prevent latestage rework by making
sure the right people are in the room from the beginning.

DOES THIS APPLY?

You need to know who your web team is – who is a good fit,
who you need to hire, and what roles they’ll be playing as
you take your party on this exciting new web adventure –
from the beginning. Roles may change throughout, and the
individuals will come and go (especially with longer
projects), but you need to have an idea who you can count
on, no matter the project.

There’s a concept introduced in tabletop games like

Dungeons and Dragons (and further codified through video
games like Final Fantasy) called “party balance.” Because
these game systems are built around a set of codified skills,
characters with complementary skills tend to make the
strongest party, as they cover for a wider range of potential
encounters. Having too many people in one discipline
makes you incredibly strong at one part of the game, but
vulnerable in others; a party of sword-swinging fighters
might be able to take and deal a ton of damage to a
wandering group of goblins, but they provide limited
options for longevity (very little natural healing power) and a
lack of range for distance fighting.

This is not unique to wizards and warriors, obviously.

Professional sports teams are often focused on exploiting the
weak points of their opponents: a basketball team that can’t
shoot from range will see their defenders fall back closer to
the basket, meaning the closer scoring options are better
defended. The best quiz teams collect people who can cover
multiple disciplines. The most successful (and most exciting)
communities are those that provide a little something for
everyone.

So too are your businesses. The web process, more than any
other creative outlet, balances the free-form thinking of
creative writing and graphic design with the nuts and bolts
of product design, which means you need a varied and
complementary team to help merge business goals with
future-focused design and technical competence.

You need a little bit of everything to build a website. Let’s

talk about what those “little bits” are.

Stakeholders
First of all, there’s the people who get to make decisions.
Stakeholders. A stakeholder is someone affected, whether in
reality or perception, by a project. On your project, you’ll
potentially run into one or more of the following types of
stakeholders:

• Those Who Affect: Here’s a quick list of people who,

without a doubt, affect the decisions and outcomes of
your web project: the person or group who controls the
organization’s goals and direction; the person or group who
controls the money; the person or group who controls the
content; the person or group who controls operations.
• Those Who Are Affected By: This is where the concept
of a stakeholder – and a stakeholder’s actual stake in
decision making – begins to get a little fuzzy. For
example, your new website may affect the sales
department’s ability to do their job, but whether or not
you make decisions based on the sales department’s needs
(what we’ll call a consulting stakeholder) or if their
process adjusts based on changes to the existing web
process (what we’ll call a passive stakeholder) determines
whether or not you bring them to the table through the
entire process.
• Those Who Perceive Themselves To Be Affected By:
These are people who are pretty sure they need to be a
part of the decision, but in reality have little bearing on
the overall project. For example, meet Francis
Jellybottom, an adjunct professor of history who has (in
the past) run his own section of the university website and
currently maintains his own separate blog on Medium.
Francis wants so very badly to be a part of the web process.
This may be because he has great ideas on how to
integrate his work into the new content plan. Or this may
be because he’s concerned about how he’ll have to change
his methods to facilitate a new site. He probably doesn’t
garner a seat at the decision-making table, especially if
 he’s represented by another ranking stakeholder. But he
does warrant an audience with the stakeholder team,
because he’s a person who will make waves.

You can see from this that a web project has four tiers:

• Affecting stakeholders
• Consulting stakeholders
• Passive stakeholders
• Perceived stakeholders

Whether or not these roles overlap into the same person or

whether you have entire teams at each level, what’s
important is that all of them are heard.

What’s additionally important here is figuring out who the “hippo” is: The Highest Paid
Person in the Room. That sounds cynical, but reporting and deference lines are important.

When you invite someone to be a stakeholder in your project, know who they report to and
how that person feels about the project. The answers to those questions will have a huge
bearing on how that person engages.

— Deane Barker

It’s easy to think that we can consult our bosses and the
people who sign off on budgets and be covered, but the
stakes for a new website go deeper than just a corporate
decision. The website is a thing that will touch the lives of all
levels of stakeholders, and while someone like Francis
Jellybottom might not have the power to approve a formal
request for functionality, he can sure shift public opinion
and gum up the wheels on whether or not the new intranet is
adopted, or whether new content workflows move smoothly.
Whether or not stakeholders have an actual stake in the
project is irrelevant: the perception of having a stake in the
project will lead them to take action.

Building the Web Project Team

When we enter into the discovery phase of a project, the
question we get most often is “who should we invite to the
initial meetings?” This is a tricky question for us because we
do not yet understand the organizational hierarchy and therefore
cannot reliably ask for specific positions or people.

Understanding the people involved in decision-making is

further complicated by the fact that your group of main
stakeholders is not necessarily the same as the team you will use
to do the actual work. In most cases, your stakeholders
inform decisions, and help determine constraints, and some
serve as a part of your web team, but they are not themselves the
web team.

Instead, the web team needs to take the concerns of

stakeholders, mash them with documented business goals,
weigh them against user needs, and make real decisions
about real aspects of the website.

Your web team needs to represent two distinct mindsets:

• Business Strategy: This website needs to serve the greater

communication needs of your organization. It needs to
provide a path to some kind of business or organizational
goal.
• Project Strategy: In order for the site to work well, we
need to successfully execute certain pieces of the project,
and we will need to maintain those pieces into the future.
We need people who can help us take on the relevant
 layers of the stack that we talked about in the last chapter.

In other words, your web team should include people who

can make business decisions, and people who can make
project decisions.

Here’s an example. Let’s say you’re a medium-sized public

liberal arts university. You have limited development
capacity, but you definitely have an IT department who will
maintain the site after launch. You despise the CMS you’re
currently using, and so you believe you need a full stack
approach, creating a new site from the ground up.

Who do you need to invite?

In this example, you need people who can represent the

major areas of the university – especially those who generate
income and drive engagement. Someone who can speak for
the needs of the admissions department, someone who can
speak for the needs of the dean’s office, and someone who
can speak for the needs of marketing. This represents
business strategy, and might look like:

• Director of Marketing
• Director of Admissions
• Vice President of University Relations

In two cases here, you’ve added in the actual decision

makers – the Director of Marketing and Director of
Admissions – and for the other, you’ve got a representative
who can speak for both the dean’s office as well as for the
entire corporate suite.

These leaders will be helping with decisions, but often won’t

be doing a lot of the actual project work, so your web team
also needs someone who can handle the project itself:
strategic project decisions, design and development,
governance planning, server and integration management,
and more. For our university example, let’s assume this
means we’re using:

• Director of IT: Will help determine server arrangement,

develop a plan for post-launch maintenance, help
integrate external services, and have a hand in helping
choose a CMS.
• Director of Marketing: Will begin developing workflow
for the new site (and the marketing that leads into it) and
will begin figuring out the viability of hiring someone
dedicated to the new site install.
• Web Content Specialist: Will be tasked with making sure
the site handles the content required for the new site, will
manage migration, and will provide high-level strategic
decisions.
• External Web Development Firm: Your designer is busy
with the work they are required to do each day, and your
IT department doesn’t have capacity to build a new site,
let alone break down a custom CMS install. You’ve
decided to hire a firm to help here.
• External Digital Marketing Firm: Maybe you are
thinking of launching the site with help from a digital
marketing firm, and keeping them on for a few years to
develop better content.

In this example, there are only five people from the

university – as well as representatives from two external
firms – involved with the web decision process. Yes, they
may delegate tasks to other people, but the core web team is
five people because five people is all they need. Some
organizations may need more.
One last quick note – while this core team is responsible for
making some deep decisions, there’s also what Lisa
Welchman13 calls the “distributed digital team,” which
consists of your day-to-day editors, product specialists,
production designers, and more. We will talk more about
these people in future chapters when we talk about
governance and maintenance.

A Web Steering Committee

We’ve seen a lot of success with the concept of a web
steering committee, where a group of stakeholders
meets weekly to discuss progress on the project and then
disseminate progress to their teams or departments. But
this is not a universal case.

Some businesses thrive with the web project existing

solely as a marketing project, while some smaller
businesses have a team of two or three trusted
executives. There is no right number, as long as various
roles and stakeholder levels are represented.

We can never tell you exactly who should be in the room,

but we can offer a few guidelines based on our experience:
• Err on the side of a smaller representative team. There is
rarely a need to send every member of a specific
department, such as the marketing team, to be deeply
involved in every meeting and decision – in fact, doing so
can severely skew decision making toward that one
department.
• Make sure business goals are represented. If a site is
being rebuilt to provide a better experience for the
 roaming external sales team, make sure someone from that
team is represented as a part of the decision making process,
even if they’re not explicitly invited themselves.
• Make inclusivity a part of your process from day one by
creating a diverse team that, at minimum, represents as
close as possible the full scope of users who will use your
site or encounter your project. People who can uncover
biases, stop troublesome messaging before it’s released to
the world, and provide a more inclusive discussion
around how the site should function.
• Understand that opinions come from beyond the
corporate suite. What are front-line employees – call
center operators, warehouse workers, or forum
moderators – hearing about the current site, and what
would make their job, and the experience of the people
they come into contact with every day, a lot easier?
• Implement a path of accountability. While any major
web decision is going to ultimately come down to a
decision between business goals, budget, and capacity,14
there needs to be someone (or a very small team of
someones) who can make hard and fast decisions.
Otherwise, we’re looking at a very expensive and
demoralizing “website by committee” approach that will
no doubt end up as the basis for a conference talk on what
not to do.
• Take each person’s workload into account. As much as
you would love to have a perfect team, people are busy.
You want someone who can attend most meetings and
help provide guidance to both major and minor decisions.
You don’t want someone who is maybe more
knowledgeable but never available. They will show up
three meetings after a decision has been made and begin
trying to refigure it.15
With this team, you should be able to look at the major
stakeholders and say that, indeed, you have most holes
covered. It will never be perfect, but it will make things
happen. You can think a web project to death, to the point
that everyone’s tired of it before it launches. Choosing the
right people is key to making things better.

When the Right People Aren’t Right

There
A new web project, whether it’s a redesign or a new site or a
major functionality overhaul, is going to create a bubble in
your capacity. Which means, for a short time – or a long
time, depending on the size of the project – you’ll need to
supplement your team. In that case you have three options:

• Create from within: Pull someone from another

department or discipline to step in, or promote someone
to a position where they’re now in charge of some
element of the new web project. This can be incredibly
rewarding for someone who has a vested interest in the
site, or has a real desire to move up into that kind of work
– and it can be an affordable answer – but it is rare to find
this kind of perfect fit. Often, you’re asking someone to
do something they don’t have time to do, something they
weren’t hired to do, or something they don’t even really
fully understand.
• Hire from outside: If your team looks as though it’s going
to need someone not just for the project, but for the long
haul, think about hiring that person before the project
starts. This works best if there’s a long-term plan for
continuous work – someone who will take on a new
position focused on site governance, for example. On the
other hand, it’s not a great idea for a project that will wind
 down almost immediately after launch, leaving that new
hire with … nothing.
• Bring in an external partner: This is the agency or
consultant model. You hire an outside person or firm who
specializes in some – or most – of the project stack. This
could be a single copywriter. This could be a design and
branding firm. This could be a full-service web agency
that will help push you from initial concepts through to
digital marketing. If you need to fill a role on your web
team, there is someone out there who specializes in it.

You’re going to need people. But, you’re going to need

people who can professionally execute the work required of
them. A web project is an expensive endeavor, so providing
the right people at the start isn’t just an issue of craft: it’s an
issue of budget and responsibility.16

Working with External Partners

External partners – web shops, or copywriters, or off-shore
IT consultants – are at their core external. They may be
experts in their field, but they will rarely (if ever) become
experts in your industry or organization. There are benefits
to this – this means they can look at business decisions
without the stain of history or preconceived notions of
industry best practices – but it also means there will always
and forever be a bit of an industry-tied language barrier.

This is the balance of external vs in-house: You trade

organizational familiarity for stack-level expertise. Your
budget (from a strictly monetary standpoint) gets a bit
bigger, but in exchange you free up your internal staff’s time
and energy for some of that industry- and organization-
specific work.
Most organizations do not have the luxury of a fully-
functioning web content, design, and development team,
which means most organizations are forced by capacity
alone to reach out to external partners for help. In these
cases, there is always a cost … but there’s also a cost if you try
to hire your own employees or take time to teach your IT
team how to develop in a specific CMS, so “cost” is all
relative.

The Weight of the New Web World

Let’s take a moment to talk about two groups of people:
those who are scared, and those who are protective.

On one hand, a new web project is going to frighten a lot

of people. While there are obvious benefits to
developing new processes and creating new content,
there’s also the universal truth that change is hard and no
one really likes it.

This is okay. It’s okay for people to hate this change. It’s
okay for people to look warily at the project, or
immediately start sending laundry lists of what they
absolutely need to keep on the new site. It’s your job as
someone who understands the complexity and larger
scope of the project to provide a larger picture – as well
as some guidance or comfort.

Through your project, you will encounter a deep and

complex set of emotions as people see what they know
change into something different. Their everyday
processes and their shortcuts and their own mental
model of what the website is and does is changing, and
that leads to emotions that range from anger to feeling
 obsolete.

Just because Francis Jellybottom seems to be focusing on

his own content needs over anyone else’s doesn’t mean
he deserves to be scoffed. Even if his suggestions never
make the final launch, Francis needs to be heard – not only
because he may actually be presenting a valid point, but
because change is hard and people want to be heard.

If you haven’t gathered that a web project is equal parts

strategy, technology, and psychological accommodation, this
is the point in which it is driven home.

Choosing a Leader
Just like web projects need to be driven from both business
and production mindsets, web projects need to be led by
both someone who can push the full vision of the site and
someone who can drive production of the site. You need a
project leader, and you need a project manager.

On rare occasions, the two can be the same. Both the 1967–
68 and 1968–69 Celtics were able to win a championship by
relying on a single player-coach (Bill Russell) who both led
on-court and off-court. Because we so often work as an
external consultant, we rarely encounter this – the
production is handled by a project manager on our side,
who works with the project leader on the client side. But
even with internal projects you most often see a natural
separation between the person who is driving decisions – the
director of marketing, the vice president of public relations,
the brand manager – and the person who is driving
production – an internal project manager, a director of IT,
or even at times a project management consultant.
To define these roles:

• Project Leader: The role of the project leader is to be the

person responsible for the success (or, ugh, failure) of the
website. This could mean anything from managing the
organization’s expectations, to making decisions on the
core web team, to giving feedback and direction to
features and strategic decisions. Regardless, there’s one
thing that’s always true: this person is going to make the
new website their life for a little bit. Or a long time.
(Usually the latter.)
• Project Manager: The role of the project manager is to be
the person responsible for keeping the project on a
timeline and managing the different resources required
for a fully functioning site. They are connecting external
team members in order to make something happen. Where
the project leader is responsible for making it valuable,
the project manager is responsible for making it work.

Ultimately, one of them decides what needs to happen, and

the other decides how it’s going to happen. Both of them
work together to drive the vision of a common web plan.

Your project leader is the person who is going to help

finalize scope. Your project manager … well, they’re going to
help you build your web project plan.

And speaking of web plans, let’s get to work making one.

Inputs and Outputs

Input for this will depend on the portions of the project
stack that you’ll be working with, but most likely you’ll need
to understand the availability and skillset of potential
members of the project team.
Output could include everything from creation of a formal
web steering committee to a project organizational chart
that outlines who will answer to what portions of the project.
Once this team is figured out, another output is a weekly
status meeting with those who are considered project
leaders.

The Big Picture

Making sure you have the right people – and making
decisions to bring in additional members from within or
outside the organization – is most likely to happen at the
start as you’re formalizing scope and creating an
environment for project work to actually begin.

But don’t think for a second that your team is going to be

100% from the start. The team you start with is rarely the
same one you end with, either because someone is only
needed for one part or another, or because the volatile
nature of hiring people and keeping them happy is often a risky
endeavor.

Staffing
This section often talks about who is tasked with executing
this phase or stage of a web project, but in this case the entire
chapter is about the act of finding and hiring staff in order to
build your web team. Which, we guess, means you are the
person. You’re reading this book, after all, which means,
more often than not, you’re in charge of some aspect of the
web project.
13 Straight from the pages of Lisa Welchman’s Managing Chaos, one of those books that seems to
perfectly balance the two ends of the project process: The decisions and short term project teams
that kick off a project, and the decisions and long-term staffing that help keep the product alive
after launch.
14 When we talk about capacity, we’re talking about the availability and processing power of the
people among your team to do the work, whether that’s an outside firm’s availability for
development work or your marketing department’s ability to take on new content creation. It was
this or “people power,” which we felt was a little less “web project” and a little more “grassroots
campaign for safer streets,” though now we’re thinking that the two might be more related than we
first considered.
15 This is called the “swoop ‘n’ poop,” a term we first heard from Margot Bloomstein: a new
stakeholder shows up, sees what’s happened, and says “LOL nope,” either ruining the timeline, the
budget, or the work you’ve completed to that point.
16 Peter Morville and Louis Rosenfeld, in their seminal tome Information Architecture for the World
Wide Web, a book that’s been mentioned so often it’s now just referred to as The Polar Bear Book,
likens this to when we need to hire a doctor or a plumber. Sometimes, if it’s a small cut, we can use
the best available resources we have. However, if that bleeding is out of hand, it’s time to find a
professional. NOTE: this also won’t be the last time you hear from The Polar Bear Book in our book,
either.
CHAPTER 4

Create a Project Plan

SUMMARY
Determine the true time scope of your project. When does it
start (hint: right now, perhaps) and how will you choose
someone to help through to the very end?

DOES THIS APPLY?

You need a plan. Full stop. Don’t do anything else without
having a plan for how it will work out. Either do it yourself
or hire someone to help you put it together. But don’t think
about a web project without a web project plan: you will
simply waste money and time.

When you think of a plan, what do you think of?

Do you think of a consecutive series of steps, like the steps

you’d take to build a table or install a thermostat?
Or do you think of a plan as a set of expectations, like a maze
with multiple correct endings?

For a web project, planning is often a mix of both. We like to

compare a web project to a building, where user
requirements turn into a blueprint, which helps plan several
concurrent areas of expertise. It’s just that instead of
electrical wiring, and framing, and interior design, we’re
looking at server setup, content management
implementation, and content migration.

Because web projects are often managed by a marketing or

communications department and closely tied to
communication goals, we often assume a web project should
be planned in the same way as an advertising campaign: a
creative burst worked under mysterious methods, then a
grand reveal. Ta-da! It’s done, now someone make it a site!

Sorry For Your Blood Pressure

If you’re the kind of person who’s choosing to read this
book, you’re the kind of person who is taking this web
process very seriously. You’re a little freaked out, and
you’re probably overwhelmed, and now you’ve got us
breathing down your neck with a “Whatever you do don’t
screw up this planning part!” and a “Seriously, this is very
crucial so do not screw this up even in the slightest!” and none
of it is very comforting.

It would be disingenuous to say “don’t worry, it’ll all be

okay.” But we do want to ensure you that it will, indeed,
be okay.

Websites have been successful with very little planning.

Likewise, websites have failed despite being perfectly
 planned. But more often than not, the amount of work
you put into making sure everything is rolling smoothly
will help exponentially when we get to actual
implementation.

There’s an old (unproven) saying that every dollar spent

on prevention saves seven dollars down the line.
Whether or not this is a valid study, the idea in that
statistic holds true – the better you plan, the more time
you spend making sure the plan works with everyone
involved, and the more buy-in you receive with a plan,
the more likely your web project will be a success.

Don’t worry. It’ll all be okay.

While some of this methodology might work, a web project

has more moving parts. The web is complicated, which
means planning for the web is complicated.

Of course, because this is a process that involves industries

that sometimes seem to work at odds with each other, there’s
more than one kind of planning involved with a web project.
Typically, two plans move along concurrently:

• The strategic plan, which defines high-level expectations

and requirements around a usable site that meets your
business goals.
• The operational plan, which determines the people and
external teams you’ll need to pull together to make the
strategic plan work.

The Strategic Project Plan

First, you need to document the expectations and high-level
requirements of the site. That’s the strategic project plan. But
while the strategic product plan pulls from a variety of
different sources, whether it be your marketing department,
your IT department, or some kind of stakeholder survey, it
is not a detailed manifesto.

Instead, the strategic project plan is, in essence, an actionable

path. It says “this is what we’re going to do” in a way that
defines the steps. If the project charter is the intent to travel,
and the project scope is selecting a final destination, the
strategic project plan is your Google Map. It’s not a step-by-
step documentation of every task and ticket – just as your
travel plan doesn’t include every rest stop and emergency
Wall Drug doughnut stop.17 Instead, it’s a road map that we
can work through in order to reach our goals.

A strategic project plan may include any of the following,

depending on your project needs:

• Reiteration of the purpose and expectations for the

website, sometimes even including enough history to help
identify and explain the initial spark
• Reiteration of project scope
• Project requirements, both explicit (as in, we need this
specific functionality and integration) and open for
interpretation (as in, we need a solution to a specific problem)
• Success measurement
• Expected deliverables and documentation
• Project timeline for both major stages and specific
deliverables
• Project discovery content, such as competitive or
contemporary analysis, content inventory and audit,
 branding and messaging requirements, or other business
strategy documentation

Much like the project scope, the project plan needs to

communicate just enough to breeze away any risk of
miscommunication, which means the more layers of project
resources – from interdepartmental to external agencies –
the more project planning is necessary. High-level purpose
and expectations can be important if the team is
disconnected from the initial spark; on the other hand, team
assignments might be completely unnecessary for a small
internal team.

In fact, the strategic web plan can include almost anything

related to the final project. It’s open to interpretation, and it
will largely depend on what you need.

Instead, it might be easier to tell you what is not part of a

strategic web plan:

• Business planning: While business needs and pain points

often surface during the discovery and testing phases of a
web project, the web project is not necessarily the time to
start trying to figure out who you are and what you want
to be when you grow up.
• Marketing planning: The website is an important part of
your marketing plan, and coordination between your
branding and web design is crucial … but we advise against
using your website as the testing ground for a full brand
refresh, unless the new site coincides with an existing
design study.

Not that these aren’t important or complementary – in fact,

mention of how a web project fits into business and
marketing planning is important – it’s just that trying to
shove every possible business fix into a single web project is
going to throw the project off and cause delays. The more
things you’re trying to change, the more you’ll have to plan
and the longer you’ll have to wait.

The Psychology of Documentation

Okay, but, come on. Has anyone actually ever read a
strategic project plan document? In our line of work … not
always. But that doesn’t make them worthless – it just
reminds us of the levels at which people interact with
documentation.

Remember, documentation is a communication tool. It’s

designed for people who aren’t in the room. Strategic
thinking is ethereal, and the decisions that are made
within a conference room only exist as far as they are
broadcast. If they’re not written down, they are lost.

Strategic documentation is a representation of the actual

work, not the actual work itself. It is a tool for approval
and buy-in. It drives change, but it is not change itself.

For example, at Blend, documentation is as simple or

complex as is necessary for our clients to approve our
work. If we’ve determined during the discovery phase
that the new site needs a new calendar, we can document
this (in order of complexity) as:

• A paragraph explaining the need for a calendar

• A detailed section documenting the specific features
of a new calendar
• A technical section outlining the functional and
technical specifications of the new calendar
 • A full document dedicated to the calendar, including
precise timeline and hours

Really, it depends on the level to which a decision needs

to be made. On one hand, you just need to acknowledge
that a calendar should be accounted for when we reach
design and CMS selection. On the other, you’re treating
the calendar as its own project, and you need a level of
detail that can help protect you from scope creep.18

The Operational Plan

And then, there’s the idea of operational planning. You have
a general idea of what you want to do, but now you need to
determine:

• A staffing outlook, including who will work on the project

and whether or not external resources are necessary.
• A formal capacity timeline, where the project is listed in
phases and real dates and deadlines are assigned.

In essence, who is going to work on it, and when will they do

it? The strategic project plan is more focused on what is
happening, the operational plan is the purview of your
project management team.

We discussed the concept of building a team in the last

chapter, but beyond this you will need to know what to
expect when reaching out for help. Let’s talk quickly about
proposals.

The Request for Proposal

At this point, with internal teams formed, you realize where
the gaps are. You need a plan of action for hiring someone to
fill the gaps. That’s where a request for proposal —
commonly referred to as an “RFP” and used to formally
request some kind of professional service — comes in.

Know this: in most cases, a request for proposal isn’t required

— they are for most projects funded by public money, but
otherwise they are completely optional – but they can be
incredibly effective in helping you choose between two
firms that you have your eye on, or to better understand the
landscape of firms. They can be great if you don’t already
have an existing relationship.

But if you know and trust a firm and you want them to work
for you … just hire them. Refer back to the first point: You
don’t always need a formal request for proposal.

What’s in a Proposal
Knowing what to put into a proposal can be overwhelming.
There’s a good chance you have no idea what to ask for, let
alone who to send it to.

There’s a balance between asking too much and not asking

enough. You could pack your proposal request with a ton of
questions – dozens of pages worth! – and get back a lot of
great answers … but you may also disqualify someone based
on a non-crucial factor, one that could be avoided through
simple conversation. On the other hand, asking for too little
in a request might flood your inbox with horrible fits.

So how do you do this? We have some tips:19

BE SELECTIVE
Do not send your RFP to everyone. Understand that the
amount of effort a firm will put into your response depends
on either how much work they have right now, or how good
the odds are that they’ll win the project. This means that:

• Desperate firms who need the work will respond to

anything.
• Selective firms will see that a bunch of firms have
received the RFP and won’t choose to respond, knowing
the odds of them getting it are too thin.

This is where pre-qualifying comes in. Look for firms that

work in your vertical, ask for referrals, or seek out thought
leaders in the industry. Usually making a quick phone call to
ask a few quick questions will disqualify a bunch of different
firms.

WRITE STORIES, NOT REQUIREMENTS

Websites aren’t just containers for features. They’re tools for
providing outcomes. If a person visits your site for a specific
reason, the site should fulfill that reason. Which means,
rather than a giant list of requirements, your RFP should ask
for a narrative response that tackles process.

Sure, you might need to know some functional details and

want to see a bullet list or two, but ultimately you’re looking
for someone who understands what you’re doing and why
you want it to happen – having them relay their version of
the story, alongside their proposed plan, will be invaluable.

Remember: the audience for an RFP isn’t just the vendors

you’re trying to attract. The work you do in writing an RFP
will pay off in helping you better understand what you want,
what is possible, and what is beyond your wildest dreams.
It’s easy to write down a feature during a planning meeting,
but it’s another thing to ask a vendor to spend time scoping
and placing a timeline on something you know isn’t
completely necessary.

BE HONEST ABOUT YOUR BUDGET (AND YOURSELF)

We know: the unspoken rule of agency life is that you never
let anyone know how much money you have. But in a case like
this, a good firm is going to take your budget and be honest
with you about how much can be done. It will also eliminate
firms that are non-starters, both those who choose not to
take on smaller projects and those who are too small to take
on gigantic projects.

Every web project, no matter the phase, requires a budget

for three separate things:

• Money: How much will this project cost in actual

currency. This is the most obvious.
• Time: How much time will this project take up? For some
organizations, time is the same as money – the twenty
hours a week that your internal content strategist spends
on a project is twenty hours you’ve paid them to do that
work instead of their day-to-day work.
• Attention or Priority: While not directly tied to money,
the amount of attention or priority a project gets ties
directly into how successful it will be. Attention and
priority often dictate both time and money.

As an organization, you ultimately need all three. You need

funding for the project, you need someone who can work on
the project, and you need leadership to give a high enough
priority for the project that it doesn’t fall into the cracks
every time some other initiative sprouts up.

Guessing at Budget, or “We Want a

Number”
A smart person who also happens to be an author of this
book once said “Proposals are hard.” Largely, this is
because everyone wants a number. As Deane wrote in his
blog post, “Everyone Wants a Number,”

“My struggle is that I want to give you a number that is honest

and accurate, while at the same time protecting my company
from unforeseen cost overruns. I obviously want to make a
profit, but – contrary to what some believe – I don’t want to
rip you off, and I do very much care that you feel like you got a
good value for your money at the end of the project.”

Proposal numbers can come in two different flavors:

• Fixed: We will give you a defined feature or project

for a fixed amount of money. For example, you get a
fully functioning website (with further, detailed
definition in some kind of long statement of work) for
$100,000.
• Hourly: Or, as we often call it, “time and materials,”
where you only pay for what you use. This means if
we estimate the project at $100,000 and we only use
half of the time, it ends up costing you $50,000. If we
end up using more time because of an expanded
scope or difficulties scheduling sprints or some other
ongoing issue, it might cost you $125,000.

The more detailed and confident we are with

 requirements, the better the number we can get. But all
of that takes a solid plan, which … we should get back to.

Also, be honest about yourself. Know your expectations, and

know your limitations. Give realistic and honest timelines
for when you’ll get back to vendors, and be clear about when
you’ll need help beyond simple feature development.

Understanding Timing
So, how long does a website take to build? You might as well
ask how long it takes a person to drive home from work – it
depends on so many factors (in this case, your distance from
home, whether or not you’re at work or on a vacation,
whether or not you’re walking or driving or flying, and even
the definition of “home” itself) that the answer is rendered
either impossible to determine or irrelevant.

What it comes down to is this: if you need a website by a

certain time, your implementation partners and web team
will let you know if that’s possible or not. It’s not as easy as
saying, “this takes 140 hours to build, so we can have it in 3.5
weeks (at 40 hours a week).” There’s so much more that goes
into it than the raw hours necessary to implement design
and write documentation.

For example, we often forget about coordination and

management time, and how it needs to be built into our
timeline. It’s easy to think that we sketch out an idea, we
throw it to a designer, and then someone immediately takes
it and codes it. But there are spaces that need to be built into
the process – gaps that allow for assessment or resource
shuffling. These spaces might include when the core team is
focused on their other day-to-day work, or when things are
waiting for review, approval, and testing.

Each phase within our project stack has its own unique
points of padded time as well. Working on strategy requires
a lot of decision making, which leads to periods where
stakeholders might mull things over. Content always takes
longer than you expect. And development has its own
unique challenges due to differing abilities within the team
or license hiccups.

Regardless, there are a handful of project management

methodologies that have been formatted for different kinds
of projects, two of which will be the most common: waterfall
methodology and agile methodology.

Waterfall vs. Agile: The Pros and Cons of Each

To bring it down to its most basic elements, waterfall
methodology dictates that your project will flow in one
direction – forward – much like a waterfall always flows
down. On the other hand, agile methodology20 is focused on
short sprints, where constant communication and iteration is
held in higher regard than a quickly outdated master plan.

Some people will tell you that waterfall is bad, and for some
organizations or industries it is. But simply throwing
waterfall out and assuming that agile methodologies like
Scrum21 are going to solve every problem is usually a recipe
for disaster.

I’ve heard about “agile” for a decade, to the point where it’s almost lost all meaning. But at a
conference in Singapore, a speaker managed to tickle some part of my brain with this
explanation that made sense to me, and I’ve never forgotten it: One of the core principles of
agile is that you can get all the way through a deploy and push some product to a staging
environment very quickly. You force fast iterations by making sure the team never gets too
 far away from this.

Just like a rock climber drives in a new piton for their safety rope when they get too far above
the last one, you never want to get so deep into a new round of changes that you’re not
pushing something new every week or two. If a segment of the project is bigger than a week,
break it down – find stopping points in the feature or change that can be pushed all the way
through to provide some working experience even if it’s fragmentary.

In this way, agile forces you to keep your focus on small changes and frequent pushes.

So, thank you, random Singaporean conference speaker, for managing to stick that
description to my brain.

— Deane Barker

For example, waterfall may seem rigid and unyielding, but

it’s often also faster, since requirements are determined at
the start instead of through a cycled process of iteration.
Stakeholders aren’t required at every meeting once they’ve
signed off on requirements, so teams that do well with
delegation can really move. Testing can be faster, since
software tests can begin being built from the moment of
requirement sign-off. And, because there’s less overlap, each
stage gets full attention at all times.

If you need to create a minimum viable product fast and

build from there, now you’re talking about agile
development. Working with large teams can benefit from
agile since it forces everyone to be together and
communicate, rather than let bad practices fester and draw
out. It also allows for change, so fast-moving industries can
see and react to product and site needs faster than with
waterfall.

Of course, the project methodology world – much like any

world that promises improvements – is vast and unending,
which allows a design and development team to pick and
choose from a variety of hybrid models, from modified
waterfall methods with fun names like “Sashimi” to pared-
back agile models like the one Blend often uses,
affectionately called “ScrumBut,” which means we use
Scrum, but … insert excuse here.

Projects, Phases, and Sprints

Regardless of how your design and development teams
decide to work, what you really need to know is how they’re
going to work and how that affects your timelines. You’ll also
need to understand the scope of how they break the project
apart – and the scope of how the project is going to be
tackled in the first place.

For example, are you building a small site? Are you building
a few sections of a larger site – or maybe the entire large site
at once? Is this thing we’re working on a full project, a phase,
or a sprint?

Some projects don’t have the structure to be broken into

pieces. They are to be started, built, and finished all at once,
and therefore need to be planned accordingly – from
making sure everything’s present at the start to
understanding the scope of the grand launch at the end.

Then, there are those who can employ the idea of a

“minimal viable product” that we mentioned before – where
a base level of design and functionality is then improved
upon over additional phases. This can come in two forms:

• Several phases of relatively similarly sized

improvements, where the full project might go from a
minimal viable product of 25% to 50% and on and on.
• One major phase – a full site built with 80% of potential
features in place, for example – and several
 supplementary phases to fill out other non-crucial or
“quality of life” features and functionality.

Finally, some projects never really end. They are in a constant

state of adjustment and are measured not in phases, but in
the individual sprints. They go through constant
improvement because the industry moves quickly, or
because the site is too large to halt, restructure, and launch as
brand new.

To be honest, this all feels like a lot. And it is. But project
planning is a promise.

It’s a promise for a future website, and it’s a promise for a

future launch date. It’s a promise for help – and it identifies
what is expected of that help. It’s a promise to keep things
rolling. It’s a promise to keep things tied to that initial
project spark.

Most of all, it’s a promise that you will take the project
seriously. That you’re really thinking about how things will
happen, who it will affect, and what your expectations are.
The biggest requirement of a web project plan is that it
answers questions and puts people at ease. It’s the document
that gets you to your end goal and gives everyone their
marching orders.

What goes into that document – and what work you do to

make your web project happen – is still entirely up to you
and the business needs of the site. In this next section, we’re
going to start looking at how we decide what a website needs
based on three things – what it already has, who it is meant
to serve, and how it’s being perceived. It’s time for discovery.

Inputs and Outputs

Depending on your process, you may create a plan based on
an existing project charter or project scope. You will
probably bring in your business or marketing plans, and if
you are doing a discovery-to-plan model you’re going to
have a content inventory, audit, personas or archetypes, and
wireframes or prototypes.

Your output is the plan itself, in whatever form it takes.

The Big Picture

Web planning can really happen at any time. It’s most often
going to happen before the project kicks off, or before any
major phase or portion of the stack. You can draft a gigantic
plan for the entire site at the moment scope is determined,
or you can break the project into smaller pieces (a kind of
plan in and of itself) and tackle each section with its own
plan.

At Blend, we’ve found a lot of success with a discovery-to-

plan model, where we begin with a requirements-gathering
project and then scope based on real findings and project
requirements. For our full-stack clients, this is a project that
goes from discovery to wireframes or design, while for our
development-only clients this is a technical discovery and
scoping project. What this leaves us with is a detailed list of
requirements that we can then both accurately bid and plan.

Planning for your team – including hiring an external

partner – might come before you ever think about web
functionality. In fact, you may hire an external partner to
actually create parts of your web plan.

Staffing
Your staffing needs for a strategic plan are going to depend
on whether you do it yourself (you’ll reach out to your web
steering committee or web project team) or whether or not
you hire someone to handle it (during which point you may
already have the basics of a plan in order to facilitate the
proposal).

17 Welcome to South Dakota. Here’s your free ice water!

18 Scope creep, as defined by the Project Management Institute, is “adding additional features or
functions of a new product, requirements, or work that is not authorized (i.e., beyond the agreed-
upon scope).” It occurs either on purpose, like when you give your kids an hour limit on Minecraft
and they ask for just five more minutes, or it happens on accident, like when you try to replace a few
boards on your deck and you keep finding additional rotten boards.
19 While this section is just three little sections, we’ve actually culled this from a longer list of five
tips that you can find on Blend’s blog: www.blendinteractive.com/news/five-tips-to-getting-a-
good-response-to-a-content-management-rfp.
20 Manifesto for Agile Software Development, agilemanifesto.org/.
21 “What Is Scrum?” Scrum.org, www.scrum.org/resources/what-is-scrum.
 SECTION 2
DISCOVERY

While a new web project often depends on some

kind of impersonal business goal, it’s ultimately
driven by the people who will use it. After all,
you can build anything you want, but if it doesn’t
meet your users’ expectations, it’s as good as
worthless. A little research goes a long way —
both into the who and what, but also into the
stuff you’ve already got.
CHAPTER 5

Identify Your Audiences

SUMMARY
We build websites to prompt an action or convey
information to humans. Who are your humans? What are
their motivations?

DOES THIS APPLY?

You always need to know the people who will be affected by
your new site or project, without a doubt. In fact, unless your
site is purely a vanity project, there’s no excuse for not
understanding the people who will ultimately use the site.

We’ve seen a lot of bad food ideas. Heck, we’re living it every
day; this is an era, after all, in which everything is dusted
with Flamin’ Hot Cheetos powder and shaped like a sushi
roll. Where wrapping a taco in a Doritos shell and chasing it
with radioactive-colored Mountain Dew isn’t just a
challenge: it’s a way of life.

But at least we’re not living in a world that accepted Gerber

Singles.

Gerber – the United States baby food company – was riding

high in the 1960s, still feeling the effects of the post-war
baby boom. But as birth rates dropped, the bottom line of
companies like Gerber, who were still struggling to diversify
beyond baby products, began to suffer.

“But what if,” Gerber thought, “baby food wasn’t just for
babies?”

With this, Gerber Singles were born. They were designed to

be quick and easy meals for the newly independent – like
college students or single adults who had just moved into
their first house – and, as an added cost benefit, they were
packaged in Gerber’s existing jars.

They weren’t baby food, you see. They came in adult flavors.
Beef Burgundy. Mediterranean Vegetables. Creamed Beef.

You can see where this is going. Turns out, adults don’t like
eating baby food, even if it’s not called baby food. They like
their Beef Burgundy to have a texture, and they like their
vegetables to be multi-colored and … whole.

More than that, adults don’t like to see themselves as giving

up, and Gerber Singles were a symbol for giving up.
Newfound freedom, whether as a single adult or as a new
college student, is about discovery and adventure, and even
if those two things never happen, no one wants to admit
defeat.

Welcome to the Discovery Phase

Gerber was – and still is – very good at what they do:
providing baby food products that are plain enough to
appeal to a wide range of developing eaters. They are experts
in that field. But they are not experts in adult food. They are
not experts in what the freedom-seeking new renter or
college student wants for dinner.

The problem wasn’t that they swung and missed at a

potential product. The problem is that they didn’t
understand the fundamental differences between their
existing audiences and their new audiences. And they didn’t
bother to ask.

We all like to think that people are waiting on our new

website with bated breath; that every page is going to be a
masterpiece, and that flipping that switch is going to drive
some kind of magic event. But, to most people, our website
is yet another thing that someone will encounter during the
day – sometimes on purpose, sometimes as an obstacle. We
have to meet them at their level.

We’re not going to mince words here: building a site without

knowing your audiences – without understanding why those
users arrive on your site and what they want – is an exercise
in arrogance. You may think it’s a way to cut costs, or to save
time, or that you already know everything you want to know
about the people who will visit your new website. In reality,
it’s the equivalent of saying you simply don’t care about the
people who are visiting your new website.

We know you care. You wouldn’t be reading this if you

didn’t care.

This is the point in a project most often called “discovery,” in

which we learn. Discovery can mean a lot of things, and
depending on the project it can be long or short, detailed or
surface-level, focused on all aspects of a product or lifecycle,
or simply focused on a specific user behavior. In fact, the
different directions in which a discovery phase can take can
feel overwhelming to someone who simply wants to know
what to do next.

These varied options are by design. In his book Practical

Design Discovery,22 Dan Brown maps the discovery process as
a grid called the Complete Discovery Activities Matrix, in
which discovery activities are plotted against two axes:

• Convergent vs. Divergent Thinking: Are these tasks

helping us dial into specifics, or are they helping us
understand the wider landscape?
• Framing Problems vs. Setting Direction: Are we setting
the stage for the project or are we making decisions for
next steps?23

Much of this section of the book — the Discovery section —

is focused on this grid, with most of the tasks and activities
landing in the gather and process quadrants. We can start
the discovery process by getting to know your people.
Figure 5.1: Dan Brown’s Complete Discovery Activities Matrix.

Users? People? Robots?

Should we address the nomenclature of what a person
on a website should be called? This is an ongoing debate
in the world of user experience, which ironically enough
has fought against the name “user” for years as being
cold and reductive. But what else can you use?

“Visitor” implies they aren’t there to stay, which is

antithetical to most business purposes. “Audience” or
“Segment” – or even getting more specific and referring
to the people who visit your site by a site persona name
 like “Mike Member” – might work on a case-by-case
basis, but probably doesn’t hold past that.

At Blend, we usually still say “users.” But when it comes

down to it, except in the case of search engine crawlers
and ad trackers, they all have one thing in common:
they’re people.

Knowing Your Site Means Identifying

Your Audiences
People in this world — and we mean every person — exist in
two binary states, as far as your website is concerned:

• They either visit your site or they don’t.

• They provide value to your mission or they don’t.
Figure 5.2: Visitor vs. Value Grid.

We break this down to show two things. First of all, not

everyone who visits your site is a mission-critical audience.
In fact, not everyone who interacts with your business or
organization is a mission-critical audience. This is important
to remember: it’s easy to get caught up in serving everyone,
but the truth is you don’t have to account for everyone.

Let’s repeat that one more time. You. Do. Not. Need. To.
Account. For. Everyone.24

Two groups of people will take up the bulk of your attention:

people with mission value that already visit (where the focus
is on retention) and people with mission value who don’t
currently visit (where the focus is on capturing their
attention.) Little attention needs to be paid to site visitors
who don’t fulfill any organizational or site need, and there’s
zero reason to worry about those who don’t visit and don’t
have any connection to your organization.

One of the best conference talks I ever heard was Scott Hanselman’s “It’s Not What You
Read, It’s What You Ignore.” We’re deluged under so much information that our ability to
exclude is arguably more important to include.

It’s the same for audiences. If you’re a local retail store, you don’t have to worry about
excluding audiences from your store, because if they physically exist in your area, they are
your audience. However, if you’re in Cleveland, you’re not spending a lot of time worrying
about how to cater to people in Phoenix.

On the web, potentially everyone can visit, and there’s a vast distance between someone who
can help you further a business goal and someone who is just … useless, in that sense. As
harsh as it sounds, learn what audiences you should ignore, and spend that energy on the
audiences you shouldn’t.

— Deane Barker

Here’s an example of determining high-level audiences. This

book has been written, in part, through use of a scheduled
weekly exercise at a place called The Source, a coffee shop in
Sioux Falls, South Dakota, that also serves beer, but most
importantly stays open past 8 p.m. Let’s walk through the
people who connect with The Source every day:

• People who drink coffee

• People who drink beer
• People who live or work in downtown Sioux Falls and
walk by it once in a while
• People who work in Jones421, the complex that houses
The Source
• Employees of The Source
• People who buy coffee beans from The Source
• People who service the automatic beer machines

All of these are audiences of The Source as a location. But not

all of them are audiences of The Source’s website. Which
means when it comes to determining site audiences, we can
weed out some people – the people who service the
automatic beer machines, for example – and deemphasize
marginal audiences, such as employees of The Source.
What’s more, this list doesn’t include those who are not
present: what about someone who wants to apply for a job, or
someone who is traveling in from out of town?

Site audiences require clarity and priority. In our above

example, we have several major audiences: people who
drink coffee, people who drink beer, people who buy coffee
beans. We have some secondary audiences: people who
work in Jones421, people who want to apply for a job. And
we have audiences that we don’t need to focus on at all.

As you walk through these audiences within your own

organization, you’ll organize audiences into sub-audiences.
It’s going to be a lot of picky, frustrated discussion around
priority – but this is good! Discussion is where the edge cases
come up, and it’s how you start whittling your list down to
something manageable.

Online and On Mission

At Blend, we owe a lot to C. David Gammel and his book
Online and On Mission for how we have developed our
“audiences and outcomes” discovery process. In his
book, Gammel defines an audience as: Any group of people
with some measurable characteristic in common which
 influences how relevant and significant they are to your specific
outcomes.

An outcome – which we’ll talk about in the next chapter

– is:

A measurable change, action, or behavior that you wish a

visitor to take or experience.

Researching People: Who Are You

Looking For?
A list of audiences is one thing. Knowing the kinds of people
who make up those audiences is another.

In understanding your audiences, you’re looking for a

balance between two things: who they are – in other words,
independent of your product or service, what kind of person
helps to contribute to this audience – and what they want –
in other words, independent of what kind of person they are,
how does this person view, interact, and create expectations
around your product or service.

The spectrum of information needed to fully understand an

audience group goes from the base level of demographic
information – age, hometown, languages spoken – to
contextual and psychological desires. What mood are they in
when they encounter your site? What pain points are they
experiencing? What do they view as a successful transaction?

We can group these into data types:

• Demographics: Who are they? Where do they live? What

unique characteristics do they exhibit?
• Psychographics: What do they rely on to make decisions?
What biases or assumptions do they have?
• Context: How do they interact with your product or
service? How will they interact with your website? How do
they interact with the web in general?

There’s a lot to digest in that spectrum, and no amount of

research can capture everything. User research should focus
only on what you need to know: what information helps us
make an informed decision about this specific project? You
need what’s called a “research question.” Erika Hall wrote
about this in a Medium article titled “Research Questions
Are Not Interview Questions”:

You won’t even know whether doing interviews is the right thing
until after you’ve written your research question. It might be
more effective to read existing literature, or observe people out in
the world, or do a competitive analysis instead.25

So, start with that research question. As you determine your

audiences, spell out what you want to know about them.
Position the question in a way that asks not just about the
person, but about their motivations and, ultimately, what
they need from your project.

• How does a potential student make a decision about

attending a university?
• Why does a person choose to order coffee beans online
rather than order them from the physical location?
• What goes into the process for selecting a development
vendor for a large content management project?
 It’s difficult to talk about audience determination and research without simply quoting
paragraph after paragraph of Erika Hall’s Just Enough Research, a wonderful book that dives
deep into all aspects of project research – organizational research, user research, competitive
research – and provides a rich base layer for understanding how to find your audiences’
motivations.

I believe in Just Enough Research so much I’m spending my own valuable counterpoint time
on it.

— Corey Vilhauer

Finding and Talking to Audiences

First, you’ll need to reach out to your audiences, which
depends on how close you are in the first place.

• Use your connections: If you are building an intranet for

your organization, or if you are working on something for
the sales department, or you want to develop a new
registration system for events, you already have the
connections you need. For the intranet or sales site, you
simply reach out to those employees or consultants. For
the new registration system, you reach out to people
you’ve worked with in the past via an email request, or as
they purchase their next set of tickets.
• Go to them where they are: While using your existing
resources works for those who are already connected to
you in some way, some audiences cannot be reached by
nature of their makeup. For example, you don’t have the
email addresses of prospective students because you
haven’t met them yet. So you have to find a representative
example.
• Reach out to them randomly: It’s not ideal, but
sometimes you need to simply reach out to people
 randomly, scattering a survey or a chunk of interview
requests into the wind and hoping you can find some
valuable information. The more universal your needs, the
easier this will be; the difficulty is finding valid interview
subjects for niche audiences.

Remember that a single subject can fulfill the requirement

for multiple audiences. Interviewing a current graduate
student might give you insight not only on why that student
chose the university or what they needed from admissions
during the application process, but also what they need as a
current student.

Once you’ve found your interviewees, you’ll have a decision

around how you perform research. You can call them, or
meet them in person, or tag along with them as they do their
everyday tasks. Ask them things that will help you answer
your research question. Try to get to know that person,
because that person is one of the closest ways you’ll ever
really understand the people who use your site.

“But what about focus groups?”

To say focus groups are troublesome is an understatement. By putting multiple people —

often strangers — in a room, you risk losing any chance of developing a rapport with any one
of them. Some people will speak up a lot, and others will fade into the background.

Honest answers give way to group agreement. They’re rarely as valuable as one-on-one
interviews or user research.

— Corey Vilhauer

Finally, let’s focus on what you collect during these research

opportunities. Questions focused on demographics are easy
to ask, and they have their place: they are a simple way to
break the ice and help an interview subject to open up. But
be careful with these kinds of questions. They often don’t
add any value on their own, and they can add unwanted bias.

For example, it might seem like common sense to track the

age of users, and then assign specific characteristics based on
age. But in most cases, you don’t actually care about age —
you care about naivety, or inexperience. Age doesn’t matter
in this case — the level of familiarity and experience does.
Focusing on age means you’ll start focusing your solutions
on older people, when in reality the issue persists regardless
of age.

Instead, focus on how and why your interview subjects will

use the site, so you can create a plan that will cater to their
needs without worrying about what state they live in.26

More than that, understand that you’re asking people for

both their time and a piece of their personal experience.
Interviewing people – even for something as cold and
lifeless as a website – is what Steve Portigal, in his book
Interviewing Users, calls a “shared experience”:

In addition to the information we learn from people and the

inspiration we gain from meeting them, there’s a whole other set
of transformations we go through. You might call it empathy –
say a more specific understanding of the experience and emotions
of the customer – which might even be as simple as seeing “the
user” or “the customer” as a real live person in all their glorious
complexity.27

What kinds of things do you ask? Depends on what you need

to know about your users. For example, if a web design firm
wants to learn about what potential clients want, they might
ask:
• At what point in your process do you begin looking for a
web design firm?
• What factors play the biggest part in choosing a web
design firm?
• What kinds of things are you interested in seeing to prove
a firm’s ability to handle your project?
• How will you make contact with a firm that you’re
interested in talking to?

In research, variety is the spice of life. It’s important to

consult people who experience the world differently from
you and your colleagues. Interview underserved sections of
the population, or people who don’t often get a chance to
influence decisions. This will provide you with a richer and
more inclusive body of knowledge.

And know that you won’t always get what you came for.
You’re going to talk to people who simply don’t care and
can’t be bothered. You’re going to hear things you wish
you’d known earlier. No matter what, someone will
complain or push back against something you feel is a great
idea. Just remember that one person’s opinion does not
validate a bad idea. Especially remember that you will not
reach everyone.

Needs of People vs. Needs of Organization

As you interview potential site visitors and document their
stories and site needs, you’re going to begin shaping your
vision of a site toward the perfect user experience: a
wonderful bubble of cool interfaces and smart answers and
brilliant design. These are noble goals, but remember that
you aren’t just building a site for the people who are going to
use it: you’re also building a site as a tool for your
organization.

This means every scenario and user situation needs to be

shaped not only through what they need within their
experience, but also how that experience benefits your
organization. It’s not enough to blindly provide every
possible customization option if half of them don’t relate to
your product or service. We’re not telling you to sell your
users or promote engagement over their simple unalienable
rights: a clear purpose, an accessible site, and an honest
message. We’re just reminding you to not take every user
request as gospel.

When Do You Stop?

You stop when it’s time to stop. No earlier, no later.

This is a horrible answer, we know. But research can be

unending. The levels to which you can dive into the minds
of the people who will visit your site can be staggering, and
often depends on either how much your organization values
research and strategic planning over gut decision making or
the size of your web budget.

Since Corey isn’t going to call out his own talk here, I will: Corey once gave a talk entitled
“Empathy: Content Strategy’s Hidden Deliverable.”

Make no mistake, empathy is what we’re talking about in this chapter. You build great things by
empathizing with the people who will use them. And you cannot do that unless you know
who those people are.

It’s hard to walk a mile in someone else’s shoes if you don’t even know how to find them.

— Deane Barker
The amount and need for research is tied into the overall
scope of the project; if you are planning a system of web
magazines under a large publishing umbrella with millions
of dollars of ad revenue, you’d better believe you need more
than just a handful of phone calls and a quick heat map test.
However, if you’re a small shop building the first of what
you hope is decades of web iterations, then your research
might be light at the start.

Regardless, at the end you should be able to answer two

basic questions:

• Who will visit this site?

• Which of these audiences should be prioritized?

You’ll usually know to stop, though. It might be budget

bound (you’ve run out of money, or time) or you might be
getting the same answers over and over again.

Documenting Your Findings:

Archetypes, Personas, and Beyond
The work in knowing, interviewing, and documenting your
audiences is more than pure busywork: this is work that
helps illuminate your site’s purpose. Of course, how you
illustrate those audiences can be just as varied as the
audiences themselves, depending ultimately on your goals
for audience research.

With the idea that this documentation is the physical

manifestation of your research question, there are a few
formats that could work:

• Personas: Personas are fictional representations of a

 member of an audience. They provide names, faces, and
personalities for a user audience, and they allow our
minds to move from abstract to concrete – instead of
“what would this audience do,” it becomes “what would
Mike Persona do?”
• Archetypes: Archetypes are quick snapshots of audience
behaviors. While the difference between an archetype and
a persona might seem incredibly subtle, it’s actually a
difference in direction and intent. Where personas focus
on the fictional representation of someone within a
unique audience, archetypes focus on a set of situational
traits. A persona (Mike Persona) might fall into multiple
archetypes (New Student; Local Resident).
• User Stories: User stories are informal narratives that
help determine feature needs, and are often used in
software development. In short, a user story combines
audience needs (an issue that’s assigned to a role) with
development needs (the feature that solves the issue).
They take several shapes; one example comes from Sarah
Richard’s book Content Design): “As a [person in a
particular role], I want to [perform an action or find
something out], so that [I can achieve my goal of …]”28
• Journey or Experience Maps: You want to understand
how a person moves through their motivations and
contexts? You want a journey map, where a
persona/archetype walks through phases of a project,
their highs and lows mapped alongside the project’s
potential areas of improvement.

Care must be taken to make sure these artifacts do not

perpetuate stereotypes and amplify biases. It’s very easy to
get lost in your own head when creating these
representations, so make sure you run any kind of user
documentation past your entire group to confirm that it
both accurately represents the users who may encounter the
site and steers clear of lazy generalizations and stereotypes.

Of course, none of this matters if you don’t use it. Reading

further into Practical Design Discovery, Dan Brown labels user
data as a “design tool,” saying:

Think about how you’ll use insights about users as part of

ongoing design activities. I use them to kick off brainstorming
sessions and as a preface to design review meetings. The format
you choose for asserting user context should be one you can use in
these and similar situations.29

When the multi-faceted world of web design shows up on

our doorstep, we often want something prescriptive.
However, the world of web design isn’t one that adheres to
strict rules, which means over time we’ll find our own
methods and needs. You may take user data and smash
together a Frankenstien’s monster of documentation, taking
the good bits from persona design and adding them to a user
story. Whatever works for you is the thing you should be doing.

Now, even though we’ve discussed this documentation here,

it’s not complete without the next chapter. This kind of
documentation often includes not just the who, but also what
– meaning the expectations and needs of those people.

Inputs and Outputs

Before you know the people who will visit the site, you must
get in touch with the people who are most likely to visit your
site.30 This might come from lists of potential customers, or
it might come from referrals from past clients, or maybe
your site is general enough that you can prop yourself in a
coffee shop and interview people for the cost of a coffee.31

The most likely output from this phase of a project is some

level of documentation around user representation, whether
that’s something complex like a journey map or something
simple like a list of expectations. Most often, this is where
personas or archetypes are created, and those artifacts live
on as a simple representation of the people who will visit the
site.

The Big Picture

Understanding audiences and user research happens before
the strategic phases of a site – you’ll want to know who
you’re building for before you make great pains toward how
you’ll build it. This, tied with outcomes and expectations
from the next chapter, make the bulk of the research-driven
discovery process.

Staffing
There are people out there who specialize in research and
user testing, and this is baked into the on-the-job training of
nearly any content strategist or web designer position. The
work of talking to people is woefully under-represented as a
“soft skill,” but it’s a crucial skill of which anyone who falls
into the strategic design phases of a site should have a
passing familiarity.

22 Remember this book, because we’ll quote it a lot: it’s a wonderful resource for understanding
the psychology and methods behind understanding site users.
23 Brown, Dan. Practical Design Discovery. A Book Apart, 2017.
24 This, of course, does not mean that you shouldn’t provide an inclusive and accessible
environment for anyone who visits your site. We’re talking about a user’s need for your
information, not their ability to access that information.
25 Hall, Erika. “Research Questions Are Not Interview Questions.” Medium, Mule Design Studio, 3
Sept. 2020, medium.com/mule-design/research-questions-are-not-interview-questions-
7f90602eb533.
26 Unless, of course, this is a relevant part of the project.
27 Portigal, Steve. Interviewing Users: How to Uncover Compelling Insights. Rosenfeld Media, 2013.
28 Richards, Sarah. Content Design. Content Design, 2017.
29 Brown, Dan. Practical Design Discovery. A Book Apart, 2017.
30 This can be one of the most challenging aspects of research – if you work at a university, for
example, how do you reliably understand a student who passed on your university if they never
once visit campus or fill out a survey?
31 This is called cafe testing, a concept that came across our desks thanks to a post from content
strategist Daniel Eizans.
CHAPTER 6

Identify Outcomes and

Expectations
SUMMARY
Your content and message – and your audiences – live on
dozens of paths and hundreds of combinations.
Understanding what they’re looking for when they access
your project will have a large impact on the steps that follow.

DOES THIS APPLY?

Just as you need to know the people you’re building for, you
also need to know what they expect out of your project. Both
building to and tempering expectations often becomes the
major, overarching thread of a full-stack web project, so
knowing what those expectations are gives you a head start
(and fewer headaches).
In the fall of 2013, the United States federal government,
driven by passage of the Patient Protection and Affordable
Care Act (PPACA), created HealthCare.gov, a health
insurance exchange website designed to help those who
don’t already receive health insurance better understand
their options.

To say this site was the crown jewel of the administration’s

fight for more affordable health care isn’t an overstatement:
it served as a public representation of years of attempted
health care reform. It was the answer to a promise – a
promise that, in part, defined the first half of President
Barack Obama’s time in office. And, on October 1, 2013,
despite the beginning of a government shutdown, the site
launched, ready for the world.

Well. Almost ready.

You see, HealthCare.gov, by any sense of the metaphor,

stumbled out of the starting gate. It was new and a little
confusing, and it was immediately panned by the Obama
administration’s political rivals. But, more than that, it was
plagued from the beginning by technical issues. The
complexity of its interconnecting systems wreaked havoc on
how information was passed from one page to the next, and
it was constantly being flummoxed and overpowered.

But, even if the technical side had held its side of the
bargain, the user experience – the user paths, the labeling,
and the information architecture – was designed in a way
that promoted failure. Confusing homepage buttons made it
difficult to know where to even start. Help text and
navigation were focused on terms used by the agency,
instead of plain language that a site user might understand.
Forms seemed overcomplicated, carousels hid useful
wayfinding text, and technical failures were hidden until a
user completed the process.

Your website is part of a larger story, and because of this it

must follow a logical story structure. Donna Lichaw, in her
book The User’s Journey, calls this the narrative arc: the
application of a beginning, middle, and end, buoyed by
rising action and excitement until it is released. There’s
background exposition that hits a pain point (the inciting
incident) and action rises until it reaches climax (the point of
action).32

For the people who visit your site, the climax is the moment
before they reach their solution, and the success of that
moment can either end with a slow denouement or a rapid
and harsh cliffhanger. HealthCare.gov definitely started its
life as a promising solution, but as it encountered real people
with real problems, it lost the plot. Users arrived on the site
with an expectation for how their experience might roll out,
and instead the site brought them to the brink and led them
directly off of a cliff.

In order to provide satisfaction – and to keep them from

being thrust into their own personal cliffhanger – we start by
understanding what a site user is looking for.

Defining Expectations and Outcomes

An expectation is what someone wants and expects – it’s a
combination of personal preference, social cues, and history.
In Thinking, Fast and Slow, Daniel Kahneman talks about two
kinds of expectations: passive expectations, in which you are
conditioned to not be surprised by an occurrence — such as
how running into a friend at a grocery store is less surprising
if you know they live in the area — and active expectations,
in which you are conditioned to expect certain occurrences
given the clues around you, such as how you expect to find
ice cream in the same spot no matter the grocery store.

These two forms of expectation frame many of the

emotions we encounter on a website: we shouldn’t be
surprised by things we don’t expect, and we should feel
successful with the things we do expect.

An outcome is an action or feeling that comes as the result of

your time on a website. Outcomes can be:

• An action, such as completing a task: “I successfully

purchased a new screen printed poster.”
• A change, such as understanding a concept: “I now
understand the history and culture of lucha libre masks.”
• A behavior, such as an emotion: “I am happy after
watching that cat video.”

Outcomes should be measurable. They represent what you’d

like to have people do, and they represent what people
expect to do. To frame both these terms, think of
expectations as emotional benchmarks. The outcomes we
provide for a site user are perceived to be successful or
valuable only if they match or exceed those benchmarks.

Researching Expectations: What Are

They Looking For?
In our world, the discovery (or research) phase is a kind of
nebulous period in which we as web practitioners are
making our best attempt at understanding the overall goals
of the site.

We think that’s worth noting – that we said “goals,” and not,

say, “users” or “functionality” or “features.” While everything
we’ve covered up to this point might be considered a part of
a “discovery” phase, all actions and exercises are leading
toward one outcome: to better understand how to make the
web project a success. To understand the expectations of
what someone wants.

There are two ways to go about this:

• Workshops: A discovery workshop is going to focus on

learning more about users, sure, but it’s also going to dive
into our assumptions about what those users expect when
they come to your site.
• Interviews: Interviews dive deeper into individuals, and
can be the best possible source of actual user truths: if you
want to understand user expectations, ask the users
themselves.

The right answer, as always, is probably somewhere in

between. There is a great amount of value in conferring with
users and bringing them into the process – in fact, in nearly
every case it’s ideal. But there’s also a balance. Users know
what they want, but they know what they want based on
what they already know.

Progress and new innovation doesn’t just come from the

expectations of users, but also from the creative solutions of
those deeply tied to the business itself. Both matter.

At Blend, we often engage in discovery workshops right off

of the bat. In this model, the discovery workshop is designed
to:

• Get all stakeholders on the same page regarding site

audiences and potential outcomes.
• Allow us as web practitioners to better understand the
organizational dynamics and the client’s industry itself.
• Form a starting point for the project.

Then, once we understand the product and the business

goals of the site, we can ask about expectations with real
direction.

Contemporary and Competitive Analysis

Despite our desire to be, among all things, unique and
special, at a general level most businesses or organizations
are neither. It doesn’t matter if you sell fish lures, provide
tax guidance, or inform parents of student activities, there’s
definitely someone else out there who probably does it. And
you probably already know this – after all, you encounter
competition, meet with people from similar organizations at
conferences, and look for insight among those who may
have gone before you.

Use this to your advantage.

There’s no shame in sneaking a peek at your competitors. I

promise you they’re doing the same thing.

What’s more, deeper study into your competitors may find

that you’re doing something that they’re not. You may be
providing a unique service, or surfacing different kinds of
information on your site, or changing your overall
messaging and marketing focus compared to the rest of the
industry. While your business or organization may not be, at
heart, a unique endeavor, it does have uniqueness built into it.
These are your differentiating factors. Knowing these
differentiating factors – and understanding how competitors
and contemporaries handle their differentiating factors – can
be crucial to communicating your value.

What you’re looking for is three-fold:

• Missing Details: Is there something related to our

proposed audiences that we are forgetting to take on? Or,
are there entire audiences that we’ve forgotten to include?
(If so, jump back a chapter!)
• Confirmation: Do our decisions make sense as compared
to those who do similar work? Are we on the same page
when it comes to understanding motivations?
• Opportunities: Are there things that we’re doing,
solutions we’re providing, or expectations we’re fulfilling
that seem untouched by the industry? Are we trailblazing
in a direction that others have let go?

With all of these remember that you are not the same as
your competitors. Brand new ideas in web content and
design are few and far between, but competitive analysis can
provide a spark toward finding your unique ideas and
developing new questions and potential outcomes. You
cannot take your competitors’ ideas as a guide, though: don’t
look at a competitor and think, “Yeah, this is what we need to
copy, right here, right now.” That does your company – and
your users – a disservice. Your users are there to hang with
you. Show them something unique.

Domain Knowledge and the Domain

Model
If you’re a person working from outside of a specific
domain, the weight of understanding expectations is
further magnified by being disconnected from the
 unique language, relationships, and knowledge bases
required of that domain. As a web shop, we’ve worked
with research hospitals, niche manufacturing
warehouses, and aircraft type clubs, all of which came
with two levels of discovery: understanding the potential
site, and understanding the industry itself.

In their book Designing Connected Content, Carrie Hane

and Mike Atherton outline their method for a mental
model called a “domain model,”33 which is simply a
conceptual model of a subject domain, showing the
relationships between different pieces of a specific
domain.

For example, someone who doesn’t understand the

domain of collecting vinyl records might not understand
that the basic unit – a record – is tied to multiple
different domain objects. A record has source-level
connections: a master release (the single identifiable
source, e.g., “Shake It Up” by The Cars), contains
different versions (e.g., the remastered reissue from
2018), each of which might contain different pressings. It
also has individual-level connections: a specific record
will have a media quality (the condition of the specific
record you are buying, e.g., very good), a sleeve quality,
and a price.

These seem like weird details, but understanding these

domain connections helps you determine the level to
which a user’s expectations can be met. We’ll talk more
about this in Model Your Content.

Outcomes: The End Point of a User

Journey
Audience research is usually focused on figuring out what
they’re going to do while they’re on your site. I promise you
they want to do something. They might want to find a
product or watch a video. They may want to figure out why
they ended up on this site in the first place. They may even
want to immediately leave – in and of itself an outcome,
though not necessarily a positive one.

We do this by baking expectations and potential outcomes

into our interviews. Beyond just knowing who they are, we
need to know what their process is. We need to ask them
questions like:

• What do you expect when you arrive on the site? Note:

this is very different from asking “What do you want to do
when you arrive on the site?”
• When you want to rent a movie, what do you expect the
process will be like?
• When you finish paying for your items, what do you
expect the next steps will be?

In programming, there’s actually something called the “The Principle of Least Astonishment”
which says that every feature in a product (and your website is a product) should do the least
astonishing thing. If a feature does something that no one expects, then that feature might
need to be redesigned.

— Deane Barker

Questions like this shift the focus from what the user wants
to do (because no one really wants to check their email for a
receipt from Amazon) to what they expect – in this case, you
expect there to be a receipt, even if you’re not immediately
going to print it and frame it forever. This focus on
outcomes over features – on “what do you expect” rather
than “what do you want to do” – allows us to be more
accommodating in our site functionality. It allows us to
make sure everything is purposeful. It saves us from having
a half dozen blogs for the simple outdated reason that
someone we talked to mentioned a blog once.

Straight up, the hardest thing to overcome in any project is

understanding that what we think a user wants and what a
user thinks they want may not necessarily be congruous to
what their actual expectations require.

Documenting Outcomes
After all of this research, you’re going to end up with an
unwieldy list of potential site outcomes. There will be a LOT
of outcomes, because everyone wants something, and they
all want something different.

Imagine, if you will, that you’re helping determine site

functionality for SpeakerBox, a totally fake company that
sells aftermarket car stereo parts – the stuff you use to
customize your “sweet ride” to “totally bump” to the new, I
dunno … Dr. Dre album.34 We’ve interviewed a ton of
people, and we’ve conferred with our central web and
marketing team, and we have come up with a giant list of
potential outcomes for the site:

• Learn about whether or not SpeakerBox carries parts for

my vehicle
• Learn about whether or not SpeakerBox carries parts for
my stereo brand
• Purchase a SpeakerBox product
• Find a SpeakerBox warranty
• Learn about what kinds of services SpeakerBox offers
• Find information about the corporate board and
employees
• See how SpeakerBox’s products match up to their
competitors
• Get information on investments
• Get information on how to install a SpeakerBox
component
• Find news and updates on the organization and the
industry
• Gain confidence in SpeakerBox’s quality
• Contact a sales representative
• Find and request a repair
• Learn about SpeakerBox’s return policy
• See new products as they are announced
• Find imagery to use in circulars and promotions
• Search and apply for a job
• Log in to vendor support
• Learn about employee benefits
• Find online retailers that sell SpeakerBox components
• Find physical locations that sell SpeakerBox components

Right away we can see that if we try to handle all of these at

once, we’ll drown in functionality options. We must
combine these into several high-level outcome groups,
within which we can build a process that handles multiple
potential outcomes. So, we look for and find those groups.

While we still have the same large list of potential outcomes,

we now see we’re really only looking at seven high-level
outcome groups. This is what we hope people will do when
they reach our site, based on our organizational goals, the
wants and needs of the people we’ve interviewed, and the
tasks provided by our competitors during that analysis. We
can feel confident in creating functionality based on these
outcome groupings, with the understanding that certain
outcomes (for example: learn about SpeakerBox’s return
policy) will serve the expectations of multiple audiences
(sales partners, potential purchasers, past purchasers).
Figure 6.1: Combining Outcomes into Logical Groups.

These high-level outcome groups also provide a bit of

context to the overall site. In the SpeakerBox example, we
might see a group like “Learn about SpeakerBox as an
investment,” and see that it really only relates to a small
fraction of site users (current and potential investors) and
provides little valuable information that can’t be found
elsewhere. Maybe this is a section that does not need to be
included in the initial phases – or at all.

From Discovery to Direction

As we wind down our initial research, we’re really starting to
nail together a kind of rough outline of purpose and
viability. Plenty of research is left to tackle – non “discovery”
research, like user testing, and even live research like
analytics tracking – but at some point we need to admit to
ourselves that it’s time to move from discovery to direction.
It’s time to start making decisions. The entire purpose of
researching a user’s expected outcomes is to provide better
access to those outcomes, most often handled through some
kind of site content or functionality.

At this point, we’ve moved from what the design thinking35

world calls “empathy” and toward what they call “ideation,”
shifting our attention from who toward what.

This shift from discovery to direction isn’t without its snags:

it requires some kind of mental model36 to help illustrate
how things will piece together when, in fact, it is built into a
future site. You could enlist a series of spreadsheets to try to
help people understand how content, design, and
functionality relate to user outcomes, but spreadsheets are
hard to sell. At Blend, we like to create a map of user
outcomes37 that shows both what kinds of questions can be
asked and also what kinds of content will be required to
support those questions.
In this model, all expected user outcomes are laid along the
middle. Because we’ve clustered our long list of outcomes
into high-level outcome groups in our example above, we’ll
only have seven boxes along the middle line.

Figure 6.2: Lining Up Outcome Groups.

From here, we begin listing the inquiry points a user will

have along their path toward a successful outcome. What
kinds of things will a user want to know if, for example,
they’re interested in maintaining a SpeakerBox product?

• How interchangeable are standard SpeakerBox parts?

• How long does the warranty last?
• Are there any SpeakerBox retailers in my area?
• Are there resources for me so I can install my own
SpeakerBox product?
Figure 6.3: Pairing Outcomes with Questions.
Figure 6.4: Supporting Outcomes with Content Solutions.

And so on. These questions stack on top of the outcome

group, illustrating the level of complexity.38

With this mental model, we must do something to counter

this weight; we need to buoy each outcome with the
necessary content and functionality types required to make
the outcome work. Under “Maintain a SpeakerBox product”
we put content concepts and content types that help solve
the questions listed above: in this case, things like “Warranty
Content,” “Installation Videos,” and “Retailer Maps.”

With this work, we’ve created a set of functions that satisfies

the expectations of those outcomes. This is one of many
ways to illustrate the shift from “what we expect” to “how
we’ll solve the problem” – whatever you can use to help
move from discovery to direction will be helpful in tying
real content and functionality needs to actual user needs,
whether that’s adapting archetypes or personas to include
more detailed outcome success, or whether that’s simply
grouping common outcomes and matching them to tasks in
a spreadsheet.

Now the question shifts away from “What do we do?” and

toward “How much of this do we already have?”

Inputs and Outputs

Inputs for this are the same as for determining user
audiences, but outputs might slant a little more toward
things like the aforementioned mental model, a deeper and
richer persona/archetype that ties together expectations, or
even a formal declaration of site features to be researched
and designed during wireframing and content modeling.
The Big Picture
Gathering expected outcomes and overall project
expectations occurs during the research or “discovery” phase
of a project, and it happens in parallel with the last chapter
on understanding the users themselves.

Staffing
Much like user research requires an understanding of how to
get usable and thoughtful information out of people who
really don’t want to talk about websites, thanks so much, this
level of determining expectations takes someone who can
speak to people, empathize with their needs, and understand
the connections between what they think they want and
what they actually need. Again, your designers and content
strategists should be able to handle this as it relates to
gathering information, understanding requirements, and
translating it into actual functionality.

32 Lichaw, Donna. The User’’s Journey: Storymapping Products That People Love. Rosenfeld Media,
2016.
33 Atherton, Mike, and Carrie Hane. Designing Connected Content Plan and Model Digital Products
for Today and Tomorrow. New Riders, 2018.
34 We’re being deliberately obtuse about this. Know that, in reality, we’ve got the bass turned up
on some early 00s Justin Timberlake jam.
35 Design thinking is, in essence, a form of discovery workshop that combines the three main
strategic focuses of a web project – understanding users, crafting solutions, and testing those
solutions – into a short burst of creative energy. It’s actually both more nebulous – and more
complex – than this simple explanation, so we’ll point you to a great Medium article about Design
Thinking by Christina Wodtke, “Five Habits of Design Thinking.”
36 According to Indi Young, author of the wonderful UX book Mental Models, a mental model
gives you a “deep understanding of people’s motivations and thought processes, along with the
emotional and philosophical landscape in which they are operating.” They are, in her simplified
terms, affinity diagrams that show groups of related things. How they are related depends on the
type of mental model you sketch out.
37 Really, what we’re doing here is a diagram of a mental model, paired with the content required
to solve the problems presented in that mental model.
38 When we say complexity, we are talking about the number of potential entrance points a
person might have when seeking a specific outcome. The solution to an outcome like “contact a
company” is much more simple if there’s one entrance query (“How do I contact the Butterball
hotline on Thanksgiving?”) versus having multiple entrance queries (“How do I contact SpeakerBox
about warranty replacements?” and “How do I contact SpeakerBox about installation questions?” and
“How do I contact SpeakerBox about my job application?”)
CHAPTER 7

Know Your Content

SUMMARY
One of the challenges in rebuilding any website is figuring
out what to do with the existing content. But before you can
make any decisions, you simply need to know what it all is. And
once it’s unearthed and exposed, then you need to decide
what information is relevant and worth recording,
determine a method to store this information, and decide
how (or if) you want to keep it updated over time.

DOES THIS APPLY?

If you have a website now, populated with content that you
intend to keep, either in full or in part, then yes, you need to
do this.

If you plan to throw everything away and start from scratch,

then it really doesn’t matter what’s out there, other than as
an evaluation tool to give you perspective on your new
content. But this is rare. Also, if this is a new build rather
than a rebuild, then there’s no content to inventory, and you
can safely skip this phase.

About a decade ago, one of the authors of this book moved

out of his old house, which involved estimating the size of
the moving truck they would need. The process took place
over a few weeks: they packed up boxes, they hired
professional packers, and they even did a test viewing of the
truck sizes available to them.

They got a pretty big truck. Not the biggest, but pretty big.
And, on moving day, after four hours of expert packing (and
a lot of cursing), the truck was completely full. It felt like a
job well done.

And then they remembered the garage.

Lawn chairs. Bikes. Tools. So much focus was placed on

getting books and beds and other items from inside the
house into the moving truck that the garage was completely
overlooked. Thus began a frantic two hour period of
securing a second truck. It was an added level of stress that
could have been saved if they’d more accurately paid
attention to the entire property, and not just the things on
the inside.

Finding a new truck is simple when compared to the work

that would go into reorganizing a site that’s already gone
through design and development. Which is why, before you
can make decisions about your content, you need to
perform the supposedly simple act of determining what
content you already have.

This process is rarely simple. Continuing the metaphor from

above, it’s like moving out of a house you’ve lived in for fifty
years. You spend a lot of time saying things like, “Where in
the world did all of this come from?” and “I don’t even
remember this,” and “Who put this here?”

This process is referred to as a “content inventory” or –

perhaps erroneously – as a “content audit.” The terms are
too often used interchangeably, but there is a difference:

• Content Inventory: The mechanical, objective process of

cataloging all the available content, sometimes also known
as a quantitative audit.
• Content Audit: The editorial, subjective process of
evaluating the inventoried content for its value to the
goals of the website, and determining the future action to
be taken on the content, sometimes also known as a
qualitative audit.

Under these definitions, a content inventory leads to a

content audit. You can’t do an audit without an inventory,
and an inventory often requires an audit in order to gain
insight beyond simply knowing the scope of your available
content. (Of course, different people call these things
different things,39 because that’s how the sometimes messy
world of the web works. The name doesn’t matter as much
as the work being done.)

The Content Inventory

Wouldn’t it be great if we didn’t have to do content
inventories at all? In a perfect world, you would always know
what content was published on your website, and you
wouldn’t have to embark on a focused effort to figure this
out. Either you’d have a perfect memory of every piece of
content you’d ever created (unlikely), or you’d have some
continual process that was constantly checking for new
content and putting together some kind of report.

Of course, this isn’t the case, so you’ll often have to embark

on an explicit accounting of content prior to a project. When
you do this, there are fundamentally three problems you
need to solve.

• How do you find all the content?

• What information should you catalog?
• How should you record this?

Finding Content
There are multiple options, each with advantages and
disadvantages. Clearly, automation helps, and is required in
anything beyond the simplest scenarios.

• A Manual Browse: Start at the home page, record

information, click on a link, repeat. Obviously, this is
inefficient and tedious and would break down on
anything larger than a small site. However, in situations
where it’s feasible, it can be comprehensive and generally
results in a more intimate understanding of the content, as
you – a living, breathing human being – evaluate every
page while staring at it in a browser.
• An Automated Crawl: Using a web crawler, this provides
the most comprehensive inventory. It is, by definition,
visitor-centric – the crawler accesses your content like a
visitor would, following links and ignoring inaccessible
content. However, what you gain in automation, you lose
in context – you end up creating a good chunk of work
reviewing the crawl to add in more human observations.
• A CMS-Generated Report: If your CMS has good
reporting tools, it might be possible to get a report of
content. This is likely quick and comprehensive, but it
might miss relationships between content, it will only
capture limited information, and it suffers from the
aforementioned problem of content which is published
but technically orphaned.
• A CMS Export: Your CMS might have an export feature
which will dump all content information to a serialized
format like XML or JSON. If you have a developer
available, this is essentially a CMS report which can be
programmatically queried for further insights.
Additionally, it’s likely more comprehensive than a report
intended for reading, as an export will generally output all
information about the content.

Pages or Content?
So, are we concerned only with pages? In most cases, for
a website, yes, you’re recording pages. More specifically,
you’re recording addressable URLs – something someone
could type in a browser and receive a payload of content.

However, sometimes it’s not quite that simple. In some

systems, you have a library of composable elements that
you combine to form pages of content. Do you catalog
these all separately? It depends on your situation. In
many cases, simply recording the output of these
elements as a single page is enough, since they will be
presented to a site visitor that way – as composed pages
of content.

In general, sticking with the “one URL = one content

item” is the simplest way to inventory your content. By
 this method, supporting files (PDFs, for example) would
also be considered content elements, since they would
respond to a single URL.

Recording Information
When forming the inventory, you’ll record more than just a
title and URL. The following is information which can
commonly be captured automatically, when using one of the
methods above.

• ID: Some identifier for the content. This will often be a

numeric ID from the CMS itself. (Yes, the URL itself could
be considered an identifier, but it’s often handy to distill
this down to something even more precise.)

• URL: The canonical40 URL under which the content is

accessed.
• Title: The commonly accepted name or title of the
content. Often, this will be the TITLE tag of a web page
(minus any branding suffix, such as your organization
name).
• Format: The digital format of the content, be it HTML,
PDF, an image type (though, it would be rare to inventory
images unless they were intended to be accessed directly).
• Language: Often, the language can be determined from
the URL, via the first segment (“/en/ about-us” compared
to “/de/about-us”, for example). In other cases, the
language will be returned as an HTTP response header or
META tag.
• Size: The length of the content in bytes. This is
occasionally handy to know when evaluating it.
• Response Time: With automated crawls, you can often
obtain the number of milliseconds it took for the content
to render.
• Assorted META Tags: Every site has a different
assortment of META tags, and some are valuable to
record. A tag of “Description” is often helpful, as are many
of the Dublin Core41 tags (those beginning “dc:”).

Once this list has been formed through automated methods,

some manual review and analysis should capture more
subjective information. Some helpful information to find
and record:42

• Content Subject: What is this content about? What

product, topic, or category of information is represented
here? (Don’t worry about defining these in advance. It’s
easier to just note something about this specific piece of
content, then go back through and make them consistent
later.)
• Content Type: In a CMS, most all content has a
designated, logical type, which dictates how that content is
structured. Is this a simple text page, a news article, an
employee profile, etc.? In many cases, this can be
determined from the URL, or through simple analysis of
the page. (Bonus points if you can persuade your
developers to output the name of the CMS content type in
a META tag you can automatically capture.)
• Owner: The human or organizational unit who is
responsible for the disposition of the content. This is the
person, group, or role who can make changes to the
content, who can add similar content, and who can direct
the content to be deleted.
• Velocity: How often the content changes, through edits to
 a single content element, or additions/deletion to a group
of content (how often a new press release is published, for
instance). When planning a content migration, for
example, it’s very helpful to know if content changes
every day, or only every five years.
• Analytics: If analytic metrics can be added automatically,
this can be enormously valuable to evaluate the status of
the content. A helpful set of analytics might be how many
times the content has been viewed in the last seven days,
thirty days, and three hundred and sixty-five days.
• HTML Analysis: Some systems will analyze the retrieved
content for information. Does the HTML contain a FORM
tag? How many headings does it contain? Is there
embedded video? Is there a supporting image?
• Textual Analysis: Some tools offer more advanced text
analysis for things like average reading level, presence or
absence of keywords, etc.

Storing the Information

Even with a comprehensive list of URLs and a clear list of
information to record, the process can break down over
something as mundane as format. How a group of people
collaborates on the inventory can have a huge impact on the
quality of it over time or the quality of the ensuing audit.

Clearly, the natural tendency, then, is to put it in a

spreadsheet. And this is fine, but – unless you’re working
completely alone – it can’t be based on a singular file. Too
many times, we see the results of an inventory in an Excel
file, passed around from team member to team member. No
one knows who has the latest version of the file, and
multiple people are working on multiple copies. It’s a recipe
for frustration and disaster.

Some options:

• The next most common option, by far, is some shared,

concurrent spreadsheet. Google Docs is perfect for this, as
is the online version of Excel in Office 365. Other cloud-
based tabular systems that allow concurrent access –
Airtable, for instance – would also work.
• Record information about the inventory in the CMS
itself. This takes a little work, but if your developer can
add properties to a “page” content object (assuming your
CMS supports one), then this information can be recorded
directly inline with the content. Combine this with some
custom reports, and you’re in an advantageous position.
During migration, this information can be
programmatically accessed to determine the disposition
of content (ex: a “Do Not Migrate” checkbox could prompt
an migration script to skip that content object.)
• Use an online tool specifically designed for inventories
and decision making.

The key is that the inventory has to be a shared resource that

the entire team can refer to and have faith in. The surest way
for a team to lose interest in the effort behind an inventory
is to have them lose faith in the integrity of the data it has
generated.
Figure 7.1: A content inventory created in Google Sheets.

The Content Audit

While a content inventory — quantitative by nature — is
going to be limited by the information you can glean from a
page and its workflow, a qualitative content audit can focus
on connecting insight to the purpose and viability of that
content. In other words, while a content inventory might
help you understand how many news articles are on your
site, the content audit helps you make decisions about which
ones you should keep and whether they are important at all.

Remember; working through a web project is not a cut-and-dried, paint-by-numbers

process. This chapter talks about content inventories and content audits as separate unique
things, but some organizations may find value in combining them into a single spreadsheet,
while others (Blend, for example) provide the content audit as a narrative, goal-driven review
of the exhaustive content inventory. I’ll say it now and I’ll say it again and again: the work you
do in discovering and understanding your content is often (and usually) much more
important than the actual deliverable itself.

— Corey Vilhauer
This might be an addition to the inventory spreadsheet;
ratings, pivot tables, thoughts. Or, this might be a narrative
analysis of the inventory with suggestions on improving
content in more general ways. Regardless, your audit may
include more subjective details, such as:

• Purpose: Why is this content here in the first place, and

does it serve a purpose to any of our users?
• Goal Alignment: Does this content align to any of your
current business goals?
• Next Steps: Does the page include a viable and
understandable next step, or is this page the final step in a
larger process?
• ROT Status: ROT stands for “redundant, outdated, or
trivial,” and is shorthand for “we don’t need this content
anymore and it should go away.” In an initial audit, you’re
identifying these as they relate to business and user goals,
and so having a column dedicated to ROT is key for your
migration and overall content creation process. However,
once the site is live and running, there’s no need to
formally track ROT content: instead, you should simply
remove or change this content.
• Accuracy: Is the content accurate, or does it need to be
updated?
• Brand and Message Alignment: Is this content on-brand
and does it align with your overall organizational
message?

There could be dozens more, and there will be. And it’s
worth noting that when it comes to auditing, you often don’t
need to provide an exhaustive page-by-page look at every
single piece of the content puzzle. Groups of products, past
news articles, or data-driven content may need to be
inventoried (for migration or maintenance needs) but do not
always require a deep audit, either because they are only
relevant as a group of content, or because they serve no
further need beyond historical.

The audit is your time to make decisions and understand the

purpose of content toward your goals. You need to do as
much as you can to feel comfortable, and usually no more.

Inventory and Audit Maintenance:

Keeping It Updated … or Not.
An inventory or audit is only current for a brief, fleeting
moment, directly after it’s created – a photograph of your
site as it was on the day you completed your work. Over
time it “decays” as the underlying content changes. This
might not be an issue if your website is fairly static and can
be trusted not to change much. In other cases, the website is
a moving target and might look remarkably different from
day to day.

When considering how to keep up with additions and

changes, the easiest way might be to simply not. In many
cases, it’s acceptable to consider the inventory and audit as a
snapshot of a particular moment in time.

I can’t help but compare this to a medical x-ray. Immediately after you receive an x-ray, no
one chases you down the hallway saying, “Quick, x-ray them again! Something might have
changed!” Rather, the x-ray is considered an accurate representation of your body at a
particular point in time, which is enough for a doctor to diagnose problems and make
decisions.
 — Deane Barker

For most sites, the content might change, but the structure
won’t – articles or employee profiles are added and
removed, but the basic concept of an article or an employee
profile remains the same, and that’s enough. When making
decisions about content, we tend to make those decisions
based on type, and often not on the actual content.

One of the values of an inventory is the revelation of

structure, which is usually more important than actual
content. Do you really need to know about every single news
release your company has made in the last ten years? Or do
you just need to know that there’s a “bucket” of news releases
at a certain spot in the site? What level of information do
you need to make decisions about it?

This is contextual to your situation. Perhaps the question is,

“Should we have a news release section at all on the new
website?” If so, then you just need to know about the group
of content and some general information about how it’s
structured. In other cases, the question might be, “What
news releases should we migrate to the new website?” In this
case, you need to know about every single news release
individually.

If the latter, then your ability to keep an inventory up-to-

date over time depends on:

• The velocity of the content: How fast is content being

added, removed, and changed?
• The distribution of the team: Do changes go through one
person? Or is content managed by a newsroom with
hundreds of reporters?
If your velocity is low and your team small (even solo), then
just manually adjusting the inventory over time might be
enough. In the opposite case, you will need one of the
following:

• Some automatic notification of content changes. Many

CMSs offer notification of subscription services to
generate email alerts when content is changed.
• A service that monitors your website from the outside
and notifies you when a new URL appears. There are
services that will crawl websites on a continual basis and
generate an alert when new content is found.

This is all complicated by whether you’ve moved past the

inventory and into the more strategic audit, because now in
addition to maintaining the location and structure of a page,
you’re also continuously maintaining its goals, relevancy,
and sometimes even its future.

In a perfect world, these methods would move you closer to the ideal of the “rolling
inventory” or “rolling audit.” Before nearly every site launch and refresh, we urge our clients
to begin a rolling audit to help stay on top of content – to bite off small pieces and distribute
them around the editorial team to keep up with things like style guide changes and updates
to policy and other ROT (redundant, outdated, or trivial) issues as mentioned above. And we
urge you, the kind reader, to do the same.

— Corey Vilhauer

Just remember that structure changes more slowly than

actual content. The basic format of a news article might stay
the same for years, while hundreds or thousands of actual
news articles are created. In many cases, just knowing the
structure of the content, where it’s located, and how it’s
navigated is enough information.
Regardless of originating methods, data captured, and ability
or method of keeping the inventory updated over time, your
efforts from this phase should have generated some level of
transparency around the content in your website. You
should know roughly what content is on the site, how it is
accessed, what type of information it constitutes, and who is
responsible for its disposition.

Now that you know what you’ve got, let’s take a deeper look
at what it’s doing.

Inputs and Outputs

The only input to this process is an existing website, and
someone eager to use a spreadsheet.

The concrete output of this project is a content inventory

document, in some form, as described above, or some kind
of content audit document with analysis of current content
and its connection to project goals. Sometimes, it’s both.

Additionally, a tacit output of this process is a shared

understanding within the organization of the scope of
current content, and the scope of new content needs.
Content creation often gets short-changed, and an important
result of this process is a newfound respect for the scope,
schedule, and expense of what needs to be developed.

The Big Picture

This phase can be done before anything else. An inventory
of the content on an existing website requires nothing but
the decision to do it.
There’s a school of thought that says when someone
announces, “We’re going to migrate the website,” that’s all
you need to start a content inventory. You certainly don’t
need to know anything about the new CMS, because you
know you’ll be migrating into something, regardless of
identifying the specific system.

In other cases, you might want to wait until you’ve

developed a content plan, since that plan will identify the
desired content for the new website, and those content needs
might help you make decisions about what content to keep
and what to discard.

At any rate, the phase needs to be completed early enough to

allow enough time for new content to be created. Content
creation takes time, and many a website has been
implemented and then sat empty waiting for new content.

Staffing
This inventory is commonly completed by a content
strategist or editor, as part of a larger engagement to plan the
content of a new website. While the process of identifying
URLs and pages is not particularly complex, making
decisions about content will require an understanding of the
organization and its goals.

39 In this case, we follow the lead of content inventory and audit expert Paula Land, who literally
wrote the book on it: Content Audits and Inventories: A Handbook.
40 A canonical URL is the single, official URL for a piece of content. In many cases, content can
be accessed under more than one URL, or combination or querystring arguments. It’s important,
then, to identify a single URL as the official address for that content – the shortest, most precise
string of characters that will consistently return that content.
41 Dublin Core is a metadata standard that dictates common names for data like author, title,
subject, date, etc. Before choosing your own names for metadata, review the list of Dublin Core
tags. Sharing standard names allows third parties to evaluate your content more effectively. The
name, incidentally, refers to Dublin, Ohio, USA (not Ireland) where the standard was formed during
a conference in 1995.
42 When it comes to determining fields for your content inventory and audit, there are tons of
resources within the content strategy field. The aforementioned book from Paula Land, Kristina
Halvorson and Melissa Rach’s Content Strategy for the Web, Meghan Casey’s The Content Strategy
Toolkit, and Ahava Leibtag’s The Digital Crown come immediately to mind, but really any book on
content strategy probably has a chapter on inventories and audits.
CHAPTER 8

Gather Insight From Your Metrics

SUMMARY
A website generates lots of numbers representing how
visitors behave. What numbers are important, and what
numbers can translate to some measure of “success?”

DOES THIS APPLY?

You can’t make well-intentioned, positive change if you
don’t know where you’re currently at, so understanding the
scope of web analytics and all of its acronyms and unique
terms is important for the forward progression of your site.
Once it’s launched, your only direction for maintenance
should be “make it better.” Tracking metrics and
understanding the numbers is how you do that.

Throughout the existence of modern homo sapiens, survival

and culture has relied deeply on patterns. Much of our
recorded history has been spent looking for and
documenting patterns: calendars were created by observing
the stars and the patterns in seasons, and the patterns of
success and failure within agricultural science helped shape
not only what and how we eat, but the entire scope of
human civilization.

Of course, we talk about patterns as if they’re preordained,

when in fact they’re more fluid and natural than we’d like to
admit.

Patterns are important only because they provide insight

into why something is happening. A single data point might
spur a small decision – a cold night might lead you to cover
your freshly potted plants – but a pattern might lead you to
simply not pot those plants until later in the season.
However, the insight gathered from both of these might lead
you to a new solution: the issue isn’t with the weather, but
with the plant being potted in an unstable environment.

In other words, it’s not just about finding patterns and

reacting. It’s about tracing those patterns back to the source
to figure out why they’re happening.

It’s not data, it’s insight.

We make changes, we understand life, and we make sense of

our surroundings by looking for patterns and reacting to
them, either on a macro level or a micro level. The same can
be said when we’re trying to understand the people who are
coming to our site. We never see them, but they’re there.
And we want to know what they’re looking for – and why
they chose us.

Why Data Is Important

Despite our best intentions, we can’t interview every person
who arrives on our site. But, in a way, if we have a
sophisticated enough measurement tool installed on our site,
we’re already interviewing them.

Knowing where and how people interact with your site,

through the data gathered with these tools, can be the
catalyst for change. Or, it can be a warm security blanket,
confirming that everything is running as expected.

It can also be a lot to understand, which is not helped by the

fact that it’s not something you can directly control. It’s out
of your hands, which makes it scary and frustrating.

That’s okay. Scary and frustrating will pass. The larger goal is
to understand how to use this data to your advantage. You
don’t need to be a wizard at Google Analytics, but you do
need to make some basic strategic decisions – and then find
someone who can help you monitor those decisions.

First, we need to know what to measure in the first place.

A quick programming note: at this point in the book –

and throughout the next few chapters – we’re talking
about strategic phases that span the entire scope of a
project and beyond. Analytics, metrics, and any kind of
measurement aren’t simply a pre-design task: they are
an active part of ongoing site maintenance.

You’ll use this data to measure user behaviors. You’ll use

this data to back up content decisions and determine
when changes are needed. You’ll need it at the start when
you choose which pages to keep, and you’ll use it for the
rest of the life of the project, as you measure failure or
success.
Determining What to Measure
Let’s define a few things.

When we talk about data, we’re talking about raw

information and individual numbers. For example, data is
how many people arrived on your site today, how many
people completed a purchase, or how many broken links a
site crawler found.

When we talk about metrics, we’re talking about the system

by which something is measured, or we are talking about the
results of that system. For example, if we want to know how
many average site visitors we have every day, we can take
our data points (Monday’s visitors, Tuesday’s visitors, etc.)
and grab the average. That is the metric.

Finally, when we talk about insights we’re talking about the

patterns and inferences that arise from our data and metrics.

You can see that we’ve moved from raw data, to calculations
based on that data, to interpretations of why that data is
happening. It’s in these insights – not the raw data, but the
thoughts and context around that data – that you find
actionable web solutions.

Jon Crowley, in his talk “Your Funnel Isn’t a Journey: Data

vs. Insights,” outlines the need for insights over data, when
he talks about our need for solid and real answers. We want
data to be real, as Crowley explains. We all “deeply want to
believe that there’s some pure unvarnished truth in the
world.”43 But, in fact, there’s insight behind that data – the
“why” behind the data and activities – and that insight
provides a lens that we can use to guide our thinking.
You can think of it this way. Your data provides fuel for your
metrics, which (in concert with your knowledge of audience
behaviors and a little common sense) can give you insight
into the patterns. You have numbers, you have math, and
you have interpretation.

Tying Metrics to Goals

Now that we’ve got those terms figured out, let’s dive a bit
deeper. First off, you need to know what you want to
measure.

There’s an easy (and dangerous) assumption that tracking

numbers is good enough; that hooking up that Google
Analytics account is going to provide deep insight into how
people are using your site, or that wading through old
numbers will help you create a more useful plan for your
new web project. In reality, those numbers aren’t useful if
they’re not telling you what you want to know.

Don’t get me wrong – setting up Google Analytics and having it running even before you
know how to use it is ideal. Eventually, you’ll want to access that data; just as the best time to
plant a tree was 20 years ago, the best day to start tracking your analytics was when your
website launched, and the second best day is right now. Even if you don’t know what to do
with it yet, make sure something is capturing inbound data and on-site data.

— Corey Vilhauer

So, what do you want to know? Believe it or not, that’s the

easy part. If you’re following along chapter-by-chapter,
you’ve:

• Defined goals for your business.

• Defined goals for your site.
• Defined goals for meeting your audiences’ expectations.

Now, we need to look at which metrics will help us gather

the insights that we’ll need.44 Trust us when we say you have
a lot of options. We see metrics fall into the following
groups:

• Activity: Simply tracking what someone is doing.

• Conversions: Tracking the likelihood someone does what
you want them to do.
• Value: Often based on conversions, how much is each
visitor worth to our process.
• Language: The words that people use to connect with us.
• Engagement: The act of spreading our message beyond
their visit.
• Performance: The technical details of your site.

Which of these you choose to focus on is going to differ

from site to site, and from goal to goal. For example, let’s say
your organization provides access to services for those who
have addiction problems. If one of your site’s goals is to get
people to call your addiction coaches, then there are a few
things you can measure:

• The words that they’re using to find us – language.

• The path they take to get to the coaches page – activity.
• The percentage of people who get to a certain point and
select our call to action – conversion.
• The number of people who engage with our social media
posts about new coaches – engagement.
At the same time that you’re tracking these metrics, you
might also understand how crucial it is to keep, for example,
an emergency connection to a counselor up and running,
which means performing some kind of periodic test to
ensure that page is actively published and accessible
(performance).

Before you go chasing every stat and metric, keep in mind

you don’t need to know everything at once. While there is in
rare occasions a need for multivariate adjustments,45 often
making changes along more than one metric at a time can be
detrimental to finding an actual solution. This is where Eric
T. Peterson, in his book Web Analytics Demystified: A
Marketer’s Guide to Understanding How Your Web Site Affects
Your Business, urges those tackling web analytics to “think
micro, not macro.” He says:

The biggest mistake businesses make is trying to change too much

at once and then not being sure what actually caused any
observed results. Give yourself a fighting chance! There is more
than enough variability inherent in the internet itself without
adding more complexity to the mix.46

But the fact remains: you need to start somewhere, so find a

goal and work backwards.

The Funnel
You’ll hear a lot about funnels when it comes to measuring
conversions. Marketing people are very into it, for good
reason: a well-optimized conversion funnel is going to drive
traffic toward the actions they (and you) hope to accomplish,
and measurement of that funnel is how you make change
happen.
The concept is based on the idea of engagement and traffic
as a kind of funnel. For every person who is aware of a site, a
smaller number will actually engage in research on your site,
from which an even smaller number will actually start
making a decision on your site, which will ultimately lead to
the smallest number of people: those who actually make a
purchase.47 The percentage of people who drop out of this
process is called, predictably, the “dropout rate.”

Essentially, your potential customers go through four stages:

• Awareness: They know about your product.

• Interest: They have interest in your product.
• Desire: They want to have your product.
• Action: They actively get your product.

This is a very commerce-centric process, but funnels can be

determined for any conversion, whether that’s signing
people up for your email newsletter or getting people to fill
out an online petition. The benefit of knowing what happens
at each step of this funnel is tied to understanding the
movements your users make as they get closer to fulfilling
their expectations and outcomes.

Determining How to Measure: Diving

into KPIs
Once you’ve decided what you want to measure, it’s time to
figure out how to do it. What you need are some KPIs.

KPIs, or key performance indicators, are quantifiable

metrics that are used to measure – wait for it! – performance
toward your goals. They sometimes have crazy acronyms
and jargon-filled titles, but they’re useful viewports into how
your site is performing and what people are doing when
they arrive.

A Short List of Important Data Points and

Metrics
There are a lot of potential data points and metrics out there,
and we want to help you understand the most common or
important ones.

• Visits/Unique Visits: A visit, or a user session, is the

instance in which a person or crawler48 is accessing the
site as a whole. Unique visits are going to filter out
multiple sessions by the same user.
• Views/Unique Views: When a person or crawler visits
your site, they are going to view pages. Views are the
number of times a page has been visited. Much like with
visits, unique views filters out multiple views by the same
visitor.
• Click-through/Click-through Rate (CTR): If a person
lands on a page, that is a “visit,” or sometimes a “hit.” If a
person then leaves your page to interact or engage with
something like a “call to action,” that’s a “click-through.”49
Click-through rate measures the percentage of people
who land on a page and travel forward via that specific
interaction.
• Conversion Rate: A multi-layered metric that consists of
two things: defining a “conversion” (i.e. one newsletter
sign-up or one sale of a product) and then measuring the
percentage of people who make it from the start of the
site through to the end of the conversion. Essentially, what
percentage of people coming to your site do what you
 hope they do? You can tie this in with other data points to
pull metrics like Average Revenue per Visit or Average Visits
Prior to Conversion.
• Referrals: Literally, the digital source from which
someone arrives on your site. In many cases, this is going
to be a Google search, which means you’ll need to know
the terms they’ve used to get there.
• Bounce Rate: Bounce rate measures the percentage of
people who leave the site without visiting another page or
performing an action. A high bounce rate is not
necessarily a negative thing; if the purpose of the page is
to deliver a user to a separate online portal, you want
them to bounce from your site.
• Time on Page: How long is the average person staying on
your page? This depends on context. If you’ve written a
very long blog post, a time on page of eleven seconds isn’t
great. But if you’ve created a page that serves as a quick
landing page before another decision, that short eleven
seconds is ideal.

Privacy Policies and Pop-Ups

If you’re going to be tracking your site users – even
anonymously – you need to set up a privacy policy page
for your site, which outlines what information is being
collected and used when those users are on your site. It
should be easily accessible to anyone who visits, outline
exactly what information is being collected, and outline
how that data is used. It should also provide a way to
contact your organization.

It can be long (like MOO’s) or it can be short-ish (like A

 Book Apart’s). It just needs to be vetted by a lawyer or
your legal department and explicit to the extent that you
track data.

We’ll talk more about maintaining these types of policies

in Plan for Post-Launch Operations.

Setting a Baseline
In baseball, there’s a concept called the Mendoza Line. It was
coined in the late 1970s by teammates of Mario Mendoza, a
defensive specialist who struggled to hit above .200 (a very
poor average) for most of his early career, and is used to
describe hitters who struggle early in the season – especially
those hovering around .200. Once the term reached anchors
for the then brand new SportsCenter on ESPN, it became
endearing to point out hitters hovering around the Mendoza
Line.

The Mendoza Line set a baseline for what it means to be a

competent hitter. Without the Mendoza Line … what is that
cutoff?

Baselines provide an anchor to your data and metrics.

Otherwise, your numbers float without reference, of little
use and unspectacular.

For example, we can measure a hundred people’s heights

and get an average height. But without a baseline, that
number is of no use. How do we use it? We need a baseline:

• We can compare it with the average height of people who

live in the United States.
• We can compare it with the average height of a
 professional basketball player. Or, maybe we compare it
with the average height of a professional jockey.
• We can compare individuals within the group against the
average; in this case, the baseline is determined by the
average, and individual people are compared against it.

Baselines don’t just appear. Sometimes we just need to make

a baseline happen. Too often we come in contact with clients
who are frozen with fear that they’ll choose the wrong
baseline, or they’ll track the wrong metrics, when in reality
they simply have to take a stab at a number. Any number.
There is no correct number for your conversion rate, or for
your time on page, or for your percentage of traffic from
search. There’s just the number you have, and the number
you want to try to reach.

And when all else fails, look into the past. If you have data
for the last three months, review it and make a decision
based on those numbers.

Understanding How People Consume

One key difference between tracking metrics and making
inferences from those numbers is that raw numbers show
you activity, while the research around those numbers – the
actual analytic interpretation – shows you habits and trends.

Let’s use page referrals as an example. Viewing your page

referrals will give you a total number of visits from a specific
page. This is the data. You know that people are coming
from a specific site more than any other, because a number
is telling you this.

Interpreting this data to be useful depends on making some

assumptions and going a little deeper in your research.
• Why are people coming from this site?
• Are there clues on this page that help you understand
why people are drawn to the link or reference?
• Is this page showing up in search instead of yours, and so
traffic drives through an external page before it’s coming
to yours?
• Are there improvements that can be made on your page
based on the findings from this page?

When it comes to reading data, know that the number

usually means nothing. It’s a clue, like Sherlock Holmes
finding a paper trail; it requires a bit of deductive reasoning
to reach a conclusion that warrants action. You don’t need to
know the percentage of people that abandon the shopping
cart as much as you need to know the reasons they are doing
so. The number is the clue, and the action depends on
research and due diligence.

Going Incognito
It’s probably no surprise that not everyone cares to be
tracked and measured. Some people – especially the
more technically savvy – will use ad blockers, privacy
browser extensions, or a browser’s own private browsing
feature50 to block any data from being transferred to
your site, which means you will not receive accurate data
for your analytics measurement.

Beyond Google Analytics: Other Ways

to Measure
Of course, there’s more than just Google Analytics and
traffic numbers when it comes to understanding your site.
You can track words, and you can compare pages against
each other, and you can even … talk to real people face-to-face.
Like we’ve said before, the way you find your insights might
have nothing to do with Google Analytics at all.

While Google Analytics and other site analytic tools can

provide a ton of information tied to search and traffic, other
metrics include:

• Seeing where users click on your page using heat

mapping or session-recording tools.
• Finding issues with common forms and their fields using
form-analytics software.
• Finding external messaging and mentions through social
and external search.
• Finding non-trackable issues through person-to-person
user testing and eye tracking.

Some of these require a big budget and a lot of time,

especially when working with real people in distributed
locations. But beyond some of these more lofty goals, there
are more common ways to look beyond web traffic and
conversion rates to find out how we’re performing and what
we can do to change: language, comparison, and feedback.

Measuring Language
Data and metrics aren’t just numbers. They often represent
something even deeper: words. The words people use to find
your site, and the words that people use to navigate your
site.

Every day, people are providing you with data on the types
of things they expect to find. They’re typing words into a
search field and either finding what they want (hooray!) or
not finding what they want (aw, nuts!). For external search,
you have answers to the first. For internal search, you have
the answers to both.

• External Search Data: Your analytics tool will provide

you information on what search terms were entered
before someone arrived on your site. The more common
the search term, the higher it will show in your reports.
• Internal Search Data: If you have an internal site search
set up, you will be able to see any term searched by people
from anywhere within your site.

More importantly, you’ll be able to get clues about what

words aren’t easy to find. When someone can’t find
something – either because they’ve searched everywhere
and are lost, or because they arrive on the site and
immediately “nope” themselves away from your weird
navigation or video carousel – they almost always turn to the
on-site search.

Lou Rosenfeld, in his book Search Analytics for Your Site, talks
about two areas of analysis within your internal search:
• Pattern Analysis: What trends do you see in how people
search your site? Are they using technical terms or more
general terms? Are they depending on synonyms? Are
they using jargon or abbreviations?
• Failure Analysis: Are common search terms returning
non-relevant or, even worse, no results?
The book goes further into framing this analysis, whether it’s
session by session, per audience, or per goal, but even doing
this basic level of research into what words are used and how
results line up will reap the benefits.

There’s so much focus on how people get to your site that we often overlook what people
are searching for when they’re finally there. When it comes to managing ongoing content
updates on a site, I’d much rather see the on-site search data: it strips away the “are they or
aren’t they” element of a user entering the site, and instead focuses on improving the
content itself. On-site search is usually available in Google Analytics, but only if your site has
been set up to track for it.

— Corey Vilhauer

Search Trends
Do not forget that relevant data for your site does not always
come from your site. There is a world of data that comes
from people who will never touch your site – the world of
search trends.

Search trends, specifically a tool like Google’s Trends, allows

you to see both what and how people are searching across
the world

This is especially useful when your data and metrics uncover

search terms that seem out of place. Let’s say, for example,
that you manage a site for a local health center specializing
in care for those with Alzheimer’s, and on-site search data
for your site shows a rise in the term “dementia.” A quick
look at Google Trend will show that while searches for
Alzheimer’s as a specific condition are staying even over the
past fifteen years, the more generic term “dementia” is on
the rise. Integrating the term “dementia” more clearly into
the site, or even creating a page that compares the generic
“dementia” to the more specific “Alzheimer’s Disease” will
clearly be of benefit to those who visit your site.

Figure 8.1: Google Trend results for Alzheimer’s vs. dementia over the past fifteen years.

Wait, Isn’t This Search Engine

Optimization?
While search engine optimization is deeply tied to
language, structured content, and metadata, knowing
what words people are actually searching for is just as
important. We’ll look more at how search engine
optimization works in Write for People and Machines.

Comparing Options: A/B Testing

If you’re using data to figure out a choice between two
common pieces of content or design styles, you’re often
looking at A/B testing. A/B testing provides site visitors one
of two choices by random,51 allowing you to actually
measure which of the two choices is most successful.

For example, let’s say you are running a web campaign that
feels lacking in how it moves traffic from the home page to
your hoped-for destination. To run an A/B test, you just
need another idea: design an alternate campaign block, or
move the campaign block, or even remove it altogether to
test the current campaign against a control group.

Now, when users hit your site, they’ll have a 50% chance of
reaching one version or the other. Tracking these metrics
will tell you which converts better, allowing for constant
iteration toward a better campaign.

Getting Personal Feedback

We talked about this at length in the chapters “Identify Your
Audiences” and “Identify Outcomes and Expectations,” but
it’s important enough to repeat over and over: knowing your
people and how they feel is the most genuine and valuable
thing you can do to measure success and gain insight. This
kind of personal feedback can be collected in multiple ways:

• Live Chat: Typically seen as a customer service outlet,

live chat can also provide you with as it happens access to
customer pain points, both with your product and with
your site processes.
• Surveys and Questionnaires: People typically don’t fill
out surveys unless they’re angry about something, so
don’t expect a lot of kudos, but you can expect some real
talk about what’s not working.
• User Testing: On-site, periodic user testing can provide
you with an unfiltered look at how people travel around
the site, and their comments will fill knowledge gaps that
raw data can’t provide.

Regardless of how you get it, what’s important is that you do

something with it. Tracking data and finding insights is an
act of pure masochism if they’re not backed by action. We’ve
talked about knowing your content through inventories and
audits, and we’ve now discussed combing through data to
infer insight. Now we’re going to dive right into that content
itself.

That’s right: in chapter nine we’re finally talking about content

strategy!

Inputs and Outputs

First off, you need to track your data. You need some kind of
analytics package set up on your site to measure who, where,
and what is active. (The obvious source for this is Google
Analytics, but this also comes from individual social media
data, internal feedback, and even content management
system reporting.)

From this, you’re going to get reports. Reports are good if

you know why they matter, and they’re just noise if they
don’t match a business goal.

The Big Picture

During discovery, you want to see numbers so you can get a
good idea of what people are doing and how it might change
(or improve, or even decline) on a new site. Beyond that,
though, you’ll constantly monitor data and metrics to glean
insights for the future of your site, so understanding your
metrics is an ongoing governance and maintenance task.

Staffing
Staffing your analytics and data roles might come from a
handful of areas. Sometimes, you might have a dedicated
analytics person, especially in a high-conversion business
like retail, where small changes in a user’s path can lead to a
drastic shift in revenue. If you are a smaller organization,
you might have someone who glances at your Google
Analytics every once in a while, so work comes in focusing
on the right metrics to help your business measure goal
progression.

Your marketing and web team are going to want to know

what’s happening, so this role can often come from those
departments, or if you’re a larger organization, this work
might be outsourced to specialists, who often also help
determine online advertising.

43 “Your Funnel Isn’t a Journey: Data vs Insights - Jon Crowley.” Design & Content Conference
2020, content.design/2016/08/your-funnel-isnt-a-journey-data-vs-insights-jon-crowley.
44 The key phrase here is that you need. In an article by Kate Lucey called “It’s time to kill the
infinite scroll,” Lucey talks about a publisher she worked at in 2015 that was very excited about the
improvement of a “time on page” metric, engineered by not allowing a user to, really, ever leave
the page (thanks to a design that infinitely loaded new content). Turns out not only was this a
misaligned metric – it did not actually provide value, as nothing had changed about content quality
other than a technicality – but it was a positive indicator that hid a negative feature: people could
no longer find the footer of the site.
45 Making changes based on one variable – such as adjusting a navigation label to improve
findability – helps you understand whether that change was the actual source of the improvement.
Multivariable testing – adjusting the navigation label, but also boosting the page’s search presence
at the same time – leaves your solutions murky, because it’s difficult to know which change was
responsible for the improved performance.
46 Peterson, Eric T. Web Analytics Demystified: a Marketer’s Guide to Understanding How Your Web
Site Affects Your Business. Celilo Group Media, 2004.
47 This is based on a concept called the “buying funnel,” which is outlined in a paper titled
“Bidding on the Buying Funnel for Sponsored Search and Keyword Advertising” by Bernard Jansen
and Simone Schuster of The Pennsylvania State University. It sounds very haughty to have
mentioned a scholarly paper, so we’ll admit we found it via search from an article on creating a
website conversion funnel from an on-site measurement service called Crazy Egg.
48 At risk of sounding like a hackneyed sci-fi film, remember that not everything that visits your
site is human. Some of them are web crawlers that index data (for search engines) or harvest email
addresses (for the sketchiest of spam monsters).
49 This is a term that is becoming increasingly troublesome, as many people never click a single
thing anymore. We wouldn’t be surprised to see this term shifting toward something more input-
agnostic, such as “action rate” or “through rate.”
50 In Google Chrome, this is called “Incognito Mode.” In Firefox, this is called a “Private Window.”
In the Microsoft line of browsers (Internet Explorer, Microsoft Edge) this is called “InPrivate
Browsing.”
51 The same concept of “micro over macro” applies here – multivariate testing can potentially
provide too many potential reasons for a change; A/B testing allows you to know exactly which one
worked.
 SECTION 3
STRATEGIC DESIGN

Web design means a lot more than just colors

and button styles. It means developing logical
connections between concepts. It means creating
content for the right users. It means modeling
content in a way that responds to different
screen widths. It means creating an accessible
and inclusive site that reflects brand standards.
Design is a strategic relationship between
graphics and content, a pairing dedicated to one
main goal: getting people where they want, how
they want.
CHAPTER 9

Develop a Strategy for Your

Content
SUMMARY
Content drives business goals, which means content drives
your site. For content that needs to be changed, content that
does not yet exist, and even content that will stay the same,
we need a strategic plan that provides both high-level
direction and a more detailed review of messaging and
function.

DOES THIS APPLY?

Creating a strategy for your site’s content is at the heart of
your entire web project. If not for the content, why is
anyone going to show up? Knowing what your visitors are
looking for and how to provide it to them is the linchpin that
holds the entire project together. Without content, you have
nothing but an empty shell.
In the beginning, there was content. Well, that’s dramatic.
Let’s start over.

In the beginning of the Internet, there was content. There was

information, and maybe a few jokes, and definitely a bunch
of people arguing about whatever people argued about on
the early days of the World Wide Web. But it was all content.

Fast forward to today. We’ve done a lot to facilitate and

promote our content. We’ve pulled in the practices of
graphic design and machine learning. We’ve moved beyond
published words into live video (and, often, social posturing).

Sure, we focus a lot on how things look, and we focus a lot

on how things run – the clever points of a website, the brand
standards, and the smooth transitions. But, except in very
rare cases, that’s not what people are here to see.

They’re here to see content. Just like in the beginning.

Content Strategy: Creating Usable,

Useful Content
When we talk about content, we’re not just talking about
words, sentences, and paragraphs. We’re talking about
communication; the transfer of your organization’s
messaging and purpose to a visiting website user. Whether it
is a comedy video, a long-form blog post, or a bunch of off-
market shirts with Hamilton lyrics, it is content.

Which means whenever we talk about content, we need to

understand why it’s even necessary.52 Why is someone
coming here? What can we provide for them? If this sounds
familiar, it’s because we talked about it in Know the Scope of
the Project – websites are tools, designed to communicate in
one or more of the following ways:

• Information
• Commerce
• Entertainment
• Persuasion
• Administration

Design and technology are still really important! But it’s

always worth remembering that even if it’s not content, it’s
built to serve content. All site widgets and advanced technical
functionality are designed to provide better access to
content. All design serves to frame and provide access to
content.

Some might argue that functionality is content, rather than just a set of features to deliver
content. Is that browser-based game considered content? Should it be managed as content?
The easiest answer is that if your visitors have come to your website to consume it, then it’s
content.

— Deane Barker

Thus, we can understand the business value of content; on a

website, your content is your product. Even if your site is
dedicated to selling physical items or consulting services,
these real-world products are represented by content, and
therefore require the same level of maintenance and careful
strategy that you would put toward developing the products
themselves.
What is Good Content?
In the study of musicology, there’s a tool called SHMRF.
Developed by musicologist Jan LaRue in his book Guidelines
for Style Analysis, SHMRF is an acronym that outlines the
different elements of music: Sound, Harmony, Melody,
Rhythm, and Form.53 The tool is useful in that it reminds us
that music is much more than just a bunch of notes that we
can hum along with: it’s a complex, interconnected art form.

Much like music, content is a multi-faceted, complex being,

yet we often focus only on one small portion of its larger
composition: usually, just the words. This is never more
evident than when budget – time, resources, attention – are
divvied out for a web project: often, it’s content that’s given
the short end of the resource stick.

In reality, when we talk about content, we’re actually talking

about:

• Message/Messaging: What is the overall messaging of

your content, and how does each individual piece of
content reflect that messaging strategy?
• Format: How does the content present its message? Is it
text, video, audio, or some kind of external social media
channel?
• Model and Structure: How is the content built and how
does it connect to other content across the site?
• Organization and Layout: How is your content organized
for findability, and how do the individual elements of a
page provide guidance to importance and navigation?
• Voice and Tone: Is the content written in a way that helps
guide your unique users toward action, and does it match
 the overall brand and messaging of your organization?
• Meta Information: What details are attached to a piece of
content to help machines understand its context, such as
accessibility markers and categorization?

And, yes – on top of all of these different layers are the

words themselves. Just like we need to look beyond the
simple humming of a melody to understand a song’s full
identity, we need to look beyond a site’s words to
understand the usefulness and operability of your site’s
content. To improve your site’s content. To make it good.

But what does good mean? How can we be sure that our
strategy is the right one for our audiences and their
expectations?

We can’t provide you an answer for that on a case-by-case

basis, but we can point you to a set of principles developed
by Erin Kissane in her book The Elements of Content Strategy,
principles that outline the basics of what good content
means to your audiences:

• Good content is appropriate

• Good content is useful
• Good content is user-centered
• Good content is clear
• Good content is consistent
• Good content is concise
• Good content is supported

We like these principles because they are honest in their

goals, and they help us determine methods and tactics that
drive us toward creating content that means something. With
every decision you make regarding your site’s content from
here on out, make sure these principles apply. What’s more,
you could replace “content” with “websites” and it would
serve the same goals.

The rest of this chapter will focus on strategy-driven

planning in three parts: purpose, channels, and messaging.

Your Content’s Purpose

The high level view of your site’s content – and, by
extension, your site’s purpose – is tied to what Meghan
Casey calls a “content compass,” which she defines as “the
role that content plays in meeting your organization’s
objectives – and even more specifically, the content’s
purpose for your project.”54 If the goal of this phase is to
help you create and maintain better content, the content
compass serves as a yardstick by which all content is
ultimately measured as on-point or off-point.

The compass can provide direction in three ways:

• Function: How does content serve a specific function

within our organization? For example: “Our strategy for
retaining clients …”
• Property: How does content serve a specific property
within your organization? For example: “Our strategy for
www.amazingwebsite.com …”
• Subset: How does content serve a specific subset of
content within our organization? For example: “Our
strategy for project case studies …”
Your Core Strategy Statement
A compass is good at one thing: telling you which direction
you are pointing. But a compass on its own is useless unless
you know the direction in which you want to travel.

Enter the core strategy statement, which is “a concise

statement that typically summarizes choices about why a
company (or team) produces content, for whom, and how it
manifests.” It takes everything you’ve gathered so far and
drops it into a single-sentence manifesto. It’s you and your
team planting a flag and saying “this is what every piece of
content on our site has to live up to.”55

While the statement may take many forms, four things

should always be included within the core strategy
statement:

• The business goal

• The audience
• The audience’s needs
• The content you’ll create

For example, when it comes to Blend Interactive’s website,

we crafted the following core strategy:

Gain the trust of potential clients by providing examples of our

competency in problem solving and advocacy on complex content
projects.

• The business goal: “gain the trust”

• The audience: “potential clients”
• The audience’s needs: “our competency in problem
solving and advocacy on complex content projects”
• The content you’ll create: “examples of our competency”

Content Strategy and Content Marketing

Let’s talk quickly about the concept of content strategy and
how it relates to content marketing.

Content strategy – literally the process of making strategic

choices about your content – is a high-level process. It’s an
important look at multiple angles: what do users want, what
do they expect, how can we help, and how can we influence
them to choose our service or organization.

Content marketing is one possible tactic within this process,

and it is exactly what it sounds like: using content to market
your services. Content marketing is focused on providing
longer and larger-form content, specifically marketed as the
product itself, usually with an added benefit of increased
lead generation.

Your Content’s Channels

Content doesn’t just live in a simple HTML page on your
website. It travels around the world in what sometimes feels
like an out-of-control disaster. It’s flowing through what we
call channels, and while we often think of channels as
parallel pipes of information, like radio stations or television
channels, when it comes to web content, channels are more
like different forms of transportation: some push content
faster, some require a ticket, and some are better suited for
large cargo.
For your web content, a standard page might be one
channel. It’s text communicated in that specific place.
Beyond that, the page might be pulled into a news feed on
your site, or displayed on the home page in a special promo
area. These are new applications of the same content.

And then, it moves beyond the site. It’s added to LinkedIn.

It’s posted on Twitter. It’s promoted through a digital
advertising campaign and included in the company
newsletter.

All of this matters because your content is on the web, which

means it’s going to live beyond your initial use. Your content
can travel through dozens of channels. You need to know
where it’s going and what you have to manage … and you
need to know the best way to push it in the right directions.

Acting on Your Research

The biggest rule in channel determination is to put content
where people will find it. Knowing where people are looking
for your content – the research into context, archetypical
user stories, and even demographic information – is exactly
what you need to help figure out where you need to be. In
Ahava Leibtag’s book The Digital Crown: Winning at Content
on the Web, she sums this up in one simple question:

How will this content float along the web and facilitate
conversations?

This is the promise of multichannel publishing: creating a

system in which our overall messaging can travel, allowing
us to distribute content in a way that’s both findable and
usable. And it’s not just digital: your channels might already
include broadcast and print. Even sales representatives, who
you depend on for closing sales, can be a channel all on their
own.

Content Ecosystems
This spread of messaging across the web is called a content
ecosystem.

The term, coined by Scott Kubie, author of Writing for

Designers, brings to mind the more natural definition of an
ecosystem – that “a forest is more than its trees, and your
content ecosystem is more than posts and pages on a single
website.”56 The idea is that while we often get hyper-focused
on creating content for our site, we have to also understand
that our content comes into contact with our intended (and
hidden) audiences in more ways than one.

Documenting this content ecosystem helps us better

understand not just the content that we have and the
channels we’re writing for, but it also helps us understand
how the things we publish move beyond their original
vessel, whether that’s through social sharing, or search
engine results, or even just word of mouth.

Without this illustration, you’re just guessing. And if you’re

just guessing, it’s difficult to justify the channels you
ultimately choose.

Choosing and Developing Channels

The reason we focus on choosing channels before we focus
on messaging is because messaging means nothing if it’s not
encountered by our audiences. We know it’s often hard to
believe, but people aren’t scrambling to read our corporate
blog or Twitter updates. We need to hit the right notes in the
right ways, both in where our content lives and what we use
to distribute that content:

The number of CEOs and university provosts I’ve met who are convinced they need a
corporate blog could staff a busy midwest Dairy Queen.

— Corey Vilhauer

• Where content lives: In the grand scheme of web

content, social media is fleeting. It’s a shifting fault line
upon which your content sits: you do not control it, and
you rarely own it. This means any content that is meant
for ongoing consumption should live on its own in an area
you can control. This is most often your website. Your
blog posts, your event listings, and even your Instagram
images should live somewhere on their own in order to
ensure they’re always around.
• How content is distributed: On the opposite side of the
spectrum is how to make that content move beyond the
site. Your website is not always a destination, which means
you’ll need to understand the ways in which a user might
encounter your content in the wild, whether that’s by
aggregating your posts to a social media channel,
encountering content via digital marketing or advertising,
or editorially curating your way into their lives.

Often, your content’s channels are going to depend on

where your users are communicating. You wouldn’t
broadcast your advertisement for Müeslix on a youth-
centered channel like MTV (rather than, say, the Game Show
Network), just as you wouldn’t post your blog post about
corporate restructuring on Snapchat (when it clearly belongs
on a corporate/work-based channel such as LinkedIn.)

Of course, defining your channels can be slippery. In his

post, “The Slippery Definition of a Digital Channel,” Deane
sketches out a digital audit of Blend Interactive’s channels,
finding no fewer than twelve channels down which Blend
Interactive’s content originated or flowed. Without fail, your
content ecosystem is going to expand and contract; a living,
breathing mess of potential touchpoints. Every one of these
channels includes both a level of effort and a level of positive
returns. It’s up to you and your team to determine which of
those touchpoints are valuable.

It’s as easy as answering two questions:

1. Does this channel provide any meaningful contact to the

people who need things from our organization?
2. Does maintenance of this channel outweigh the benefits
we will receive from it?

Your Content’s Messaging

Finally, now that we’ve talked about the purpose of your
content, and talked about the channels your audiences are
most likely to encounter, we can touch on the concept of
messaging.

Messaging, at its core, is the high-level personification of

your communication goals. Messaging within this book, for
example, is focused on providing an overview of the entire
web process, one slice at a time. We hope that as you read
through this, you come away with several key findings: that
the web process is complicated, but not unknowable; that
you don’t need to be an expert in everything, but knowing a
little bit of each phase is wildly helpful; that the authors are
both wonderful writers and very humble.

Messaging is also more than what we want to say. It’s also

how it’s written. It is an extension of your organization’s
brand. Knowing how to word something, or what to include,
or what to leave out, is all a part of messaging, and while the
concepts of voice and tone are often thrown into the generic
pool of “web writing topics,” they also help shape the intent
of your messaging.57

Message Hierarchy and Architecture

While we often want to try to serve every audience (and
organizational silo) with our messaging, the simple fact is
that we can’t. Oh, that way lies madness.58 Instead, we need to
make some tough choices. We have to choose favorites.

There are two ways this can be handled, spanning the

spectrum of project messaging: a message hierarchy and a
message architecture.

MESSAGE HIERARCHY
With the message hierarchy, you’re focusing on the what of
your messaging. As outlined in Kristina Halvorson and
Melissa Rach’s Content Strategy for the Web,59 a message
hierarchy identifies message priority by assigning a primary
message from which all other messages flow. For example, if
we are creating a message hierarchy for The Web Project
Guide, it might look like this:

• Primary Message:
∘ The Web Project Guide is a relaxed, accessible, high-level
view of how to build a website from ideation to launch
 – and beyond.
• Secondary Messages:
∘ We provide an outline by which you can understand
the entire web project process.
∘ We are a multi-disciplinary pair of writers who provide
both contrasting views and levity to each chapter.
∘ We serve as an aggregation of deeper resources.
∘ We provide single-chapter access to any of a web
project’s many phases.

Below this is a web of copy points and other details that help
fill in the blanks. For example, “We wrote a chapter about
content inventories” isn’t a message. It is, however, a notable
detail that helps prove the message of “We provide single-
chapter access to any of a web project’s many phases.”

All content should flow from these primary and secondary

messages, all interpreted and adapted for their specific
audience. Each audience may see the message in the same
way, or they may encounter them in unique ways.

MESSAGE ARCHITECTURE
Meanwhile, message architecture focuses on the how of your
messaging. As coined by Margot Bloomstein during her talk
“Communicating Content and/by/through Design” back in 2010,
message architecture is a “hierarchy of communication
goals.” While this feels eerily similar to the aforementioned
message hierarchy, in reality a message architecture is
focused on the attributes of a message. For example, we
hope the message architecture of this book looks something
like this:
• Confident: With a level of experience and knowledge;
researched without being academic
• Approachable: Accessible to those without a deep
knowledge of the web industry
• Understanding: Written without judgment; aware of
complicated concepts and trivialities

Of course, message architecture – the very basis of your

future style, voice, and tone guides – may also dictate your
message hierarchy. It’s silly to think that if we highlight this
book as “relaxed,” that we would have a stuffy and rigid
primary message of, “We provide academic rigor and no-
nonsense education.”

Once you have done the work in determining what your

website wants to say you can start:

• Creating a list of topics that ties messaging to your

audiences.
• Determine whether or not certain channels are single
message, multi-message, or omni-message.
• Go back through your content inventory and tie each
piece of content to a message.
• Confirm that every page in your future site map has a
purpose tied to an organizational message.

The Big Decision: Refresh vs. New …

or Just Keep the Old
So, now that you know what you want to do, are you going
to scrap what you’ve got and start fresh? Or are you going to
carefully refresh each page?
For some business goals – especially those that require a new
or revamped focus on your site – you have no choice. You’re
going to have to write new content. For content that you’ve
already written, the decision isn’t so cut and dried.

In fact, it often doesn’t depend on your content needs at all:

it depends on your time and resources. The strategic
decision to move forward with older (but still serviceable)
content is perfectly okay, as long as that content still represents
the goals you’re trying to achieve for both site visitors and
your organization. Writing takes time, and you’ll need all the
help you can get.

When it comes down to it, you really don’t have a choice at

all. Your decision is based on your time constraints, need for
a refreshed brand, or creation of a new content focus. And
here you thought you had control over your own content.

Inputs and Outputs

Before you can determine the purpose and application of
site content, you need to know your users. Your discovery
process leads directly into this: taking the expectations of
your audiences and turning them into actual, usable
communication. This is helped by knowing what content
you already have and, more specifically, how much and to
what extent your existing content is matching user
expectations.

From this phase, you’ll have made major decisions in what

kinds of content you need, what channels you’ll want to
populate, and a framework for your overall web presence
and messaging. What form this takes is largely up to you and
your team: it can be pieced into several illustrative
deliverables, such as a message architecture plan or a content
ecosystem diagram, or it can simply be contained in a high-
level strategic plan document.

The Big Picture

With this phase, we begin forming the schematics and
determining functionality for the entire project. Content
strategy, information architecture, visual design, and content
creation all provide the substance of your project. Things
have been theoretical; now they’re becoming practical.

Staffing
To be clear: creating a strategy around your content and
actually writing your content may fall on the shoulders of
the same person – or it may be completely separate. As we
will discuss throughout the next few chapters, the overlap in
skill sets between content strategy, information architecture,
content modeling, and content authoring is as wide or
narrow as your industry and organization needs.

Most often than not, the bulk of strategic planning is going

to fall on someone who has an understanding of both how
your customers interact with content and how it will be used
into the future. This may be a content strategy consultant, or
it may be a full-time team member who will eventually see
their job transform into more acute strategic planning and
content maintenance. They should be able to see the big
picture across multiple departments, and they should be able
to translate the needs of site users into effective content and
marketing ideas.
52 This is, for lack of a better term, the chapter on content strategy. But, in reality, content
strategy is a combination of several fields, stages, and tasks – what Kristina Halvorson defined as
“guiding the creation, delivery, and governance of useful, usable content.” To learn more about the
specifics of the practice of content strategy, you can check out this great blog post from
Halvorson’s agency Brain Traffic: “New Thinking: Brain Traffic’s Content Strategy Quad.”
53 Nolan Gasser, one of the chief architects of the Music Genome Project (which was eventually
leveraged to create Pandora’s musical service), felt a key element of music was missing from
SHMRF: lyrics and text. His solution was to adapt this to the even weirder sounding SHMRFT:
Sound, Harmony, Melody, Rhythm, Form, and Text.
54 Casey, Meghan, et al. “Create a Content Compass.” A List Apart, 30 June 2015,
alistapart.com/article/create-a-content-compass/.
55 If you can’t get your web steering committee to focus around a free-form sentence, you might
try to craft it as a Mad Lib-style exercise. Sara Wachter-Boettcher has posted several examples of
this model, but you can always adjust to fit your industry, content team, and methods.
56 Scott’s written at length about content ecosystems in a four-part series on Brain Traffic’s blog:
www.braintraffic.com/articles/an-introduction-to-content-ecosystem-maps.
57 To be clear, we still aren’t going to talk about that in this chapter. For now, you’ll have to wait
until Chapter 12: Write for People and Machines.
58 Heck, yeah, we just dropped a King Lear reference.
59 While there have been dozens of books written on content strategy in the past decade,
Halvorson and Rach’s Content Strategy for the Web, a book in its second edition, is a major
touchpoint in understanding the discipline’s purpose and practice.
CHAPTER 10

Organize Your Content

SUMMARY
Your site won’t just magically arrange itself. Instead, you
must provide organization in a way that speaks to those who
visit your site. What labels do they expect? How do they get
from one section to another? How do they hone in on an
information scent?

DOES THIS APPLY?

Just as anyone wants to know their way around a hotel or
hospital when they arrive, the people who visit your site
need to know where to go to get what they want. They have
expectations, and those expectations are managed somewhere
on your site. Your first step is to get them there, provide
them with information in a way they understand, and
minimize frustration as they navigate the vast pool of
information your site contains.
Anyone who has lived in a high-traffic, vehicle-centric city
can attest to at least some kind of failure in urban planning.
Boston is home to a choked bottleneck, as roads wander
along old footpaths. Houston pushes hard against any kind
of zoning, leading to a rich and confusing tapestry. The
suburbs of Washington D.C. shun any of Pierre Charles
L’Enfant’s main city design in favor of standard suburban
sprawl, leading to a mishmash of styles and growth that has
led to the worst traffic in the country.

These may be common examples, but they’re not solely

located in major cities. Even here in the gentle community
of Sioux Falls we run into issues with a proposed
entertainment district, bottlenecking on a major
thoroughfare, and a sprawl unhindered by any natural
barrier.

No city is built with the idea that it’s going to be impassable.

In reality, cities are built with the best of intentions. The
entropic nature of humans and the constant change of
improving technology, however, have no such intentions. A
city is planned in a room and tested through chaos.
Thoughtful organization of a city requires a lot of planning,
a lot of luck, and an awful lot of patience.

Everything we’ve said above plays into the idea of keeping a

website organized. Your site is a city, and within it lies all of
the same issues: thoughtful zoning and organization;
effective and useful channels by which to travel; and
accurate navigation and wayfinding. In a city, this is called
urban planning. For your website, this organization of
content and the paths for discovery fall under the discipline
of information architecture.

Not to beat this metaphor to death, but John Eckman has given a talk on the correlations
 between city planning and content organization called “Content from the Inside Out.”

— Deane Barker

While it might make sense on a superficial level, comparing

the entire discipline of information architecture to urban
planning glosses over the nature of information and how we
create meaning among relationships. It isn’t enough to
create a road and label it correctly, or to put a few pages next
to each other. Content doesn’t take up space, which means
most actions are, in a way, metaphorical: how you move
through content is represented through placement in design,
but it is also managed behind the design. Peel back the visual
layer of a website, and you’d see hundreds of threads
connecting each page, element, and navigational label.

In this chapter, we will set aside the title of “information

architecture,” just as we set aside the title of “content
strategy” in the last chapter. Instead, we will focus on the
basic elements of arranging and connecting information.

• Organizing: how content is grouped, both as collections

and branches of a site, but also as elements on a single
page.
• Navigation: the methods of wayfinding that help us move
through the organization systems we’ve chosen.
• Labeling: the words and icons we use to represent
wayfinding.

Organizing
Robert J. Glushko’s book, The Discipline of Organizing, defines
organizing as “creating capabilities by intentionally
imposing order and structure.” It seems harsh: imposing order
sounds like something straight out of the mouth of Mrs.
Trunchbull.60 But it’s not far from the truth: everything
wants to be messy, and systems of organization are designed
to help impose their methods onto the mess that is your
content.

How those systems impose their methods is going to depend

on which part of your content needs to be organized:

• Information: How is raw information and messaging

managed and organized on your site? When you look for
a specific product, what methods are in place to help
people find it?
• Structural: How are pages organized on your site? Is there
a structure based on a parent/child relationship, or is it a
pool of content organized through labels?
• On-Page: How is information assembled on a page?
When you go to a product page, what decisions are made
to the order and hierarchy of the content?

Organization can be hard, because people organize things in

different ways. One person’s spice drawer is another
person’s nightmare. Which means organization requires a
level of planning that allows for both commonality and
differentiation. We need to be able to let people find things
in different ways, while still providing as much structure as
possible.

Systems of Organization and Your

Information
Much like how cities are organized in different ways based
on their landscape, natural features, and existing
infrastructure, a system of organization – such as
“alphabetical” or “by audience” – provides a baseline toward
how you want your site and its content to be organized.

While there are, potentially, hundreds of different systems of

organization, most of them fall into one of two main
categories. Peter Morville and Louis Rosenfeld (authors of
the seminal book Information Architecture for the World Wide
Web) have labeled these groups as:

• Exact Organizational Schemes: Dividing and classifying

content into well-defined schema. Examples include
alphabetical (because a descriptive name can only begin
with one character), chronological (because an item can
only be assigned a single period in time),61 and
geographical (because an item can only exist in one place
at a time).
• Ambiguous Organizational Schemes: Often subjective,
these schemes defy exact definition. Examples include
topic or category (because the purpose of a piece of content
may differ from person to person), audience (because
different people identify as different things – and may in
fact identify as multiple things), and even weird hybrid
themes, such as a bookstore that defines its genres by
topic (mystery), audience (children), and even reality itself
(non-fiction).

When it comes down to it, organization systems are a natural

extension of what you need to have organized. For example,
in the world of biology, Linnaean hierarchy62 is a system of
organization that helps us better understand the lineage and
genetic makeup of different animals. This could not be as
effectively accomplished if we organized animals by hair
color or chronologically. Organizing depends on your
audiences. What makes the most sense for them will make
the most sense for your site.

How Is Your Site Organized?

All of this is helpful in knowing how information is
organized, but what about the act of organizing the actual
content itself? Where does it live? What shape does that
organizational model take?

For your website, your content will be organized in two

potential ways:

• Hierarchical: You have a home page, and from that home

page branches a tree of additional pages, each page
representing a new topic. As you move down through the
tree, the pages get more focused. This model is based on a
relationship between what we call “parent” content and
“child” content, and it often dictates site navigation.
• Categorical: Items are organized based on their common
fields, and your query of a field delivers results that match
your expectations. In this case, the content is organized
when requested, based on the labels we give it and the
organization structure we choose. This is often seen in
aggregated content, such as search results, or as a feed of
blog posts.

On-Page Organization
Beyond the organization of pages, we also must focus on the
organization of content on a single page. While this might
seem like it falls a little deeper into the court of design, in
reality these are decisions of information hierarchy: when
someone arrives on a page, what information is the most
important for them to see?
More than just grouping similar ideas, on-page organization
– such as the decision to place navigation on the right side or
left side, or the choice to include one content block ahead of
another – reflects an organization system based on message
priority. Sections of content that are higher up on a page
demand more attention. Sections that are placed next to
each other in equal columns are viewed as equally
important, unless some other element of design is
introduced to highlight a specific column.

This is also the point in which we begin seeing the effects of

an always-shifting screen width: the architecture of content
on a single page goes a long way in helping us understand
how a page should look when it’s on a much smaller or
narrower screen.

Card Sorting
Because different people have different ideas of how content
relates to itself, information architects have developed a
hands-on exercise called “card sorting” that puts the power
of organization in the hands of those who will use and
maintain the site.

There are no secrets to card sorting – the name tells you

everything: you provide a list of cards, and you ask people to
organize them into groups based on their own perspective.

Your insight and results will depend on the type of card sort
exercise you are willing (or able) to take on. If you are
looking to organize content within an already defined
taxonomy of categories, you can run a “closed” card sort, in
which categories are listed and users place cards into the
categories they think most represents the item. Or you can
run an “open” card sort, where cards are more freely
grouped according to whatever topic the users feel is right.
You can even run them remotely, using an online service
like Optimal Workshop’s OptimalSort.63

More than anything, remember that this tactic is just that: a

single tactic. You should not take the results of card sorting
as unwavering law; instead, it is one of many methods you
may use to help frame your decisions. As Donna Spencer
says in her book on the topic, Card Sorting, “Remember that
you are the one doing the thinking, not the technique.”

Card sorting is an example of what might be called “bottom up” information architecture. In
that process, you have the content in your hand, and you use it to build an organizational
framework.

I maintain this always works better than a “top down” approach, where you create a
hypothetical organizational framework and then try to apply your content to it. You’ll
invariably find that ideas which seemed great in theory have little applicability in practice.

— Deane Barker

Navigation
If the organization of your site is the zoning and districts
within a city, navigation is clearly represented by the
transportation systems – roads, busses, ferries, and even air
travel. It’s one thing to organize something in a logical way.
It’s another to provide them with a way to get to the area
they’re looking for.

This is the ultimate goal of navigation: helping others

understand the thought process behind how you’ve arranged
things.
Information Scent and Wayfinding
Humans are evolutionarily predetermined to seek out the
best and most valuable path with the least amount of effort
possible. Biologically, we seek shortcuts and rely on
familiarity because that is a more efficient use of our time
and energy, and it ties back to our ancestors and their need
to remember the best places to find food without exerting
too much energy.

This was Peter Pirolli’s take. Pirolli, Senior Research Scientist

at the Institute for Human and Machine Cognition, calls this
the “information scent;”64 we forage for clues in order to
short-cut our way to a solution. In recent years we’ve seen a
shift toward a more empathetic (and less primal) term:
wayfinding. It’s not just providing a trail toward your calls to
action – it’s a conscious look at the balance between signals,
noise, familiarity, and unfamiliarity that lead us in the right
(or wrong) direction.

Of course, wayfinding is more than just an organizational

method: it relies on an understanding of what people want
to find in the first place. Wayfinding takes user-centered
groupings and develops signs and directions upon which site
visitors will depend. Wayfinding is navigation, sure, but it
also includes your calls to action, highlighted links, and
helpful tips. It’s deeply rooted in how people look for
information, a concept that will differ from audience to
audience.

How People Look for Information

Donna Spencer, in her book A Practical Guide to
Information Architecture, introduces us to several types of
information behaviors, helping us understand the many
different ways a person might try to access information
on our site. Some of these include:

• Finding Known Items: You know what you’re looking

for, and you have a great idea on where to find it.
Example: Finding your most recent car payment from
a commonly visited bank site.
• Exploring: You have an idea of what you need, but
you have no idea where to find it, let alone articulate
it. Example: Searching for a new band to listen to on
Spotify.
• Refining and Narrowing: You have some
information in mind and want to narrow down your
results to only that information. Example: You want to
find a recipe that uses radishes.
• Comparing: You are trying to decide between two
items and you want to know the similarities and
differences between them. Example: Comparing
content to help you choose between a Toyota
4Runner and a Ford Explorer.
• Discovering Unknown Things: You came for one
thing, and got sidetracked on some other line of
discovery. Example: You went on Wikipedia to find
information on “Macho Man” Randy Savage’s world
title history, but ended up reading the history of Slim
Jim.

The full list of nine items also includes things like

“diving into detail” and “keeping up to date.” We suggest
grabbing a copy of A Practical Guide to Information
Architecture to learn more.
The Site Map: Boxes, Lines, and Spreadsheets
When we talk about navigation, we’re usually talking about
two things:

• The path someone will take to reach a specific item of

content.
• The space in which a page “lives” within the hierarchy of
the site.

It’s worth remembering here that while we can adjust menus

and create connections between content in a way that a
single page is encountered dozens of times on a site, that
page also has to “live” somewhere in the site. It needs a
central source. You may link to the “hours and admission”
page on your site from multiple spots, but where do we
attribute its actual location?

Often, this representation of navigation is shown as a “site

map.”65

There are two main ways to express a site map:

• Graphical Site Map: A graphical site map consists of lines,

boxes, and other symbols. It is limiting when it comes to
information, but is very useful in illustrating the
relationships between pages – parent and children pages,
for example, as well as groupings of common content
types. A graphical site map doesn’t always require the full
slate of future pages; instead, it focuses on a high-level
look at navigation, verbiage, and sectional hierarchy.
• Detailed Site Map: A detailed site map is a spreadsheet,
which means calling it a “map” is a misnomer. Instead, it’s
really a future content inventory – each page is presented
in a way that both represents the content hierarchy (with
 child pages indented just enough to illustrate its
placement within navigation) and the future state of
content. Because it’s a spreadsheet, the shackles of space
have been thrown aside, allowing us to not only show how
a page is organized, but also what content will be on that
page, its content type, and even its status during content
migration.

Site maps are important because they provide clear

documentation around the future or best case scenario. Lisa
Maria Marquis reminds us in her book, Everyday Information
Architecture, that the site map is where you document the
dreaming. “It is your system’s north star.”

At Blend, we often focus on the detailed site map. Working

through this spreadsheet helps us determine the scope of the
content model (which we’ll discuss in Chapter 11: Model
Your Content) as well as help inform clients of the scope of
their future content migration (Chapter 21: Migrate and
Populate the Content).
Figure 10.1: Graphical Site Map for Relationships; Detailed Site Map for Data.

But, this spreadsheet tends to become a very dense and

difficult document, especially for those who simply want to
know how the site’s going to be organized. This is where the
graphical site map comes in handy, where we can easily sum
up the future, debate navigation terms, and provide quick
visuals of the site’s future during presentations and briefs.

Naming Navigation
When it comes to building a house, fixing a vehicle, or even
passing law through legislature, the words we use are
incredibly important. A common language is required to
make these complicated processes move smoothly; to pass
along information from person to person, to ensure
communication and adherence of standards, and to help
those entering the industry to understand the landscape into
which they are treading. For example, door widths are made
standard, and every part of the door is named according to
an accepted taxonomy, which means anyone who
encounters a door knows what to ask for and what is
expected.

The world of web strategy and design still struggles with this.
Part of that is tied to the creative nature of web design, but
much of it is simply because we’re not asking for the same
level of adherence that a mechanic or builder requires.
Nowhere is this more common than when we start naming
our groups of navigation.

It starts simply enough: main navigation is the top level of

navigation, and this is pretty universally accepted. But now,
let’s name the second layer of navigation the stuff that falls
under the main navigation. Or how about the stuff that sits
above the main navigation. What do you call the left or
right-hand navigation on each internal page? What do you
call navigation in the footer?

Well, you’re getting the universal answer for the web: it

depends. We can tell you what we call these menus, however.

• Main Navigation: The main navigation of the site,

sometimes called the main menu. If it expands into a
dropdown of additional pages, it can be called a flyout
menu or mega menu.
• Secondary Navigation: This is what we call the
navigation within a section that often sits on the left or
right of page content. It begins with the second level of
navigation and moves down through the entire current
section of the site. This is also sometimes called section
navigation or left-hand/right-hand navigation.
• Utility Navigation: The top list of links that are, often,
focused on more task-based sections (calendar, login,
 account) but commonly includes anything that doesn’t
explicitly communicate the meaning of the site. Depending
on site design, we’ve also seen this called eyebrow
navigation.
• Footer Navigation: Navigation in the footer. This is
pretty easy.
• Audience Navigation: We see this a lot on university
sites, where a second layer of navigation is provided as a
block on the home page, sending users to common pages
customized for that specific audience.
• On-Page Navigation: We’ve built sites that include a kind
of “table of contents” for a specific page, highlighting all of
the headings and important sections and linking to them
using anchors.

Figure 10.2: Examples of Common Navigation Elements: Main Navigation, Utility Navigation, and
Audience Navigation.

Does any of this matter? The names themselves do not

matter, as long as you and your team have a shared
understanding of what each of them means to you.

Labeling
If organizing your site is the city plan, and navigation is the
streets, then labeling your content and interaction points is
the system of signage by which you identify your current
place. Labels are the names you give things, so obviously
they become the signage by which users will travel through
your site. If you don’t provide the right label, people will not
make the correct assumptions.

If you only take one thing from this book, let it be this: a link
is a promise. The text of the link – the label you give it – is an
explicit designation: if I label a link as “calendar,” I’d better
provide you access to the calendar. Nothing rouses
frustration more than a mislabeled link.

Of course, while labels provide identification to different

navigation points and sections of your site, labels also serve
as a form of messaging. Think of the top-level navigation of
your site as a unique opportunity for providing brand
awareness. While you may have bold messaging at the top of
your home page, and while you might find more explicit
messaging for each of your audiences within your site, there
are very few spots where you can provide a level of
messaging that stays persistent across the site.

Your navigation is this place. For example, the University of

Notre Dame’s top-level labels include some of the usual
(Academics! Admissions!), but also includes Faith & Service
and Global, signifying to anyone who arrives on the site
from any entrance page that they promote global fluency
and provide a culture of faith and service.
 When we build a site map for organizations within a heavily populated industry, such as
healthcare or higher education, we often urge them to provide differentiation within their
navigation. For example, providing even a hint of uniqueness within the labels you use at the
top level of navigation – as long as they’re still clear and reflect valuable content – can help a
university stick out from the crowd of the “four As” (About, Academics, Admissions,
Athletics).

— Corey Vilhauer

Categories, Tags, and Taxonomy

Of course, labels go beyond the top-level of navigation: they
also provide a way to filter and narrow down large groups of
content. These are labels that provide context to our content
within a larger group.

First, some definitions:66

• Categories: Categories are labels placed on content items

in order to better facilitate search, filtering, or grouping.
Categories are how we broadcast content topics, and link
to similar content. They’re also one way we can inform
the content management system’s robot brain that two
pieces of content are connected, which comes in handy
when you want that robot brain to give you a news feed
filled with only articles about a specific topic.
• Tags: This is our book, so we’re going to go ahead and
give you our definition of a tag as it relates to content.
Tags are free-form. They’re created ad hoc – sometimes
by editors, sometimes by users. The main difference
between a tag and a category is that a tag provides more
freedom, but at a higher cost of maintenance. Tags are
great for quick notes or for personal organization. They
 are not great at being a system-wide search solution.
• Taxonomy: A taxonomy is a classification scheme, which
means it outlines the rules by which a site is organized – a
taxonomy is the name of the system that includes
categories, tags, and metadata. This is a very high-level,
general definition of the term (Patrick Lambe’s book
Organising Knowledge: Taxonomies, Knowledge, and
Organizational Effectiveness names two other definitions
just for the word itself, let alone applications of the word)
but it should get you far enough in understanding why it’s
important.

What’s important here isn’t the terms themselves, but how

they’re used within a site to help organize and label content. In
this case, the categories, tags, and the larger taxonomy are the
labels themselves. They assign meaning both to us as humans
(because when we see a category of “biology,” we know
through our understanding of language that the content is
somehow connected to biological science) and to that robot
brain in the CMS (because when a CMS sees “biology,” it
knows that it’s connected to the other content items labeled
as “biology”).

A Quick Note on Metadata (for

Organizing)
Is this all metadata? Technically, yes.

The classic definition of metadata is that it’s “data about

data.” Anything that describes the content, rather than
being the content itself, is often seen as metadata. For
example, the date stamp on a photo is metadata.
Assigning a category to a news article is metadata.
 We’ll talk about the “behind the scenes” metadata in
Write for People and Machines. In this chapter, we’re
focusing more on metadata that serves to label a piece of
content. When we think about metadata in this way – as
a tool for labeling content – we get a better
understanding of how a website understands the content
for which it is responsible to present.

Our constant refrain is to remind clients that, “Your

website is a robot.” It does not understand context and
nuance, so we have to program this into each piece of
content we present. When I add a category to a page, for
example, I’m telling the website itself, “Whenever you
need something that has this category, you know that this
is one of those somethings.”

How categories and tags manifest within an actual working

site is as a list or system of terms (taxonomy), either created,
maintained, and structured by a central editorial team
(categories) or created ad hoc as necessary (tags). These
terms assign meaning through their labeling, and that
labeling is used either on its own or in concert with other
terms.

When you can’t organize by a page tree relationship, you

can still organize by these common terms. Even if a page
doesn’t have “family” in the form of parent and child page
relationships, it can still have “friends” in the form of
common interests and labels.

Application of Information
Architecture
The practice of information architecture is deeply rooted in
library science and information systems, and all of this talk
of taxonomies and hierarchy and ontologies can seem a bit …
dense. The real question is “How does this affect me and the
site I’m trying to build?”

The answer lies in one of the universal struggles of the web,

which in turn fuels one of our most common requests: “We
want people to be able to find what they’re looking for.”
Information architecture, at its core, is about organization.
It’s about making things seem logical. It’s both an exercise in
tidiness and labeling; not unlike Marie Kondo’s dream of
simple, purposeful spaces, information architecture focuses
on making the most of the space we are given.

Which means information architecture helps us with the

following:

• Knowing the hierarchy of content within a template, like

the home page or an interior page, helps us make better
design choices, including how content is accessed when on
a smaller, mobile screen.
• Understanding how content needs to be labeled helps us
make better decisions when it comes to search results,
filtering options, and other aggregated content streams.
• Navigation groupings don’t just help us find things: they
help us prioritize sections of the site, and they help
surface content that might otherwise be forgotten.
• All of this helps us piece together all of the different
content types and blocks and sentences and complex
systems that we will use to help a person make their way
through the site.

It’s ultimately all about organizing what you have in a way

that makes sense to the people you’re designing and creating
for. There’s that theme again: your information architecture
is driven by user needs, which means it’s driven by users.
Test for them. Create for them. Build a site that helps them
find their way to your content.

A strong information architecture requires a system of pages

that can support it: it needs fields for categories, and it needs
pre-determined relationships, and it needs to be able to
handle all of that complicated work you can’t manage as a
human editor. That’s where we’re going next: into the world
of content modeling, where we start giving our content
shapes and we start defining just exactly what each of those
templates represents.

Inputs and Outputs

You need to know your audiences and what they expect
from you, especially when it comes to how they talk and
what terms, patterns, and paths they’re most likely to follow.
You can grab some of this during initial discovery interviews
and through more information architecture-specific tactics
like card sorting or site map testing.

Out of this you will get some cool deliverables that will start
making your site feel more real. You’ll hopefully get a site
map. You’ll develop a taxonomy of terms that can be
followed for maximum organizational power. You might
even use this information to help shape wireframes and the
design of other high-level pages. More than anything, you’ll
start seeing structure around those ideas you came up with
in the last chapter.

The Big Picture

Information architecture, content strategy, and creation of a
competent content model (see Chapter 11: Model Your
Content) are intertwined and deeply connected. Your
message’s purpose is tied to how it will be organized, and
both are tied to the actual functions each piece of content
will provide to end users.

Staffing
Site organization during a new site or a redesign will fall to
someone with experience in information architecture. On
smaller teams, this may be your web steering committee or
your content strategist, but on larger teams you may have
the opportunity to hire a dedicated information architect
who focuses on information connections, taxonomy and
categories, and other relationship-based content questions.

Because the bones of organization systems begin during the

strategy phase and are baked into design, only to fall to more
of a maintenance mode after launch, we see a lot of
organizations bringing in an information architecture
specialist for the initial build, followed by a governance plan
that empowers someone on the content team to manage
organization, navigation, and content connections beyond
launch.

More often than not, the practices and tactics found in both
information architecture and organizational (rather than
editorial) content strategy are shared among people who
have a mind for thoughtful organization and content
purpose. Go find yourself a library scientist, or at least
someone who has a well-organized record collection.
60 Heck, yeah, we just dropped a Matilda reference.
61 Well, not quite. Chronological schemes get very complicated, very quickly, which is why
developing the perfect web calendar can be so difficult. Some events take place over multiple days
and some do not really occur at all, they’re simply an all-day long holiday or deadline. If you think
time travel movies and Chrono Trigger play hard and fast with the rules of time, you’ll be blown
away by the difficulty in programming a calendar that takes into account week-long deadlines as
well as recurring same-day events.
62 Unofficial fact: Linnean hierarchy – kingdom, phylum, class, order, family, genus, species – is
the coolest system of organization. Do you remember the mnemonic device you used in high
school to remember Linnean hierarchy? (We’re partial to “Kings Play Chess On Flat Green
Squares.”) Unrelated, but did you know one of the authors of this book has a degree in biology
education?
63 https://www.optimalworkshop.com/optimalsort/.
64 Before it was called “information scent,” it was called “information foraging” by Pirolli and
Stuart Card. This term was used because analysis showed that web users employed the same
strategies as food foragers, though there’s no word as to whether any of these users dug around the
couch cushions of a website in order to find enough coin to buy a Slurpee.
65 There are two ways to think about a site map. One is as a tool to help figure out site navigation
as you’re building or maintaining a new site. The other is as a tool for search engines to crawl. If you
see a page called “Site Map” on a website, it’s most often this second tool: a way for a search
engine crawler to easily reach every page on the site, rather than a high-level planning document.
66 The larger problem with defining anything in the world of organizational structure is that
people have very strong opinions about everything. Taxonomy means a lot of things to a lot of
people, but unless you’re neck deep in the intricacies of knowledge transfer, you can take our
definitions as a starting point.
CHAPTER 11

Model Your Content

SUMMARY
Content takes many shapes and connects in many ways.
How these shapes and connections manifest – both in how
they relate to the editorial and design model and in how
they are converted into data that a content management
system can manage – has considerable impact on every
subsequent stage of the project.

DOES THIS APPLY?

While the technical side of content modeling is focused
heavily on building connections within a content
management system, the concept of content modeling
applies to any situation. It’s important to understand how
content will be understood by both the content management
system and any external resources, and even hand-coded
boutique sites need to know how the pieces of a specific page
are interpreted on different mobile widths or by different
search engines.
If you watched cartoons, game shows, or soap operas in the
early 90s, you might have seen an advertisement for Better
Blocks.

Figure 11.1: Three kids and their Better Blocks.

An attempt to compete with LEGO, Better Blocks promised

freedom in the form of a single brick shape. Built for low-
cost consumption and sold to parents who bristled at the
cost and specialization of LEGO sets, Better Blocks lived by
one major selling point: they were uncomplicated and one-
size-fits-all.

Unlike LEGO, which depended on unique shapes to create

realistic builds beyond the standard rectangle (like wing
pieces for planes, or wheels for cars), Better Blocks curved, so
you could use the standard piece to create nearly anything.
They were a perfect sell for parents who were tired of losing
the one piece that kept the whole castle together.

Except … that’s not entirely true. Not surprisingly, Better

Blocks were severely limited because of their simple shape.
Because they weren’t specialized, they weren’t really great at
building anything. Castles were blocky and overbuilt. Cars
had laughably oversized tires. Eventually, Better Blocks
began advertising themselves as an extension of your existing
block system, thus admitting that they were useless without
the specialized pieces they’d mocked in the first place.

And then they simply died out. The one-size-fits-all model

didn’t take off.

Defining the Content Model

If every piece in a building block set is the same, there’s no
inherent way to determine which one goes where. Unique
function leads to unique forms, and those unique forms help
guide us toward understanding purpose.

This is what happens inside your website. Your content, no

matter how hard you’ve worked on it or how strongly you
feel about the subject matter, is just data to a content
management system. It’s an amorphous blob of characters
and images, mushed into the cells of a database in some
cloud environment. It’s a pile of similarly shaped bricks, and
your content management system doesn’t know what to do
with any of this data until you tell it what it is, how it works,
and where it should go. Until you shape it in a way that
communicates its purpose.

This is the work of content modeling. A content model,

according to Deane’s Web Content Management: Systems,
Features, and Best Practices, is:

“A conceptual term for the collection of content types, attributes,

relationships and datatypes in place to accurately describe a
logical domain of content.”

The idea of a content model can feel a little abstract, because

it balances between the conceptual idea of content – the
organization and strategy that we’ve talked about in the last
two chapters – and the functional structure of that content.
Jeff Eaton, in his presentation “Maps, Models, and Teams:
Content Modeling as Collaboration,” defined content
modeling in simple terms as:

• What kinds of things we make

• How they relate to each other
• What bits of info they contain

In other words, content modeling defines the container

within which we will place our content. Elements within a
content model fall into two types:

• Discrete: the self-contained internal structure of an object

– e.g., the fields within a content type, like a sub-title or
author name.
• Relational: how an object of the type relates to other
objects – e.g., a category assignment or aggregation.

For example, take the standard “article” content type. An

article has a set of unique fields that manifest as content on
the page – discrete elements, such as title, sub-title, author
name, main body, or publish date. An article also contains
several relational elements, such as how it automatically pulls
into a news feed, or how assigning a specific category allows
that page to show in a related feed.67

The Content Model in Action

Of course, the actual concept of content modeling means
different things to different people. To those leading a web
project or planning and managing a website, content
modeling is focused on defining and maintaining the
templates needed to serve your unique content needs. To
those designing a website, content modeling is focused on
visual representation of content types, including the
structure of content at different screen widths and within
applications. To those building a content management
system, content modeling is focused on defining the
parameters in which content will work within a template.

In reality, a content model helps streamline the editorial

process. It helps us create:

• Content reuse: Instead of repeating the same content

over and over again, we rely on relationships to “reuse”
content from other sections, such as programmatically
created lists based on categories
• Intelligent content management: Because the content
model assigns meaning to pages, components, and fields,
the robots in your content management system
understand what to do and where to go.
• Freedom for content beyond the content management
system: Data connected to your content model informs
both current applications and external applications, either
through API68 or some other kind of data transfer.
Multichannel publishing is not possible without a well-
 defined content model.

Understanding Adaptive and Structured

Content
While the content model is largely responsible for defining
and providing connections between content types in a single
content management system, it also provides us with the
tools to begin shaping our content beyond the standard
page. This is where terms like adaptive content and
structured content come into play.

• Structured content describes the process of breaking a

single content type into individual attributes or fields,
allowing these fields to be delivered to different places at
different times. The classic example is a recipe: a recipe is
not just a blob of words, but instead a set of unique parts
(recipe title, cooking time, individual ingredients and their
amounts).
• Adaptive content uses structure to adjust what content is
displayed based on the device or environment.69
Sometimes this is design-related – responsive and
adaptive design rely heavily on structured content to help
maintain the content’s meaning while rearranging design
based on screen width and speed – and sometimes it’s
personalization, such as when a site like IMDb serves
different content based on whether you are logged in or
not.

For example, think about how a specific episode preview of

Parks and Recreation on a streaming service might provide a
season number, an episode number, a title, and a summary.
This is adaptive content being uniquely displayed on the
preview page, fueled by the unique structured content fields
within the larger content system.

If you imagine creating a page within your website, anything

outside of a rich-text editor70 or not hard-coded into your
page template is, in some small way, structured. There’s irony
in this, as noted by Rachel Lovinger and Razorfish in their
white paper “The Nimble Report”:

Ironically, it’s more structure that makes content nimble and sets
it free. Not the kind of blind structure that defines the layout of a
web page, but tags that express the meaning and function of each
individual element in a content item.

National Public Radio’s COPE

The classic example of a structured and adaptive content
model – and by classic, we mean it’s now almost
mandatory to mention it in any article about content
modeling or structure content – is National Public Radio’s
COPE, which took one centralized database of content
and served different versions based on media width,
platform, and user status.

Planning the Content Model

You can do nearly anything with your content if the content
model is developed in the right way. That’s the difficulty, of
course: a content model does not live in a vacuum. You can
dream as much as you’d like, but if it does not fit what your
tools can actually manage, the content model’s promise of
an interconnected editorial experience will fall flat.
Connecting Objects
Of course, part of that dream is to actually begin mapping
out what your site needs to develop a real model. What kinds
of things are necessary to communicate to your audiences
and provide closure to their expectations?

For example, let’s imagine you run a record label, and that
users are coming to your website to purchase merchandise
for one of the artists on that label. From right here, we can
start sketching out the types of things they’ll be looking for.
For example, digging down into the information necessary
to sell an artist’s music we find that:

• Each individual artist is its own object

• Each artist has a set of albums
• Each album has a set of formats (vinyl, CD, cassette,
digital)
• Each digital album has a set of songs

Another branch is formed if we dive into artist merchandise:

• Each artist has merchandise

• Merchandise can be organized by media type: album, by
tour, by type (shirt, pin, sticker)
• Each shirt has a set of parameters (size, color, style)
Figure 11.2: Connecting Elements of a Record Label Website.

What’s more, each artist might have an artist bio, an artist

discography, or tour dates. Each of these might be structured
in a way that they show on the artist’s product page, or even
on every individual product. The artist might show in
certain sections if they’re still active (versus being retired or
currently signed to a different label). Those tour dates may
trigger an artist to be “featured” on the home page.

This isn’t to say every content model will go this deep –

instead, we’re highlighting how each object is a unique piece
of content, and how they connect is largely dependent upon
a balance of technical complexity and editorial workflow.

Balancing the Content Model

With the general concepts defined and some basic list of
content types created, we look then to the language of
templates.

We often think of our websites as collections of pages, each

one unique and focused on one specific chunk of content. In
reality, for sites run on some kind of content management
system, websites are patterns of templates. Each template
relates to a specific kind of content, and is created to
uniquely serve that kind of content. The content inside is, in
a way, a series of answers to a long list of questions.

Take a news article, for example. The template helps define

a publish date, and an author. It may provide a different
visual layout, or provide unique layouts for different
situations. Or, these templates may represent a small section
of a page that can be dropped and reused on multiple pages
– a block, or a component. These templates might even
represent a simple definition, such as when we define the
categories that might appear on a list of products.

Within a content management system, we see, essentially,

four categories of content templating:

• Pages: Pages are what you see.71 They are often URL
addressable, and more likely to be larger and more
complex templates, with a common set of unique fields.
An example is a university professor’s profile page.
• Blocks: Sometimes known as modules or components,
depending on the CMS. These are unique content chunks
that are not assigned to a specific URL and are designed to
add customizability to existing content pages. An example
is a video block that can be placed on that university
professor’s profile page.
• Aggregations: These are feeds or collections of content
 already created within the CMS, reconstituted for a new
purpose. An example is a university faculty directory:
outside of the request to list and sort all faculty members,
none of the content for the directory actually lives on that page –
it’s all aggregated from the existing profiles.
• Integrations: These are pulled into the CMS from a
completely external source. Integrations are often
completely and totally out of the control – outside of
design and parameters – from the CMS itself. An example
is an integration of content from Google Scholar onto a
professor’s profile page.

This is all mentioned to show that there are tons of

connections to consider in order to replicate the
understanding we as humans already possess. A well-
modeled site is created in a way that approximates the
connections our brains already understand, which is why we
find ourselves frustrated with a poorly modeled site: we
assume that some kind of knowledge, whether it’s how a
news feed is displayed or what shows up in search results, is
so common that it should be present.

Balancing this content model requires just as much

thoughtful user-focused design and domain knowledge as its
fancier siblings in content and graphic design. In her book
Content Everywhere, Sara Wachter-Boettcher urges us to
consider our content model against three criteria:

• Gains and losses: What do you gain by making something

its own piece of content vs. keeping it as a piece of a larger
template?
• CMS capabilities and trade-offs: Will your content
management system support extra complexity, or will it
slow down the entire site?
• Authors and workflows: Will content creators and editors
find the extra structure or added content types to be
helpful, or will it hurt productivity and morale?

Common sense needs to be programmed, and it can be one

of the most difficult things to do because we’re making
assumptions about what a CMS knows the second we
encounter it. Until the content model is actually
implemented, however, the connections and concepts
therein are nothing but a dream. Just as a schematic diagram
accomplishes very little without real physical connections, a
content model needs to be defined within the content
management system through code.

Implementing the Content Model

With the objects determined and the overall model sketched
out, we can start defining things for both editors and the
content management system. Largely, this falls into
documentation and creation of attributes within each
content type.

Content attributes fuel what you see on each page. If you

imagine a single page on a website, you can imagine it as the
arrangement of multiple unique attributes: title, main body,
related items. But content attributes also fuel the
connections between content types. They provide guidance
behind the scenes, in the metadata and content aggregations.

For most content types, a majority of the attributes will be

easy to uncover. An album page from our music example
above will have a field for title, artist, album image,
description, track listing, and price. Determining what feeds
into each of these attributes is a bit more complicated:
• Title: A standard text string, or a “fill-in-the-blank” field.
• Artist: Chances are, a content type related to artist already
exists, so you would add the relationship in this field. In
this sense, you’re not typing in a random text string;
instead, you are saying “when I say artist, I mean this artist
object.”
• Album Image: An uploaded image. This could pull from
a central library, or it could be connected to this
individual page.
• Description: A rich-text (WYSIWYG) field that may
include links to other content on the site.
• Track Listing: This might be rich-text. Or, it might be a
content relation to each individual track (if they’re
available on their own).
• Price: A standard text string, or potentially a tie into an
existing sales catalog.

As you can see, populating the attributes in a content model

is not as simple as a fill-in-the-blank form. In Rachel
Lovinger’s A List Apart article “Content Modeling: A Master
Skill,” she says that for each attribute, you must consider the
following:

The Content Model as Editor Interface

A site’s content model has a large impact on how a
content management system’s editorial interface is
created. We have to remember that the programs we’re
using to create web content are often piecing together
bits of data from several databases, translating them into
readable and viewable human language, and then
 arranging them into a specific shape based on a structure
of HTML. If we used the same language as a CMS to
populate those fields and make those connections, we’d
be looking at rows of spreadsheets and random
characters.

This means that there’s an added level of work that

needs to be done in order to translate the connections
and attributes within a CMS to a form that editors are
comfortable with:

• Labeling fields in a way that’s understandable, such as

referring to the content and not the file type.
• Providing help text – including image sizes and
character limits – on every field.
• Staying consistent throughout the user interface.

For more on creating a usable editing interface in the

CMS, read Eileen Webb’s article “Training the CMS”
from A List Apart.

• Layout: Do some things need to be displayed in a

completely different style, or in varying places on the
page? Avoid having markup and styling stored with
content – instead, if different layouts break up content in
different ways, break them out into unique attributes.
• Reuse: Again, a separate field of data can be pulled out
and used independently of the rest of the page, but not if
it’s all part of one big body of text.
• Sorting and filtering: If you want to be able to sort
content by date, or filter content that pertains to a
particular city, then these pieces of information have to be
in a field by themselves so that they can be used to sort
 and filter.

Implementing Aggregations and Automation:

Using Categories and Metadata
We talk a bit in Chapter 12: Write for People and Machines
about writing for metadata – writing text that can be used
beyond the page itself to help populate search engines and
identify important concepts. Here, we’re talking about
metadata as classification – a guide to helping content get to
where it needs to be, often behind the scenes in a way we’ll
never formally encounter.

For example, let’s say we’re in need of a news feed on our

site. We all know what a news feed is: it’s a list of news
articles, usually in reverse chronological order. But to the
content management system, that news feed is a kind of
saved search, filtered by a set of parameters. It’s up to us to
define the parameters. Some of this happens in
development, as the page is created within the content
management system, while some of it happens editorially
and is assigned, either during programming the content type
or as an editorial task. For our news example to work, we
need to make the following programmed choices or editorial
decisions:

• Program the news feed to only pull content of a specific

content type – in this case, a news article.
• Determine what structured content within that content
type will display on the feed – in this case, the title, article
summary, publish date, and author.
• Create a rule for feature articles that allows an editor to
flag an article as “feature,” which means it will appear at
the top of the page layout.
• Create rules for how to handle the news feed if more than
one article is flagged as “featured” – do you show all
featured articles at the top, or only the most recent?72
• Determine the default number of article previews per
page, and paginate beyond that. Is this hard-coded into
the content type, or can an editor change that number?

This combination of human editorial metadata – curation

by data, in a way – and programmed relationships is the
ultimate promise of a well-balanced content model.

Structured and Semantic Content

Semantics is the study of “meaning,” and for the web it
means helping complex systems understand the meaning of
words and concepts. Again, content management systems
don’t understand human language, so we have to define
languages in a way that they understand: through
connections and data.

In some sense, we’re still talking about metadata – managing

semantic content means assigning metadata like “location”
and “people” and “date” – but when we talk about structured
language and semantic content, we’re looking at something
called XML – extensible markup language – which helps
provide meaning and structure within our templates. In the
words of Rahel Anne Bailie and Noz Urbana in their book
Content Strategy, “XML explains to computers what humans
immediately know about content just looking at it.”

From a technical standpoint, building this XML into a

specific page template is the work of back-end developers.
However, it’s a full-team process to determine what schema
to use and which XML elements to incorporate.
There are universal schema developed for dozens of
industries and organizations that help identify content types
and data types for purposes beyond a web browser,
including creative works like books and albums, health and
medical data, and even how reviews and ratings are handled.

Additionally, there are proprietary schema that exist outside

of XML, specifically focused on aggregation of content
within social media or search results. These include Google’s
structured data and Opengraph.

Developers will integrate XML within the standard markup

of a page – the HTML, or the basic structure of content and
design recognized by web browsers – and very little of it is
going to be interpreted by actual humans. This is all behind-
the-scenes stuff.

Beyond Structure: Writing Still Matters

Implementing the content model and creating the vehicle
for your content is an exercise in balance and
deconstruction. You work backwards from a finished
product in order to figure out how things fit together – and
how far you’ll need to break it apart.

Of course, this is only tied to the content you can fit within a
unique attribute. Beyond that is the actual words themselves
– not just what a title is, but how that title is written. Not just
the content in the main body field, but how that main body
field matches user expectations and drives action on your
site.

Structured data and content modeling is important to help

keep your content intelligent, mobile, and free. But that
content isn’t worth anything if it doesn’t connect with your
audiences. In the next chapter, we’ll take a deeper look at
writing for the web – the methods, the rules, and the myriad
of possibilities you’ll encounter as you go from dream to
reality.

Inputs and Outputs

For content modeling to work, you need to understand the
technical goals of your site. You cannot build a content
model for a calendar, for example, unless you understand
the types of events you’ll be promoting and the browsing
patterns of those who will attend. You’ll also need to know if
there are any standards in your industry or organization that
need to be followed. Finally, you’ll need to have some basic
understanding of how your content management system
will handle certain types of content.

As a result of the content modeling phase, you’ll understand

the scope of what is necessary for front-end and back-end
development. You’ll have identified the full suite of
templates and their attributes, and you’ll have a stronger
sense of who will manage (and how they’ll manage) the
content for your new or revamped site.

The Big Picture

Content modeling tends to pull from both the strategic
content process and information architecture in that it takes
the strategic and organizational needs of your site and builds
a model by which you can reach your content goals. At
Blend, we often tackle content modeling as a part of our
larger content management scoping process – knowing the
templates and aggregations of our site helps us get a better
grasp on how much time design and build will actually take.
Staffing
Content modeling requires a mix of content strategy,
information architecture, and content management system
development. It’s a transition period that’s most often staffed
either by someone who understands how a content
management system works, but in a way that takes an
editor’s experience into account.

67 In some systems, discrete and relational elements are actually one and the same, such as an
article that fills its “author” field not with a string of text, but instead with a relationship to an author
page located elsewhere on the site.
68 An “application programming interface” that effectively connects two systems – on a website,
this might be a connection between the content management system and a set of data located on
some other site. For example, any app that pulls content from Twitter’s ongoing data feed is using
an API to ask for, format, and deliver that data.
69 Karen McGrane has already tackled this topic at such wonderful depth that you should just go
watch her presentation, “Adaptive: Content, Context, and Controversy.”
70 A rich-text editor – or a “What You See Is What You Get” editor (often spelled WYSIWYG and
pronounced “whizzy-whig”) – is the all-too-common Microsoft Word-style text box in the middle
of your template. It’s where you can just write, and it allows you to highlight and bold and italicize
and add new headings and sometimes even change colors. It’s perfect for those times when you
need to write a lot of words for a page, but because it’s all a single field on the site, it’s also very
difficult to pull content from the rich-text editor.
71 This is actually becoming more and more of an outlier, especially on sites where content is not
as rich in connections. Marketing sites may have one or two simple content types that are largely
generic, with the bulk of content living in small blocks that can be arranged ad hoc on the page. This
is the model that a service like Squarespace depends on.
72 Even this can be ill-defined. When we say “most recent,” we have to define what that means.
Most content management systems allow you to add a “publish date,” which is the day you want
the page live on the site … but this is not congruent with “creation date,” which is the day you
actually create the page. It’s also not congruent with a “dateline,” which might allow you to assign a
date that’s not connected to the CMS at all.
CHAPTER 12

Write for People and Machines

SUMMARY
Your text content doesn’t just appear out of nowhere. It has
to be written. This chapter is about writing for the web,
understanding how to write for both people and for web
services like search engines, voice recognition, accessibility
tools, and more.

DOES THIS APPLY?

You need content to be written in a way that is
understandable by your audiences, so of course this applies.

Ernest Hemingway famously said, “There is nothing to

writing. All you do is sit down and bleed.”

Let’s make the wild assumption that Hemingway never

stared down a 500-page content migration project. He never
had to – he was a writer afforded a lot of leeway, whose
brilliance came from freedom. He wrote as art, and though it
takes looking past his boorish character, he could bleed out
some of the most striking and powerful prose.

You are not Hemingway. You are not writing for art. You are
working toward something tactical and functional. You are
building a website, and, while a bit of levity and creativity is
important, you don’t need art. You need something that can
communicate effectively.

You don’t get to sit down and bleed; instead, even more
importantly, you get to help people understand.

But it’s more than that. The web is limitless, yet fiercely
structured. In order for your words to travel, they need to be
written for the machines that make the web work: for search
engines, voice recognition, and assistive accessibility tools,
through use of metadata and in-content structure.

It means writing for people and machines. Hemingway

never had to face those odds.

What People Want

The first rule of writing content is understanding that the
focus isn’t on writing the words. The focus is on your site
visitors reading the words. Reading is, in essence, cypher
cracking. Letters, words, and sentences are all codes for
illustrative meaning. The more comfortable we are with the
code, the faster we are to comprehend.

Comprehension is stifled on the web, where our readers are

not necessarily excited or perfectly situated to read what
you’ve written, so our goal is to make things as easy as
possible. Rachel McAlpine, in her book Write Me a Web Page,
Elsie!, lays out the odds we’re up against. Our readers are:

• Uncomfortable: They’re reading on a bright screen,

holding a phone or staring at their laptop.
• Always adjusting: Because there is no standard width or
font size, content layout has difficulty staying consistent.
• Goal-oriented: There is very little casual reading on the
web, especially when you’re selling a product or a
solution.
• Diverse: You can rarely count on a single, universal
audience to write for; instead, you are tasked with writing
for everyone.
• Impatient: For all of the reasons above, they don’t want to
dawdle around.

In other words, it’s up to us to lighten that cognitive load.73

It’s up to us to write for people, and not at people.

The Difficulties of Writing in General

Why does writing for the web seem so difficult for some?
Because writing combines a multitude of frightening
issues on its own, let alone adding the “for the web” at the
end.

This chapter is about the things you will need to take

into account when writing content for the people who
visit your site. It is not about writing itself, because that’s a
topic best left for longer books.

Or shorter books: for that we direct you to Scott Kubie’s

Writing for Designers, a wonderfully written, brief book
 that talks about writing first. It’s a book about writing that
just happens to be for the web. Scott’s views on
structuring your time, writing fast and editing slow, and
overcoming your own writing insecurities is both
accurate and invaluable.

Writing for Readability: Plain

Language and Scannability
To the Center for Plain Language, “plain language” means:

“… The target audience can read, understand, and confidently act

on the information in your content.”

Which means the definition of “plain” is a definition that

shifts with the audience. What is plain language for one
audience may not be plain language for another audience.
Content that is specific to, say, a biology teacher is going to
reach a different level of “plainness” than content meant for
their students.

First, use shorter, more common words whenever you can,

especially if it carries the same meaning, and even more
especially if you’re writing content meant for a wide variety
of people at different levels of understanding. In a pinch,
imagine what your words would sound like if you were
saying them out loud during a conversation. Are you
“incentivizing your offspring for positive behavior?” Or are
you “rewarding your kids for being good?”

Write simply, and your readers will benefit. It’s best to write
at a low enough reading level that the widest audience can
understand. Without losing meaning, of course. We’re not
asking you to “dumb things down.” We’re asking you to be
clear and purposeful: write at roughly a high school level;
limit paragraphs to roughly eighty words; and avoid jargon
when possible.

There are accessibility benefits to all of this: it benefits those

with cognitive impairments as well as those who do not
speak your language at a high level. It even benefits
distracted people. But really, it benefits anyone who is
reading it.

Write for Scannability

At our worst, as Ginny Redish puts it in her book Letting Go
of the Words, instead of communicating information, we
write documents. She says:

Most people come to the web for information, not for a complete
document. They don’t want the user manual; they want
instructions for the task they are doing. They don’t want the
hand-book; they want the answer to specific questions. They want
usable, manageable pieces.

This is true even if we look more granular: people don’t

want a page – they want an answer on that page. While there
are some looking for the full set of instructions, most are
simply looking for a detail.

Creating easily scannable content helps you, in essence,

break your content page into what might look like proto-
pages. Your audience can approach content from any
number of angles with a high level of understanding:

• They can easily parse the different concepts within the

 page.
• They can get a feel for the entire process thanks to logical
sections within a page.
• They can quickly find a specific section on a page.
• They can find unique information based on common
formatting clues.

Writing for scannability builds upon the simplicity of plain

language:

• Write short paragraphs and sentences.

• Write headings that clearly define the section of content.
• Write one main subject per page, and one main thought
or concept per section and heading.
• Use bullet lists to summarize important points.
• Make good promises with your links by accurately
describing where they will take someone.

Here are examples of low and high readability using the

always popular “Star Wars Ipsum”:

LOW READABILITY

Cute Headline
What!? You mean it controls your actions? I can’t get involved! I’ve got work to do! It’s not
that I like the Empire, I hate it, but there’s nothing I can do about it right now. It’s such a long
way from here. Dantooine. They’re on Dantooine. Kid, I’ve flown from one side of this galaxy
to the other. I’ve seen a lot of strange stuff, but I’ve never seen anything to make me believe
there’s one all-powerful Force controlling everything. There’s no mystical energy field that
controls my destiny. It’s all a lot of simple tricks and nonsense.
 Don’t be too proud of this technological terror you’ve constructed. The ability to destroy a
planet is insignificant next to the power of the Force. You mean it controls your actions? I
have traced the Rebel spies to her. Now she is my only link to finding their secret base. I call it
luck. I have traced the Rebel spies to her. Now she is my only link to finding their secret base.
Hey, Luke! May the Force be with you.

HIGH READABILITY

Relevant Headline
Now she is my only link to finding their secret base. I call it luck. Hey, Luke! May the Force be
with you. I have traced the Rebel spies to her. Now she is my only link to finding their secret
base.

Relevant Sub-Headline
What!? You mean it controls your actions? I can’t get involved! I’ve got work to do! It’s not
that I like the Empire, I hate it.
• Don’t be too proud of this technological terror you’ve constructed.
• The ability to destroy a planet is insignificant next to the power of the Force.
• You mean it controls your actions?
What!? Clear and actionable link to solution. I can’t get involved! I’ve got work to do! It’s not
that I like the Empire, I hate it.

Writing for Understanding: The Right

Thing
If that previous section felt like an exercise in middle-school
English, you’re not wrong. The foundation of what we write
for the web – just as it is for all writing that’s meant to be read
– lies in our ability to be clear and organized.

Writing for the web is not just saying what we mean, but
doing it in a way that conveys the meaning. It is writing for
both action and emotion.

Voice, Tone, and Editorial Guidelines

Writing is more than just perfect sentences. It’s also voice
and tone: it’s the words you choose, and it’s the mood you
exhibit. In Nicole Fenton and Kate Kiefer Lee’s book Nicely
Said, voice is “what makes people feel like they’re listening to
someone they know when they visit your website.”

Let’s define these two terms:

• Voice: This is who your company is. In Nicely Said, this is

referred to as your company’s public personality; it does
not change from day to day. While your organization may
have multiple messages or audiences, it should have one
consistent voice.
• Tone: This is the interpretation of your voice in a specific
situation. It’s what your readers pick up as they read an
error message, or a successful submission of an email
address. While your organization will have one consistent
voice, it may have multiple unique tones for different
situations.

In other words, if your voice is your day-to-day demeanor,

your tone is how you sound when you’re mad about the
kitty litter box going uncleaned for three days.

Developing voice and tone is purposeful, and requires

maintenance. Readers can detect a voice that’s not real. Of
course, developing a voice and tone and executing that voice
and tone are two different things. Writing with voice and
tone in mind can be difficult to non-writers, or writers who
feel stifled or micromanaged. It comes down to developing
tools that balance the freedom of writing with the strict yoke
of editorial standards.

This is where your editorial guideline documentation comes

into play. Guideline documentation might take one of many
forms, including:

• Voice and Tone Guide: The focus of a voice and tone

guide is around examples and situations, rather than exact
terms. Mailchimp’s Content Style Guide has forever been
the standard bearer in this department, with good reason.
• Formal Style Guide: Editorial style guides are staples of
the journalism industry, focusing on standards around
grammer, usage, and spelling. The web has its own, the
Yahoo Style Guide, but be warned that it was written in
2010 and can tend to lag in certain areas.
• Voice Chart: A voice chart provides a set of “decision-
making rules and creative guidance,” in the words of
Torrey Podmajersky in Strategic Writing for UX, and
focuses on making your user interface content and error
messages read a little bit less subjective.

But beyond this, it’s about being patient with writers,

fostering an environment of teaching, and reviewing and
training throughout the process.

Writing Guidelines for Understanding

Beyond voice and tone – and beyond that approved list of
terms you should and can use within your organization or
industry – writing for the web is best summed up as “writing
for understanding.” Which means the quips we use to add
flair to our writing can be troublesome to those who visit our
site.
Our goal isn’t to be a stick in the mud or boring. It’s just that
there’s a balance between the plain language we mentioned
above and the voice and tone we use to infuse brand
attributes into our text. Here are some basics we need to
understand in order to be both inclusive and honest with site
visitors:

• Be Clear: If you need someone to take action, provide

them with a strongly worded task. Instead of “Reach out to
us to sign up,” say “Email us at
[email protected] to schedule your
appointment.” Instead of “Thanks for reaching out!” say
“Thanks for contacting our service department! We will
contact you within 24 hours to confirm an appointment.”
• Be Consistent: Stay consistent with tone, direction, and
even the words you use to describe things. For example, if
your university refers to a specific department by both its
department name (Education Department), its school
name (The Verynice School of Education), and its location
on campus (Verynice Hall), make sure these terms are
clearly assigned to specific meanings, otherwise confusion
will run rampant.
• Be Sincere: It’s easy to want to say everything is amazing
and wonderful and perfect. It’s probably not. Be honest
and sincere with what you write. Review your adjectives to
make sure you’re not making some crazy claims. Don’t
tell someone your product will change their life. Tell
them how your specific features will improve their
workflow. Don’t tell someone you’ll get back to them right
away. Tell them you’ll contact them within the next 24
hours.
• Be Jargon-Free: Stay away from jargon, idioms, and
metaphors whenever possible – like overusing industry-
specific acronyms or technical terms, or dropping
 nonsense business quips like “being in the driver’s seat” or
“taking the bull by the horns.” They’re often more
confusing than simply saying what you mean. What’s
more, industry jargon draws a clear line between you and
any readers not indoctrinated into your circle of
knowledge – it says, in essence, that if you don’t know
these words, you do not get to enjoy this information.
They are difficult to translate, occasionally
misinterpreted, and quite often very cheesy.

Testing Reading Level

It’s tempting to want to run your writing through a
reading level measurement tool to help determine
understanding. However, testing reading level is
troublesome. Most tests assign values based on word
length or sentence length of syllables, which takes
context and meaning out of the equation. As long as you
understand this, we suggest running your text through a
tool that measures multiple scores in order to get more
context like the one you can find at
ReadabilityFormulas.com.

Another option is to test the familiarity of the words

you’re using. Randal Munroe’s Simple Writer online tool
takes a block of ten and compares it to the 10,000 most
frequently used words in the English language.

Writing for Machines

While your content management system focuses heavily on
structuring content for more intelligent use, there are still
places where your words live in a place of freedom: the rich-
text editor, or “WYSIWYG.” In this field you are not tied to
fields or content chunks. You can write anything in nearly
any format.

But that freedom comes with responsibilities, especially

when it comes down to how a machine interprets your
content.

First off, let’s remind ourselves that web browsers and

assistive tools cannot read. Instead, they scan and parse
content based on a set of codes. When we see the words
“Mary had a little lamb,” we understand the context within
the words. We know that Mary is probably a person. We know
that Mary has a lamb, and that the lamb is little. We may even
understand some of the background – that this is a line from
a children’s song, or that it’s commonly accompanied by a
specific melody.

A browser does not know this. A browser sees five words. It sees
eighteen characters and four spaces. It may recognize some
words based on an internal database – it may understand
that Mary is a proper noun (because it’s been told it’s a
proper noun) or that a lamb is related to sheep (because it’s
been told that “lamb” is related to “sheep”).

Beyond that, though, it knows nothing. We have to tell it

what’s important. We have to tell it why it should care.

Headings
Headings are, in essence, section titles. If you’re unfamiliar
with how a browser or screen reader encounters content,
headings look like nothing more than a design element. This
is where trouble sets in; in fact, headings signify to both
browsers and readers the topic of a section, in a specific
order. They are not a simple design flourish, but instead a
framework for understanding.

Just like a page outline, headings are sequential:

• Heading level 1: This is the top heading. This

communicates the overall page topic. Sometimes, this is
equivalent to the page title, but even if the page title is
separate this first level heading should identify the overall
concept of the page.
• Heading level 2: Second-level headings break the page
into major sections.
• Heading level 3, 4, and beyond: Beyond the second level,
headings break larger sections into smaller ideas.

Heading 1, therefore, should be reserved for the title of the

page. Search engines use headings to help identify what
parts of content are most important. Accessibility tools use
headings to allow readers to easily skip sections of the page,
approximating the act of scanning a page with our eyes.

Descriptive Text Links: Beyond “Click Here”

Where headings are designed to be scannable and assist with
navigation, links are designed to actually take you elsewhere.
What this means is that your text links need to be
understandable. Again, a link is a promise: you are essentially
telling someone that this is where you’re going to go. A
“Click Here” link means, effectively, nothing in terms of that
promise.

It’s not just humans, either. Search engines use link text to
define the destination page. The words you use within a link
are the words a search engine uses to understand context – if
your link includes the text for “pamplemousse La Croix,” the
search engine is going to make the natural assumption that
the link itself relates to those words.

Finally, link text serves as a guide for those who cannot see
surrounding content. Remember: not everyone or
everything can see that context – a “click here” link might
mean something if it’s next to a call to action to apply for a
loan, but search engines and those who use assistive devices
cannot always see that context. They come to a link that says
“click here” and they think “Why? Where does this go?”

Instead of “click here” or “read more,” your links should be

descriptive and clear. Links on their own as buttons or calls
to action should help the user understand where they’ll go,
such as a link that says “View our policy catalog.” Links
within a larger line of text that are not necessarily calls to
action should at least use text that is clear about the target.

Metadata and Titles

The lack of context extends beyond links and into the page
itself. Each page requires its own system of machine-
readable metadata tags, allowing machines to parse the
meaning and structure of the page. This includes:

• Page title
• Page description
• Template-specific content (such as signifying and labeling
dates and authors within an article or blog post)
• Audience-specific content (such as signifying and labeling
job posting date within a job listing)

These are sometimes called meta titles and meta

descriptions, or they’re created using a scheme called Open
Graph (for social media summaries and “cards”), or
Schema.org (for more structured content such as media
listings or job listings). Regardless, they’re clues to web
browsers and search engines and assistive devices as to what
content is important … and where it should go.

Summaries and Meta Descriptions

Your content may live in one spot, but it’s going to be found
everywhere. Portions of it will be pulled for search engine
results pages, or for your on-site news feeds, or excerpted in
RSS feeds or social media bots. And while it feels like it
might be completely out of your control, how that content is
found can often depend on a combination of fields within
your CMS and metadata.

What’s important to remember about summary content is

that if you don’t explicitly write it, something will write it for
you. It’s not enough to just let it truncate where it will – as
Karen McGrane often says, “truncation is not a content strate
…” – especially if you have the ability to quickly write
something that you control. Writing these are as simple as
summarizing the purpose and overall thoughts of the page
itself, usually within the accepted summary or description
parameters.74

These fields include:

• Page summaries/excerpts: Your site may include a field

for page summaries or excerpts. These are often used in
page aggregations, such as on-site search results or on a
news feed, as the small blurb of content under the title.
• Meta Descriptions: Meta descriptions are most often used
in Google search engine results, and allow you to be more
purposeful with how your page is encountered when it’s
 pulled out of its environment.
• Open Graph: many sites are equipped with unique fields
for Open Graph titles, images, and summaries, which
allow you to specifically target titles and summaries for
use on social media.

Filling in each of these fields for a single page can seem like
a pain for your site editors, and we get that. At Blend, we
often program a series of fallbacks, so that editors can get as
detailed as you like, with the benefit of pre-selected text
when it’s less important.

For example, we will build unique fields for page summary,

meta description, and Open Graph description. But if you
don’t fill out an Open Graph description, that’s okay – we’ll
just use the meta description, which is often very similar. If
you don’t fill out either, we’ll fall back to your on-site page
summary. This way you are populating all of those different
fields even if you only have the time or capacity to handle
the bare minimum.

Search Engine Optimization

Writing for search engines is a process that feels like running
in place. Because search engines change their algorithms
constantly, the details of how to write for search engines can
be tricky to pin down. There are, in essence, two angles to
consider when writing for search engines. One is helping
people find what they’re looking for. In this way, writing for
search engines is an act of wayfinding that helps users find
your content based on the terms they understand. For
example, clearly labeling pages, providing helpful
descriptions, and providing one-thought-per-paragraph
headings will break content up to be findable.
The other is promoting the content you want them to find. In
this way, writing for search engines is a kind of marketing,
where you’re pushing content toward the words they use in
order to gain visibility.

Both are valuable – you need people to find your stuff, and
you also want to promote your stuff – and both take a
different mindset, just as writing for a user’s manual and
writing for a digital marketing campaign take a different
mindset.

Chris Corak and Rebekah Baggs, partners at Onward and

experts in user-centered SEO, offer a quick list of what’s
important in writing for SEO:

• Find themes within your industry — for example, if a

term like “implementation” is often found when people
search “content management,” make sure you’re using
that common language on your site.
• Use analytics to understand top performing and under-
performing pages, and develop a plan to rewrite them
according to your research.
• Make sure navigation and organization terms match the
words people are searching for.
• Align structured content (like your meta descriptions and
titles) to highlight both your key messaging and important
industry keywords.

This is different from writing for search ads or digital marketing, neither of which we cover
fully in this book.

— Corey Vilhauer
In large part, if you are honest and truthful in how you
position your headings (highlighting the most important
content) and structure your page for accessibility (using
simple, clear, and accurate link descriptions and headings),
you’re also being honest and truthful for search engines.
After all, both are technical systems that look for context to
help a person understand what’s on a specific page.

Writing for Accessibility

On the web, accessibility is the practice of removing barriers
for people with disabilities. Much like new building
construction must provide accessible entrances, and
businesses must provide reasonable accommodations to
employees with disabilities, websites must be created in a
way that allow access to information despite any existing or
future disability.

Writing for accessibility – much like writing for search

engine optimization – boils down to writing clear, scannable,
well-structured content. If you’ve done the work for one,
you’ve done most of the work for the other. For example,
the W3C’s Web Accessibility Initiative includes the following
tips for writing for accessibility:

• Provide informative, unique page titles.

• Use headings to convey meaning and structure.
• Write link text in a way that clearly describes the
destination.
• Write meaningful text alternatives for images.
• Create transcripts and captions for multimedia.
• Provide clear instructions.
• Keep content clear and concise.

Simply put, writing for accessibility is just writing for

understanding and clarity, with a little bit of structured content
thrown in to help assistive devices. Let’s quickly focus on the
two we haven’t covered yet: alternative text and multimedia
transcripts.

Alternative Text
We’re talking largely about writing content in the body field
in this chapter, but we don’t want to discount one of the
most important parts of web accessibility: alternative text.

The rule is that every non-text element requires a text

alternative so that it can be read (or understood) using
assistive services. Your images are essentially invisible to
those who cannot see them, and so alternative text (or alt
text) helps explain what the image communicates. The basic
rule is to convey the same level of information that someone
who can see the image might get.

Accessible Media
Videos are just “moving pictures,” which means they require
the same level of care as our images. But while images need
alternative text, videos (and podcasts or other audible media)
need captions or transcripts.

Captions and transcripts aren’t the sole concern of those

with permanent or temporary disabilities. Everyone wants
captions and transcripts; they are useful for when you might
have your computer’s sound down, or because you’re on a
bus, or because the text itself is easier to search and index.
The main point is that not everyone consumes information
in the same way.

To be compliant, you can do one of the following:

• Captions: Useful when the video is meant to be viewed in

real time with the text – a live event, or something in
which the video is closely tied to the audio. With captions,
you are tying your text directly to the video itself. This
means, in addition to the words, you have to consider
timestamping and matching that text to the correct spot in
the video.
• Transcripts: With this, the video is no longer the focus:
the text is. While this won’t work for live events, or for
sound that is closely tied to visuals (such as managing
comedic timing), for everything else it provides an easily
searchable and scalable alternative to the video itself.

Writing for Unique Situations

Writing, as simple as we try to make it, is a very
complicated topic to tackle in just a few thousand words.
Through your project, you’ll run into dozens of
specialized situations in which you’ll be asked to write in
a very specific way. These include:
• Writing for social media: Not only are you
constrained by space, you’re also competing for
attention in a completely different format. What’s
more, writing for social media is rarely a one-size-fits-
all process – you’re writing for each audience and, if
you’re doing it correctly, writing in a way that doesn’t
repeat itself for those who follow you on multiple
channels.
 • Writing error messages: If you’re researching the
worst parts of your web experience, there’s a good
chance it includes an error message. Writing these in a
way that’s friendly and helpful without being
patronizing is a challenge itself, but you also have to
worry about the context of the message.
• Writing for forms: The longer the form, the more
complicated your writing can get. Form labels have to
be clear on their own, but they also need to fit in with
the larger form. They need to be marked in a way that
provides guidance, while not overwhelming the user
with too many options.
• Writing for translations/translating: Writing in a way
that’s both friendly to automatic translators is
important, which we discussed previously in the plain
language section. Also important is knowing the
process for having real language-specific content
written – it’s not enough to run some content through
Google Translate to get a Spanish version; in reality, a
human translator with awareness of human context is
required.

We don’t show this list to provide answers. Instead, we’re

helping remind you that your content is more than just
an article written in normal paragraphs – it’s also
directions, help copy, form fields, error messages, and
other forms of microcopy.

From Words to Design

We’ve talked a lot about content over the past several
chapters, and we’ve built a solid foundation based on user
goals and expectations. We’ve set a path for action: we’re
providing a system by which we can communicate to
business goals. We’re really doing some great content things!

That’s all it is, though. Content things. It’s words and images.
We have yet to discuss the main visual aspect of the site. We
have yet to discuss how content is displayed, how we
illustrate the brand beyond text, and how that content
responds to different browser widths.

We have a bunch of text files. But we do not yet have any

design. And we’ll talk about that in the next chapter.

Inputs and Outputs

Inputs for writing content depend on your organization’s
brand standards and guidelines, but at minimum you should
have some kind of strategic plan for what you’re going for. You
need a site map (so you know what you’re writing and what
needs to be created from scratch) and you need a content
strategy (so you know the reasons why you’re writing new
content).

The output? Brand. New. Site. Content!

The Big Picture

In the perfect project, writing is organized and created
throughout the scope of the project, from development of
the site map through to launch. In reality, writing often is
the bottleneck at the end of a project: not enough time was
allocated to making sure all of the new content was created.
While we know no project will be perfect, you should aim to
be a part of that first group: plan and start writing as early as
you are comfortable.
Staffing
You probably need writers. You almost always need writers.
If you’re lucky, you already have writers – it’s just that they
often do not consider writing as their sole responsibility,
despite always seeming to be on hand when you need some
content written. As you get closer to launch, however, you
may need to hire someone who can either specialize in
writing to your brand, or someone who can simply crank out
a ton of content while your organization continues with its
day-to-day responsibilities.

73 Says the authors who wrote 5,000+ words on organizing content.

74 Currently, for example, Google truncates snippets to about 155–160 characters, so providing a
meta description under that limit will better ensure that you’re protected from that truncation.
CHAPTER 13

Develop the Graphic and Interface

Design
SUMMARY
With knowledge of the content and how it’s organized, along
with your organization’s marketing assets, you can visually
plan the site from wireframes to fully rendered design.

DOES THIS APPLY?

In a full-stack project, this applies – in fact, it’s often the very
reason a web change is happening in the first place. But it
also applies to nearly every kind of partial-stack project –
essentially, anywhere layout creation or changes, mobile
adaptation, or brand alignment needs to take place.

Planning a website involves a lot of meetings. Meetings to

gain alignment on requirements and meetings to clarify
audiences. Interviews with stakeholders and workshops
involving sticky notes. Working sessions to shore up existing
content and brainstorming sessions to work through the site
map.

These meetings are important, because these meetings

define our project – they save time later on by helping us
understand the scope and purpose and audiences, and they
help us gain traction and buy-in within our organizations.
But they all seem to have one thing in common: there’s
always one person who seems to ask, either out loud or in
their head …

“So, like … when do we actually get to see this thing?”

Everyone wants to get to the design phase. Everyone wants

to see a thing. That’s when the site feels real.

What is Design?
Design covers a lot of ground. It’s a sketch that shows
something to be executed. It’s an underlying scheme that
governs function. It’s the arrangement of details in a product
or work of art. It’s the creative process of executing aesthetic
or functional designs.

Design is all of these things (and more), but designer Mike

Montiero defines design as “how we communicate what an
object does, or its function, through its shape or form.”75
Which means, in reality, everything we’ve written about
over the last dozen chapters – from stakeholder alignment
to information architecture to content layout – is in some
way design. It’s more than just a layer of paint on a fading
house; from location to architecture to interior to, yes, even
the paint, it’s the entire process of homebuilding.
In this chapter, we focus on how design takes what we’ve
learned – from expectations to content model – and
translates it into a communication of function, both in
traditional graphic design and web-focused user interface
design. It’s time to talk about what your website will look like,
how interactions are organized and laid out for various
viewpoints, and how your site communicates your
organization’s brand attributes.

Some Design Definitions

Of course, it’s not that easy – not in this world, where the
practice of design has been segmented into smaller pockets
of expertise. Within the world of web design is a scattering
of sub-disciplines.

It might feel like rocket science, but really all of these

disciplines help define the larger scope of what “design” is:

• Graphic (or Visual, or Communication) Design: This is

what many of us think of when we first think of design –
the pictures, colors, and typography of a website. If you
think of design as creating a logo or a full-page ad, that’s
communication design.
• User Experience, or UX, Design: User experience design
focuses on how a user interprets and navigates your site,
and takes into account many of the principles outlined in
the content and organization chapters. It dictates how a
site works when you perform certain actions. It’s also
sometimes called interactive design.
• User Interface, or UI, Design: The actual design of the
interfaces you come in contact with. Taking elements of
both user experience and graphic design, UI design is
particularly focused on things like form layout, buttons,
 and other interaction methods.
• Information Design: Closely tied to both content
modeling and data visualization, this is a special subset of
design that’s focused on presenting information in the
most readable way.
• Front-end Design: The translation of graphic design into
workable code. This is more than just a pixel-by-pixel
representation; front-end design interprets the design to
work at different screen widths, and makes sure graphic
elements are visible to (and usable by) assistive
technologies.

Elements and Principles of Web

Design
While that list of sub-disciplines might make web design feel
like a fractured landscape, it’s meant to show how the
framing mechanism around web design – despite appearing
along the same branch as material or traditional graphic
design – requires an entirely new way of thinking. In fact,
one of the biggest struggles of early web design was
educating those new to the process that web design doesn’t
simply follow the same rules.

To be clear, it still follows the same principles. Good design

is always concerned with harmony, balance, and hierarchy,
and web design is no different. However, there are two
factors that, in part, differentiate web and tech design:

• We’re adding a layer of technology atop what had

traditionally been a physical media (communication
design).
• We’re removing many elements of control from the final
 product, including canvas width and content.

I bristle on behalf of all designers when the web design process is brushed off as “pretty-ing
up the website” or “making something look good.” It’s a frustrating shortcut, and it’s
potentially harmful in that it immediately undercuts the seriousness and importance of the
design process.

— Corey Vilhauer

Design for the web is less about a single thing, and more
about a set of patterns – a system by which layout and
content are presented. In fact, if we think about how design
manifests on a webpage – laid out by HTML, styled through
CSS, and populated with content from a database or content
management system76 – we better understand how design is
really not about a single page or feature. It’s about a complex
system of elements and patterns coming together based on a
set of programming rules.

And if that sounds like it detracts from art and inspiration,

then you could say the same about a well-designed teapot, or
a memorable brand logo. If design doesn’t work, was it really
well-designed in the first place?

Designing for User Experience

To follow this idea that design is not merely an aesthetic
adornment, let’s focus first on the idea of user experience – of
designing the journey upon which brand standards and
typography will interact. In most cases the act of designing
layout and interfaces – including interactions, content and
element hierarchy, and the very patterns by which the site
will be built – begins early, before the more traditional
graphic design process. There is a natural progression from
the vague feature requests we saw in earlier chapters toward
the more structured templates that started to take shape
when we talked about content modeling.

While we often view our sites as a set of pages, in reality our

site is a series of interaction points. Designing the user
experience is about designing the pathways through these
points, including:

• Point of attention: what elements do we create and

prioritize to get the attention of the site user?
• Point of interaction: what elements signify interaction
and how do we show success or failure?
• Wayfinding: what elements help guide us to other areas
beyond our initial goals, or what elements help us confirm
we’re in the right place?

User experience design does not require a deep

understanding of brand attributes, so it’s most often
communicated through content hierarchy and layout, using
something like a wireframe or prototype.

Wireframes
Akin to an architectural blueprint, wireframes are
representations of layout and function. They’re often
greyscale, devoid of images, and very rough … and that’s
exactly what they’re supposed to be – their low-fidelity
nature makes them effective tools for communicating
functionality, allowing for important interaction decisions
without the distraction of brand colors or fonts.

The actual deliverable of a wireframe will vary based on

your project. Napkin sketches might qualify as wireframes.
Organized walls of Post-it notes might qualify, too. While
the name itself is a call back to the kind of spartan sketched
design that preceded 3D modeling, today’s wireframes come
in a lot of shapes and flavors, depending on your project
needs, from low-fidelity sketching to high-fidelity design
files.

Figure 13.1: Three stages of progressive wireframe design: an initial whiteboard sketch, a high-fidelity
grayscale wireframe, and a final design mockup.

Wireframes help validate and confirm layout before going

too far toward visual design and branding. But what if you
want to have someone actually test those wireframes?

Well, then we’ve just crossed the line into prototyping.

Prototyping and Wireframe Testing

Your wireframes mean nothing if the interaction points do
not resonate with site users. Enter the world of interactive
prototyping, where you get to take those spartan designs and
turn them into … clickable spartan designs.

Prototyping tests your design against the habits of your

users. While we often feel a level of accomplishment when
flat designs and site map spreadsheets are approved by a
leadership team, in reality they need to be vetted. You need
real people to find (or sometimes miss!) the “sign up” button,
and you need someone to say out loud that they “don’t
understand what About means in the navigation.”

Prototyping and testing has many different forms,

depending on what you want to actually test. Often, this
plays into the research and user testing we discussed in the
discovery sections of this book, and just as the fidelity of
wireframes falls on a spectrum from napkin sketches to
nearly complete design, the complexity of prototypes can
range anywhere from rough paper sketches to fully
interactive websites.

• Paper Prototyping: Simply print out some sketches and

ask people to reflect on the layout and interaction points.
• Wireframe Prototypes: For this, you’ll take those
wireframes and connect them using a program like Adobe
XD, Figma, Invision or Sketch, allowing users to click
through interaction points.
• Developed Prototypes: Now you’ve developed a base
level site that approximates either the basic HTML layout
of the site or a close-to-complete design. This is most
often used for higher-profile projects that can
progressively develop toward full launch.
 “The Point of Visibility”
Your project – the templates and navigation and
headlines and all of the rest – are now shaping into
something that resembles an actual website. It’s at this
point that the number of people who are interested in
giving their opinion will double, if not quadruple.

We like to call this the “Land of Oz Effect.”

Just as in the 1939 movie The Wizard of Oz, everything

seems to change once you’ve thrown a layer of color
onto the screen. Despite all of the work that you’ve done
in presenting your research, in gathering opinions from
stakeholders, and even in creating wireframes and
prototypes, there’s a switch that’s flipped once you’ve
made choices on color and typography. The website now
looks real and people who had been otherwise
disengaged are suddenly very interested in giving you
their opinions.

You can curb some of this by having key stakeholders in

the process from the beginning, but even with those
precautions there’s always a bit of “swoop and poop.” It’s
just what happens. Stay strong, document your previous
decisions, and pray that it ends quickly.

Visual Design
When people think of “design,” they most often think of
graphic design: of how something looks; of colors and
typefaces.
In reality, some of this is true. Web design does take these
things into account: there is a direct line from what might be
called “traditional print design” and the elements we see in
modern web design.

The difference is how it’s applied: graphic design on the web

is tied to elements and building blocks, rather than the
finished art of print. We have limited control of the canvas
in this sense, so we’re not building for the perfect approach.

Instead, we create dozens of design elements which are then

grouped according to their need. Within all of this is the
concept of a design system, which is based on three major
touchpoints:

• Brand Identity: The assets that make up the overall

design, including logos, graphics, photography,
typography, colors, and even animation guidelines.
• Design Language: The general atmosphere and
guidelines that govern your design.
• Pattern Library: The individual elements that make up
the larger templates, and their points of interaction.

Brand Identity and Design Language

Just as voice (the way a brand sounds) and tone (how voice
translates in specific situations) are two similar but separate
concepts within web content, brand identity and design
language are two intertwined concepts within graphic
design.

Brand identity focuses on the visual elements that separate

your organization from others. These may already be in
place when you begin designing your site, but you should
not take these assets whole cloth: because the web is an
always-adjusting landscape, your branding will adapt for
different situations.

Design language, on the other hand, focuses on defining the

overall atmosphere of the design, and in fact a design
language is often a byproduct of the more rigorous work of
creating patterns and brand assets.

Because design language is sometimes vague – just as the

voice of your content can be vague – we have to come up
with unique ways to document it. Upon launch, design
language is documented as a style guide of situational design
scenarios – “If you are creating a bio page, make sure the
image is properly lit and aligned to the right” – but during
the design phase it may be developed using a mood board or
style tile.

• Mood Board: A mood board provides a collage of

inspiration, both from the web and from the real world.
As Sam Otis, Blend’s lead UI developer (and designer of
this site) says, “It’s like a wireframe for the visual design.”
It focuses discussion on the visual elements separate from
the content or page hierarchy, and as such is more loose
and open to interpretation. You can imagine it like a
Pinterest board for your website.
• Style Tile: A style tile provides the basics of the brand
identity, but in the same single page style of a mood
board. Style tiles tend to be more concrete and higher
fidelity than a mood board, including actual fonts, colors,
and graphic assets that the full design will use. We often
use a style tile as a design checkpoint to confirm design
standards before we begin work on actual content
templates. You can imagine it as a first pass at a site brand
standard.
Figure 13.2: On the left, an example of a mood board originally published as a part of Marissa
Epstein’s post on Why Web Designers Should Moodboard on the right, an example of a style tile
originally published on Style Tiles.

These are not separate practices, and in fact they always

influence each other. Your brand identity doesn’t just dictate
the color – it helps inform how colors are used within the
overall design language, as well as how it is used within a
unique element of the pattern library. Those unique patterns
are governed by the voice of your content, and they are
shaped by the design language you’ve chosen. They include:

• Brand Alignment: The various ways in which the design

will pair with and accent existing brand materials and
collateral.
• Visual Hierarchy: The way different elements are given
priority – both in visual style and via layout – across the
site.

• Typography: The typefaces and font styles77 you use to

represent content on your site is one of the largest drivers
of readability, which should come as no surprise.
However, understanding fonts – just as with anything in a
mobile world – also means understanding how to adapt
fonts for different screen widths, zoom levels, and even
perceived reading distance.
• Color and Contrast: Page contrast is important for those
with low vision, but it’s also crucial for anyone who spends
time reading on a screen. Our eyes can experience fatigue
like any other muscle in our body, so providing a low-
stress, low-strain combination of colors is beneficial to
users.

Pattern Libraries
This all ties directly into the underlying practice of graphic
web design: the idea that elements rule over static complete
design.

For example: with a brochure, you create one of everything.

One title. One block of content. One background. One size.
If you need another size, or if you need to adapt collateral
for a different medium, you create it all again. You copy the
original file, and you resize everything. All of the elements
might be similar, but they’re not the same exact file.

On the web, things are a little different. There was a time

that every individual page required its own lines of code, an
insufferable practice that made design on the web nearly
impossible. And then: Cascading Style Sheets, which changed a
website from a giant pile of individual text files into a series
of coded patterns. Now, instead of recreating a promo block
on your home page every time the page width changes, your
site is smart enough to provide a reusable pattern.

What this means is that visual design is no longer tied to

individual pages, and instead to a library of patterns that,
ultimately, make up the entire scope of what you see on a
site.

In Brad Frost’s book Atomic Design, he calls this modularity. In

discussing the movement from “page” to “element,” Frost
writes:

What is an interface made of? What are our Lego bricks? What
are our Subway sandwich pieces that we combine into millions of
delicious combinations?

Pattern libraries identify those Lego bricks and Subway

sandwich pieces. They go deeper than the template – and
even deeper than individual components or blocks – into
the individual elements that you’ll use. Rather than
recreating a button style for each component, you’re going
to create one set of buttons that are used everywhere,
promoting consistency, lowering the amount of code that
needs to be written, and making everyone’s life a lot easier.

Managing Images
Because text can reshape to fit a new width or height –
because the things we write are made up of small elements,
and a sentence can effortlessly flow into a new container
rather easily – we can develop a site design with the
confidence that it will still be readable no matter the width
or layout. This is not necessarily the case for images.

Template and site design must account for what an image

will do when it’s forced into smaller widths, or what will
happen if the image cannot load correctly. Sometimes this
means finding a new place for it to live in order to retain its
dimensions. Sometimes this means swapping out the image
with a mobile-friendly version to improve page speed or
presentation.

We often think things just look better if the images look great.
But a site that’s overdependent on images can lead to a lot of
trouble. We won’t tackle the entire scope of image
maintenance and design here, but here are some points to
remember.

• Images are large and slow: Large images and groupings of

images – especially stacks of images in a home page
carousel – seriously drag down page performance. While
there are ways to adjust the weight of images and their
effect on page load, a good rule of thumb is the more
images you throw into your design, the more your page
speed is at risk.
• Images are not accessible on their own: Screen readers
cannot read images within your content in a reliable way,
which is why we assign alternative text to them. When
designing with images, imagine every image as a blank
spot: what text can you provide that helps the user
understand the purpose of those images?
• Images should be separate from text: Following that
note, remember that if your image cannot be seen,
neither can any of the embedded text within that image.
Rather than embedding text, structure content so that the
text is a separate field overlaid on the image.

We’re finally getting to a place where carousels are no longer de rigueur, which is exciting
because carousels represent the worst kind of “design-by-committee” thinking. If you’re still
wondering whether you should use a carousel, check out ShouldIUseACarousel.com. (Hint:
the answer is almost always no.)

— Corey Vilhauer

Designing for Mobile … and Beyond

While there are a lot of things we can control on our site –
the content, the images, the design, the functionality –
there’s one crucial thing that we cannot control: the
container in which site visitors view our content, images,
design, and functionality. While this often focuses on
designing for mobile, we’re really talking about designing
for any and every screen size, which means we need to rethink
how we approach our content in the first place. We have to
be responsive.

This also means that you typically can’t control things that drive traditional designers
absolutely bonkers, like line breaks or orphans, because those line breaks and orphans are
different for every person.

— Corey Vilhauer

Design on a Fluid Grid

In order to design in a site that can standardize along
different mobile widths, we have to introduce some level of
standardization within the content and templates
themselves. This can be done by imagining the site as a
series of columns and designing within those restraints, a
concept defined as a “fluid grid.”

What this provides is guidance toward the allotment of space

each element gets as it moves through different widths, and
makes spacing between elements both consistent and
standard. Proportions stay the same because elements are
not based on pixel widths or any other static measurement,
but instead are based on percentages.
Figure 13.3: An example of a fluid grid, originally posted in Ethan Marcotte’s article “Fluid Grids” for
A List Apart.

Designing to Break Points

While the basics of responsive design dictate a constant,
subtle adjustment of layout based on the width of the screen,
there are points at which the components simply no longer
work in the same arrangement, necessitating a full re-
configuration. These are called breakpoints, and they’re
fueled by something in the CSS called a “media query,”
which defines certain pixel widths as points where the page
layout needs to change.

You’ve maybe seen this if you take your browser window

and slowly change the width – you’ll see a slow change in
content as it retains the same column ratios, and then
BOOM! you’ll see actual page elements move and readjust.
That’s a breakpoint.

Mobile-first Design
There’s a tendency to imagine a website as a full-width
medium – that the desktop view is the optimal state, and
all other widths and layouts branch from this. This is
because for many of us, desktop view is how we learned
the web.

But, not unlike the trash compactor on the Death Star, a

site built for full-width breakpoints can run into issues
when the walls start to close in. Functionality and user
interface elements designed for a full-screen experience
are smushed and crushed, often to the detriment of the
original functionality.

Enter the idea of mobile-first design, which promises to

maintain the integrity of the always changing content
layout by thinking about its smallest width first. In this,
you literally start with the mobile view of your site and
work toward a hyper-effective mobile design, adding (or
progressively enhancing) as you move to wider widths.

Of course, mobile-first design isn’t a strict definition as

much as it’s a philosophical practice: it’s a mindset that
tends to result in a more focused and usable design –
both on mobile and larger screens.

When we wireframe, we often begin designs at the

traditional mobile width (the width of a smaller mobile
device in portrait mode) and at full width (the smallest
usable width for a full-screen laptop).

And on to Integrations
A website is more than just your content and your design; it’s
also a collection of external elements. Things you need to
better track information (like Google Analytics) or things
you need to assist with collecting money (like Square) or
even things that tie to information held outside of your site
(like curriculum records through a tool like Banner).

And while you can sometimes adapt the design and control
the content, you also have to make allowances for how those
integrations interact with both existing content and your
users.

What happens when you invite someone else’s code into

your website? We’ll talk about that in the next chapter.

Inputs and Outputs

The main input of the design stage is a good understanding
of user behaviors and expectation – knowing how someone
will navigate their way through interaction points. Other
inputs include more traditional graphic elements like
existing design standards, as well as content and template
focused documentation like content model needs.

There are different outputs depending on the project. You

may choose to provide wireframes, or you may go all the
way to prototypes. Some may simply go directly to visual
design – and this visual design might actually be delivered as
front-end code, which we will talk about in a future chapter.
The Big Picture
Design rarely happens on its own. To provide responsible
design, you need to know the content it will serve and the
templates it requires. You need to have worked together
with any larger branding initiatives. Additionally, while
design might be a separate phase in between “content” and
“development,” more likely visual and responsive design is
handled in concert with both.

Staffing
You need a designer who understands the web – templating,
pattern libraries, and accessibility. Beyond that, the designer
might take on other aspects of the design: they may also be a
front-end developer, or they might take on some of the
more strategic tasks of wireframing and user interface
design.

75 From You’re My Favorite Client, a great book that helps non-designers understand – and
actively participate in – the world of web design.
76 We’re going to start talking about code a lot as the book continues, so be prepared. In the
meantime, in ridiculously simplified terms, HTML (Hypertext Markdown Language) is the code that
defines the structure of the page, while CSS (Cascading Style Sheets) is the code that determines
layout, color, typography, and more.
77 A typeface is the style of type, and it represents the entire family of potential combinations.
Times New Roman is a typeface. A font is the size and weight of a typeface. Times New Roman in
bold at 12 pt is a font. Also, this probably doesn’t matter except to the most esoteric. Of which,
unfortunately, we sometimes tend to be.
 SECTION 4
SYSTEM REQUIREMENTS

There are a lot of tools and gadgets in the world,

and your web project is no different. The
question is: which tools and gadgets do you need
to focus on? Will your site serve as a conduit for
some external database? Do your developers
require a specific development language? What
editorial features are required — and which ones
are nice to have? Before you can start coding,
you’ve got to know what you’re working with.
CHAPTER 14

Know Your Integrations

SUMMARY
A website will often need to communicate with some
external system. These situations can be fraught with peril.
The key is to know what they are early, and to plan for the
unknown.

DOES THIS APPLY?

If all of the content and functionality for your site will be
delivered from inside the walls of your CMS, then you don’t
need to worry about integrating with anything. And this can
be true of smaller, content-based sites. However, as your site
grows, you’ll likely run into an integration need, sooner or
later.

If there’s one thing that is universally reviled in all of

academia, it’s the group project.
Usually, throughout your time in school, you’re at your
limits, just barely managing to get your own stuff done. But
then, inevitably, your professor assigns a project to be done
with a partner, or – even worse – in teams of three or four.
Your heart sinks. Why? Because:

• We have to coordinate with other people, which leads to

communication issues.
• We’re limited by the worst-performing member. Our
grade is affected by anyone who doesn’t step up.
• The final product runs the risk of being a mish-mash of
styles, instead of an integrated whole.

In working as a group, we’re now at the mercy of group

dynamics, and we start to lose control of things. This is not
something we’re keen to concede, unless we’re the weak link
ourselves.

But if you think you hated group projects in school, just wait
until you deal with them in a development project. Just wait
until you have to invite a third party into your code via
integration.

And it’s not just school. If you want pure entertainment, watch the early rounds of American
Idol when they get to “Group Night.”

So. Much. Drama.

It’s an individual singing competition, so I maintain there’s no purpose to group auditions,

except for the delicious voyeurism of watching performers slowly self-destruct over the
course of an all-nighter.

— Deane Barker
What Is an Integration?
An “integration” is when two systems – meaning, two
different pieces of software – have to talk to each other in
some way. The two systems have to be … wait for it …
integrated.

When building a website, one of those systems will be your

content management system (CMS). The other system could
be anything.

This is done because some content or functionality is not

provided from your CMS. Often, content in your CMS
needs to be augmented with content from some other
source, or some functionality is provided by some other
system and you’d like to make it appear as though that other
system works as an integrated (ahem) part of your website.
Examples of this include a university course management
system, in which course information is pulled from a central
source, or “single sign-on,” in which users’ login credentials
are connected to a centralized authentication system.

This is not a technical issue that can be ignored until you’ve introduced the development
team into the project. Most often, integrations are content issues, in that they relate to pulling
– and then mingling – information from one source into your site, which means you get all of
the benefits of some other system doing the content work with all of the risk of some other
system doing the content work.

— Corey Vilhauer

In each of these cases, you’re gluing together two systems to

provide a consolidated experience. You’re reaching beyond
the CMS and communicating with an external system, which
requires making sense of how the CMS responds and
incorporates that response into the flow of your website.

This is where the fun starts.

The Challenges of Integration

Much like your group project at school, integrations can be
fraught with peril. Many organizations have problems
keeping one system running, and now we’re asking it to keep
more than one system in good working order, and keep
those systems talking to each other.

There are two types of risk:

• Development risk: Risk incurred during the development

and launch of the project. There is a risk of the two
systems being incompatible, or of the work to connect
them together taking too long and consuming too many
resources. This risk, thankfully, is one-time.
• Runtime risk: The ongoing risk of keeping the two
systems working together over the long term. Both need
to stay running, communicating without unreasonable
delay. This risk is often independent of development risk:
you can get the systems working together, only to have
the partnership break down in production when they lose
connection with each other. If you’re really unlucky, this
might happen randomly, multiple times a week.

Thankfully, some integrations are so common as to be

productized. You’re not the first organization to attempt to
link, say, a shopping interface with order processing
software like Square, so the communication between them is
known and already developed. In fact, several products are
specifically designed to be connected, like a digital asset
management (DAM) system, for example.
However, in other cases, the integration you need might be
the only time anyone has ever tried to glue together those
two systems, either because the system you want to integrate
is relatively rare, or it’s a one-off custom system that your
organization built internally.

For example, a university might have a system that shows

the status of washing machines and dryers in the laundry
area of a residence hall. The university might want to display
this information on the page for each residence hall so
students know when there are free machines available.

This integration is likely quite rare. It’s not likely to be

productized for even one CMS, much less multiple.

Not to overdo the group project metaphor, but if you have

to do a group project, clearly you want to do it with people
you know. If you already have established friendships and
communication patterns, it makes things easier. The person
you have to work with is already in the contacts in your
phone, you know their schedule, you know how they relate
to other people, and you may have known them long
enough that your relationship has already had its ups and
down, so you’ve fought, talked it out, and made up multiple
times.

Other times, you’ve never met this person. In these cases,

you cross your fingers and hope for the best.

Real Time vs. Scheduled

Let’s talk quickly about the nature of content, and how it’s
treated by a technical system like a CMS. A large percentage
of integrations are intended to combine content from two
sources – usually your CMS and some external system.
When doing this, a key question is how close to real-
time/instant does this connection have to be?

Content is naturally categorized using the term WORM –

Write Once, Read Many. We might publish an article one
time, and it is read 10,000 times. Once published, the
content doesn’t change. Since it hasn’t changed, there’s
ultimately no reason to retrieve it again.

But our content isn’t always this static. We often change

content – data is updated, course schedules change, or
product prices change. So when we talk about keeping
content synced between integrations, we’re juggling three
factors of timing:

• Communication: can the systems speak to each other?

• Velocity: how fast does the content change?
• Latency: how quickly do we need to make those changes?

The question becomes whether you require real-time

changes or whether you can settle for less frequent
scheduled changes. Either one works, but know that all
things come with a cost. A good rule of thumb: the more
volatile the external content is, the more it will cost to
integrate, in terms of schedule, budget, and risk.

How often do the external content change? And how quickly

do you need those changes reflected in your content
exposed to the public?

Let’s return to our university example from above. Say we

have a page for each faculty member. That page has some
very subjective, marketing-ish copy like their biography and
credentials. This is maintained by the marketing staff,
directly inside the CMS.

However, also displayed on that page is more fundamental

information like the professor’s email, phone number, and
name. This information does not need to be maintained in
the CMS, because it’s stored elsewhere. Duplicating the
phone number in the CMS would mean maintaining this
information in yet another place (the “double entry”
problem).

This is a classic case for an integration. Ideally, the

professor’s page on the website would be a hybrid of content
coming from both the CMS and the internal course
management system.

To connect these two systems, let’s consider a combination

of technical and logical questions. For any integration, you’ll
go through a similar exercise:

1. Can the CMS and the course management system

communicate with each other?
2. How fast and stable is this line of communication?
3. How often does the information in the course
management system change?
4. How quickly do we need those changes reflected on the
website?
5. What is the risk of this content becoming outdated?
Figure 14.1: The delivery of a faculty page to the requesting visitor is an internal mixing of content
from the CMS repository and an external system.

For the purposes of this example, let’s assume that yes, the
web server and course management system are located on
the same network and can communicate with each other.
But, for fun, let’s say this connection is unstable. The course
management system is on an old server, and gets overloaded
from time to time when students are registering for classes.
The server admin has said – quite gruffly, unfortunately –
that you new-fangled kids cannot have on-demand access to
this server.

Okay, that’s questions #1 and #2 answered.

For question #3, let’s consider how often this information
changes. Professors are normally hired during the summer –
not a lot of faculty starts at other times of the year. Also,
once a faculty member starts at the university, their phone
numbers and email addresses rarely change. The courses
they teach do change, but maybe once a year, at most. It has
a low velocity.

Highly related is question #4. What are our requirements for

immediacy? If a professor did change their email address,
how quickly do we need that change reflected on the
website? Right away? In a perfect world, sure. But in the real
world, a 24-hour delay isn’t going to kill anyone. We can
tolerate high latency in our content changes.

Finally, question #5: what is the risk of incorrect content? Of

course, we want our content to be up-to-date all the time,
but at the end of the day, is anyone going to die if an email
address is temporarily wrong? Probably not. There are likely
multiple other ways to contact this professor, and the sender
would get a returned email to notify them that their email
wasn’t received and they should use other means. Clearly,
our risk is low.

In this case, we could likely use an “import and update”

pattern. We can configure our CMS to import content from
the course management system, then keep it updated on a
schedule. Once every twenty-four hours, let’s say, in the wee
hours of the morning when load is low, a scheduled job
would check for new or changed information and update the
content in the CMS.

If a professor changed their email address sometime in the

afternoon on a Tuesday, it would be wrong for the rest of
that day, but correct itself overnight.
 Are you horrified by our tolerance of incorrect content?
If so, then welcome to the never-ending debate of
perfection vs. practicality.

In a perfect world, everything would be up-to-date all

the time. And this can absolutely happen. But nothing is
free, and in enabling this, you might suffer in other
ways. Real-time connections can be unstable, expensive
to set up, and prone to error.

Sometimes, it’s just better to be practical and tolerate less

than perfection in exchange for other benefits.
Everything is a trade-off.

Our university example might seem contrived, but this set

of circumstances is fairly common. External content sources
often move slowly, and the content is low-risk.

However, there are exceptions.

Consider if you provide stock quotes on your website.

• This information is highly volatile – it has a high velocity.
• We need to see changes immediately – we require low
latency.
• People will be making financial decisions based on this
information – it has high risk.78

In this case, you can’t do an import and update. Doing that

even once per minute would likely be more latency and
therefore more risk than people are willing to tolerate. This
type of content simply demands a real-time connection
between systems.
Determining if Integration Is
Necessary
With all of this talk of latency and risk, let’s ask an important
question: are we even sure that integration is even the right
choice? Because there are times when it’s not.

In our university example, an integration is probably the

right way to go. The content we want – phone numbers,
emails, etc. – is locked away in our course management
system without a public viewing option, so we have to get
that content into our CMS where we can display it.

However, consider the stock quote example. If we want to

display stock quotes on our website, we open up a Pandora’s
Box of issues. An argument could be made that it’s more
trouble than it’s worth.

Removing a Link in the Chain

One option would be to not display stock quotes, of course.
We could decide there are too many issues and just throw in
the towel on the idea entirely. In this case, we could simply
link users to another site to get the quote.

However, another option would be to remove a link in the

chain by moving the integration to the client, rather than the
server.

What we mean here is moving integration from the website

— the situation we’ve largely focused on up until this point,
in which a user asks for data from the site and the site then
turns around and grabs that data from another service —
and taking a link out of that chain by patching the other
service directly to the user. We can do this a couple of ways:
• An inline frame (an IFRAME) could contain a window
into a source’s website that would display the stock quote.
For many services, they provide URLs specifically for this.
• Some JavaScript could execute in the user’s browser and
request content directly from the source.

Despite understanding that IFRAMES are often necessary and cost-effective, I often get
nervous when we start to peek through those windows into other content sources. Will the
IFRAME layout respond correctly to the same design breakpoints? Will the styles match the
rest of the site’s design standards?

— Corey Vilhauer

Technical details aside, both of these methods have done the

same thing: they’ve removed one link in the chain. Now the
user is bypassing our website and getting content from the
source, which is always going to be more direct and involve
less risk.

Showing the Seam

On the other hand, sometimes the system you want to
integrate with is just too feature-rich and constantly evolving
to “proxy” all its functionality into your website.

For example, there are services to which banks subscribe

that manage the process of applying for a mortgage. These
systems allow users to fill out a lengthy, multi-step
application, upload documents, authorize credit checks,
attest to facts, etc. They’re so complicated that an ecosystem
of vendors has sprung up to build these systems. Banks don’t
build them internally because they’re complex and other
people have solved the problems.
While it might seem noble and ambitious to build this into
your site, it’s not a realistic approach. Initial development
would be staggering and costly – remember, the reason this
external vendor stays in business is because they’ve built
something that’s difficult to replicate, and they evolve it over
time with new releases and features.

Sometimes, it’s better to just show the seam. If the customer

wants to apply for a mortgage, let them know you use an
external service for this, and hand them off. These services
will often let you “skin” their tools with your logo and colors,
so it has some branding connection.

Would it be perfect if this was on-brand and on-site? Sure.

But it’s often not worth the trouble.

The Costs of Integration

Given the volatile nature of integrations, they can be hard to
scope. Often, you’ll be trying to integrate one system with
another in a combination that you or your implementation
partner has never done before.

Thus, the answer to the inevitable question of “How much

will it cost?” might very well be “… we have no idea.”

Integrations can often be a whirlwind trip into the unknown.

Even if it seems straightforward, these things can turn on the
smallest of issues – some minor thing pops up that makes
attaining the goal impossible, due to a quirk of how that
factor intersects with your particular requirements.

If you’re using an internal development group, this can mess

with your timeline. If you’re using an external development
partner, both your timeline and your budget are at risk.
Problems with unknown integrations have run wild, soaking
up tens of thousands of dollars that were intended for
something else.

When an external partner is asked to budget for one of

these, they’ll generally do one of two things:
• Leave the budget open-ended – they might provide a
good-faith estimate, but allow for overages.
• If a firm, fixed number is demanded, they’ll pad that
number like a bad living room sofa from the 70s.

Or, in taking a long view of your problem, you may find

one, single integration that’s problematic and unknown,
while the rest are completely mainstream. In these cases,
you may consider a third option — a two-stage budget: a
fixed price on everything but the unknown integration,
which is kept open-ended.

Practical vs. Perfection

Remember, everything is a trade-off, and until a CMS is
created that does everything you could ever want to do,
we’re going to be stuck integrating with other systems. The
trick is to be wise about when to do this, and when to just
show the seam and have your users get their content or
functionality directly from other systems.

Every answer to an integration question is a combination of

budgetary, schedule, and technical factors. There’s no
blanket approach that works in all cases, so be prepared to
consider all the factors when making a decision.

Inputs and Outputs

The input to this phase is an understanding of where
everything on your website is coming from. Consider every
hope and dream you want for your website – are you going
to create all that content (or have it created)? If not, then
where is it coming from? You need to be able to answer that
question in every case, and the answers to those questions
are the output of this phase. You need to be able to articulate
those data-sharing requirements to whomever is scoping
and developing your website.

The Big Picture

This phase can sort of be lumped into scoping and budget,
but it needs to happen just before that – you need to go into
that process with understanding of where all your content is
coming from. To scope anything, a developer needs to know
the technical factors they’ll be juggling. So, the project can’t
be scoped for schedule or budget until this is complete.

Staffing
The logical component of this can be done by a content
strategist. As part of the planning process for the website,
whomever is in charge of content should naturally know
where this content is coming from, whether internally to the
CMS, or externally from somewhere else. The scoping
component of this is technical by nature, and needs to be
done by a developer responsible for figuring out the
development schedule and budget.

78 You know how they say “price quotes are delayed” on most stock tickers? They do this even
when the quotes are up-to-date, just to make sure they have a disclaimer at all times – there’s that
much risk involved.
CHAPTER 15

Determine System Requirements

SUMMARY
At this stage, you have enough information to draw up
requirements for what you need in a content management
system (CMS).

DOES THIS APPLY?

This only applies if you know you’ll be selecting a CMS. You
might already have one, or one might have already been
selected for you. If so, then this is something you don’t need
to worry about.

However, if you’re going to be using a CMS and don’t

already have one, you’ll need to concern yourself with
everything in this chapter.

Purchasing decisions are based on two things: your actual

requirements and your gut feeling. Marketers play on both
of these things.

If you’re looking for a vehicle, you might have some tangible

requirements for it:

• You have three kids, so you need a backseat.

• You live out in the country, in South Dakota, on a dirt
road, so you need four-wheel drive.
• You have two horses, and you need to pull them around
in a trailer.

Clearly, with these three requirements, we’ve taken the

entire domain of available vehicles and cut them down
drastically. You need a pickup or maybe a full-size SUV with
a minimum towing capacity.

A Note on the Next Two Chapters

Forgive us if we get a little meta. This chapter and the
next (Chapter 16: Selecting a Content Management
System) both focus on two sides of one of the most
important decisions you’ll make as a part of your web
project: determining the actual software you’ll use to
build your site. This isn’t like building a house — this is
like choosing what city and neighborhood you’re going
to live in.

If you are beginning or in the middle of this process, you

already know how daunting it is. We’re potentially
talking about a lot of money, or a lot of time switching
languages and systems. For that reason, we are summing
it up over two chapters.
 The first (this one) helps you understand the scope of
your decision. The next one helps you make a decision
on a software vendor based on that decision. A third
variable is choosing a web development firm to help
implement — that comes into play later, in Chapter 18
(Select an Integration Partner).

As was intended, feel free to move to the chapters that

affect you the most.

To be fair, a lot of options still exist in that space, but if you

go to the car dealer and come home in a Porsche 911 you’re
going to be sorely disappointed the first time you try to
hook a horse trailer up to it.

But then, there’s that little thing called a gut feeling. How does
the vehicle make you feel? A pickup might make you feel like
a general contractor, while an SUV might make you feel like
a parent hauling kids to a soccer game. They may not be
tangible, but those feelings still matter.

Thus enters the grey area of prioritizing requirements.

System Requirements in a Nutshell

Despite the word itself, requirements aren’t always required.
When we talk about a content management system,
requirements are simply elements of a software platform
that exist on a sliding scale of desirability. We might roughly
segregate them into:

• Hard: these are non-negotiable (“must-have”)

• Soft: these are negotiable, and some are more important
than others (“nice-to-have”)
When it comes to buying software, these requirements can
fall into all sorts of subject areas:

• Features: specific capabilities the software claims to have

• Infrastructure: how the software exists inside your
organization’s technical environment
• Financial: how the software is priced, both in amount and
structure
• Ecosystem: the organizations and services that exist
around the software

This means your requirements for software are a

combination of two axes: your needs and how elastic those
needs are.

Let’s talk about each subject area, with some examples of

both hard and soft requirements with each.

Features: What Does It Do?

Content management systems have a wide range of features.
There are some features customers commonly need:
• Content Modeling: This is the ability for a CMS to
accurately represent a logical model of your content –
essentially, the technical representation of the model we
created in Chapter 11: Model Your Content, and it’s more
important in some situations than others. A small
campaign site might not need much beyond a generic
“page,” while other sites might have detailed, intricate
models.
• Editorial Tools: These are the tools editors are given to
actually manage content. Features like workflow,
 approvals, preview, collaboration, etc. These are tools that
let you do the “management” of content management.
• Security Tools: This allows for the management of users,
their organization into groups, and the assignment of
permissions. Some systems are simple enough to be
binary – you’re either authenticated or not – while others
allow for highly granular control over specific
permissions for what might be hundreds or thousands of
users.
• Publishing Tools: These are the features and frameworks
that allow you to broadcast content into a delivery
channel somewhere. For most systems, this is a
templating system that allows you – or your developers –
to generate HTML that can be delivered to a browser.
However, a CMS can push content into other channels,
like social media or mobile devices.
• Media Management: These are the features around the
management of rich media files, like images and
documents. Some systems just allow you to manage a
directory of files on the server, while others allow detailed
modeling and management of media files just like other
content.
• Integrations: As we discussed at length in Chapter 14:
Know Your Integrations, these are the hooks that allow
your CMS to communicate with other systems, as well as
the library of other systems that have packaged
integrations with your CMS.
• Marketing and Optimization Tools: These tools allow for
the optimization of content by doing things like
personalizing content for specific visitors, showing
different variations of content to see which one performs
better, and tracking visitors to develop a comprehensive
profile of them.
When determining what features you need, it’s important to
take a critical look at your organization, your plans, and your
capabilities. Lots of projects have bitten off more than they
could chew and purchased functionality they didn’t have
any chance to use.

While it’s tempting to find a system that’s loaded to the gills

because “we just might need this feature someday!” know
that every feature costs money, in terms of both upfront
outlay, and increased support, training, implementation, and
distraction. Don’t take your eye off the ball.

I’m convinced every organization has a “maximum technology absorption rate,” and it’s
lower than you think. Humans are habitual animals, and a new system means breaking old
habits and creating new ones. This invariably goes slower than you expect.

— Deane Barker

Instead of focusing on sheer numbers of features, focus

more on the goals you want to achieve, and be flexible. For
example:

• Good: We want to create multiple versions of content to

see which one is more effective.
• Less Good: We want multivariate testing that allows us to
visually compare unlimited versions, specify the
percentage of visitors exposed, and track click-throughs to
a conversion page.

The “less good” example is very specific. If a system fails one

part of that – for instance, if it can’t offer visual comparison
– then does it fail the whole requirement?

In a perfect world, our CMS selection story would begin and

end here – we would simply pick the system that had the
features we needed, and everything would be wonderful. But
will this play nicely within your existing infrastructure?

Features are not binary. Sadly, many organizations

create “feature matrices” that only allow the respondent
to check a box to say, “yes, we have it” or “no, we don’t.”
This is grossly short-sighted because features are highly
interpretive. A system might not have Feature X, but it
has Features Y and Z that you might combine to do 90%
of what you wanted to get from Feature X. Additionally,
a system might have the feature you’re looking for, but
just call it something different.

Infrastructure: Who Is Building, and

Who Is Hosting?
Software has to exist and execute somewhere – on some
computer, in some data center, in some country, managed
by some people. Traditionally, we’ve called this “hosting” or
“web hosting.” Some combination of infrastructure –
servers, routers, network access, etc. – serves as the “host” for
software you could connect to.

With the advent of the cloud, the questions around hosting

have gotten hazier. Lots of people think software just exists
“out there” somewhere. So long as you can connect to the
Internet, you’re good. The cloud has become hosting by
another name.

Occasionally, an organization requires control of software’s

hosting – the software needs to run on computers they
control. We still see this in the financial services and health
care markets a bit, over privacy and security concerns. But
cloud hosting has advanced to the point where most CMS
sales teams assume that the software will run elsewhere,
managed by someone not in their organization.

Here’s really what you need to know:

• Who in your organization can make this decision, and

what are their preferences and reasoning?
• Do they require control of the software, or do they
specifically not want to come anywhere near it?

In addition to hosting, software is built on some “stack” of

technologies, from the operating system outward. There’s
software that runs on Linux, software that runs on Windows,
and – increasingly – software that runs on both. Beyond the
operating system, software is written in a specific language –
Java, PHP, and C# are common – and uses a specific
database software.79

To what extent does your organization want or need to

program against or manipulate this technology stack? Are
you going to develop and program the website in-house? Or
are you going to work with an external partner?

And if your organization is hosting the software in-house (as

opposed to “the cloud”), are they prepared to support all the
separate layers of the technology stack? Do they have servers
running the correct operating system? Do they have a
licensed copy of the database server?

To someone like me, this all feels like technical jargon … until I remember that building in a
specific language or using a specific software requires specific people with specific skills.
Understanding the technical stack of a web project is not just a technical decision, but a
 staffing and governance decision.

— Corey Vilhauer

This can really get into the weeds, so let’s illustrate with a
few examples of how these requirements might play out:

• Mark works for a small non-profit that needs a marketing

site. They only have nine employees, and no IT staff.
They use Google Apps and everyone works on their own
laptop. Mark literally cannot host anything: all he has is a
company credit card, and a task to get a website up next
week.
• Jennifer works for a global financial services company.
She works with a marketing agency on a campaign
microsite. The organization is incredibly concerned about
security for their clients. IT — a 1,500 person department
that includes several hundred database administrators and
developers — requires everything to be hosted in their in-
house data-center.
• Sam works for a regional banking chain. They have an
extensive IT staff, but that staff is busy running frontline
business applications. Since the public website is mainly
marketing functionality, they’re fine with it being hosted
with the CMS vendor.

Each example provides various restrictions:

• Mark is self-contained. He can’t (1) host, or (2) develop.

So, those two restrictions limit his selection to simple,
unattended, site-building systems like Squarespace or
Wix.
• Jennifer doesn’t have development restrictions (we
 assume her marketing firm is developing the site), but it’s
going to need to be hosted in-house, so it requires a
system that runs on compatible in-house servers.
• Sam can host it anywhere (remember, the IT department
doesn’t care), but it’s going to need to be built by the
organization’s developers, so it needs to be based in the
same programming language.

For people having to use the system to achieve a business

result, this can all be annoying. To most marketers, for
example, the details don’t seem relevant to the effectiveness
of the final product. But, unfortunately, these have to be
accounted for sooner rather than later, because finding out
about a hard restriction down the road (“um … we don’t
know that language”) can be a real problem.

Find the people in your organization with authority over

your IT infrastructure and ask:

• Who is going to build the website, and what language do

they know?
• Who is going to host the website, and what technology
stacks can they support?

Then you’ll be closer to your solution. Now, how much are

you willing to pay?

Pricing: How Much and … How?

Pricing of CMS systems differs wildly in both the obvious –
how much does it cost? – and the less obvious – how is that
cost structured? Given the differences, the only real way to
examine costs is to consider a metric called Total Cost of
Ownership, or TCO.
TCO measures the total cost of a solution over a specific, named
timespan. There are a few things from that sentence we need
to unpack:

• Total: meaning not just the cost of the software itself, but
the cost of the services and infrastructure surrounding it,
no matter to whom the check is being written (or if it’s an
internal cost).
• Solution: which usually means software and services. The
CMS, any add-ons, and the cost of design and
implementation, for example. Vendors will often use the
word “solution” to signify that they’re selling those things
together.
• Specific, named timespan: which means from the day
you start paying to some point in the future, which is used
to estimate and equalize costs.

Here are a few examples of software cases with associated

hosting, using a five-year timespan:

Type of CMS license Up front Monthly or annual TCO over

costs costs five years

CMS An “unattended software as a service $0 $99/month $6,000

X (SaaS) system80 that you can
subscribe to with a credit card.

CMS An “enterprise software $30,000 20% of upfront $54,000

Y subscription” that is hosted in the up-front ($6,000) per year
cloud.

CMS A system that requires you to $10,000 $6,000 per $442,000

Z provide your own hosting. onboarding month, plus
fee $1,200 per month
in hosting.
Two things to note there – First, these are simple
calculations. The real world is messier, and might involve
things like the time-value properties of money,81 expense
categorization,82 other contractors you might engage with,
and vendor claims that you will actually save money on
other aspects of your environment over time.

Second, you can begin to see why you have to name a

specific timespan. The three systems above have drastically
different pricing structures, and there’s no way to compare
them without some reference to how long you’re going to
pay for them. CMSs X and Z are “rented” for time periods,
while CMS Y seems to be purchased with a maintenance fee.
They just have no comparison value outside of a time
period. Additionally, note that CMS Y is front-loaded, with
over half of its expense coming in year one. It looks more
attractive the longer you use it. Changing your timespan
from three to five years changes the financial picture of that
system.

How CMS Pricing Models Are Structured

For years, the predominant pricing model was a one-time
purchase cost, with a percentage of that cost every year
thereafter. This is known as “software subscription,”
represented by CMS Y in our previous example. Paying this
annual fee might be required to continue using the software
or it might just enable some added value – such as support,
upgrades, or free copies of the software for test servers.
Recently, the model has shifted slightly to remove the one-
time purchase cost and instead focus solely on a monthly
subscription.

The major question with subscription pricing is when you’re

going to start paying for software. When does that first
month commence? A full, ground-up web rebuild like the
one we’re outlining in this book can take eight to ten
months. If you select your CMS early in that process, simple
logic tells us that the vendor wants you to start paying as
soon as possible (a pretty safe rule: vendors like revenue).

However, do you need the software that early? Sometimes …

yes.

You often need a license to start developing with the

software, so you can’t start building until you pay. If you can
find software that delays costs until you deploy, or after a set
development time, this can make the difference of tens of
thousands of dollars.

One thing to remember: everything is negotiable. If you have a specific request around pricing,
ask for it. Vendors will deal.

— Deane Barker

Should You Even Pay for a CMS?

All of the above assume you’re going to buy a commercial
CMS, which isn’t required. There are hundreds of open-
source CMSs available, in varying degrees of quality and
polish. In fact, CMS is probably one of the most popular
genres for open-source development.

The open-source market varies wildly in scope and quality.

Some systems that have reached a massive level of adoption
(Drupal and WordPress, for example), but there are
hundreds of others with little adoption, for which support
and documentation is scarce.
With attractive options available at no cost, why buy a
commercial CMS at all?

• Marketing functionality: Open-source CMSs are

generally more concerned with the core management of
content, and less concerned with higher-level marketing
functionality. Few open-source systems have marketing
optimization features like personalization or A/B testing
built into the core of the product, and relatively few of
them integrate with the larger marketing automation
suites.
• Core functionality, rather than plugins: Open-source
CMSs are often comprised largely of add-ons or plug-ins,
given the distributed nature of the communities that
develop them. It’s quite common to keep the core of an
open-source CMS very lightweight, then depend on
addons provided by the community for advanced
functionality. This can bring some problems, like upgrade
compatibility and security issues.
• Single vendor “security”: For better or worse, many
organizations want a single vendor to stand behind any
product they use. If they use an external partner to
develop their open source solution, they can still get this,
but if not, then they have to depend on a sometimes-
amorphous community to provide unpaid support.
Certainly, several companies have sprung up to provide
commercial, “enterprise-level” hosting around open-
source products,83 but then you might end up paying just
as much as you would pay to a commercial vendor.

Your mileage may vary, of course, and for many

organizations, open-source works wonderfully and the lack
of a license is simply a bonus.
Ecosystem: It’s Better with Friends
Oftentimes, an organization decides to build their own CMS,
rather than purchase one, or use an available open-source
option. They figure they won’t have to pay a license fee,
they’ll know it intimately, and they’ll craft it to their specific
requirements.

Sometimes this works out. Mostly, it doesn’t.

One of the biggest problems with building your own CMS is

simply that you’re the only one who uses it. You are a small
island in a vast ocean of challenges and problems. When you
need a solution, you have only yourself to lean on. There’s
no one out there coming to your rescue.

“Ecosystem” is a handy term for the entire environment of

other people and organizations who are experts in a software
platform. This is both the vendor who may have built the
software, and the entire universe of people using the
software. An ecosystem manifests itself in different ways —
through community support, robust documentation, and a
rich partner network.

While the example of building your own software clearly

exhibits a lack of everything above, you can have the same
problem with software you purchase or download. Don’t
assume that because the system is publicly available – either
open-source or paid – there’s a thriving ecosystem around it.
Many open-source systems don’t have wide adoption, or are
getting quite old and are no longer being actively developed.
Additionally, some commercial vendors are quite small and
don’t have much of a third-party partner network to speak
of.

The ecosystem needs to be evaluated like any other feature.

Some are better than others, and unless you have a deeply-
staffed internal department, or an external partner with
scads of experience that you expect to be working with for
many years, you will need the benefits of an ecosystem at
one point or another.

Inputs and Outputs

The input into this process is a well-informed team with a
plan for what the completed website will need to do. You
need to know what your editors want, and some idea of how
they’ll interact with the system. You also need to get at least
some idea of where your organization stands on budget, and
if you have hosting and/or development constraints that
would require a specific technology stack.

The Big Picture

You need to put some thought into this before you start
looking for a CMS. And to have productive conversations
about it, you need to have done some planning for your
future web presence. It’s going to be hard to define
requirements if you don’t even know what you’re building.
Your plans don’t have to be perfect, but you need some
framework of needs before you can decide how to solve
them.

Staffing
You can do this yourself, but you might want to employ a
“selection consultant” for help with this. There are
consultants who work with organizations on just this
problem – helping them match their needs to a software
platform. The first stage of a good consulting exercise is
what we discussed in this chapter: determining your needs
and how these might overlay on the current state of the
market. In later chapters, we’ll talk about the other parts of
this engagement, writing RFPs and managing the process
itself.

79 We’ll talk more about all of this – hosting itself, as well as the technological stack – in Chapter
17: Plan for Hosting.
80 The classic examples are Squarespace or Wix.
81 The “time value” of money means that money you have now is worth more than money you’ll
have in the future. So, a $5,000 expense 10 years from now is more affordable than the same
expense today, because inflation will cause $5,000 to be effectively worth less in 10 years.
82 In the accounting practices of many organizations, there’s a difference between a one-time
“capital expense” and an ongoing “operating expense.” Organizations might have differing
amounts of money available for each.
83 The most obvious example here is Acquia, which provides a hosting and value-added
infrastructure around Drupal, which is open-source.
CHAPTER 16

Select a Content Management

System
SUMMARY
Selecting a content management system (CMS) is a
combination of research and vendor engagement. You need
to identify prospective systems, investigate their capabilities,
engage with the vendors for demonstrations or questions,
and finally distill and synthesize all that information and
come to a decision.

DOES THIS APPLY?

If you need to select a new CMS, then yes, absolutely.
However, you might not need all of this, and we’ll talk about
how to abbreviate the process. If you’re not picking a new
CMS, or have already picked one, then feel free to skip this
chapter.
Everyone knows an audiophile. One of those people who
elevate their sound systems to wild levels. They buy things
like stereo wires that cost thousands of dollars, then claim a
difference in sound quality that no one in the world could
probably identify.84

Then, at the other end of the spectrum, you have someone

who plays music from a tinny AM radio powered by dying
batteries that they’ve dropped in the bathtub one too many
times.

This is juxtaposition of message and medium. The message

is the music. The medium is the physical thing that makes
the sound.

While you can go overboard on hardware, not paying any

attention to it is just as bad. No matter the quality of music, it
needs to be played on something that will allow it to be
received to its full potential.

Likewise, good content is wildly important to your project,

but that content needs to be managed and delivered in such
a way that does it justice. You’re most likely going to deliver
your content via some type of CMS. This entire book is
predicated on the assumption you would be using a CMS for
your website.

You need to make sure you pick the right CMS. Not too
much, but not too little either. It needs to be enough to
manage and deliver your content to the level it deserves, but
not so much that it breaks your budget or is too complex to
work with.

To be fair, you don’t have to use a CMS. Whether they’re

generated by a CMS or hand-crafted, web pages are still just
HTML, and there have been some fun advances in static site
generation in the last few years. But for most organizations,
usage of a CMS is a non-debatable point. Once your content
gets over a certain volume, and especially if you have
multiple editors working with it, then a CMS usually
becomes a requirement.

At some point, you’re going to need to select which platform

to use, and this is where things can get difficult. When you
consider that the CMS as we know has been around for only
about 25 years, you can imagine the level of volatility still in
the industry. What’s more, for some on your team, this is the
first time they’ve evaluated a CMS, or it’s been over a
decade. A lot has changed.

CMSs are complicated things, and so are projects. They both

have a lot of moving parts.

You know those inflatable dancers that car dealerships use to

promote sales? The ones with the arms that whip around
non-stop? Try getting two of them to dance in perfect
synchronization. Now throw software vendors and their
sales teams into the mix, and we’ve got a real party.

The best we can do is try to wrap some structure around the

process so it doesn’t devolve into a confusing free-for-all.

(Disclaimer: you may read through this and say, “Wow, this
is a lot.” And it is. But we thought it was better to show you
the long-form method, and then let you dial it back if you
like. We’ll address how much of this might apply to you in a
section at the end. Hang on – we’ll put it all in context.)

The Selection Funnel

A funnel is a handy metaphor. A funnel can represent
anything that starts out with a lot of something, then slowly
whittles the number down over time.

The reality show Survivor is like a funnel. There are lots of

people on the island, and we slowly vote them off as we
move from the big end of the funnel to the small end.
Finally, a single winner emerges from the wild.

With CMS selection, this funnel is just two or three steps.

You’re going to start wide, asking vendors to provide general
information about their systems, then you’ll eliminate some
of them and narrow the group by asking the remaining
vendors to relate their systems specifically to your
requirements, then you’ll eliminate more, then you might go
an extra step and ask very few of them to actually do some
integration work for you.

Finally, you’ll end up with a selection.

The Long List

This is the widest end of the funnel. This is where you create
a “Long List” of potential vendors and toss them into the
mix.

How do you come up with the Long List? There’s no great

answer to this. The longest list is every possible vendor on
the planet. But clearly, that’s unmanageable and not really
fair because you should only include vendors that have at
least some chance of satisfying your requirements. In general,
you should try to keep the “long” list as short as reasonably
possible – roughly five to eight vendors long.

Two reasons for this:

• Selection processes take work: You need to manage

 requests and responses and do the evaluation, usually
spread among multiple members of a team. Every extra
vendor means more work for your team, and can add to
extra confusion as they present features not central to
your project.
• Vendors are people too: When a vendor responds to your
request, they’re investing time that they could be
spending on other opportunities. Sometimes, they’ll work
nights and weekends to get your request out the door
(especially towards the end of a quarter). You’re in a
position to create work for someone, so don’t do that
unless they have a reasonable chance of seeing a reward.
Don’t waste people’s time.

When developing the Long List, we will lean heavily on the

decisions made when we determined system requirements.
Your Long List will depend on:

1. The nature — or “gestalt”85 — of your project: Are you

simply managing content, like technical documentation
or other non-marketing content, or do you really need a
full-blown content marketing platform that happens to
also manage content?
2. Your technical restrictions: This might be a specific
language, or a hosting requirement, or some other rigid
requirement that will eliminate a chunk of vendors right
off the top.
3. Your price point: Is your project budget $10,000?
$100,000? $1 million? And how much of that can you
spend on software?
4. Your need for services: There’s a big difference between
selecting a system you can implement, and selecting a
system that you need someone else to implement.
Simply accounting for these four points will eliminate a
majority of vendors. You can compare your answers and
requirements to the information vendors provide on their
websites and from other online information – it’s not hard
to understand the basic nature of a system and figure out if it
even remotely overlays on what you want to do.

Bringing in Help
However, if you still have no idea who to include on your
list, you can employ outside help.

Analyst firms exist to help organizations with technology

questions – Gartner and Forrester are big ones, but there are
hundreds ranging from enterprise to boutique.

Companies pay a monthly subscription fee to these firms for

a set number of consulting hours – or even full “advisory
days” – and access to the firm’s published research. Your
organization might have one of these subscriptions, and you
might be able to get an analyst on the phone, describe your
requirements, and ask them to suggest a long list of firms for
you.

Alternatively, these analyst firms often publish some of their

research reports. Generally, they publish their flashiest
report, which is usually well-branded and well-known in the
technology industry.

For example, Gartner publishes what it calls the “Magic

Quadrant” (known as “the MQ” or just “the quadrant”)86 and
Forrester publishes the “Forrester Wave.” These reports
provide a very toplevel ranking of vendors in a particular
space, such as “Business Intelligence and Analytics
Platforms” or “Mobile App Development Platforms.”
 Two more (somewhat cynical) notes on analyst reports:

1. Some project teams just blindly long-list all the

vendors off the MQ, which can be frustrating and
counter-productive, because some great smaller
vendors don’t appear, and some other vendor
appearances are inexplicable and don’t match their
capabilities (which leads to the next point …).
2. Understand that every vendor ranked by an analyst is
likely also a customer of that analyst firm. Rumors fly
about implicit “pay for placement” models, so just
keep that in mind.

On second thought, these are not as cynical as they are

entirely accurate and realistic.

If one of the analyst firms isn’t an option, consider a limited

engagement with a consultant. Several exist in the CMS
space (Deane used to be one of them, before he went to work
for a vendor). For a set fee, they can advise you on your
selection process. A small engagement might be reviewing
your requirements and helping you form a long-list. A more
complete engagement would be to help you write the
Request for Information (RFI), the Request for Proposal
(RFP), manage the demos and manage a Proof of Concept
(POC), and finally assist in analysis and decision-making.

If you work with analyst firms like Gartner or Forrester, they

can help here. And there are smaller, content-focused firms
like The Real Story Group and The Content Advisory.

The Request for Information (RFI)

Now let’s get some more detailed information, which we do
through a process creatively called a Request for Information
(RFI). This is exactly what the title says – we’re asking the
vendor to answer some questions so we can decide whether
or not to move them along in the process.

There is no set format for this, so know that when someone

says “RFI,” they could mean almost anything. Generally
speaking, you’re sending a multi-section document that both
provides some information and requests some information.

First, you’ll provide some information around the following:

• Your organization: What do you do? Why do you exist?

• This project’s background: Why did it come about? What
are the major problems you want to fix?
• The selection process: What are the steps in the process?
What is the timeframe for selection? Who is the primary
contact person? When is the response to the RFI due?
• The technical environment: What is your plan for
implementation – internal, partner, or vendor? Where do
you plan to host the software?
• The scope of your implementation: How many websites
do you need to run? How much content, in terms of
objects or pages? How many editors will work with
content? How many page views do you think you’ll need
to handle?

You’re explaining this to give the vendor some context.

Remember that vendors get a lot of these requests, and
many vendors need to decide if the project fits their
product.

Vendors might respond to say they won’t participate, or they

might just not respond at all. This is a good thing. Very rarely
do I see a vendor withdraw that should have stayed in the
process. If a vendor bows out, it’s very unlikely they were the
right choice for your project anyway.

In addition to providing information, you’ll also request

information. The heart of the RFI is a series of questions you
want answered about the vendor’s product. You can ask
about anything, but these are some common questions:

• What are the technical specifications of your product?

What is its hosting disposition? What supporting software
is required?
• What is a rough price range for your product, given the
sizing information we have provided, and how is it
structured?
• What does the product ecosystem look like? Do you offer
training or certification programs for customers using
your product, or do you have a customer extranet or
community?
• How many customers do you have in our industry (or
organizational size, or project size, etc.)?
• What integrations with other software does your product
offer around a specific functionality? What would our
relationship be with your company after purchase? Will
we have a dedicated account representative?

The goal is to find out enough information about the

company and the product to decide if this is a vendor you
want to move down the funnel to the next round. You’re not
getting too specific here – this is a general, high-level
summary to get some questions answered and establish
contact and rapport with a vendor.
Give vendors enough time to return this – at least two
weeks, and perhaps more, depending on the number or
depth of your questions.

Some vendors will ask for a phone call for “discovery.” They
likely want a chance to ask you some further questions,
though some of them might be looking for an opportunity
to make an early sales pitch. You can handle this any way
you wish. We know some customers who refuse all contact
requests, with the goal of treating all vendors equally, but so
long as all vendors have the opportunity for further discovery,
then let them ask for it. More communication and
transparency can do nothing but help you.

The evaluation of the RFI response is how your short list is

developed. The goal is to cut the vendor pool from the
aforementioned five to eight down to two to three for the
next round.

The Short List and Request for

Proposal (RFP)
Once you’ve notified a handful of vendors that you’ve
decided not to move forward with them, you need to
prepare an RFP for the remaining vendors.

This document has the goal of fact-finding, like the RFI, but
it gets more in-depth, particularly in two respects:

1. You will provide specific usage scenarios you want

demonstrated.
2. You will ask for a binding price quote.

The response to the RFP will usually come in two forms.

First, vendors will provide a written response with a price
quote. Second, vendors will perform a demo of their
product, either remote or occasionally onsite.

Usage Scenarios
The bulk of the RFP should be a set of scenarios – examples
of your expected usage that you’d like to see in action. Here’s
a very simple example:

Mary wants to create a new press release. She logs into the system
and selects the Press Release content type. She enters a title and a
summary. She selects an image from her local machine and
uploads it to be added to the content. She enters several
paragraphs of text and formats it using a formatting toolbar. She
previews the content as it will be displayed on the website, and
schedules it to be published tomorrow at 8 a.m. When she submits
the content, it appears as an approval task for Brenda, who
reviews and approves the content for publication. At 8 a.m. the
next morning, the content is published and automatically appears
in the index of press releases.

This is a very simple, mainstream editorial workflow

scenario. It’s helpful for something like this to be the first
scenario demonstrated, because in showing the functionality
to complete the tasks described above, the vendor gives you
a summary tour of the CMS itself.

Further scenarios can get more complicated. Things you

might want to see:

• Marketing functionality, like A/B testing and

personalization
• Localization support (“Mary also creates a Spanish
 translation of the press release.”)
• Content quality tools, like spell checking, link checking,
and reporting
• Collaboration support
• Advanced workflows, like content annotation and
processing multiple changes as a unit (“changesets”)
• User management and permissions

Keep your scenarios to seven or eight, at most. Remember

that each one will take fifteen to twenty minutes to work
through when you account for questions and follow-ups
from a group. You could be in for hours of watching a screen
if you’re not careful, and that’s just for one vendor!

Also, be realistic about how much time vendors have to

respond. If your scenarios require customization work, three
to four weeks is a reasonable amount of time for a vendor to
respond as well as prepare and schedule a demo.

Pricing
For the pricing section, you will need to provide whatever
information that vendor needs in order to price. What is this
information? Well, it could be anything.

As we discussed last chapter, software is priced on an

infinitely variable list of factors, and each vendor is going to
need different information. Some common ways pricing is
handled include:

• Number of servers the software will be deployed on

• Number of editors who will be able to use the software
(either the number of editor user accounts, or the number
 of editors who will use the software concurrently)
• Number of content objects under management
• Number of websites the CMS will manage and serve
(note: exactly what constitutes a “website” is very much up
for debate)
• Number of aggregate page views the websites will deliver
during a particular timespan (by month or year)

Just be prepared that a vendor might ask for anything in

order to come up with a price, depending on what their
business model is. Several vendors will likely ask for another
discovery call, which is fine. We believe that more
transparency is better, and it’s tough to predict what
information a vendor might need to price your solution.

Again, remember this is pricing for the software itself.

Implementation is often handled by another firm, which
might require an implementation RFP, or at least for the
implementation and software RFPs to be combined.

We never said this would be a fast process.

Software Demos
As part of the RFP, you’re asking for the vendor to
demonstrate parts of their system for you. You can do this
remotely over a desktop-sharing system, or on-site and in-
person. Vendors will gladly get on a plane for the right
opportunity, which normally means that it’s (1) large enough
in pure dollars, and (2) one that they have a reasonable
chance of winning (described as “well-qualified”).

Either way, the vendor is likely going to need to build out

functionality for your scenarios. Be understanding of their
ability to do this for your demo. They will likely customize
their system, but know that this isn’t production-quality
code, and some of the functionality you want demonstrated
is too in-depth to build in advance. In these cases, vendors
might show you a combination of actual demo and then talk
through some of the more in-depth points, explaining how
it would work in a production deployment.

You need to interpret and discern here. While it’s

unreasonable for a vendor to build everything out, you can
get a general feel for the level of effort the vendor is putting
into it. You want to gauge how well they’ve actually read
your scenarios and how well they understand them. We’ve
seen situations where it’s obvious the vendor first looked at
the scenarios on the flight in.

For your part, you need to have an evaluation team

prepared for any demo. If the vendor is putting forth the
effort, you need to make sure your team is assembled
without anything else to do. There’s little more
disheartening for a vendor to spend thousands of dollars
preparing and traveling, only to find that six of the eight
people canceled, and one of the remaining two spends the
day with their head buried in a laptop.

Timing will vary, but plan on three to four hours for each
demo. You’ll spend a couple hours getting through the
scenarios, then another thirty to sixty minutes discussing
pricing and follow-up questions. Sometimes it’s also helpful
to send the vendor out of the room for thirty minutes to
discuss their presentation as a private group, then invite
them back in for any questions that came up during that
discussion.87

The demo is your chance to see the system in action and ask
questions about what you see. This demo is for you, not
them. Some vendors might try to gloss over issues or
redirect your questions and concerns to an area of
functionality where they’re stronger. This is not a naturally
adversarial engagement, but be prepared to be assertive in
what you want to see.

Something else to remember: vendors love questions,

because it breaks up something that can otherwise get a
little monotonous. Remember, the vendor does these
demos all the time. What gets interesting for them is to
hear your problems and issues and then figure out how
their system might solve them.

Verifying the Decision with a Proof of

Concept (POC)
For many organizations, an RFI and RFP are enough to
come to a decision, but some organizations want to go one
more step further into a proof of concept. In this step, the
vendor works with the actual customer team to implement
some solutions to project requirements. It’s a deeper dive,
where the customer can get hands on with the system and
interact with the vendor’s team.

Sometimes, two vendors do a competitive POC (usually in

consecutive weeks). Other times, the customer has chosen a
vendor after the RFP round, and the POC is seen as a
verification step for that choice. If the chosen vendor fails
completely at the POC, then the customer backs up to their
second choice and has them do a POC.

Here’s the thing about POCs – you need to be very serious

about the project, and you need to have a big enough budget
to warrant this.

POCs should be paid for.

We’ll say it again: POCs should be paid for.

Vendors can only invest so much in an opportunity without

any return, so you need to be prepared to invest in your
POC. Often, POC costs are proposed as a “kill fee”
arrangement, where the vendor is paid if the POC doesn’t
result in a sale. (Other times, the customer asks that the POC
fee is credited toward future services. Whatever, same thing.)

Another caveat with POCs is that you need to be sure your

team has the time to invest in it. If you’re having the vendor
come on-site for a week, then you need your team to be
liberated from anything else they have to do that week. In
fact, it helps to have POCs off-site if possible, so your team
doesn’t get dragged back into other work.

Think of a POC as a “super demo.” Refer back to our

scenario example above. If we were to expand this to a POC,
then the vendor would actually work with your
development, editorial, and marketing teams to implement
the press releases functionality, including:

• Modeling the content with all validation rules and

editorial interface support
• Setting up the users and permissions
• Defining and creating the approval workflow
• Creating the templates
• Training the customer on how the system works
• Some hands-on content operations work (e.g. each person
 on the customer team enters two complete press releases
in a workshop/classroom environment)

The goal is to get end-to-end on some segment of

functionality. Ideally, the hands-on work would even reveal
some shortcomings which the vendor can then address,
which would illustrate how the system changes and evolves
post-launch and the attentiveness and responsiveness of the
vendor.

However, don’t confuse a POC for actual production code.

You might solve some logical questions and come up with
some technical design and implementation patterns and
ideas, but the code generated during a POC should always be
considered disposable.

Decision Time
We’re calling this section “decision time,” but that’s
something of a misnomer. By this point in the process,
you’ve likely made multiple decisions (remember: a funnel
gets narrower with each step), and the team has probably
come to some informal consensus.

Nevertheless, at some point you have to call the process to a

close with a final decision. When you do finally reach a
decision, you’ll need to enter a formal negotiation with the
vendor. Remember, everything is negotiable. If you need a
particular price or pricing structure to make your project
work, ask for it. Vendors can be flexible. They want to make
a sale, and they’ll deal if they need to.

And, be prepared for the paperwork to take some time. It’s

not uncommon for vendor vetting and due diligence at
larger organizations to take thirty to sixty days, so be sure
you understand their policies and know when you can
actually take possession of a license or account to get started
on your project.

So … Do I Really Need to Do All That?

Yes, yes, we know – this is a lot.

Rest assured, not every project needs all of this. Larger

projects with a wide range of CMS options will need
something resembling this, but other projects can cut this
process way down.

Some options:

• POCs are probably the exception, not the rule. There are
reasons not to do one. As we note, POCs should be paid,
they take a lot of effort from your own team, and they
push out your decision timeframe considerably. Think
very carefully before you embark on one.
• You might skip the RFI. If you start with a relatively short
list of vendors, you might jump right to a combined
RFI/RFP, which is an RFP with some additional questions.
You might send these to a slightly larger group of vendors
(call it a “medium list”), and explicitly state that you will
invite vendors to demo scenarios depending on their
response. You might only have one vendor demo.
• If you have a consultant you trust, let them guide you. If
you find a consultant who you think has enough
experience with your type of project, then perhaps let
them make a recommendation? Have them tell you what
system they would use for your project, then have that
vendor demo. You might find yourself comfortable
enough to make a decision solely from that.
Note too that, for some projects, you might not even be able
to do all this even if you wanted to. The process detailed
above assumes you have a willing set of vendors with sales
teams ready to engage in a personal selling relationship. This
isn’t always the case — some systems simply don’t do
individualized sales, and open-source software often has no
seller.

There’s just no process that fits every project, every team,

and every mix of potential vendors. Pick and choose, and
come up with a process that works for you.

Above all, keep an open mind. Seek to learn as much as

possible. Even a system that ends up not being the one for
you can teach important lessons about what’s available on
the market, what works, and what doesn’t. Sometimes,
seeing something you don’t like helps you clarify what you’re
looking for.

Finally, know that there’s no one system for everyone. The

truth is that your project will likely be equally successful
with more than one system. Remember this when and if you
get overwhelmed by the decision.

Do your best. Good luck.

Inputs and Outputs

You need the requirements that we discussed in Chapter 15:
Determine System Requirements, and the integration stuff
from Chapter 14: Know Your Integrations. Also handy – a
site map (Chapter 10: Organize Your Content), a content
model (Chapter 11: Model Your Content), and any designs
and wireframes you have (Chapter 13: Develop the Graphic
and Interface Design). The output of this phase is a binding
CMS platform decision, and a purchase agreement for that
system.

The Big Picture

Clearly, you need a decision on CMS before you can start
building your site, or sometimes even before you start
looking for an integration partner if they aren’t helping with
your CMS selection. However, you can’t rush into this right
away – you need significant site planning in place before
you have enough information to make a solid decision. You
need to thread the needle between those two things.

Staffing
As we discussed in this chapter, a consultant is pretty helpful
here. You can hire one for the entire selection process, or
perhaps find someone in the web content management
space who would give you just a few hours to review your
requirements and make some recommendations for your
Long List.

Besides that, the core project team should be enough, so

long as everyone is involved. Everyone needs to see the CMS
demonstrated and provide their feedback on it. Considering
the typical expense here, you don’t want to surprise anyone.

84 Consider a length of cable that claims to be “composed of 16 solid-silver conductors arranged

in a double counter-spiral geometry, with each strand guaranteed to have a flawless surface. The
cables use foamed-polyethylene for the dielectric, and a multi-layered carbon-based sequence of
components acts as a noise dissipation system.” A 20-foot length of these particular cables costs
$76,800. We wish we were kidding about this.
85 Gestalt (noun): something that is made of many parts and yet is somehow more than or
different from the combination of its parts.
86 As we discussed earlier, Gartner has discontinued the MQ for its Web Content Management
category. However, they will have an MQ for “Digital Experience,” which overlaps heavily.
87 Kudos to Tony Byrne, founder of Real Story Group, for introducing us to this technique.
(Alternately: “Scorn and resentment go to Tony Byrne for making us suffer through this
technique.”)
 SECTION 5
DEVELOPMENT

For those on the outside, it’s easy to think web

project development is just a bunch of code and
curly brackets. In reality, developing your site
requires an understanding of how code works,
the development ecosystem, and how your
content and design will fit into that ecosystem.
Developers can do amazing things, but your
content management system isn’t limitless, and
understanding those limits is key in creating
something with longevity.
CHAPTER 17

Plan for Hosting

SUMMARY
A website needs to be deployed in a public environment to
function correctly. You need to determine the technical,
organizational, and financial parameters of this hosting.

DOES THIS APPLY?

To be honest, there’s a high chance this doesn’t apply to you.
If you have an IT staff that manages all your infrastructure,
then they’ll manage most of this. An external development
team that’s building your website will often also manage it,
so they might handle all this as well.

However, even if this chapter doesn’t apply, you might find

it interesting as it covers some of the underlying
technologies and architecture of how the internet works.
You will be affected by hosting at some level, so you may as
well know how it works.
Also, this might apply to your budget. Even if you don’t have
to deal with hosting at a tactical level, your organization
might want to take it out of your budget, so it might be
worth a read.

Back in the days when stock markets were in-person, a

trader needed a “seat” on a market. These were the days
where traders would get together in crowds around pricing
boards and yell out dollar amounts to try to find someone to
trade with.

Seats on the New York Stock Exchange were closely guarded

and very expensive. When the practice ended in 2006, a seat
cost about $3.5 million. Traders would risk everything just to
scrape together enough money to effectively buy a place to
work. Just having the seat, of course, wasn’t enough – that
was just the price of entry to work.

And that matters. To do anything, you have to have a seat at

the table. You could be the greatest in the world at
something, but if no one knows about it, that’s not going to
do much good.

The same is true of websites. Your website has to be

somewhere in order to be available to the world. It would be
the greatest website in the world on your local hard drive.
It’s not going to do you much good there.

At their base level, websites are just a collection of files.

Those files have to be copied to a computer somewhere, in a
format the computer can understand, and that computer
needs to be hooked to the internet and configured in such a
way so when a visitor types your domain name into their
browser, the mighty power of internet routing directs them
to your website on that computer in such a way that it can
match up their request to some resource and return the
correct response.

That’s the long version.

Here’s the short version: your website needs to be hosted.

“Hosting” is a word that represents all the stuff it takes to

make your website less theoretical and more actual. It’s the
processes and infrastructure to make your website available
to visitors.

Depending on your staffing, organizational, and contractual

scenario, you might be involved in this a great deal, not at
all, or any gradient in between. You might depend on an
internal data center within your organization. Or, you may
depend on a subscription service in which you never need to
worry about a thing. Regardless of whether you handle it, or
someone else handles it, or some company in Seattle,
Washington handles it, your site will be hosted.

In this chapter, we’re going to talk about hosting in general,

and a lot of hosting-related topics. You might never come
into contact with any of this stuff after you finish reading
this. Or you might.

The key is: you need to find out.

To go back to the original point: your website has to be

somewhere. So you need to get some questions answered
before you have any chance of actually unleashing your
magnificent creation onto the world.

In this chapter, there are lots of words with footnotes.

This is because we cover a lot of computing jargon in
 here. We’ll try to explain them inline when we can, or in
footnotes when we can’t.

The Hosting Account

We’re going to roll up a lot of functionality and discussion
into the idea of a hosting account. This is a service you
purchase from some provider that allows you to run a
website and expose it to the internet.

Hosting accounts have varying capabilities. At the bare

minimum, a hosting account is going to provide the ability
to store a set of files and the ability to make those files
available at specific URLs.88

Beyond that, let’s talk about some of the other things you
might need to know.

Programming Language
Briefly, let’s cover two terms:

• Request: data your web browser sends to a server

• Response: data the server sends back to your browser in
response to your request

When your web browser – perhaps your trusty copy of

Firefox or Chrome – requests an image file, for example, the
server responds with a set of bytes that represent that image,
along with some other hidden data such as what type of
image it is. This is a request-response.

The simplest request-response is:

 Browser: “Give me this file.”

Server: “Here are the contents of that file.”

But not everything is that simple. Sometime right after the

web was born, someone got the idea that we might do things
to those files before we send them back. So instead of
sending requests to actual files, some decided to send them
to programming scripts that would execute on the server
and return the results.

Now we have:

Browser: “Execute a script based on this URL.”

Server: “I have executed that script, and here are the results.”

(In reality, when your browser makes the request, it just has
a URL which is a series of characters – /products/, for
example. It has no idea if that represents a file or a script. It’s
the server’s job to figure this out.)

Flash forward twenty years, and this is largely how the web
works. URLs point to scripts just as often as they map to files.
Sometimes those scripts are an actual file (like /news.php), and
sometimes they’re just some designation that a larger
process reads in and uses as input (like /news/topics/africa).

Most every hosting account is going to be able to execute

some language. Different accounts will service different
languages. Common languages include PHP, .NET
(pronounced, “dot net”; also commonly referred to as “C#”
or “C-Sharp” for reasons that aren’t important), Java, Ruby,
or Python.
Whatever CMS you select will be based on some language,
and it will need a hosting account capable of understanding
and executing that language.

Databases
Databases are places to store and retrieve information, and
they function as very complicated and multi-layered
spreadsheets. If you have 10,000 news articles, for example,
you could put those in a database for safekeeping, and then
query the database to return certain articles based on
criteria. We might ask questions like this:

• “Give me all the articles.”

• “Give me the last twenty articles that were written,
ordered by date, newest first.”
• “Give me all the articles containing the word
‘economics.’”

Refer back to the programming language discussion above –

any one of those scripts, when executing, might contact a
database, get some data back, and then incorporate that data
into its response. Common databases include MySQL
(pronounced “my sequel” or “my ess que elle” – no one
really agrees), SQL Server (see a trend there? SQL is a
common database query language), and Oracle.

I have said “my ess que elle” at a table with two other developers and was ridiculed, so I can
say that there are some people who have definitely agreed on the pronunciation of MySQL.
Pronounce it at your own risk.

— Corey Vilhauer
Every CMS is based on a database of some type. In fact, a
CMS might be considered a super database that wraps a raw
database in another level of functionality for people who
want to manage content.

The “Technology Stack”

The programming language of the hosting account,
combined with the database it supports, comprise what’s
known as the “technology stack.”

It’s called this because every CMS runs on an underlying

“stack” of technologies. At the lowest level, there’s the
operating system of the computer itself. Then the web
server that runs on it. Then the programming language that
executes. Then the database that’s included. And then the
CMS sits on top of all of these.

Here’s an example for Optimizely:

• Programming Framework: ASP.NET MVC

• Programming Language: C#
• Web Server: Internet Information Server
• Database: SQL Server
• Operating System: Microsoft Windows

Each piece builds on the one “below” it. Optimizely requires

all the pieces in this stack, from top to bottom.

Almost every CMS requires a specific technology stack, and

this tends to be a rigid requirement, which means you’ll
need to acquire a hosting account that supports the
corresponding technology stack.
Shared Hosting vs. Owned Hosting
The hosting accounts we’ve been talking about are quite
simple. They’re what’s called “shared hosting,” where you
buy an account on a server that hosts a bunch of other
websites, not just yours. You’re buying an apartment inside a
bigger apartment building with other tenants.

However, some systems require more than that. Some

systems need to “own” the entire computing environment.
They have hooks and tendrils that need to dig deeper into
the hosting system than just a small, shared hosting account
will provide. The technology stack for these systems requires
you to have administrative control of an entire server.

Acquiring a Hosting Account

Before you worry about how to get a hosting account, you
should find out if you even need to do it. Two reasons why
you might not need to care at all:

1. Many CMS platforms come with hosting built-in (they’re

“in the cloud”)
2. If someone is building your website for you, they can
sometimes host it when it’s launched

Those two scenarios probably represent the majority of

situations. It’s uncommon for someone to build a website
with absolutely no guidance on where it’s going to live in the
long-term.

If you’re working for a large enough organization, there’s

also a chance that your IT department wants to host the
website on their own servers in their own data center. This is
becoming less common, as IT staff like the idea of the
website being someone else’s problem, but you still see this
occasionally in healthcare and finance where there might be
privacy and security concerns.

If none of those apply, you will need to find a place to host

your website. Thankfully, compatible hosting accounts are
easily purchasable from many vendors, unattended, with
nothing but a credit card.

At the higher end of the spectrum, if you have a massive site

serving lots and lots of traffic, you’ll probably tend towards a
large enterprise cloud company, such as Amazon Web
Services (AWS) or Microsoft Azure (“az-sure”, like “assure”
but with a soft “z” sound in the middle; also, some people
emphasize the two syllables, while some run it all together).

These two companies provide immense computing

platforms that can scale89 easily and quickly.

For example, if you run a TV commercial during the Super

Bowl, you could expand your website capacity by a factor of
10x in just minutes, then reduce it later when the traffic has
died down. This ability to quickly increase capacity is known
as burst scaling.

Unfortunately, this can also be quite expensive and

complicated. If you have a website that needs this level of
hosting, then you likely need to find a qualified
infrastructure architect who can put together an
environment for you.

If your website isn’t quite so large, then thousands of hosting

vendors can provide you with hosting accounts on various
technology stacks. And, there are a handful of companies
that have platforms specifically designed for the CMS you
want to use — typically open-source, such as Pantheon for
Drupal or WP Engine for WordPress. We’re not endorsing
anyone, but just be aware that many hosting vendors claim
to have special expertise in particular platforms.

Hosting vendors will price their plans on several different

axes, all supposedly based on how much load you’re going to
put on their servers.

• Number of inbound domain names

• Whether you need Secure Sockets Layer (SSL)90

• Number of databases

• Amount of traffic in and out, or necessary bandwidth91

• Number of user accounts to transfer files
• How much storage space you need for files

They usually sell these things in packages. Something like

“basic” gives you certain amounts of each; “business” gives
you a little more; “enterprise” even more, etc. (They all love
three package levels, for some reason.)

While they claim that those pricing factors are to compensate you for load on their hardware,
there’s the real truth: they just want to know how much money you have.

Consider the variable of how many inbound domains you have. That imposes no additional
load whatsoever, but if you have lots of inbound domain names, you’re probably doing a
bigger project, and you’re a bigger organization, so you have more money.

Every vendor wants all the money you have to spend. They just need ways to figure out how
much they dare ask for, and that’s why they price along those factors.

— Deane Barker
When you create a hosting account, you’ll be offered
multiple ways to actually get your files out there. These
might not mean anything to you, but they matter to your
development team:

• Manually push using File Transfer Protocol (FTP or

SFTP)
• Deploy directly from public source control systems like
GitHub
• Synchronize against file storage systems like Dropbox or
Amazon S3
• Publish directly from code environments via plugins to
those tools

We’ll talk a little more about deployment in Chapter 20:

Implement the Back-End Functionality.

Once your files are in your hosting account, and the domain
name is attached to the account (we’ll discuss this soon), then
you technically have a functioning website available on the
internet. Congratulations.

Uptime, Capacity, and Reliability

Your website needs to stay available, and hosting issues can
severely affect that availability. Think of this in terms of
errors: if you make a mistake on one part of your site’s code,
that problem might take down a page or a set of pages. With
hosting, however, those mistakes or errors are absolute – the
website just goes away completely.

Reliability in hosting is known as uptime – literally, how

often is the server “up” and available for connections. The
opposite is downtime. Hosting providers don’t really split
hairs about uptime or downtime. The server is either up or
down, and they don’t really do any shades of gray.

Sometimes, they might have a “slowdown” based on some

external factor. For instance, maybe their upstream
connection to the broader internet is congested with
traffic.92 They might announce this as a service degradation,
but more often they just do their reporting and service
quality in terms of uptime and downtime.

Uptime is reported in percentages, representing how much

time a server was available during the year.

How often should your server be up? Well, 100% of the time,
of course. But you usually can’t get to 100% on a single
server. Servers have to be rebooted occasionally. They need
maintenance. Hard drives might fail. There are lots of things
that could go wrong.

Here are some uptime percentages and the amount of

downtime they would represent in a single year.

• 99% means the server would be down for almost four full
days per year
• 99.9% is about nine hours of downtime
• 99.99% is just under one hour
• 99.999% is about five minutes
• 99.9999% is just 30 seconds downtime per year

In the hosting industry, these different levels of reliability

are known as “nines,” as in “how many nines of uptime do
you offer?” Clearly, the more nines, the less downtime.93
What’s acceptable? It depends on how important your site is
and when the downtime happens.

If you have a small campaign microsite, targeted towards

North American business users who are usually active only
during business hours, and the downtime can be scheduled
overnight, then perhaps a total of nine hours of downtime
spread throughout the year is okay for you, and three nines
(99.9%) is acceptable.

But if you’re Amazon, this isn’t gonna work. Amazon pulls in

tens of millions of dollars in revenue from all over the world
every hour (every minute, even). Additionally, their website
isn’t an optional part of their business – no website, no
money. Amazon can never be down.

Is it possible to achieve perfect, constant uptime? That

depends. How much money do you have?

Each “nine” you add to your minimum requirements will

add costs. Remember that servers will always need to go
down for occasional maintenance, so if you need “high
availability,” your website has to be spread across multiple
servers and synchronized. This allows individual servers to
go up or down without the website being affected.
Something called a load balancer sits in front of all these
servers (called a server farm), and it knows which servers are
up or down, and it routes requests only to the functional
servers. A server could go down, and the load balancer
would just stop sending it traffic until it came back up.

Additionally, hosting companies need to guard against entire

data centers going down, which means they will synchronize
across continents, so that if the East Coast of the United
States somehow goes offline, you can route traffic to the
West Coast.
The difference between four nines (99.99%) and five nines
(99.999%) is usually where costs begin to creep upwards
markedly. Six nines (99.9999%) is where things start to get
very expensive. From that point forward, the annual hosting
costs might start to overshadow all the other costs associated
with the project.

Be careful with your desire for nines. Occasionally, we see

RFPs that just casually throw out requirements for six
nines without any thought to how it will affect the
budget. In these situations, we’ll just respond with a
proposal for four nines (which is what they really want),
and tell them that if they really want six nines (they
don’t), then we can discuss doubling their budget (this
never happens).

Bells and Whistles

What we’ve explained above is the bare minimum you need
to have a website connected to the internet. But there are
some extra things to consider with hosting:

Caching
When you ask for a specific page — making a request to the
database to populate some template — know that this takes
work. It consumes CPU cycles. It takes time — sometimes
enough time to make a website feel sluggish. Which makes it
beneficial to save a request that’s already been made —
rather than pull that information a second or third (or
hundredth) time, you can ask for it to be saved for the
future.
These saved responses are called a cache (sounds like “cash”)
and the action of doing this is called caching.94

Caching is performed at all levels in computing – the CPU

inside your computer even caches certain data to make it
run faster. For a website, caching could take place at multiple
points.

• The CMS might hold onto content that it has retrieved

from its own repository.
• The web server might hold onto responses it has
generated.95
• Some infrastructure in front of the web server might also
hold onto responses; requests are sent through these
dedicated caching servers first and might be handled at that
level, and never even touch the actual server.
• The visitor’s browser might hold onto data it has received
and not request a new version for a period of time.

The downside to caching is that a cache can “get stale,”

which means the underlying content has changed, but since
an older version was cached, visitors are still seeing that
instead. To prevent this, systems have methods to invalidate
their cache, which is a fancy way of saying they’ll delete the
cached data so that it has to be requested from scratch (and
then they’ll re-cache the fresh data).

Caching can make a website very fast, but sometimes stale

cache can cause strange issues where two people see
different things.

Monitoring
Let’s face it: most of the time, you’re just trusting that your
website is running. You don’t know this for sure unless you
go look. If your website mysteriously goes offline every
night at 11 p.m. and comes back online at 4 a.m., and if
you’re not awake and looking at the website at those times,
how would you ever know?

This is where a monitoring service comes in. There are

subscription-based automated services that will check your
website multiple times a day – every hour, every minute,
whatever – to make sure it’s functioning.

Monitoring systems can check lots of different things. At the

highest level, they can simply make sure the website
responds, which would verify the server and network
connection are up. Going deeper, some systems can monitor
at a deeper level, actually replicating user testing. They can
request specific pages, virtually click on various navigation
options, and submit search forms, all in order to verify that
the site is running smoothly.

In QA and testing parlance, the usage of these checks is

called test coverage. Ideally, you would create automated tests
to give you maximum coverage – to automatically explore
every nook and cranny of your website on a timed schedule.
The corresponding downside is the expense and the effort,
both to create the tests and to change them when the
underlying functionality of content changes in such a way
that it makes the test invalid.

These tests aren’t just designed to monitor the hosting server, but also to notify whether new
code breaks old code – called “regression testing.”

— Corey Vilhauer
Location and Recovery
Hosting can be spread across multiple servers or even
multiple locations.

• Content Delivery Networks: On a high volume site,

sometimes it’s helpful to serve rarely-changing static
assets from another server. By doing this, you relieve your
main server from the workload of something it doesn’t
really need to do, improving site performance.
• Data Residency and Sovereignty: The location of data
servers might also come into play for legal reasons.
Occasionally, you need to be concerned with where the
actual servers storing your data are physically located,
especially in the case of collecting personal information.
Different laws might apply to data stored in different
places.
• Disaster Recovery (DR): If a disaster strikes and your
entire hosting infrastructure goes offline, how quickly can
you recover? Disaster recovery is the process in which
your entire website is constantly replicated to another
environment (called, appropriately, a DR environment or
DR server), which means you always have a duplicate
version of your website on standby, ready for traffic to be
routed to it at any time.

I’m not trying to minimize the need for disaster recovery, but in my twenty-five years of
working on the web, I have never once had a client need to fail over96 to a DR environment.
These environments often exist to fulfill a regulatory requirement for organizations subject
to oversight. In practice, they’re rarely ever used (which is absolutely a good thing).

— Deane Barker
Domain Names and DNS
Earlier, I congratulated you for getting your files out to your
hosting account and “getting on the internet.” But I skipped
an important part: your domain name. There’s a step where
you have to give the world your web address. Specifically,
you need to point your domain name –
www.myawesomewebsite.com – to the website you built.

We’re going to cover this at a pretty high level.

Computers on the internet are actually identified by

numeric labels called IP addresses97 – something like,
12.34.56.78.98 Given that address, the magic of the internet
can send your request to the computer to which it’s assigned.

But humans can’t remember those, so someone came up

with the idea of using easier-to-remember text labels as
stand-ins for IP addresses. These text labels are called domain
names.

So, your domain name of www.myawesomewebsite.com is actually

mapped to an IP address. It’s resolved to this address by way
of the domain naming system (DNS). When you type your
domain name into your browser, it contacts the global DNS
system to find the IP address to which that domain name is
assigned, then sends your request to that computer.

It isn’t a one-to-one match. A server might have a single IP

address, but be serving 10,000 websites at the same time.
This still works because requests for all of those 10,000
websites will come into that server bearing the domain name
they want. That server can evaluate that domain name, then
send the request to the files of the hosting account
configured for that specific domain name.
So the process for making this all happen takes all these
steps:

1. You need to acquire a hosting account and determine

what its IP address is.
2. You need to acquire a domain name by purchasing it
from any number of vendors who sell them.
3. You need to configure a DNS record that tells the global
DNS system what IP address that domain name should
map to.
4. You need to configure your hosting account – which
exists at the IP address from step #2 – to handle inbound
requests for that domain name.

As I said before, this is wildly simplified. Hosting vendors

often combine the domain purchasing and hosting process.
You can get a domain name and hosting account in one
transaction, and the vendor will handle all the mapping for
you automatically.

What this also means is that if you’re rebuilding your

website, launching it often just means changing where your
domain name points. You might build your new website on
a new hosting account, serviced by an alternate domain
name, like new.myawesomewebsite.com. When it’s time to launch,
you just change where the DNS record for
www.myawesomewebsite.com points, then shut down the old hosting
account (which shouldn’t be receiving traffic any longer).

DNS takes some time to change. Since the DNS system is

contacted a lot, DNS servers will cache99 the mapping
between domain names and IP addresses. They might check
for changes once an hour, or once every twenty-four hours.
So when you change where a domain name points, it
sometimes takes a while for everyone to see the new website,
and you can have situations where someone in one part of
the country is seeing the new site, and someone somewhere
else is still seeing the old site.

Even if none of this interests you, there’s something you

need to be aware of: for you to launch your new website,
someone in your organization will likely need to change a
DNS record. If this is the case, find out who this person is.

There’s nothing more frustrating than getting ready for a big

launch … only to find out that no one knows who has access
to re-configure the domain name, or that you didn’t allow
enough time for the DNS cache to update. The person who
can do this – likely a system administrator of some kind –
needs to be acutely aware of your launch schedule and be
on-standby to make the required change.

Inputs and Outputs

Before you discuss hosting, you need to know what
technology stack your website will run on. This means that
you need to select a CMS. Additionally, you need to
determine if hosting is even your problem. It might not be,
for reasons discussed in this chapter. If hosting is something
you need to manage, then the output of this process is an
acquired hosting account, ready to receive the finished
website.

The Big Picture

You’ll need to have a development environment – a place to
build – figured out before you can start building your
website. And clearly, you’ll need to have a production
environment – a place to store the finished site – set before
you can launch.

Staffing
If you have them, you probably need to involve your IT staff
in these discussions. There’s a lot of stuff here that might be
affected by your organization’s IT policies. Ideally, you can
hand this problem off completely to someone on that side.

88 A Uniform Resource Locator is just an address to a specific resource, like a web page. It starts
with “http…”
89 Scale means to get bigger. Take something small and make it bigger and you just “scaled” it.
90 Secure Sockets Layer or SSL is a method of encrypting web traffic to make it secret. Sites using
SSL have URLs which start with “https”, not just “http”. The “s” is for “secure.”
91 Bandwidth means traffic capacity or the need for it. A narrow urban alley has low bandwidth. A
six-lane interstate highway has high bandwidth.
92 This can sometimes happen due to nefarious action like Distributed Denial of Service (DDOS)
attacks.
93 There’s actually a hosting company called “5NINES.”
94 Caching generally means “save for later.” You remember when geocaching was big a while
back? Well, people were hiding physical things to be found later. Same concept.
95 Static site generation is a form of caching. The response is generated offline and cached as a
static file which is the easiest thing for a web server to process.
96 This is a bit of slang, but fail over generally means that something is so screwed up that you
need to switch to an entirely different environment.
97 IP stands for “Internet Protocol.”
98 Technically, this is an IPv4 address, which is being superseded by IPv6 addresses which are
longer and includes some letters. The world has to switch because we’re running out of IPv4
addresses.
99 There’s that word again.
CHAPTER 18

Select an Integration Partner

SUMMARY
In many projects, you will engage with a services firm to
install, configure, and customize a CMS to deliver the
website you need.

DOES THIS APPLY?

If you’re developing your website completely in-house with
workers who are employed by your organization, then you
can skip this chapter. But if you’re contracting any part of
the project out, then this absolutely applies to you.

Both the authors of this book worked at a small boutique

web development firm for years.100 One of the hardest
things to do at a small firm is hiring.

First, when you only have twenty employees, one single hire
isn’t just a desk and a computer – it’s a full five percent of
your workforce. Any one person is a big chunk of capacity.

Second, working at a small firm is intimate. There are no

departments. The organizational chart is flatter than you
might find at a multinational corporation. If something
doesn’t work out and you need to part ways with an
employee, it’s hard. You feel that.

So hiring decisions were protracted. We would interview for

months to find someone to hire. Our standards were high,
and we didn’t want to make a mistake. During any hiring
cycle, the stress was palpable. You need to make a good
decision about someone’s capacity to work with a team for
years into the future. You don’t take it lightly.

Your web steering team or marketing department might not

be a small boutique web development firm, but unless you
have the capacity to implement your CMS completely in-
house, you’re going to feel that same capacity and intimacy
of a new hire. You’re going to need to hire someone – an
implementation firm – who will work closely with your
team, and that hire will represent a shockingly important
relationship over the next few years.

Wait … a few years?

No, it doesn’t take that long to launch a new website (usually

…), but a web project doesn’t end at launch – and there’s a
good chance your web relationship, if it’s a good one, won’t
end at launch either. Professional services relationships like
these tend to last a long time. They’re not really “project
constrained.” Very rarely will a contractor come in, do the
job, and then just walk away.

Your project will give birth to a new digital property that will
require care and feeding. And the integrator who planned,
designed, built, migrated, and launched it will end up
knowing more about it than anyone else. Including you.

This means that these relationships will linger. You will

likely be involved with this other firm for several years. If
the relationship ends early, it’s usually a sign that something
went wrong.

Therefore, just like hiring for a small services firm, you need
to pick carefully.

What Are You Looking For?

The first question you need to answer is what, specifically,
you need an external firm to help you with. You’ve already
got an idea as to what your team can handle, so what we’ll
focus on here is what you need to hire out – and how to
select that firm.

The standard full-stack project is essentially made up of

dozens of different, overlapping sub-projects — like a big
menu or buffet:

• A planning project to define audiences, outcomes, goals,

and content
• A User Experience (UX) project to wireframe the basic
user interface (UI) and plan the users’ interaction with it
• A design project to incorporate your branding and
marketing collateral and apply them to the UX
• A technical consulting project to plan how the required
functionality will be delivered by a technology stack
• A development project to configure a CMS and
programming framework to deliver the required
 functionality
• A migration project to move your current content from
your old CMS to your new one
• A content creation project to generate new text and
media for content that didn’t exist before
• An infrastructure consulting project to plan and set up
the hosting environment and required technology
• An ongoing support project to respond to and repair
website problems
• And, finally, an overall project management … project, to
make sure all these pieces are coordinated, delivered on
schedule, and within budget.

Understand that you absolutely can contract the “full scope”

of your website project to other firms and go completely
hands off. Thousands of companies are standing by,
available to run the entire project for you. The pro to this
approach is all you need to do is stay relatively engaged,
provide feedback, advocate for your vision, and reap the
rewards when the site launches.

There are also a few related disciplines that rise above a

single digital property:
• Experience: this is the entire experience of
interacting with all of your company’s digital
channels, including your website, your social media
platforms, your email strategy, how they all interact
together, how customers transit between them, and
how you track them doing that.
• Inbound Marketing: this is how people find out about
 your organization and get to your website or other
digital channels to experience any of the above. So,
this is based mainly on content appearing in other
places.
• Governance: this is how all the members of the digital
team work together to deliver all of the above, and
how you manage the care and feeding of your
ongoing project inside your organization.

We’re not going to talk about these, but be aware that

they’re things that get contracted out all the time too.

The cons are that this is a bit more expensive, and you are
delegating a lot of responsibility, power, and accountability
to another company.

Instead, we often see a mix of partnerships. While there are

companies that do all of the above, perhaps they’re not the
company to hire for a particular aspect of it.

For example, let’s say you love the design work of a

particular company, but they don’t work with the CMS you
want. The CMS vendor has recommended a partner, but
they don’t do migration work. And neither of them handle
copywriting or content creation. Also, the integrator will
host the site, but your internal IT policies require 24/7
network monitoring, and they don’t do that, but they know a
company that specializes in this sort of thing … and so on.

If you can get everything in a single company and can afford

the price tag, then good for you. But if you can’t, then you’ll
need to find multiple companies, each providing a piece of
the puzzle. And you’ll need to either ride herd over all of
them as the general project manager, or structure the
agreements so that smaller contractors work for some of the
larger contractors who agree to be accountable for their
performance.

A Key Question: What Does Your Post-

Launch Staffing Look Like?
When considering the service provider landscape, it’s critical
to think about your post-launch environment, meaning:

• Who is going to host the website?

• Who is going to respond to problems?
• Who is going to work on continued development,
strategy, and design?

We tend to look at launch day as the finish line, but it’s really
the starting line. From this point forward, you need to care
for and develop this thing you created.

Some questions to consider and get answered:

• Will your organization control your own creative and

development teams? How hard will it be to schedule
updates?
• Will you have a budget for an external development or
creative team? Is this just an allocated sum of money (a
“slush fund”), or will you require every piece of work
individually scoped and approved?
• Will you have a technical resource available to respond to
website issues? What is their support coverage – 24/7, or
only during business hours? If you can’t reach your
primary contact, do you have an escalation path?
• How many separate firms are going to be involved in
 support? Who is going to manage the interactions
between them?
• Are you technically competent enough to diagnose
website issues and understand who is the correct provider
to respond?

For further illustration, put yourself in these two somewhat

opposite scenarios:

• A large planned project: The company is branching out

into a new service area. They need a new section of the
website created in thirty days. It requires a unique design,
specific new functionality, and ten to twenty new pages,
totaling about 2,000 new words of content with associated
media.
• A critical emergency: The website is down. Every page is
displaying an error about a “SQL timeout,” whatever that
means. A developer you know says this is a server
problem. But the hosting company says everything on
their end is fine – that the website was programmed
wrong. Your phone rings. It’s the CEO.

Can your team handle these situations? Or will you need

external help with either one? Your answers will dictate your
relationship with your providers after launch.

Does Industry Experience Matter?

This question comes up a lot. Everyone wants to hire
someone who has worked in their industry before. You see
the same questions on RFPs all the time: “What other
projects have you completed in [insert industry here]?”

But is this relevant?

The answer – predictably, and probably frustratingly – is
sometimes. It can help, but not as often as you think. In fact,
demanding industry experience can be counterproductive
and cause you to reject companies that might have done a
lovely job for you.

The key question is: what aspects of a specific task would

benefit from industry experience?

Let’s say we work for a regional bank, and we need to hire

someone to do a full website rebuild. Let’s break down our
project by the list of subprojects from above, examine each
one, and consider if having completed similar projects in the
banking industry would benefit this particular project.

• Planning: Yes. A discovery project clearly benefits from a

deep understanding of visitors and their needs. A
strategist who has done this for your industry before has
an existing reservoir of experience and data to work from.
• UX: Maybe. A similar project might have some interaction
patterns that are similar, and perhaps some functional
elements that would appear often (financial calculators,
for example).
• Design: Probably not. Good design is good design. I
suppose someone could claim to specialize in the colors
and shapes that appeal to banking customers, but that
seems pretty esoteric. And you’d probably end up with a
website that looks like all your competitors’ websites. With
design, fresh perspective often helps.
• Technical Consulting: Maybe. There might be some
technical aspects to a banking website that would appear
again and again, but this seems like a small advantage. Any
competent technical architect could probably adapt to
this.
• Development: Probably not. As above, there might be
some technical challenges that cross over, but what’s far
more important here is experience in the CMS platform.
If there are specific industry angles to an aspect of the
project, the issues would likely have been examined and
translated into standard development tasks during
technical consulting.
• Migration: No. Content is basically content.
• Content Creation: Yes. This is a core marketing function
that is helped by industry and visitor experience.
• Infrastructure Consulting: Not really. There are some
industries that are more stringent about security, but
“high security” is a general concept that any provider
could be familiar with. Any differential benefit of
experience would be limited.
• Ongoing Support: No. Like development, it’s far more
important that the provider understands the CMS and
hosting environment.
• Project Management: No. Web project management is
basically the same across industries. Banks manage these
projects the same way as everyone else.

While there’s always the benefit of having some experience in a specific field or industry
when embarking on a new project, domain knowledge should not preclude deeper
organizational research. Hiring someone because they have experience in education over
someone who has proven to do better work despite a lack of experience in that vertical
misses the point of research: to uncover and move past assumptions.

— Corey Vilhauer

As you look through that list, note that there are a few
absolutes – some planning and content creation – and lots of
waffling. When we waffle, we’re basically saying this:
“Industry experience might be helpful here, but it shouldn’t
be the only consideration and can be easily outweighed by
other factors.”

In those situations, if you’re a little more comfortable with

Company A than Company B, but Company B is claiming
“industry experience!” then ask yourself if the benefit of
their experience for the specific task they are doing for you
matters enough to overcome your preference. For some
disciplines, maybe it does. For others, it won’t, and you
shouldn’t let industry experience act as a mirage that pulls
you forward into a bad decision.

So … What Does Matter?

What you’re looking for with an implementation partner is
broad-based, long-term compatibility. This means it’s hard
to generalize since the right partner is specific to your
project and your implementation.

While we can’t generalize, we can present the following Q&A

of various vendor questions. Note that no single point
(except maybe the very last one, as noted) should be an
absolute deal-breaker. Each company will have a couple less-
than-ideal answers. You need to take them all into
consideration.

General Fit
• How closely does their typical project match yours?
Content management projects come in all shapes and
sizes – a body of technical documentation is not the same
 as a campaign microsite. Make sure they have at least some
experience in the general type of content management
you’re planning.
• Where does your project fit in terms of size – are you at
the top range of what they do, or are you far smaller than
the typical project? Neither situation is great. You don’t
want to be so big that you overwhelm them, but you also
don’t want to be their smallest client, fighting for
attention. You’re looking for somewhere in the upper
middle range – big enough to be important to them, but
not so big they can’t handle you.
• How much experience do they have with the specific
CMS and technology stack you’re considering? There’s
some chance you’re only talking to them because they
know your CMS, which is great. But if this isn’t the case,
you need to nail them down on their level of experience.
A modern, enterprise CMS is complicated enough that
you don’t want to be their first project with it.101
• How long have they been in business, and what’s their
total headcount and turnover? You’re trying to gauge
general stability, to make sure they’re going to stick
around. You can also ask for financial statements, but
don’t do this unless you actually intend to examine them.
Would you even know which numbers signify what’s
healthy or unhealthy?102
• How are projects invoiced, and is payment based on
milestones or accrued hours? Know that what the partner
wants more than anything here is predictability. They’re
looking for a way to know how much they can expect
from you every month.

Production
• What is their development methodology?103 Dozens of
different methodologies exist. Simply put, make sure they
have some process. You don’t want step two in their
methodology to be “… and then a miracle occurs.” Ask
yourself if it sounds clear, reasonable, and repeatable, or if
it sounds like they just made it up on the spot.
• Will you get a dedicated resource or team, or will you
have a partial resource who is working on other things?
The latter option isn’t necessarily wrong. At times your
project won’t be in active development, or specific team
members won’t have anything to do for you, so they’re
obviously going to work on something else. But know
where you stack up in someone’s daily responsibilities.
• At what points in the project are you expected to do
something? You need to figure this out in advance to
manage your own staffing. You don’t want to be caught
flat-footed, because having the project grind to a stop can
be devastating, especially if it drags on so long that your
partner re-tasks some of your production team.
• Who is your point-of-contact on the partner side, and
how much access do you have to the production team?
Ideally, you want a single point-of-contact. But at the
same time, you don’t want to be forcibly prevented from
contacting the people doing the work. A direct
conversation goes a long way sometimes.
• Will the partner keep the work in-house, or are they
sending it off-shore? I’m not indicting the off-shore
approach, but investigate the model behind that. Is the
off-shore team employed by the partner or
subcontracted, and will the partner take absolute
responsibility for their work?
Quality
• How do you signal acceptance of a deliverable or
milestone? Will you agree in a meeting, or will you
formally certify a deliverable? If you’re certifying a
deliverable, know that you might be sacrificing your
rights to complain about something later. If this is the
case, then make sure you have some process to make
absolutely sure that deliverable is ready to go.
• What is the partner’s QA process, and what do they
expect from you? Many different processes exist, so it’s
hard to say one is better than another. Just evaluate their
answer to make sure they have some process. If they look
like a deer in headlights when you ask this, then plan on
doing your own QA.
• If you’re not happy, what is your escalation path? Ideally,
you would rate at least a short conversation with someone
at the C-level before you sign-on. If something goes
wrong, you need to know how you climb that tree and talk
to someone who can take action.

Support
• What is their normal scope of customer relationship,
and what happens after launch? They may hand you off.
They may continue working with you. Neither option is
wrong, but make sure that your expectation matches
theirs.
• How does follow-on work get handled? They may want a
retainer worth a set of hours, or they may scope each
feature or project. What’s right here depends on how
much work you expect to continue to do with them over
time. If you’re going to have an active, ongoing
 relationship, seek some kind of standing retainer – you
can often get a better deal on hours and priority
scheduling.
• To what extent are they available for support? Not a lot
of shops offer 24/7 support. This usually comes from a
hosting provider, but your hosting company might tell
you that your implementation partner did something
wrong. What happens then?
• Do they offer a warranty, and how long is it? A warranty
might be one week, or one month, or one year. Don’t
expect the latter, because partners have to put some
boundary around support, but just find out what that is.
• What’s the intellectual property (IP) status of what they
do for you? At Blend, we’re sticklers for making sure you
can walk away when you want to. We absolutely will not
advise you to engage with a company that would maintain
any IP control over your project. Make sure that if you cut
ties, you get everything you need to restart with someone
else.104

Staffing and Schedule

The following questions are common, but understand that
they’re often difficult for providers to answer with
absolutely certainty.

• Who is going to work on my project? Who the provider

assigns to your project depends highly on schedule. They
can’t just have a stable of people sitting around doing
nothing waiting for your project to start. And aspects of
your project that get defined midstream might change
who staffs it. Clearly, you want to make sure you’re not
getting “the B team,” but asking for iron-clad staffing
 commitments for a project that doesn’t even exist on their
production calendar is only possible if you will be the
largest project they have going and they’re willing to clear
the calendar for you.
• When will my project be finished? The only answer here
can be given in relative terms, because this necessarily
depends on when it starts and what the final scope of work
looks like. The provider might answer, “This is an eight to
ten week project.” So, it’s done eight to ten weeks after it
starts, whenever that is. If they give you a date, and then
you delay on making a decision, expect that date to slip.
Additionally, like staffing, things might come up during
the project that change its course and cause the date to
slip. This makes exact commitments tough and
inadvisable.

References
Asking for references is a common thing, but the value is
highly questionable. We find it hard to recommend it as a
research method.

Here’s the thing: no one is going to refer you to someone who

will give them a bad reference.

All the names you get will know in advance they’re being
used as references. You’re not going to catch anyone off-
guard or unprepared. The company might even kick them
back something to the reference in exchange for the
favor.105 Any reference given to you is probably not the first
time they’ve done this.

The company you’re considering might have this down to a

science. Every experienced company has a “stable” of
references they can use when they need to. Larger
companies might have someone in marketing who is
formally responsible for cultivating, maintaining, and even
coaching references.

We’re not saying to ignore references completely, but keep

them in perspective. You’re not going to get a reference that
tells you to run away. Most references will be
overwhelmingly positive. If you’re lucky, you’ll get someone
who gives you some honest candor and cracks the door on
something south of perfection. Listen to those people.

Take everyone else with a grain of salt.

Pricing
The most important thing to understand with pricing is that
it varies greatly in degrees of “firm-ness.” Consider these two
extremes:

1. “We will charge you $150/hour. We’ll just keep working

on your cool idea until it’s done or until you run out of
money.”
2. “We will charge you $73,742.13 for exactly your
requirements listed in this 183-page Word document that
has 87 footnotes.”

Everyone is going to want the latter, because everyone loves

specific numbers that are set in stone. But what they don’t
understand is that when someone is trading you $X for Y
result, then you need to be in absolute agreement on what Y
is.

If you’ve nailed your requirements down clearly, so you can

say with certainty that you have described exactly what you
want, then you can expect a firm number in exchange. But
there are two problems here:

• Defining your requirements is a process in itself. It takes

time, which you may not want to wait for. Additionally,
whomever is doing it for you will probably want to get
paid for it. They might do a simple statement of work for
no charge to speed the project along, but they’re not going
to deliver exact technical specifications unless someone
pays them.
• Even if you think you’ve nailed down your requirements,
edge cases exist, and interpretations and
misunderstandings come up, where one side genuinely
believed one thing and the other side genuinely believed
another thing. The only unassailable requirement is a
running, implemented system that everyone can use and
say, “Yes, this is what we want.” Sadly, you’re attempting
to get a price to build this system, so it isn’t helpful.

The only practical advice here is to understand that the

number you get will be roughly as firm as your
requirements. If you’re vague on what you want, then they’ll
be vague on how much it will cost. Expect either a wide cost
range, lots of rigid assumptions on their side that you’re
expected to agree with, or “escape” clauses that allow them to
re-scope if things get complicated.

In reality, this is never perfect. You’ll come up with some

firm-ish idea of what you want, and they’ll come up with
some firm-ish number. For any large project, you’ll have a
few disagreements about requirement scope, which is to be
expected.

The ability for you to work through disagreements is

directly proportional to the long-term relational upside for
the partner. If they think they can have a long-term,
profitable relationship with you, and you think you can work
with them for an equally long time, then you’ll both usually
meet in the middle or otherwise figure it out.106

The Myth of the Hourly Rate

Lots of people will fixate on hourly rates, thinking that a
lower hourly rate is better. This is a myth.

If someone consistently takes twice as long to do something

as they should, then their hourly rate is effectively twice as
much as they quoted.

To accurately gauge hourly rate, you need to account for the

following variables:

• How efficient are they? How long does it take to get

something done?
• How good is the result of what they do? Do they have to
fix stuff every time?
• Are they even doing the right things? Many times you’ll
depend on your implementation partner for advice. Are
they giving you good advice or wasting time on bad ideas?

These three variables can swing so widely between two

contractors that it’s basically impossible to consider hourly
rates in isolation. The best you can do is look back at a
period of time, evaluate what was accomplished compared
to what you paid, and ask yourself if you thought it was
worth it.

A Team to Make Things Real

Finding a service provider is a tricky thing. You need to walk
a line between competence, affordability, and culture fit. But
for some projects, this is unquestionably the most important
decision. It’s a foundation on which everything else will be
built.

Your partner will directly impact your projects in countless

ways. They’ll guide you on how to communicate to your
audience, they might help you select technology platforms,
they’ll have a large impact on the schedule of when things
get done, and they’ll advise you on the most foundational of
questions: what is possible, and what isn’t.

More than anything, the key is trust and rapport. Before

making any decisions, ask yourself if you trust this firm with
your project, and if they’re a group of people you want to
work with for a long period of time.

There will absolutely be moments when problems come up

and the relationship strains. If you have a basis of trust and
connection with the other side, you have a much better
chance of working through the issues and moving forward.

Inputs and Outputs

The input to this process is a site plan, much like the one
you used when evaluating CMS vendors, that helps you
understand the team you need to supplement. The outcome
is a selected implementation partner, with an executed
agreement.

The Big Picture

Clearly, you need this before the site development can start.
But to get this, you need to know quite a few things about
project scope – you can’t expect a price unless you know
what you want done. So you need to be far enough along
that you can confidently provide a scope of work.

Staffing
The evaluation of a partner needs to be done by the entire
core project team, perhaps assisted by someone in legal or
finance. There’s going to be a contract involved at some
point, and that will need to be evaluated.

100 Deane co-founded it. And Corey still works there, for the record.
101 Place no value on the number of developers they have “certified” in the CMS. Lots of
certifications are absurdly easy to get and signify absolutely nothing.
102 Don’t bother asking for “audited” financial statements. Unless the company is publicly held
(not likely), it’s not getting financial records audited.
103 Spoiler: expect to hear the word “agile” a lot.
104 Watch out for shared code libraries. Development teams will often put common code in
reusable libraries. References to these libraries might be liberally scattered throughout your project,
and they’re loathe to hand them over.
105 We suspect a lot of Starbucks gift cards get emailed around in situations like this.
106 And don’t think an ironclad, punitive contract will protect you. If you ever have to lawyer up,
then you’ve already lost.
CHAPTER 19

Implement the Design

SUMMARY
To take visual design and turn it into a fully functional (and
responsive) web design is a mix of programming, math, and
human interaction.

DOES THIS APPLY?

This will affect you. Every website comes down HTML being
loaded into a browser and interacting with other resources
like CSS and JavaScript. You might not write this code
yourself, but there are dozens of factors that a developer is
going to juggle to make this work, and you should
understand what these pressures and influences are, along
with the basic tools of the trade.

The need to take something from plan to implementation is

a universal challenge in any creative work. A sculptor has a
scale model to work from. A builder has a blueprint. A
portrait artist has a subject.

The plan – whatever that might be – is in a different

medium than the material or environment the final product
is actually created in. In many cases, it was developed in a
controlled environment, not at all like the reality of final
construction.

An architect generated that blueprint in the safe, quiet

confines of their office; the builder, on the other hand, is the
person standing out in a field in a South Dakota winter,
looking at a piece of paper, comparing to a pile of building
materials on the frozen ground, and hoping that the final
product matches the plan. Such is the life of a creator.

This entire book has been an exercise in moving from

theory to reality. This story started with you just thinking
about your goals and dreams. From there, you slowly
refined the idea, resolving questions and issues, getting a
little more concrete with each round of changes and
considerations. You went from audience needs to rough
sketches to now – a design, ready to be implemented.

You’ve finally arrived. We’re ready to build something.

Some time ago, you got a design from someone. This isn’t a
web page – it was probably a file from a design application
like Adobe Photoshop or Figma.107 This is a representation
of what a web page should look like. It’s really just a theory.
Now, you need to implement that design, which means
turning it into a functional web page that can load into a
browser and perform in all the ways we expect from a web
page.

Clearly, we’re not going to teach you how to code. But we

are going to introduce you to some coding concepts so you’ll
have an understanding of what goes into it and what to look
for when you get to this point in the project.

Front-Ends and Back-Ends

In the early days of the web, there was only one kind of
developer: a web developer. They did it all. They were
responsible for configuring the content management
system, writing the code that ran on the server, and writing
everything that displayed the results. They worked with the
full stack of technologies.

Over the years, this “Swiss Army knife developer” has

bifurcated. As the Internet grew and matured, the possible
combinations of technologies available to build a website has
simply grown to an unmanageable level. There are vastly
more languages, technologies, and frameworks, and more
seem to pop up every day.

These technologies exist on a spectrum with two ends: glass

and sand.

• The glass is the screen our users stare into; a monitor or a

mobile device. A technology that’s “close to the glass” is
something the user directly perceives or interacts with.
• The sand is the silicon in computer processors. A
technology that’s “close to the sand” is a programming
function, primarily concerned with execution by the
server’s processor.

Different technologies line up in different virtual distances

from where the user interacts with them. The page loaded
into their browser is the most immediate, direct technology
that affects what they perceive, while the operating system
on the server thousands of miles away is the most distant
and indirect.

If we stack up our technologies from glass to sand, it looks

something like this. (We’ll focus on some of these definitions
later in this chapter):

• HTML
• CSS Framework
• (Raw) CSS
• JavaScript Framework
• (Raw) JavaScript
• Network Infrastructure
• Content Management System (CMS)
• Programming Language
• Database
• Server Operating System

This corresponds to what we call front-end and back-end.

Technologies considered to be on the front-end are those
that are close to the glass – HTML through Javascript. Back-
end technologies are close to the sand.

To complicate this a bit further, front-end and back-end

are also sometimes known as client-side and server-side.
The browser is considered a client of the server. So
working on the client-side means all the technologies
that happen in the browser – HTML, CSS, and
JavaScript. Working on the server-side means all the
technologies that happen on the server.
The dividing line is the point when the response leaves the
web server. When the server has read or created something
like a “page” and shipped it out the door to the browser, the
responsibilities of the back-end developer are done. When
the document arrives in the browser, the front-end
developer’s job takes over, and continues until the document
is unloaded from the browser (usually by being replaced by
another document).

Specializations
Because both sides of the front-end/back-end dichotomy
have become more complex, developers have come to
identify and specialize with one of the other. Somewhere in
the last ten years, most web developers made a career choice
as to whether they wanted to work on the front-end or the
back-end, and new developers make this same choice today:
do they want to work with front-end, presentation-level
code, or back-end, processing level code?108

Most professional services firms of any significant size will

employ both roles. A team will have back-end developers
well-versed in the CMS and the associated programming
language. Their job is to manage the processing of data on
the server and provide this data in the correct format for the
front-end developers to morph it into the visual
representation required for the project.

And what happened to the “full stack developer?” There are

developers who are still claiming mastery of the full stack,
but it usually comes with caveats. They usually know a
specific JavaScript and CSS framework, a specific CMS, a
specific server-side programming language, etc. They know
a full stack, but that stack is comprised of a specific
combination of things – call it their full stack.

Standards
Finally, there’s something to note about our stack list above:
we get less specific from front to back. On the front-end, we
have three specific, named technologies: HTML, CSS, and
JavaScript. Moving backwards from there, we can only deal
in generalities: a CMS, a programming language, etc.

This is because the technologies that are close to the glass

have a common execution environment: the web browser.
The developer doesn’t control the browser – their code is
merely visiting while their web page is loaded. A developer’s
relationship with a browser is temporary. This being the
case, the governing authority of the web had to settle on a
common standard of technologies for browsers to support.
Thus, we can name those explicitly and expect that anyone
working on the front-end will know HTML, CSS, and
JavaScript.

But there is no governing authority for what happens behind

the scenes. A web page can be created and served from any
kind of CMS running any kind of database and any
language. The server environment is controlled and known
– we own this, remember – so it can execute any
combination of technologies. We could invent our own
programming language and use it to generate web pages, if
we wanted, and no one would know the difference. Thus,
back-end technologies exist on a much wider range than
those on the front end. Their only requirement: deliver
results in the common languages of the browser.
The Toolbox: HTML, CSS, JavaScript,
and Frameworks
The tools of the front-end developer are the top five from
our list above: HTML, a CSS framework, CSS itself, a
JavaScript framework, and JavaScript itself. Every front-end
developer will know HTML, CSS, and JavaScript, and they
likely have a preferred CSS and JavaScript framework that
are commonly used.

(As we explain this, we’re going to show you some code.

Don’t panic. It’s merely illustrative of concepts, and you
don’t have to understand it completely to get the main idea.)

Hypertext Markup Language (HTML)

“Hypertext” is a term coined in 1965 by scientist Ted Nelson
when he was a professor at Vassar. Nelson conceived it as
text which could reference other text, and which you could
activate to reveal other documents.109

HTML is a text format that embeds formatting and other

presentation information inside text. HTML is the basic
format of every web page.

An HTML document consists of text interspersed with

“tags,” which are represented and recognized by opening
and closing brackets. HTML tags perform different
functions. Tags surround text, and impose different
functional and visual characteristics to that text. An opening
and closing tag with its contents is known as an element.

This is some text. <strong>This text will be bold.</strong>

In the example above, the strong tag is opened and closed,
and contains a sentence. That sentence is given special
formatting or functionality based on the surrounding tags –
it would be rendered in boldface, in this example.

The opening tag might have constructs called attributes

which supply additional information.

<h1 class=”title”>This is the title</h1>

In that example, the h1 tag denotes a “Heading, Level 1.” This

imparts some default formatting (large, bold) and some
structural designation (the most important headline on the
page), and the class attribute gives it a referable name so that
we can find it again later with CSS and JavaScript.

Tags can nest inside each other – so an entire element can be

contained within another element. In fact, all the HTML
should be contained inside a “master tag” of HTML that opens
at the beginning of the text and closes at the end.

This entire string of text is known as a document. This is what

your browser loads and interprets.

HTML is the most basic technology of the web. It forms the

backbone and structure of every browser-based experience.

Cascading Style Sheets (CSS)

HTML tags can impart style information to text (like the
bold example above). However, it’s considered bad form to
embed too much styling into HTML because it can be
difficult to sort through, and a lot of it ends up being
duplicated from document to document. By separating the
style information from the HTML, you can manage the
visual appearance of your documents much more
efficiently.

This separation of styles from HTML led to “CSS,” or

Cascading Style Sheets. CSS is a language that recognizes
certain elements of HTML and applies a style to those
elements — styles like color, font weight, spacing, and
alignment. CSS is not part of the HTML, which makes it easier
to manage. Essentially, it’s a kind of color-by-number – the
tags within the HTML designate document-wide styles in
CSS.

Referring to our HTML example above, let’s say that we

wanted to color all bolded text red, for whatever reason.

strong {

color: red;

That example will color red any text inside a strong tag
element.

If the weird spacing of CSS – with its orphan closing brackets and its line breaks – seems
difficult to read, understand that an entire stylesheet of these can become a pretty big chunk
of random characters without some kind of logical whitespace and breaks. It looks weird
called out on its own, but it’s much more readable in practice.

— Corey Vilhauer

The specification of an element and the associated style

information is called a rule. We can put that CSS in a
separate file – called a stylesheet – and link it to our HTML.
In fact, the same stylesheet can serve multiple HTML files —
100,000 different HTML files could look to a single CSS
stylesheet to help determine link color, or standard image
widths.

This is notable, because it allows for wide sweeping style and

design changes without the need for massive rework. For
example, if we wanted to change all of our bolded text styled
in the example above to, say, blue, we can change the code in
our single stylesheet and the appearance of all HTML linked to
it will change.

What’s more, we can combine and nest those rules to be

more specific. We can say that all links are blue, but we can
then further adjust this so that all links in a list are black, or
that all links in a specific block are left-aligned.

CSS is technically optional – every browser has a set of

default styles that get applied to different elements – but has
become the fundamental method of styling a web page.
Almost every single HTML document will be linked to an
associated stylesheet that provides visual formatting, and
many websites will have a single stylesheet to which every
document is linked.

JavaScript
So far, HTML and CSS have simply allowed for the creation
and visual styling of our documents. They are technically
not programming languages. They allow for many quasi-
programming concepts, but they don’t have full support for
complete logical programming110 – things like variables,
looping, and conditional statements. That’s where JavaScript
comes in.

JavaScript is the programming language that executes in the

browser, in the context of an HTML document.

JavaScript has nothing to do with Java, another

programming language. In fact, it was originally called
LiveScript. However, when it was invented in the late
90s, we were embedding small Java programs in web
pages, which were called Java applets. LiveScript was
viewed as a simpler alternative to a full Java applet, so
the name was changed to reflect that perception.

Java applets, thankfully, are not a thing we do anymore –

they were complicated to write, slow to execute, and
provided an incongruous user experience. Over the
years, JavaScript has matured to provide all the
functionality we need.

Using JavaScript, we can manipulate our HTML document

in real-time, while the user is looking at it.

For example:

var node = document.getElementById(“title”); node.parentNode.

removeChild(node);

To you, that probably means nothing. But to a browser, that

is a small request to find an HTML element identified by the
name “title” and delete it. It would disappear from the visual
display of the document, in real-time. This code might
execute in response to someone pushing a button, for
example.

JavaScript typically works to adjust what’s called the

Document Object Model (DOM). The DOM is the digital
representation of a web page – all the elements, ordered and
nested as they appeared in the HTML from which the
document was loaded. To “manipulate the DOM” is to do
things like in our example – add, delete, change, or
otherwise fiddle around with elements of the DOM.

Figure 19.1: HTML documents provide structure, but are further transformed through the addition of
style elements (CSS) and manipulation (JavaScript).

JavaScript began as a lightweight programming language

meant for simple document actions. However, in the two
decades since it was invented, it has become an enormously
popular language, and has advanced to the point where an
HTML document might simply be a shell designed to load
and execute a complicated JavaScript program.111
CSS and JavaScript Frameworks
CSS and JavaScript have become so indispensable that
frameworks of pre-written code have developed around
them to accomplish common tasks. Some frameworks are
simple and designed merely to assist, while other
frameworks are large libraries of code with associated
philosophies and methodologies around their use.

The largest frameworks are so widely known that many

front-end developers use them as a default for every new
project. In fact, some developers might struggle to write
code without them.

Some examples:

• Bootstrap is a CSS framework designed by Twitter. It

provides CSS that automatically attaches itself to HTML
elements with specific attributes and handles such rote
tasks and rendering them as columns which adapt to
different screen sizes.
• React is a JavaScript framework designed by Facebook. It
allows a front-end developer to create complicated HTML
structures in JavaScript code and makes them easier to
manipulate when building complex applications.
• JQuery is a JavaScript framework with associated CSS that
eases many visual tasks like making elements appear,
disappear, and animate.

Some frameworks are so widely used that they spawn sub-

frameworks or plugins. A front-end developer might use
React and a dozen React extensions to change how it
functions.
Templating and Design Components
HTML documents don’t normally exist as actual files
anywhere. They’re usually assembled from fragments of
HTML. You can envision it as a library of separate pieces
that are mixed and matched to form a document.

Every website repeats a lot of stuff, visually. The only

website that would have an entirely new and different layout
on every page would almost have to be an art project of
some kind. If you compare one page on a website to another,
they might only differ by a heading, some images, and a few
paragraphs of text.

Even when the actual content differs, the structure is the

same. Consider an image carousel or rotator on the home
page. Every frame or slide of that has the same basic
structure – image, headline, maybe a few sentences of
supporting text, and a link somewhere. The slide itself is a
common structure, just with different content injected into
it.

Therefore, one task of a front-end developer is to determine

what the repeatable elements of the design are. The
developer will view the entire design, note what elements
repeat, and figure out how to draw those out into reusable
libraries of code, called design components.112
Figure 19.2: A standard page template that includes a header, footer, main content, and navigation
areas.
A goal of components is consistency and efficiency. You
want this to look the same on every page, and you don’t
want to re-code it every time. By identifying things like this
as repeatable components, the front-end developer can
employ techniques to “lift them out” of specific documents,
maintain them separately, then “inject” them into
documents that need them.

This idea of components is a key construct of what Brad Frost calls “atomic design,” in which
design is broken into things like atoms and molecules. This makes for a more consistent
overall site design – you’re reusing every element in a way that promotes consistency – and
it also leads to more maintainable and cleaner front-end code, as developers are no longer
custom coding every instance of a button or link.

— Corey Vilhauer

This assembling of documents from HTML fragments is a

function of templating. Here are a few different ways this
happens:

• Server-Side Includes: Some tags or tag-like structures

can be detected by the server when it’s reading the file to
send the response. The server can replace those tags with
the contents of other files. Thus, your header component
could exist in its own file, and be injected into every
document at the instant it’s being returned from the
server. If it needs to change, it can be changed in a single
file.
• Server-Side Rendering Languages: Some full
programming and templating languages exist that allow
logical, procedural computer code to be interspersed with
HTML. When the document is requested, this code is
executed. It generates or hides HTML constructs in the
document, meaning the document “writes itself” at the
 moment of response.
• Client-side Templating: Using JavaScript frameworks
like React, design components can be created in the
browser, and they can populate the content around
themselves by making special requests to the server.

In all the cases above, the HTML document that finally

displays in the browser doesn’t actually exist as a single file
somewhere. It’s assembled from a series of design
components, either on the server or in the browser. This
rendering does two things:

1. Generates HTML tags and elements

2. Injects dynamic content into that HTML, often from the
content management system

If this is done on the server, a full HTML document is

delivered to the browser, and all the theatrics that happened
on the server are hidden.

If it happens in the browser, the document is essentially a

small computer program written in JavaScript that executes
in the browser to create a new version of itself by
manipulating the DOM.

Balancing Front-End and Back-End

We’d like to say that we can totally encapsulate the front-end
development to a single role, but in reality, your project will
likely start proceeding along several tracks in parallel here.

Additionally, the role that actually does the front-end

development is not a simple answer. Roles and lines will
start to get blurry.
Here are a few common scenarios:

• Strictly defined: A front-end developer will code all the

HTML, CSS, and JavaScript as a set of HTML documents,
then hand them off to a back-end developer who converts
them into templates in the CMS. This can be inefficient
because the back-end developer has to translate what the
front-end developer has done. And if a change is needed,
the front-end developer has to change their files, and this
has to be translated again.
• Back-end helps with front-end: A back-end developer
will do the templating in the CMS to generate basic,
generic HTML. The front-end developer will write CSS
(“apply styles”) and JavaScript against this HTML, asking
for changes to the HTML when needed. In this case, some
of the front-end development (the HTML) is handled by
the back-end developer, but this can work since the
HTML is often non-debatable, and a development team
might have conventions to ensure the front-end
developer gets the HTML they expect.
• Front-end helps with back-end: A front-end developer
might be able to template in the CMS directly so they can
generate their own HTML. This is very efficient, but some
CMSs make it difficult because the templating can’t be
separated from the rest of the code.
• Front-end goes it alone: A front-end developer might do
client-side templating in a JavaScript framework like
React or Vue. In this case, they don’t need any server-side
HTML. Rather, they make requests to special URLs on the
server that provide content as pure data which they
render to the screen using JavaScript to manipulate the
DOM. In this scenario, the back-end developer just needs
to make sure the server is returning the correct data.
• Full stack: A full-stack developer might do everything.
This could be both efficient and inefficient – efficient
because there’s no communication or dependencies
required, but inefficient because one person can only do
one thing at a time, so your project would have to proceed
serially instead of in parallel. Once a project gets of a
certain size, it can be tough to expect a single person to do
everything.

Like we said, roles get a little blurry.

The examples above provide a helpful segue into the world

of DevOps, which is short for “development operations.”
This is the seemingly mundane but absolutely critical aspect
of a project where you figure out how people are going to
collaborate on the same code and software without getting in
each other’s way.

Regardless of how many people are coding a site, there is –

in essence – just one site. Which means there’s always a risk of
coordination issues: the output of all those people has to be
combined to form a single, cohesive project. If a front-end
developer is writing CSS and JavaScript, their code needs to
be combined with all the back-end code to be deployed to
the production environment.

Additionally, some developers might require the output of

other developers to do their jobs. If I’m a back-end
developer working on some aspect of integration, I might
need some of the templating code from a front-end
developer. And some other people on the team might need
my code to test or develop their stuff.

This combining of multiple code sources into a single thing

is known as building. The result of a particular combination
is called a build.
 Consider a book where each chapter was written by a
different author, in their own copy of Microsoft Word,
and having no contact with other authors. You now have
27 separate Word documents. Plus, it turns out your
authors are all hopped up on espresso and keep making
changes to their individual chapters every five minutes.
How do they get combined to form a single document
that can be printed?

Every time any chapter changes, it needs to be line-

checked for errors, and then reincorporated into the
final output. And understand that the chapters aren’t
wholly self-contained – each chapter will drive changes
in common resources of the book, like the table of
contents, the list of tables and figures, the index, and the
page count … which in turn controls the width of the
spine … which determines how the text on the spine will
wrap … and so on.

That’s the DevOps problem – combining multiple,

independent, volatile outputs to form an integrated
whole in a repeatable, predictable way with minimal
human effort.

Code generally works its way through multiple

environments before it finally gets deployed to the live,
public environment.

1. Developers will write code on their local workstation.

This means they usually have an entire copy of the
website running on their own computer. Often this
requires them to install the complete technology stack –
database, programming framework, CMS, etc.
2. When their code seems to be running okay, they will
submit it to a source code management (SCM) system,
like Git or Subversion. These are systems that keep source
code safe, and track all the different versions of it. Using
an SCM, you can see exactly what changed in code and
who changed it, which is helpful when trying to debug
something. Additionally, the SCM becomes the central
clearinghouse for code, from which developers will
download each other’s code to update their environments.
3. When code is submitted to an SCM, it will often trigger a
script which automatically builds and deploys it to an
integration environment – essentially, the working copy
of the site. Just by submitting new code, an entire build of
the website is deleted and rebuilt with the latest submitted
code from everyone on the team. This is a concept known
as continuous integration (CI) or continuous deployment (CD).
If you have lots of developers writing and submitting
code, your integration environment might get destroyed
and rebuilt dozens of times a day. Developers can submit
code, wait a minute for the build, then go check to make
sure all their stuff worked with everyone else’s stuff.
There also might be some automatic tests that run after
building to check for problems.113
4. Every once in a while, the integration environment is
copied to a test environment. This is where the QA team
will test all the features to make sure they work and often
where the client will review the work product. The test
environment is more stable than the integration
environment, because it’s changed much less often. You
might update the test environment from integration once
a week, so it stays relatively stable.
5. From test, code might be deployed to a staging or pre-
production environment for final testing. Some
organizations might have a battery of automatic tests that
 run in this environment, just to make sure no problems
slipped through.
6. From staging, code is deployed to the production
environment – the live environment – where it finally
sees the light of day.

Yes, code takes a long, winding road from the keyboard of a

developer to a place where customers actually interact with
it. This is often called a deployment pipeline or CI/CD pipeline.

What we’ve described above is appropriate for a larger

project with a larger team. A smaller project might be done
by a single developer, in which case they might only have
two steps: they write and test code on their local machine,
and they deploy it to production.

These are two ends of the spectrum, and your project lies
somewhere between them.
Figure 19.3: A representation of how multiple developers move code through different environments
toward the launched site.

One thing common to DevOps is files. Code is contained

in files, and files can be moved around easily. Most
 DevOps processes boil down to moving files from
system to system where they’re read and acted upon.
Some CMSs eschew the file, and insist on storing code
and configuration inside databases or other non-file data
sources, which can frustrate DevOps processes and the
developers who use them.

Front-End in Action
Now that our front-end code is live and interacting with the
world, what behaviors do we need to account for?

In addition to evaluating the design for components and

actually writing the code necessary to bring them to life,
your front-end developer is juggling other concerns and
responsibilities.

Browser Compatibility
There are lots of different browsers – Chrome, Firefox,
Edge, Internet Explorer, Opera, Brave, etc. – and they’re not
all equal. Occasionally, they do things a little bit differently –
they might render an element in an odd way or not support
some new-fangled features of HTML or CSS. For example,
some older layout options work on one browser, but are
completely left out of the code for other browsers.

HTML, CSS, and JavaScript are not static. They

constantly evolve and add features. As of this writing,
HTML is currently on version 5. CSS is technically on
version 2.1, but support for most of version 3 is
common. JavaScript conforms to a specification which is
 versioned by years – version 2019 roughly corresponds
to version 10.

This used to be very painful for developers, and there were

notorious browsers that front-end developers had to make
concessions for, sometimes to the point of coding entirely
separate stylesheets just for them (we’re looking right at you,
Internet Explorer 6.0). Today’s browsers, thankfully, support
a more common set of features and capabilities.114

When front-end developers test their code, they have to test

in a variety of browser platforms, including many different
versions of those platforms. Services even exist that will
retrieve your web pages in different browsers and versions
and then show a grid of images representing the result.

Remember from our discussion above that there’s one

server, but an infinite number of browsers, each with their
own quirks? A front-end developer has to find a happy
medium that works for all of them.

Responsive Web Design

Not only do we have zero control over user browsers, we
have zero control over the width of those browsers, which
means we cannot design to a rigid structure. We must be
responsive to the device being used.

Responsive web design enables a web page to change itself in

response to the browser environment in which it’s loaded,
primarily in relation to the size of the viewable area. A “full”
browser experience on a desktop is very different from the
tiny browser on a phone, and a web page can be developed
to adapt to these differences.
 We touched on this in Chapter 13: Develop the Graphic and Interface Design, but it’s worth
reiterating here: the idea of responsive web design is not to develop a unique design for each
individual breakpoint, but instead to thoughtfully and purposefully design a site for all
breakpoints. Design – and responsive development – serves the user by providing equal
access to content no matter the situation, whether that be small screen size, low bandwidth,
or some other restrictive element.

— Corey Vilhauer

This is accomplished mainly using a CSS tool called a media

query. Media queries allow a separate set of CSS rules to
apply only when the browser environment meets certain
requirements, such as the size of the viewable area.

For example, imagine a design in which all images will

appear on the right side of the screen, with text flowing
around them. To allow for a better view on a mobile device
(when the screen size falls below 500px), we may assign two
new CSS rules – we will center the image on the page, and
we will remove the text wrapping, as it will not work well on
a narrower browser window.

The 500 pixels designation in this example is known as a

breakpoint, meaning it’s a threshold where new rules apply –
a “breaking point” for the design to change. At what widths
your front-end developer sets the breakpoints is up for
debate, as is the number of breakpoints they respond to. You
can define as many breakpoints as you like.

img {

float: right;

@media screen and (max-device-width: 500px) { img {

 float: none; display: block; margin: auto;

Here are some examples of screen size and variability –

when the width of the browser rendering area falls below the
pixel width listed, the design might change for that
particular environment:

• 320px: Phone in portrait mode

• 480px: Phone in landscape mode
• 640px: Tablet in portrait mode
• 960px: Tablet in landscape mode
• 1280px: Standard full browser
• > 1280px: Wide screen

For many developers, that’s too many. It’s quite common

just to support three – phones, tablets, and full browsers. But
your situation depends on your visitors and the complexity
of your design.

Browser width is the most common usage consideration for

responsive design, but media queries can act on any number
of variables. You can respond to the resolution of the device
(when Apple’s hi-res “retina” displays were new, some sites
provided sharper images for browsers on those devices), the
available color palette, or even user preferences, such as if
they have a setting to reduce motion (common for some
users with vision or seizure disorders) or whether they want
a high-contrast color scheme.

Media queries have enabled web design to keep up with the

relentless pace of new devices, brought about mainly by the
revolution in mobile computing. When everyone viewed
web pages on a full computer monitor, it was relatively easy
for designers and developers to control that experience.
Today, they can’t control anything, they can only respond
and adapt to whatever environment they have.

Accessibility and General Usability

Of course, technology is not the only barrier – front-end
must also help facilitate the structure and functionality of
accessible websites for those who use assistive devices.

As a reminder, accessibility is a set of practices and coding

conventions that seek to provide equal access to the
information in a web page, regardless of physical or
cognitive abilities. For example:

• Some users have visibility issues, all the way up to total

blindness. These users might need higher contrast,
avoidance of certain color schemes, the ability to enlarge
text size, or well-structured HTML that makes sense when
it’s read aloud.
• Some users cannot use a mouse, and have to navigate a
web page by keyboard. The HTML needs to allow
intelligent tabbing from one element to another and the
option to skip over non-essential elements.
• Some users have seizure disorders that might be triggered
by certain movement or color changes.

Accessibility overlays a bit onto responsive design in that

browsers are now providing settings to allow users to specify
when they have accessibility needs, and CSS and JavaScript
can request this information and use it to modify the layout
and functioning of the page.

And, fittingly, accessibility overlays quite closely with

general usability. A web page that’s difficult for someone
with disabilities runs a very good chance of being difficult
for lots of other people too. Conversely, an accessible page is
likely also a very usable page overall.

Simply put: there is no one universal user. Every user exists

on a spectrum of physical and cognitive abilities, and we
can’t design pages solely for the most capable end of that
spectrum.

Performance
A lot of CSS and JavaScript will exist in separate files, and
these files will need to be linked to the HTML document
being rendered. In addition, all the images in a website likely
exist in separate files. In some cases, dozens or even
hundreds of supporting files might need to be downloaded
just to display a single page of content.

This requires multiple connections and download time.

These days, a web page is basically a computer program that
has to be downloaded and executed by every user.
Additionally, our HTML document might not be fully
functional right away. The document might display itself,
then, as different resources load, react to the information
those resources provide or the functionality they dictate.

What we’re saying is that there’s a lot going on, and this can
cause the website to slow down. To avoid dragging down
performance, there are a number of things a front-end
developer might do. They might combine separate CSS or
JavaScript files into a single file, or they might optimize
background or structural graphics to reduce file size.
The goal is to provide the desired experience with as few file
requests as possible, using the least number of bytes possible,
and causing the least amount of disruption as resources are
progressively loaded by the web page.

Striking a Balance
The role and responsibilities of front-end web developers
have changed enormously over the last decade. Front-end
code has transitioned from simple presentation into a full
execution and development environment. Some of the most
complicated code in your project might be in the
combination of HTML, CSS, and JavaScript that executes in
the user’s web browser.

Front-end developers have the additional challenge of

coping with a variable environment of different browser
brands and versions, screen sizes, capabilities, connection
speeds, and user abilities. Stability and predictability goes
out the window. Their code has to be flexible and
responsive, adapting to the environment.

It’s like trying to perform a ballet on the deck of a ship in a

hurricane while balancing a house of cards on your nose.
Consequently, front-end developers have moved from being
basically non-existent as a distinct role to being hugely in-
demand rock stars in the development world.

Front-end development is about concessions and striking a

balance between hundreds of different factors. Be flexible,
and understand that making things amazing for a small
percentage of users is less valuable than making something
beneficial for the overwhelming majority.
Inputs and Outputs
Before you can implement a design, you need one. The
output of this process should be a set of files that represent
the design in HTML, CSS, and JavaScript. Those files might
be standalone, awaiting conversion to back-end code by
another team (different development models were detailed
in this chapter). In other cases, the files have templating code
in them, or constitute an entire client-side application.

Either way, the output is code.

The Big Picture

By the time this happens, development is in full-swing. This
is one of the two big categories of development, the other
being the back-end, server-side development. Both of these
tasks can usually proceed together, in parallel, and they
often have to, as they inform and provide information to
one another.

Staffing
This job has to be done by a developer. In some cases, this
will be a dedicated front-end developer. Other times, a “full
stack” developer might be working on the entire project, or a
primarily back-end developer will do double-duty. Either
way, the person who does this needs to know the basic tools:
HTML, CSS, and JavaScript.

107 Often called a design comp which is short for “composition.”

108 That’s not to say a back-end developer knows nothing about front-end development, or
vice-versa. They can cross the line a bit. But the career tendency is towards specialization, and
most disciplines are split in terms of professional services.
109 However, the general concept can be traced back further to Vannevar Bush, an American
scientist who wrote an article called “As We May Think” for The Atlantic in 1945. In it, Bush
described something very similar to today’s web.
110 What makes something a “full” programming language is up for debate, but one standard is
known as Turing Completeness, named for British computer scientist Alan Turing.
111 JavaScript has also graduated out of the browser and onto the server. You can use JavaScript in
server environments to do anything. In fact, you can generate your web pages on the server using a
JavaScript framework called NodeJS.
112 Note that there’s really no standard term for the concept. We’ll use “design components” for
brevity and clarity, but different terms exist.
113 If your particular code submission causes the resulting build to fail these tests, it’s known as
“breaking the build” and is generally a source of ridicule and humiliation. You don’t want to be the
person who breaks the build.
114 In December 2018, Microsoft made the very un-Microsoft-like decision to abandon their own
HTML rendering engine and adopt the open-source Chromium project which is maintained by
Google. The first version of this new browser was released in January 2020. Front-end developers
rejoiced.
CHAPTER 20

Implement the Back-End

Functionality
SUMMARY
This is a deceptively simple step for what amounts to
actually building the inner workings of the website. You
need to examine site functionality, break it into manageable
iterations, and plan how it all will come together.

DOES THIS APPLY?

You’re almost always going to have to do this at some level,
but the depth depends on the system. Some systems will be
implemented from code and deployed via DevOps, and
other systems will be just configured from an interface.

The only time that there’s no backend implementation

required would be a highly pre-packaged system for a
known, controlled use case (a simple blog, for example).
If you want to build a house, you can visit your local
building supply superstore. They literally have everything
you need. They have lumber, plumbing, electrical wiring,
shingles, windows, and doors. They have hammers. They
have toilets.

All you have to do is wander around, fill up your shopping

cart, pay for it, and schedule delivery. They’ll be happy to
put everything on a truck and deliver it to a patch of dirt that
you own.

But when you go to live in that house you bought, you’ll find
there’s no house. There’s just a bunch of stuff stacked on the
dirt. Because – obviously – you didn’t buy a house, you just
bought the materials to make a house. Even if you thought
ahead and bought some prefab walls, they still aren’t bolted
together to make a room.

You bought a potential house; without a human being to put

it all together – to apply some knowledge and a lot of effort
– it will never reach that full potential.

At some point, someone is going to have to coerce a CMS

into doing what you need it to do. Most CMSs can publish
content in some form out-of-the-box, but they have to be
persuaded to do it in a way that fulfills your requirements.

“Coerce” and “persuade” might seem like weird ways to put

it, but the backend development of a CMS is really a process
of bending a tool to your needs. Sometimes it’s very close –
so the influence just needs to be slight – but sometimes it’s
wildly off and you need to apply more pressure to get it
where you need to go.

Also, there’s a sometimes blurry line between web

development and CMS implementation. “Pure” web
development would be programming from scratch, rather
than building on the base of a CMS as a platform. Think of a
CMS as the prefab walls of a structure. Rather than building
each wall from nothing but wood and nails, you just need to
bolt some existing things together. There’s still quite a bit of
development that comes into play, but the CMS should
handle a lot of the routine work of processing managed data.

In the sections below, we’ll assume you’re working with a

competent web development team. What we’re outlining
here are the terms and concepts you’ll need to understand to
communicate with that development team as they get your
CMS to model, aggregate, manage, render, and publish your
content.

Model Implementation
In Chapter 11: Model Your Content, we discussed your
content model, or how to represent your content in a way
that maximizes your ability to present and reuse it. Now you
have to convert that model into something your CMS can
manage.

We’re going to call this a model implementation to separate it

from the model in theory. The model implementation is
your content model working inside your chosen CMS. It’s
how the idea of an “article,” for example, becomes an actual
article on the site.

In practical terms, a model implementation is a combination

of these things, which are fairly universal:

• Types: The specific types of content. Each content type is

a named combination of multiple attributes. For example:
“Article.”
• Attributes: A specific piece of managed data. A unique
 combination of attributes forms a type. For example, an
article content type usually includes attributes like “Title”
or “Publication Date.”
• Datatype: Each attribute has a datatype which limits the
data which can be stored by it – for example, the “Text”
attribute may only allow for an unformatted string of
characters.
• Validation Rules: A rule enforces the datatype – or
confirms there’s data at all – in specific attributes. For
example: the “Title” attribute may only allow 250
characters, or the “Author” attribute may be required.

These three things need to be created and configured inside

your CMS, usually from an administrative interface or –
more commonly, these days – from code.115

There are several goals to the model implementation.

• Descriptiveness: The model implementation needs to

describe your content at a level that allows you to
manipulate and output it effectively.
• Usability: The model implementation will drive your
CMS’s ability to provide your editors with both usable
interfaces to manage it and logical relationships.
• Resiliency: The model implementation needs to keep
your content safe and valid, and prevent editors from
storing content in an invalid state.

The achievement of these goals is not binary – it’s not like

your model implementation is “descriptive” or “not
descriptive.” It just gets closer or further away from an ideal.
You’ll usually never get all the way there (if it could even be
objectively defined).
Why shouldn’t you always attempt full-realization of that
ideal? Because every model implementation is a balance
between complexity and flexibility. A key point when
implementing your model in a CMS is deciding how far to
take it.

For example, you may dictate that every instance of an

“Employee” type includes dozens of fields, all of which are
required. This leads to a rigid, structured content type –
good in some cases, bad in others. On the other hand,
perhaps the “Employee” type is just a rich-text (WYSIWYG)
field. We’ve increased flexibility, but at the expense of
structure. Editors have it easier, but the CMS no longer has
the explicit definition of each field that came from the
structured content.

You might try to handle every possible edge case and

theoretical situation, but the result would be too complex for
your editors to work with. The stricter your model
implementation becomes, the more friction it introduces to
the editorial process. You need to decide how strict this
needs to be.

Additionally, your CMS imposes limits. And sometimes

they’re unfortunately arbitrary and final. In a theoretical
model, anything is possible. However, CMSs have specific
feature-sets around content modeling – they’ll no-doubt
support some aspects, but might struggle with others.

I’ve oft-maintained that you can’t do a good implementation with a particular CMS until
you’ve screwed up about five of them. Mistakes are never great, but if you remember and
learn from them, you get better over time.

— Deane Barker
Not Every Model Can Fit
Your ability to accurately represent your model depends on
the modeling capabilities of your CMS, but also on the
creativity and experience of your development team. Given
enough experience with a specific CMS, a developer will
learn what all the traps are.

Any developer experienced in a CMS should be able to look

at your requirements and mentally formulate solutions to
90% of them, while the more advanced problems might
require prototyping, or even trial-and-error.

And, sometimes you just can’t wrap a CMS around your

model requirements. For example:

• An “Article” requires a link to an “Author” object. This is

supported, and it allows readers to see who wrote an
article, then find their author page. However, what if your
CMS doesn’t consider this link to be bi-directional? Now
it’s not possible to perform the opposite action of seeing a
list of “Articles” on the author page.
• A “Meeting” object requires “Topics.” Each “Topic” is also
a content object, which means you need to connect a
“Topic” to a “Meeting” in a parent-child model. However,
what if your CMS doesn’t have a content tree that would
allow this? Now someone else could link another
“Meeting” to the same “Topic” (not allowed by the model),
and it won’t stop a deleted “Meeting” from “orphaning” a
bunch of “Topics” (also verboten).

These examples might seem weirdly specific, but they’re

accurate examples of where content models run into
problems. Even the simplest modern CMS allows the
definition of structured types – that’s the easy part. The
problems crop up at the edges, where you had an idea that
seemed simple in theory but becomes infuriating in practice
when you simply can’t wrap your CMS around it. You try to
“fit” your idea in multiple ways, but the CMS seemingly
thwarts you at every turn.

Model implementation is a process of concessions. Consider

our second example from above, and here are some ways
you might get around those limitations.

• You might decide that someone could link a Topic to two

Meetings, but that’s just a thing you’re gonna have to live
with. Maybe you educate your editors to just not do this,
or create a report that shows you when this happens, so
you can correct it.
• You might limit the deletion of Meeting objects by
permissions, restricting it to administrators (or even just a
single master editor) who knows better than to orphan
Topic objects.
• You might have a developer create some code to unlink a
Topic from a Meeting when it’s linked to a different
meeting, or automatically delete all related Topics when a
Meeting is deleted.

Two of these options tie to governance, not programming,

while the third is more of a complex workaround. The
reality of your CMS’s capabilities can be a wet blanket, but
it’s something most projects encounter at some point. The
flexibility of a theoretical model often clashes with reality.

Editorial Experience
One of the goals of the model implementation we explained
above was “descriptiveness.” You need to describe your
content to your CMS.

Let’s take a trip into the Theater of the Absurd. Imagine

sitting at a whiteboard with your CMS, and drawing it out so
your CMS understands what the different types are, how
they work, and why this matters. Consider this imaginary
conversation with your CMS:

You: Okay, now an Article has a Published Date …

CMS: I’ll show a date picker for it, but does it need a time?

You: No. No time.

CMS: [takes notes] Okay, I won’t show the time selector then. Can
the date be in the future?

You: No.

CMS: [furiously scribbling notes] Okay, I’ll prevent them from

entering a future date.

As you describe your content more carefully, the CMS can

use aspects of its UI to force or coerce editors to enter
correct data.

We might call this Theater of the Absurd, but I find comfort in the character of “CMS.” They
are the hero this book needs.

— Corey Vilhauer

• Data Coercion: The usage of editorial elements to

prevent the entering of invalid data. For example, the
 usage of a date picker, or the elimination of the time
selector. By doing these things, the UI is actively
preventing invalid data from being entered. There is just
no other way.
• Data Validation: Sometimes, an editor can enter invalid
data, but the CMS can prevent it from being saved or
stored by validating the published date to be sure it’s in
the past. If it fails validation, the CMS can show an error
message and require the editor to change it.

Let’s continue the conversation:

You: I want them to be able to format this text.

CMS: I can display a rich text editor. Can they do anything they
want?

You: No, just bold, italics, and linking. No tables or anything like
that.

CMS: No worries. We’ll only show them buttons they can use.

Limiting or “neutering” rich text editors is a critical aspect of

editorial experience. As a general rule, only show editors
things they can use.

You: Okay, now if they don’t enter an “SEO Title,” we’re just
going to use the regular title.

CMS: Got it. We should tell them that. I can include a message
under the field so they know.

Accurate labeling of form fields is critical, both in the simple

label and any extended help text. Every field should have
clear instructions of how it relates to the model.

You: This is a lot of fields. This might be confusing.

CMS: Tell me how they relate. I’ll put them in tabs.

The simple grouping of fields under tabs or collapsible

headings can help enormously in limiting the cognitive
overhead of perceiving a giant page of form fields.

In each case above, we’re describing our content model

more and more, which is enabling our CMS – or, more
specifically, the team in charge of implementing your CMS
– to make our editors’ experience better and better. Most
systems will have these features built-in, but they logically
require an understanding of the model to be manifested – a
CMS can’t just decide how to group fields; you need to tell it.
Generally speaking, the more you describe your model, the
better the experience can be.

Projects tend to concentrate on the visitor experience, and

gloss over editorial experience, to their detriment. Happy
editors make better content, and a shocking number of CMS
re-implementation projects have started from the same
sentence: “Our editors hate using our CMS.”

Cater to your editors. Implement your content model at a

level that allows the CMS to help them. The happier they
are, the better your content will be, and the longer your
CMS implementation will last.

Aggregations
As we discussed in Chapter 11: Model Your Content, content
objects don’t exist in a vacuum. They usually have to be
organized into larger structures in order to provide some
value.

Every CMS will offer a toolkit of features to manifest your

logical model aggregations. One of the key skills in working
with any CMS is knowing what these aggregations are, and
their relative advantages and drawbacks, so you know when
to use one over the other.

Some common aggregation tools:

• Content Tree: A very common pattern is a “tree” of

content, where you have a “root” object with a hierarchy
of descendants below it.116 Every object is a child of
another object, and might have one or more children of
its own. This is a very common way to organize content
and overlays naturally on navigation and website
organization. For many systems, this is the main
organizational method for content.
• Folders: Occasionally a system will organize content by
containers, often visualized as “folders” to piggyback on
the visual model of most operating systems. In a way, this
is also a parent-child structure, but parents can only be of
a specific type (the folder), and these folders often do not
manifest as content on the site.
• Menus or Collections: Most systems will also have some
arbitrary method of organizing and ordering content into
serial lists or hierarchical menus. In some cases these are
literally meant to be web menus (sometimes with pre-
built HTML),117 in others cases they’re just meant to
structure content so it can be accessed in some group via
code or from templating. A key point here is ordering:
both these aggregation methods allow you to put content
 in an explicit order.
• Tags or Categories: As we discussed in Chapter 10:
Organize Your Content, it’s also common for some
method of tagging or categorizing content. The two
methods are very similar, but categories are usually
created in advance by someone responsible for
maintaining the organization structure, and they can often
be organized into a tree. Conversely, tags tend to be ad
hoc, so editors can make them up on-the-fly.

The differences between aggregation methods can be subtle,

and there’s often a lot of overlap. A hierarchical menu
structure is very similar to a content tree. And tagging or
categorizing content can seem very similar to putting
content in a collection.

The choice to use one over the other can come down to
some very subtle factors, and tragically, these factors might
not surface until after the system launches and is in
production. Months down the road, your editors might be
frustrated or have come up with some particular use case
that a certain aggregation doesn’t handle well, and to fix it,
you have to back out large portions of the system and re-
work them using a different aggregation method.

Your developers will use content aggregations to build out

the basic framework of your site. Your content model, even
when turned into a concrete model implementation, is still
just theoretical until it starts filling up with content and those
building blocks are stacked, via content aggregation
methods, into some sort of framework to form a larger
domain of information.

The actual aggregations that come out of this process might

be used to:
• Form primary navigation (ex: the main, overhead
navigation, or a “super footer”)
• Create localized, sectional navigation (ex: “In this
Section”, or “Our Products”)
• Create index pages, or lists of content (ex: “Latest News”)
• Create topic-based indices of content (ex: “Articles About
China” or “Related Content”)

Content Rough-In
Even once the model implementation is in place, the content
is still very theoretical. A model implementation is a
framework or container for content, but there’s nothing in it
yet.

Your developers will usually have to go through some

explicit stage of “rough-in” where they add some content to
the system. They’ll need to do this both to test the model
implementation – what works; what doesn’t work – and to
confirm that aggregations work as expected. It’s hard to
figure out if a particular aggregation will work for the main
navigation unless you create it and work with it.

There are two parts to this:

1. Entering “dummy” or sample content into an individual template. This allows your
development team or testing team to understand how content works within each field.
You’ll see what happens if a too-long title is given to a page, or if a page is given a hero
image.
2. “Stubbing out” the full site of content. In this way, you’re essentially creating the standard
page without any content within, which allows the development or testing team to see
how navigation works with a full content tree.

— Corey Vilhauer
Content rough-in is not migration. You might test some
migration methods by moving some content and using that
(highly recommended, in fact; nothing works like real
content), but often a developer will just enter some “junk”
content to provide some building blocks to the system.

When the model implementation is in place, the aggregation

methods are created, and content rough-in has provided
something to put in structures to create the basic “shell” of a
website – that’s when you can really begin to see how things
come together.

Templating and Output

In Chapter 19: Implement the Design, we discussed front-
end development and gave some examples of HTML. What
we didn’t explain is how your content comes to be mixed in
with that HTML. Static HTML doesn’t help – we need
HTML that changes to represent the different content in our
CMS.

This happens through some process of templating, whereby

static HTML is mixed with dynamic content to form output.
A template provides a starting point for output – it’s usually a
mixture of HTML and special programming code that
injects data from a content object to generate a specific
output. Apply Content Object A and you get a certain
output; apply Content Object B and you get a different
output.

Templating features come in a few forms:

• Token Replacement: The most basic form of templating,

in which HTML is formed as a structure for a page, and
 code snippets called tokens are placed in the right spots —
a token where the title goes, a token where the main body
goes, and so on. Your content then replaces those tokens
in the template, and the page shows up with all of your
words and images.
• Output Filtering: In this style of template, content is
filtered into a template and changed in some way. For
example, you may want to pull in content and display it in
all caps. An output filter added to a specific field will
template that change. Or, you might filter based on an
argument, such as displaying a date in a specific way
different from the raw data.
• Looping: Your template might have a piece of data
representing a collection of objects, and it can repeat a
section multiple times. For example, the loop for an
article listing will create a list of all articles, over and over
again, in a loop, until it reaches the end, whether that be
five articles or five hundred.
• Conditionals: These allow you to make decisions about
whether or not to do something. For example, you can
add a conditional that suppresses a field if it is blank (such
as if an article has no selected author).

These four constructs – token replacement, filtering,

looping, and conditionals – are the basis for most every
templating language. Using these things, a developer can
take content data and form HTML output.

Request Mapping and the Operative Content

We introduced the request-response model of the web in
Chapter 17: Plan for Hosting. Remember that a web content
management system responds to requests. Someone inputs a
URL in their browser and some HTML is returned.

In most CMSs, specific content objects get assigned URLs

when they’re created. The URLs are often based on the type
of content, or where the content sits in a content tree (each
object gets a segment, and the segments of all the ancestors
back to the root object form the URL).

Regardless of method, content objects which are intended to

be directly addressed by a URL know what URL they should
respond to.

Given this, here’s how the request-response model plays out

for a CMS.

The process in steps 2, 3, and 4 is quite common in CMS

architecture: map the URL to a content object, select a
template, and execute the template against that content. The
content object which is found in step 2 is known as the
operative content object, meaning it’s the content object on
which the request is “operating.”

For example:
1. The URL /news/tax-increase-is-coming is requested.
2. The CMS reviews that, searches, and locates News Article
#437 as matching that URL.
3. Checking its configuration, the CMS finds that News
Article objects used the template in a file called news-
article.tpl.

4. The CMS executes news-article.tpl with News Article #437

as the operative content object and gets a bunch of HTML
in return.
5. The CMS sends that HTML as the response.

In most systems, there is always an operative content object.

It might be a news article, a text page, a news article listing
page – whatever. But there is usually a central, operative
object on which each request is operating.

We noted in step 3 that the CMS needs to find a template.

What template does it use? Usually, there’s a single template
per content type – so News Articles have one template,
Products have another template, etc. This makes sense,
because templates need to know what type of content
they’re operating against. You can’t execute the Author
content for a Product, for instance. You have to know what
data you have before you can output it.

Some systems have more complicated templating rules. It

might default to a template per type, but there might be
situations where you can specify a custom template for a
particular object, for example. So all News Articles use the
same template, except for News Article #437, which uses a
special template, for whatever reason.

Template Languages
Template languages exist independently from CMSs. This
means that knowledge of a particular template language can
span different CMSs.

Remember our discussion of the “technology stack” earlier,

and also remember that every CMS is written in an
underlying programming language. Templates are “sub-
languages” within those, that run “inside” those languages.

Here are some common languages for various underlying

languages.

• .NET: Razor is very common, and is the default for most

projects. Other languages are Fluid and Scriban.
• PHP: Twig is the most common language. Smarty is an
older language, but still popular. And some systems
simply use PHP itself (discussed more below).
• Java: Freemarker and Velocity.
• There are also templating languages that have versions
for multiple programming languages, like Mustache.

Other Development Tasks

So far, the back-end developer has implemented the content
model, designed and created the necessary content
aggregations, roughed-in the content, and templated the
output. This is the backbone of a CMS implementation. The
bulk of the work exists in those tasks.

However, depending on your requirements, there are quite a

few other details to be handled.

• Users, Groups, and Permissions: Everyone accesses a

CMS in the form of a user (even if it’s a common user like
 “Anonymous”). Those users need to be created, organized
into groups for manageability, and have permissions
assigned. The goal is to protect your content, and protect
users from themselves – no one should accidentally be
able to do something they didn’t intend.
• Workflows and Content Operations: If the headcount of
your editorial team is larger than one, then there might be
a larger process to get content published – so-called
content operations.118 This might involve making sure
content preview works the way it should, and work-flows
and approval chains are in place to ensure more than one
set of eyes looks at content before the public does.
• Localization: Many organizations publish content in
more than one language. Your CMS will need to be
configured to allow content translations in specific
languages, and you’ll need to decide how to detect
language requests,119 and perhaps fallback through
multiple language options for the best match. Templating
might need to change as well – some languages are
vertical, some are right-to-left, some are longer than
others,120 etc.
• Marketing Tools: One of the goals for a new CMS might
have been to use some new-fangled marketing tools, like
personalization and A/B testing. While these are more
content challenges than technical challenges, they will still
need to be enabled and configured.
• Page Composition: Some pages on your site will be
composed rather than templated, which means editors
create the pages by visually dragging managed
components around a page surface. Special pages or
templates will usually need to be created to support this.
These pages often have zones or regions into which
 components can be placed and ordered.121
• Search: Sometimes search just works, but there are often
lots of different configuration options available. You
might want to hide some content from search, or boost
other content. You might need to configure options like
faceting or methods of finding related content.
• Reporting: Editors often need reporting about their
content, ranging from simple usage analytics to quality
checking and productivity reports – what images are no
longer being used, where does a certain term appear in
the content, how many content objects has each editor
touched in the last thirty days, etc.
• Archiving: What happens to content when it’s not needed
anymore? Does it get hidden? Deleted? Archived? What do
those terms even mean in the context of this CMS? You
need to plan for the entire lifecycle of content, and your
CMS might need to be configured to handle obsolete
content in a specific way. This includes content versions –
how many versions of content should you retain,
extended back how far in the past?
• Integration: As we discussed in an earlier chapter, your
CMS might need to talk to other systems to provide
content or functionality. These integrations need to be
developed or installed and configured.
• Forms: Forms are handled differently depending on the
system – in some, they’re a development task, while in
others, they’re managed as content, purely by editors.

A Common Backbone
It’s hard to generalize about implementing the back-end of a
content-managed website, since the tasks and challenges are
wildly different based on requirements. What we’ve tried to
do here is present the bare minimum of what would have to
be done – a common backbone of work:

1. Model Implementation
2. Aggregation Implementation
3. Content Rough-In
4. Templating

We can state with some confidence that those four things

have to be done in all implementations. Beyond that, every
CMS and every implementation will be done a little
differently.

Inputs and Outputs

The input to this process is almost the sum total of
everything you’ve done so far. You’ll need your
requirements, your integrations, your selected CMS, and at
some point, your front-end implementation. The output is a
running CMS implementation, ready for deployment.

The Big Picture

Back-end and front-end implementations often run in
parallel. There’s a lot that a back-end team can do before
they need the front-end team’s output for templating. And a
lot of templating is trial-and-error. The two teams will need
to communicate frequently, and go back and forth quite a
bit to make some things work.
Back-end implementation is also often being done at the
same time as content migration, which we’ll talk about later.

Staffing
You need a server-side development team, well-versed in
your selected CMS and the underlying technology stack on
which it runs.

115 So-called “code first” systems describe their models directly from programming code, which
is often helpful with DevOps because the model definition exists in a file.
116 Yes, yes, it’s really an upside down tree. Whatever.
117 A trend which is thankfully dying off, since there are too many rendering methods to
commoditize this anymore.
118 Remember DevOps as a way of moving code to production? “Content operations” might be
“DevOps for content.”
119 There are different options to detect what language a user wants, such as by URL segment
(“/en/”), subdomain (“en.mysite.com”), or an invisible part of the request, known as a “header.”
120 For example, German is, on average, 40% longer than English. This can mess with your
navigation labeling, since navigation is often integrated into the design and might be length-
constrained.
121 Dynamic page composition is exciting to see in a demo, but editorial teams usually never use
it to the level they imagine they will.
CHAPTER 21

Migrate and Populate the Content

SUMMARY
An oft-overlooked step in a website project is actually getting
the content into the CMS. This might be an automated or
manual project, depending on where the content is now, and
how it might need to change.

DOES THIS APPLY?

Unless you’re creating a brand new site with all new content
or throwing away all your old content and starting over, then
you will be migrating content. Your specific project will
dictate how much is automated or manual, but know that
this workload will exist.

It’s time for a new house.

You spend a bunch of time looking at home plans and

talking to home builders. You pick out finishes, buy an
empty lot, and engage with an architect. You spend months
visiting the construction site, keeping careful track of how
it’s progressing.

You realize that your new house is going to drive other

changes in your life. You register your kids in a new school.
You decide to buy a more fuel efficient car since your new
house is fifteen miles further from the old one. You buy a
new file cabinet to store all the paperwork, from builder
invoices to instructions for the new oven.

The house nears completion. You call your utilities and

arrange for transfer of service. You file change of address
cards with all your different subscriptions. You tell Trevor,
your landlord, that you’re moving out at the end of the
month. You even plan a house-warming party for fifty of
your friends.

The end of the month comes, and the house is done. The
builder gives you the keys. You sign the mortgage papers. It’s
all yours, congratulations.

You visit your new house. You walk inside … and sit on the
floor. There’s no furniture. You go to make dinner, but there
are no dishes in the sink.

Your phone rings. It’s Trevor, your old landlord.

“Hey, when are you planning to come get all your stuff?”

[record scratch sound effect]

Whoops.

This is the story of content migrations. In our excitement

and rush to build something new, we sometimes forget that
we have a ton of stuff that we’ll need to move when this is all
done.

In this chapter, we’re going to explain how to avoid this.

Defining “Migration”
“Migration” can be a very dangerous word.

Some people will say “site migration” to mean the entire

process of moving from one website to another. To them,
the entire thing is a migration, from when you start talking
about it, to when the new site goes live.122 Planning,
designing, development, and moving content are all
“migration.”

To other people, “migration” is moving content from one

platform (your old CMS) to a new platform (your new CMS).
The migration is one part of a much larger project.

We’ll revisit this point a couple times below, but let’s just get
something out now: sometimes, the content migration is
The Thing. Many projects are very small development
efforts with monumental migration efforts behind them.
We’ve seen projects where almost half the budget was
dedicated to migration.

When someone says “migration,” do they mean the entire

project, or just moving the content? Be relentless in
baselining the usage of this term, because mistakes can be
disastrous.

The Three Questions of a Content Migration

When planning a content migration, there are three
different questions you need to answer. Sadly, these aren’t
yes or no answers – these are more like three complicated
problems you need to have solutions for.

1. The Editorial Question: What content is moving, and

how does it need to change on the way over?
2. The Functional Question: How will functional or logical
aspects of the content work in the new CMS?
3. The Procedural Question: How will the actual bytes
move from one disk to another, and what does the timing
of that look like?

We’ll discuss each question below, but understand that some

of this retreads over subjects we’ve covered in the past. You
will likely have done some of the work already, and that’s a
great thing. Now you’re just going to reconsider that work in
the context of your content migration.

The Editorial Question

We need to know what we’re going to move. We need a list
of everything that’s going over, so we can move it and check
it off our list.

Thankfully, this is the easiest question for us to answer by

this point in the process, because a lot of this work will have
been done already.

If you’re moving from your apartment to a new house, the

scope of what you need to move is pretty simple – you need
to get everything out of the apartment. Where that stuff goes
is up to you, of course. Most of it will make it to the new
house, but some of it may be donated or even thrown away.
Still, it’s easy to know when you have everything accounted
for, because in the end your apartment needs to be empty. A
simple visual sweep can tell you if you got everything or not.

The same isn’t quite true of websites. While your apartment

has a standard set of doors that you pass every day, your
website has thousands of rooms – some of which you
haven’t seen in years, and some that might not even have
doors. It is very easy to forget something, or not plan
adequately for it. Then you turn off the old website and that
content simply goes away (insofar as your website visitors
are concerned).

First, let’s look back to Chapter 7: Know Your Content and

pull out that content inventory. This encompasses the scope
of content that’s going to be on the new website. You also
have a site map that defines content organization for the
new site, including any new content to be written.

Essentially, you need to get from the current content

inventory to the future site map. We can ignore new content
at this point, because creating new content is an
operational/editorial concern, and not really part of a
migration.

But for content that already exists, we need to define within

the inventory whether each page is a one-off or part of a
highly structured group:

• One-off, or Specific Content Objects: The home page.

The privacy policy. The “about us” page. These are
specific individual objects that will need to move from the
old CMS to the new CMS.
• Structured Groups of Content Objects: All news releases.
All technical documentation. All forum posts. These are
large groups of similar content that can be grouped
 together in a “bucket” that all have to go over to the new
website. You do not need to list every news article, so long
as everyone can agree on what a news article is, and that
they’re all migrating.

Make It Easier on Yourself

It’s worth saying at this moment that you often don’t need to
move all your content. Now might be a handy time to get rid
of stuff.

Remember the apartment analogy above where some of the

stuff in your apartment went to the trash dump? Same deal
with digital content. Here’s a statement that you should
repeat to yourself five times every single morning while
you’re doing migration planning.

The easiest content to migrate is content that you throw away.

Seriously. We’re not even being flippant. What to make your

migration easier? Throw stuff away.

Intranets are ripe targets for getting rid of content. Do you know how much content
accumulates on an intranet and how much of it is time-sensitive, meaning it has no value
after a specific point in time?

We’re pretty sure no one needs to be reminded about Shirley’s “bon voyage!” party that
happened on April 26, 2013. I hope you took pictures, Shirl, because the new intranet is
gonna forget that ever happened.

You could delete 90% of the content on some intranets and no one would flinch or even
notice.

— Deane Barker
If you’ve performed a detailed content audit, you’ll have
already reviewed this content from a few angles. Here are
some factors you could take into account when deciding
whether to keep or discard something:

• Traffic: Check your analytics. How often has this content

been consumed?
• Centrality: How often is this content linked from other
content? If it has 300 inbound links, that can be a
problem. But if it’s not linked from anywhere – if it’s one
of those rooms with no doors – maybe there’s a reason?
• Age: We’re not saying that old content is always bad, but
consider how current or relevant the content is to your
current content consumers. Are they likely to get any
value out of it?
• Keywords: Some organizations are much more
concerned about SEO than others, but consider if any of
your target keywords appear in the content. If the answer
is no, then evaluate whether or not it’s serving a purpose
for you.

I can tell you from practice: you will end up, essentially, going through your content at least
twice: once to understand the full scope of content, and a second time to match each page to
a content type within your new content model.

— Corey Vilhauer

By using a set of rules, you might be able to identify a huge

subgroup of irrelevant content in a larger group. Yes, all
news articles are going over, but before you migrate them,
can you perhaps cut down the “all” there? Delete what you
can, then migrate the rest.
 Sure, if you automated a migration, then a script doesn’t
care if there are 10 news articles or 10,000. But they still
need to be checked for quality after the migration. And
every content object is a chance for a one-off error that
someone has to fix.

The goal of The Editorial Question is to identify a list of all

the content or groups of content that are migrating. Once
this is done, then we move onto the next question, where we
figure out how all your content is going to work in the new
CMS.

The Functional Question

There are certain features and common page models that
are relatively standard, regardless of the CMS.

For instance, news releases display a title, publish date, and a

body. You can likely count on this working reasonably well
in most any CMS. The simple display of structured content
is a well-handled pattern.

However, some content-based functionality can be more in-

depth and unique from CMS to CMS. For example, what
about the page that lists all of those news releases? Let’s
consider all the functionality that might exist here.

• News releases are listed in reverse chronological order by

date published.
• Certain news releases are hidden unless the user is logged
in with the correct user permissions.
• News releases can be filtered or categorized.
• The user can perform a full-text search on all news
releases, and this search includes functionality like type-
ahead suggestions, stemming, fuzzy matching, and
scoring.
• The user can subscribe to a particular category to get
email updates when a news release is added.

And so on.

This is essentially a software application, embedded as a

subset of the larger website. Looking over that list, are you
sure your new CMS will be able to do all of that?

If not, you’re going to need to make some decisions.

• What of those requirements are you willing to abandon?

• Do you have an integration partner that can find creative
solutions to work around limitations in your new CMS?
• Is your new CMS the right choice? I’m not saying you
should bail out at the smallest problem, but if you keep
evaluating functionality and your new CMS keeps up
coming up short, then you might need to take a beat and
think through this some more.

And understand that this is just one page on your website. A

typical website has a dozen or more of these content-based
applications scattered around. You need to account for all of
them and make sure there are plans to make this all work.

Remember: functionality has to migrate, too. And even if that

functionality is migrated, there’s a very real chance your
new CMS handles it completely differently, and it cannot be
migrated so much as it has to be reconstructed.

Navigation is a good example. Many systems (especially

web-focused systems) use a tree of content to organize their
pages, as we discussed in Chapter 20: Implement the Back-
End Functionality. If you’re moving from a content tree-
based system to another content tree-based system – for
instance, from Sitecore to Optimizely – then you’re in pretty
good shape. But what if you’re moving to a system that
doesn’t use a tree? Say, Drupal? Or a headless system, which
have mostly eschewed content trees altogether? If your
entire navigation logic depends on parent-child
relationships, then you’re going to have to find a new way to
program this.

Finding all this programming is not easy. Some of it will be

reflected in source code, and the developers who
implemented the system can point this out. But other
functionality will simply be inherent to the CMS, and might
be so ingrained that you can inadvertently extrapolate that
functionality onto all CMSs, assuming your new one is going
to handle it in the same way.

Sometimes, the best way to catalog this functionality is to

simply walk through your current website with your
implementation team. Look at every unique page, and make
sure they have an answer for every piece of logic and
functionality that goes beyond the simple display of a single
content object.

Coming out of this process, you should have a list of all the
content that’s moving (from The Editorial Question section
above), and a list of all functionality that’s going to need to
be replicated from one system to another.

The Procedural Question

By this point we know what content is migrating, and we’re
aware of all the content functionality that’s going to have to
be reconstructed (or reconsidered). A lot of that functionality
was identified as development tasks and is being
incorporated into our new website.

Now we have to figure out exactly how we’re going to

migrate this. Our migration is basically a separate, related
project to main website development. Our plan for this
subproject is a roll-up of a number of different problems
that need solutions:

• Extraction: How are we going to get content out of our

old system?
• Transformation: How does the content need to be
cleaned up?
• Import: How are we going to get the content into the new
system?
• Timing: What does the order and spacing of this process
look like?

We’ll look at each one individually. But first, do you need

robots or humans?

Automated or Manual?
Here’s your first crucial decision: are you going to try to
automate this process at all?

Make no mistake: you can do a migration manually. There’s

nothing stopping you from buying pizza for all the interns
and stuffing them in a conference room for a week to copy
and paste content from your old CMS to your new one.

In fact, for some projects, this is exactly the right decision.

Here’s when this makes sense:

• Low Volume: If you’re migrating less than 100 pages,

then there’s little point in automating the process. You’ll
spend more budget to configure the automation than you
would save over doing it manually.
• High Transformation: Some content needs to be
transformed considerably on the way over. For example,
if you’re taking a bunch of content out of PDF files and
putting this in HTML, that’s probably something you’re
going to have to do manually.123
• Low Cost Labor: I wasn’t kidding about buying pizza for
the interns. This happens all the time. Universities are
legendary for using work-study students for this.

Copy-and-paste is low-tech and tedious, but reliable and

low-overhead. A manual migration takes no prep to get
started, and sometimes you can brute force a migration
faster than getting clever with it.

If you decide to do a manual migration, then very little of

what’s below will apply to you. You will extract, transform,
and import all in one step.

Also, know that any automated migration project will in

reality include some manual migration. There’s always
content that is not automatically migratable.124 These pages
are usually made up of a mixture of content from a single
object, design components that display other content, and
aggregations that bring in more content. The complexity of
these pages in relation to their relatively scarcity means
these will need to be reconstructed, rather than migrated.

Extraction
There’s a number of different options for getting content
out of a CMS. Some are well-supported and helpful. Others
are less so.

• Export: Some systems actually have an export system.

However, it’s getting less common, and even if it exists, it’s
important to know in what format the content will be
exported, and if all the detail you need will be included.
• API: Most all systems have an API that you can
manipulate from code scripts. It’s not hard to use this to
export content into some neutral format that you design.
This generally gives you the most granular way to control
exactly what gets exported and in what format it ends up.
• Database: If a system doesn’t offer either of the above
options, you might be able to go around the CMS entirely
and manually search its database. In many situations, a
developer can hook directly into the database and retrieve
content. The danger here is that the content in the
database might not be exactly representative of what
makes it to a browser.
• HTTP: The final option would be to simply make an
HTTP call to the URL where the content is located. If you
can get a list of URLs where the content is the operative
content object (see Implement the Back-End
Functionality), then you can very easily request it just like
a browser would, then parse the HTML to break it up into
the attributes you need. There are some drawbacks here –
non-public content can be difficult, as can non-displayed
attributes – but this is occasionally your last resort.

The goal of extraction is to get the content out into some

neutral form where it can be easily accessed and
manipulated, usually as a text markup format like JSON or
XML, though occasionally you might deposit it directly into
a simple database or other storage mechanism.

Transformation
Once you have the content out of the old CMS, it often
needs to be transformed or adjusted before being imported
into your new CMS. Occasionally the content was modeled
poorly in the old CMS, and it would be inefficient to move it
as-is.

For example, consider some scenarios of content in your old

CMS.

• The author’s name was represented in a single field. You

want to be able to order authors by last name, so this is
going to need to be split into first and last names.
• The model for committee meetings had a set number of
fields (say, six) for attendees. This becomes a problem
when more than six people attend, so the plan is to break
this out to a relational attribute in the new system. Each
meeting attendee will need to form a separate content
object, and be linked into the meeting object where they
used to appear.
• Comments were stored in a separate database table. This
content needs to be extracted alongside the CMS content
with a reference to the correct article content object from
the old CMS.

Remember, when you import to your new CMS, it has no

idea where the content came from, which means the rules you
used on your old site to dictate design mean nothing.

Many times, you need to “scrub” rich text. Your old CMS
may have generated HTML from rich text editors – the
body of an article, for instance – and this HTML is of
varying quality. Sometimes it’s clean and can be imported
without changes, but other times, you’ll need to write scripts
to comb through this HTML and fix problems, like
embedded scripts, character encodings not compatible with
the new CMS, or deprecated HTML tags like FONT and (gulp)
BLINK.125

These operations can be tedious. If you’re lucky, the HTML

is consistently bad, meaning you can fix these things at the
global script level. Usually, the HTML is inconsistently bad,
meaning you have to pick through it and fix them manually.

I once did a migration of content that had been through five or six different CMSs over
sixteen years, and had never been cleaned. The HTML was just rolled over into a new
system. I was finding problems in the HTML that occurred a decade prior and three CMSs
ago. It was wildly and irrationally satisfying to scrub this HTML until it was perfect.

— Deane Barker

Import
Finally, what goes out must come back in again, and
eventually you’re going to have to take that content you’ve
gotten out of your old CMS and move it into your new CMS.

There are fewer options for this scenario. Most CMSs don’t
have an “import content” function.126

Usually, an import needs to be performed from code, by a

developer, working against the new CMSs API. It would
seem fairly simple, but there are some nuances.

• You will need to keep a “manifest” to tie content from

your old site to its corresponding new content.
• You will need to make your script “update aware,” so you
can run it and re-run it over and over without creating
new objects every time.
• Working with referential attributes – where an attribute
on one content object points to another – can be tricky. If
you’re importing 10,000 articles and each one is linked to
one of 300 authors, then you need to make sure the authors
exist first. You can’t link an article to something that isn’t
there.
• You will need to do a link resolution process, where you
search all HTML for embedded links to other content and
then point them at the correct content.

Of course, these are all going to depend on the specifics of

your migration. In reality, the best way to illustrate the
complexity of a hypothetical migration project is … to
provide an example of a hypothetical migration project.

Timing and Iterations: A Hypothetical

Migration Project
We’ve been talking about a “migration” like it’s a singular
thing that happens at a point in time, but that’s not how it
works. A migration is a process that occurs alongside your
development project.

Many parts of a migration are iterative, meaning you’ll try

them, realize you did something wrong, delete the results,
fix your problem, and do it again. This happens on
extraction, transformation, and import. These things go in
cycles, continually being refined, closer and closer to an
ideal.

Remember too that migration can start early. You should

start inventorying as soon as you decide to move your
website. You can start extraction shortly thereafter. And you
can do a lot of transformation without knowing the final
destination for the content. Don’t sit around and wait for the
new website to be done. Start working on your migration as
early as you can.

The best way to illustrate this is to give a hypothetical

timeline of events. Here’s how the entire migration process
might work for a large project with around 50,000 content
objects (pages, components, relationships, etc.):

• Your organization decides to move to a new CMS. Even

before development has started – indeed, even before a
new CMS is selected – the content team includes The
Editorial Question in their content strategy. They start
developing a list of what content is migrating and what
isn’t as a part of the site map.
• The development team starts looking at ways to get
content out of the old CMS. They determine they can do a
rough export. Remember that the new CMS still hasn’t
been selected, but the developers know they’re going to
extract the content no matter what, and getting it out isn’t
affected by what it’s going into.
• They don’t know exactly what content they’ll need, so
they just export every last bit of content they can find.
This is an iterative process – they export, review, evaluate
what they missed and what’s not ideal, then delete the
result, tweak their script, and export again. This goes on
for a couple weeks. The developers eventually get the
content out into thousands of JSON files.
• The developers get busy cleaning up the old HTML. It’s
really old and messy. They still don’t know the CMS it’s
going into, but they know it’s going to need to be fixed,
 regardless of destination.
• Finally, a new CMS is selected.
• In an epic working session on The Functional Question,
the content strategy, design, and development teams
figure out where content is going to go in the new system,
and how it’s going to have to change to work under the
new architecture. Much of this work begins in content
strategy and information architecture, but this is when the
concept becomes action. These teams also create a plan
for content that needs to be created or manually migrated.
• The developers spent the next few weeks preparing the
exported content in the JSON files. They write scripts to
transform them, review the result, tweak their scripts,
then transform again. This goes on until the JSON files are
as perfectly clean and importable as possible.
• The migration QA team comes up with a plan to import
content in stages, then QA the result before moving on.
The content is divided into groups and a schedule is put in
place.
• Import begins. As an example, the developers run a script
to bring in 16,000 news articles. They take a quick look
and realize something went wrong, so they delete them,
fix their script, and re-import. Testing starts, and this time
the testers realize that none of the images were imported.
So, testing stops and scripts are tweaked.
• Up to this point, testers have just been recording issues,
but not fixing them, in case everything needs to be re-
imported. However, as QA continues, it appears that the
last import is solid and they can commit it. A decision is
made that an automated mass import will not be done
again for the news articles, so manual editors and testers
are free to start correcting issues.
• The developers will never run the news article import
script again. They move on to the next group of content.
• Testing continues. Issues are fixed where possible, but
occasionally there are issues that need further review. For
example, one news article links to an older one that was
discarded. Testers open tickets for these issues and assign
them to the relevant staff to ensure the issues aren’t
missed. The content strategy and editorial teams are busy
analyzing problems and adapting the content to fit.
• This cycle of import, re-import, commit, and testing
continues until all content is in. This process might take
weeks. During this time, the content team has been
creating new content to fill in the gaps. The new website
slowly starts to come together.
• Once a content group is imported and the teams commit
to that import, the content team acknowledges that this
content is “frozen.” This means that it will not be re-
imported, so if they want to change the content in the old
system (which is still running the public website), they will
need to wait on that change until after launch, or duplicate
that change in the new system.
• All testing completes, all new content is completed, and
the new site is fully populated and ready to launch. From
this moment, the new site begins to get “stale.”
Remember, the old CMS with all the original content is
running the public website. And the new CMS with all the
imported content is just sitting there. So, either no content
can change in either system, or any change to the public
website (which would be on the old CMS) must be
duplicated on the new website-in-waiting.
• Thankfully, this period is short. The new website is
cleared for launch. Once it launches, the other website is
hidden from public access. It’s left online for a period of
 weeks in case the team realizes they missed something, or
need to refer to old content or configuration.
• The old CMS and website is eventually taken offline and
archived.

Now, look back through the above narrative, and

acknowledge one thing: we didn’t talk at all about building the
new website. That was all migration. Throughout that
narrative, it’s assumed there is another project and another
group of developers actually building the new site.

Can you imagine if that team got all done building the new
website, and then said:

Okay, now let’s figure out how to migrate all this. I don’t know,
maybe we should start with a content inventory or something?

Do you see that dot disappearing over the horizon? That’s

your launch date.

Users and URLs

There are two specific situations that come up in enough
migrations to be worth discussing separately.

User Migration
Clearly, you’ll have to retrain your editors and get them new
accounts on your new CMS. But what if you have users who
log into your website? You might have user accounts for
your customers or the public that they use to access content.

Many times, these user accounts are stored in your CMS. If

this is the case, these accounts are going to have to move to
the new CMS. The problem is you likely don’t have access to
the users’ passwords. This is by design.

Passwords are not normally stored in clear text. Rather,

they’re one-way encrypted so that you can’t view them in
their original form. This is a good security practice, but it
means you can’t seamlessly create a new account for your
users on your new CMS – you don’t know what their
password was.

Often, this means that moving all these user accounts will
require your users to create new passwords, or even entirely
new accounts,127 which isn’t as much of a technical lift as it is
a communication lift. You’ll need to develop a plan to address
this change – not only to clearly explain what’s necessary,
but also to convince them that this isn’t a phishing attempt,
and that you genuinely do need them to reset their
passwords.128

URL Redirection
If your website has been online for any period of time, you
have published URLs that have crept “outside the walls.”
Search engines have indexed them. Users have shared them
on social media. They have been bookmarked.

Which means people will click on them … and they will get …
nothing?

In a perfect world, your URLs won’t change. But this isn’t

common. Different CMSs have different ways of forming
URLs. You can override this on some of them to mock up
your old URL structure, but sometimes this creates more
problems than it solves, and it can be an overbearing
solution to a problem solved through other means.

The most straightforward way to manage redirection is to

store the old URL with the new content. So every one of the
16,000 news articles you imported will have an attribute for
“Old URL.” When a request comes into the new website and
generates a 404 Not Found (since the old URL doesn’t exist
anymore), you can do a lookup to figure out what they were
looking for, then redirect them.

If you have a structured URL system on the old site, there’s a chance you can use this old
URL as a migration tool to help identify where the page will move.

— Corey Vilhauer

Many times, new sites have been launched without a URL

redirection plan. They promptly fell out of every search
engine, and 404 Not Found requests went through the roof.

Whoa
Migrations are … unpleasant. No one wants to think about
this stuff until it’s too late. Consequently, migrations are
chronically overlooked, in terms of both budget and
schedule.

A universal rule: plan more time or budget than you think

you will need to migrate your content. You will absolutely
use it.

Know too that migrations tend to be a little less planned and

smooth than the development of the new website. Even if
you run the most perfect development project in the world,
your migration project might get a little rougher the closer
you get to launch. Problems will be found, quick fixes will be
hacked into place, and the entire thing will be looked at as
disposable – you need to do “just enough” to get it done.

Most migrations come skidding across the finish line

backwards, on their roof, and on fire. But the checkered flag
tends to make all those problems seem insignificant.

Inputs and Outputs

The inputs and outputs are hard here, because this is not
something that happens within the larger project, but rather
alongside it. So there are many inputs and outputs,
happening all throughout the main project.

At minimum, some of the tasks performed during content

planning – a content inventory, audit, and site map – will
inform the next steps.

The Big Picture

You need to start your migration early. Like, at the very,
very beginning of all this – back when you started talking
about goals and plans. You should have been inventorying
content back then. And, as our extended narrative above
explained, your migration runs alongside the main strategy
and development project. At your very first meeting about
this project, you should start talking about migration. No
time is too early.

Staffing
This is something that everyone will be involved with,
except maybe designers (they might do a bit of QA, but
that’s about it). You’ll need the full cooperative of the
content, development, and management teams to pull a
migration off.

122 These people tend to be on the outside of the project. As people get further away from the
work, they naturally summarize things like this.
123 In between his sophomore and junior years of college, Deane’s son did this for an entire
summer, for $15/hour. We promise that you’ve never seen a kid more excited to get back to school
in the fall.
124 Home pages and campaign landing pages are hardly ever migrated by script, for instance.
125 The BLINK tag, as the name would suggest, caused text to blink on and off. It was an early
HTML tag, was never standardized, is no longer supported, and is generally considered an unholy
abomination against humanity.
126 Indeed, how would that even work? An import file would have to be of a very specific format.
Even then, content can be structurally complex, and it would be very difficult to specify all the
different nuances of how the imported content should look.
127 Very rarely, a developer can perform some sneaky acrobatics that watches users input their
old passwords to log in, verifies it’s correct, then creates a new user account with that same
password in the new system. However, this isn’t routine, and we wouldn’t count on it.
128 This might be a good time to mention that you should ideally migrate user accounts to an
external user management system, such as Active Directory or Okta, rather than your new CMS, so
you don’t have this problem again in the future.
 SECTION 6
LAUNCH AND BEYOND

Your site is ready to launch! But this is not the

finish line — in fact, this is barely the start. How
your site works when it’s time to show the world
is one thing, but keeping it at that level over time
— as content (and your web team) changes — is
the real work of a web project. And
understanding how to keep everything fresh,
clean, and working smoothly, as well as who’s
going to do it, is the best thing you can do to
retain and improve upon your investment.
CHAPTER 22

Test and Launch the Site

SUMMARY
The time has come to launch. You need to check off the final
items on your list, make sure the site is running in its
production environment, and launch. Then, you need to
make sure you resolve the issues that crop up after the site
goes live.

DOES THIS APPLY?

At some point in the lifespan of every project, it will need to
be tested and launched. Therefore, this chapter applies to
every project, though in varying degrees. Some of the
differentiation will depend on whether or not you
completely control your production environment. In many
cases you may deploy to an environment controlled by
other organizations, which will affect your communication
plan and distribution of work.
Launching a space shuttle must be a wild roller coaster of
long-range planning and methodical preparation, capped by
several minutes of stark terror as you hope everything
comes together at the right moment and your shuttle
actually takes flight.129

At that moment, when the shuttle is powering up on the

launch pad, and you’re waiting for the countdown and main
engine ignition, it’s a little late to remember that one thing
you were supposed to do. You had months to do that thing.
All your effort is like a funnel that has narrowed down to a
tip, which is this moment. How this moment at the tip of the
funnel goes depends very much on all the work you did
further back.

So, here we are. It’s launch time. Almost.

There’s actually quite a few things you need to do up to –

and surrounding – the launch. Website launches aren’t
magic. They feel great because the moment has come, but
there are few things worse than a botched launch.

First, you need to make sure your website is tested. And

QA130 is not a single thing as much as it’s a family of related
practices.

Additionally, you might need to choreograph the actual

deployment. There are often a series of things you need to
do to get a website project out the door. You’ll have a
checklist of things you need to do.

Once it launches, you need to be vigilant for unforeseen

issues that always tend to crop up right after your new
project sees the light of day. There’s often an acute period of
“stabilization” that needs to happen in the days and weeks
after launch.
Finally, you need to make sure acute operational processes
and reporting lines are in place. We’re going to talk about
governance and product management later, but for now,
you just need to make sure you know who to call if
something goes wrong.

Let’s get started.

Testing the Site

Quality assurance (QA) is not something you embark upon
right before launch. If you haven’t done any QA before this
point, you likely have some big lurking issues you haven’t
found yet. QA should be built into every code release. Your
testers should have been in the developing site, early and
often.

All QA is not created equally. We can separate the things we

find into two rough groups.
1. “Hard” Issues: This is stuff that’s simply broken. This
stuff needs to be fixed before launch.
2. “Soft” Issues: This is stuff that isn’t broken, but could be
better. We’re actually not going to talk about this in this
chapter – these are issues that stem all the way back to
your work on your information architecture, content
strategy, and design. Your site might work perfectly, but
people can’t find anything. The editor UI is wonked up, or
the blocks are too complicated to pair together. These are
not problems that a late-stage QA process is going to fix.

We point out this distinction because people might tell you

that something is wrong with the website, and you need to
decide whether or not this is a “bug/issue” – something
broken – or just a “change request” – something you’d make
different. Just because someone wants something changed
doesn’t mean you have a QA problem. You might just need
to refine some earlier thinking, and you might do this after
launch as you work to optimize your website as a product of
the organization, rather than a project with a start and end
date.

What we are going to discuss here are three different axes

that a QA issue can turn on. An issue’s scope is based on the
specific combination of characteristics from the variables
below:

• Public or Private: A public error affects everyone on the

site. A private error affects only editors or those who work
for your organization.
• Absolute or Partial: An absolute error prevents any
productive work or content consumption from
happening. A partial error just impedes part of work or
consumption, or only occurs under outlying usage
patterns.
• Uncontained or Contained: An uncontained error is one
that “blows up ugly” when someone attempts to do
something – a raw error message or crash. A contained
error is when functionality is broken, but the affected user
is presented by a friendlier error experience – an error
page, or some other intended message.

Here are some examples:

• Whenever anyone attempts to access your website, they

get an unformatted page saying “Error Code 4023:
Database connection failed.” This issue is public (everyone
can see it), absolute (every page is broken), and uncontained
(the error message is raw).
• When editors try to change the privacy policy, the CMS
reports a “Permissions Error. Please contact your
administrator.” This issue is private (only editors see it),
partial (it only affects one content object), and managed
(the editors get an error page with more instructions).
• When viewing the home page, the widget that shows the
weather returns the wrong temperature. This issue is
partial (it’s only one piece of the page), and is likely private
and contained – even though it’s in clear view, it doesn’t
appear like an error and no one would know it was an
error unless they actually checked the temp from a
different source. (Unless it was showing something like
150 degrees, in which case it would be public – whether or
not someone knows there’s an error can matter.)

We’ll talk more about the backlog in Chapter 24: Maintain

and Improve, but, in short, it’s the list of stuff that needs
to be taken care of on any website after it has launched.

Just like owning a home, there’s always stuff to do on

your website. At any time, you’re vaguely haunted by a
list of stuff that’s undone, needs to be fixed, or could be
improved. Some are more important than others
(triage!), but they’re all just sitting around waiting to be
addressed.

This is your backlog. It will never be empty. Make peace

with this.

The larger point here is that not all QA errors are the same.
In addition to the prior delineation of “hard” and “soft,”
some errors are, well … harder than others. This matters
because you’ll be collecting issues in the run-up to launch,
and you’ll need to triage131 them to decide what will actually
delay your launch, and what can be shuffled to the backlog.

Types of Testing
“Testing” or “QA” are terms so generic as to be useless.
There are actually lots of different styles and gradations.
Here are some of the most common.

• User Acceptance Testing: This is when your users –

humans – work with a system or a change to ensure it
meets their requirements. This is usually done as a
component of development with the intention of
providing feedback.
• Unit/Functional Testing: This is when a developer writes
some code to test some other code. They might have code
that adds two numbers together. They test by passing “1”
and “3” to that code and ensuring that it returns “3.”
• Accessibility/Usability Testing: This is testing to ensure
an interface makes sense and meets the cognitive and
physical abilities of the users, regardless of ability.
• Load Testing: This means artificially pushing massive
volumes of load (traffic) and measuring the response
times and error rates. How will your website handle the
traffic your SuperBowl ad generates?
• Penetration Testing: This is when a website is probed for
common security problems, either by an automated
battery of tests, or an actual human that tries to hack into
it.132
• Fuzz or “Stress” Testing: This is testing that pushes
atypical inputs to a program in an attempt to provoke an
error. What happens when someone pastes the full text of
 War and Peace to your web form?
• Device Compatibility Testing: This used to be called
“browser testing,” but now it’s expanded past just browsers
to the broader concept of ensuring your content looks
acceptable on all devices at all widths.
• Regression Testing: This is not a separate category of
testing, but rather a discipline of repeating your past
testing whenever you make a change, to ensure that
everything still works. Occasionally, a new change will
break some already integrated functionality that has
always worked, and unless you go back to re-test
everything, you wouldn’t know until someone
complained.
• Link/Request Testing: An HTTP request to make to a
specific URL (or a hyperlink is follow/activated) and the
resulting status code or content is evaluated. Usually done
as a full-blown crawl of a website, where a page is
requested, and all the links on the page are followed, and
so on until the entire website has been processed.

Testing Practices
The actual process of testing generally falls into two
categories:

1. Automated: A program of some kind performs the tests

and provides a report of the result.
2. Manual: A human interacts with your website – either
informally, or according to some defined test scripts to find
problems.

Some tests can only be one or the other.

• It’s unlikely you could ever coordinate enough humans to
complete a useful load test.
• A user acceptance test requires a human to experience
and certify a system.

Ideally, you want to automate as much as possible. Some

forms of rote testing don’t need the intricacies of human
judgment for performance or evaluation.

Automated testing can take a few forms, from scripts that

crawl your website and report on errors all the way to virtual
browser testing.

Many projects will have testing completed as part of the

code check-in and deployment process. When a developer
checks code into the source code repository, these
automated tests can initiate and run unattended. The
development team lead and project manager can get reports
of tests which failed, allowing them to make decisions before
deploying to new environments.

However, many aspects of your website’s functionality will

require a human tester to evaluate. These testers will need a
set of test scripts describing tasks to complete, and the
outcome they should expect.

Generally, you’ll have test scripts133 for each release to the

testing environment, which will occur upon the completion
of each sprint or stage of work. These scripts will get longer
and longer as more and functionality is completed. A
regression test requires you to retest past functionality, and
it’s not at all uncommon to run into new problems with
existing features as new features are released.

Final Launch Checklist

In addition to release/regression testing, you need to follow
a final launch checklist to make sure all the “i”s are dotted
and the “t”s are crossed. Often, a team will launch their
project with several housekeeping items yet to be
completed. These items often fall into the awkward space
between development and content, which means no one
person or group takes responsibility for them.

Error and 404 pages need to be present, yes. But do not forget to design a 404 page: make it
useful, make it honest, don’t leave it for some throwaway template at the end of the project.

— Corey Vilhauer

Consider the following:

• URL Redirection: Is there a method in place to redirect

old URLs? Are all old/new mappings in place and
functioning?
• Error and Not Found Pages: If someone accesses a page
that doesn’t exist, what happens? If you force a server
error, what happens? Are these scenarios handled
gracefully (a “contained” error, as we discussed above), or
do they make scary noises (an “uncontained” error)?
• META and Open Graph Information: Does all your
content have adequate META tags and Open Graph data?
This isn’t visible to a browser-based user, so it often gets
overlooked.
• META File Links: There are URL paths in META and
other tags in your HTML. Things like a favicon, and Apple
Touch Icon, tile files for Microsoft Windows, custom
fonts, etc. Your link checker might not have validated
these links – are you sure all the files are there?
• ROBOTS.TXT: Is there a ROBOTS.TXT file in place to
manage search crawlers? Perhaps more importantly, if
one was in place to hide a testing environment from
Google, has it been removed?
• Caching: If you turned off caching for your testing
environment, has it been turned back on? Are you
prepared to reset the cache immediately after launching?
134

• Email: If your website sends email, does the production

environment have access to an SMTP135 server?
• Analytics and Other Tools: Are all analytics or tag
manager tools in place? These often get removed for
testing environments to avoid polluting the stats – have
they been put back?
• SSL Certificate: Do you have the SSL Certificate ready
for installation on your new hosting platform?

There are a lot of details to manage, and without a checklist

you will forget them. Make sure you have some place to
collect these items throughout your entire process.

Deployment
Done properly, the actual launch of your website shouldn’t
be stressful. (If you’re under a lot of stress and tension, the
real question is whether you’re actually ready to launch.

By this point, the project may look different than expected.

Several of your requirements may have been thrown
overboard. That’s not uncommon, and brings us back to
your backlog – approaching launch, you need to be
constantly triaging your remaining issues and fixing only
those absolutely required for launch. Some will be
sacrosanct, but others will be more fluid. They can get
pushed onto the backlog for the proverbial “Phase 2” release.
A looming deadline tends to clarify these things.

First off, please don’t wait until launch day to make your first
pushes to the production environment. Some “pre-launch”
preparation is necessary and crucial.

We talked about environments in Chapter 19: Implement

the Design. Throughout the project, your development team
moves code through multiple environments. Individual
developers will move code into the integration environment,
it is pushed to the testing environment for testing, and
sometimes it’s pushed into a pre-production environment.

This is because the final production environment often isn’t

usually available right away. Integration and testing use
lighter weight resources and are easier to modify and swap
after creation, so they can be set up on the fly. However,
production requires a more significant infrastructure
investment and more planning, which means it’s not
established right away.

Ideally, at about the two-thirds point in your project, the

development team should spin up the final production
environment, and then begin frequently pushing code.
Problems can crop up when deploying into production, and
you’ll want to ensure that you have significant lead time to
correct these problems before launch day comes around.

This “pre-launching” is possible because only very rarely is

your new website going to exist on the same computing
instance as your old website. Back in the day, we used to
have to reuse physical server hardware. This meant that we
would physically136 install a CMS on a server somewhere, so
we would have to take the existing website offline while we
spent the time to get the new website up and running.

Thankfully, this is no longer the case. Almost universally

today, the new website is developed in a parallel
environment while the current environment still serves the
old website. In fact, many organizations take this
opportunity to upgrade their computing capacity. To install
the new website in the old environment would likely cause a
downgrade in performance.

This means for a brief moment in time, your organization

will have two completed websites running right next to each
other. The entire concept of launch, then, simply boils down
to changing where your domain name points, as we
discussed in Chapter 17: Plan for Hosting.

Remember that DNS changes are not instant.

I remember a project where a very high-profile customer had a large media campaign
launching at the exact same instant as the new website. Unfortunately, their domain names
were configured to cache for 24 hours, meaning no one would see the website for many
hours after launch, in the best case.

In fact, many people didn’t see the new website until the next day. This created some
embarrassing inconsistencies in their media plan.

— Deane Barker

This has drastically lowered the stress level of launches. Not

only is the launch a simple configuration change, but if
there’s a disaster post-launch, it becomes much easier to
fallback to the previous production environment.

Additionally, ensure that your production deployments are

just as automated as all your other deployments. The last
thing you want to allow is some one-off manual process for
deploying to production. If there’s any environment deploy
that should avoid stupid mistakes, it’s your deployment to
production. There is no reason why they shouldn’t be as
automated as everything else.137

So that’s the big rule: launch early and launch often. Make
the actual launch day as boring as possible.

Post-Launch Stabilization and Testing

Earlier, we talked about the idea of regression testing, where
you test old functionality after new functionality has been
introduced.

The same is true after launch. You may think nothing has
changed since you tested right before launch, but
understand that the switch in domain names can introduce
some very strange bugs. In some cases, functionality might
be referencing the organization’s domain name (meaning it
was referring to the current – now old – website) or the pre-
production domain name, which might no longer exist.
These bugs would be invisible until the domain names
change and things start to break.

Plan on doing a complete regression test immediately post-

launch, to test all the functionality in the installation. Do not
consider yourself completely launched until this regression
test has been completed and passed. It’s amazing the
number of bugs that can be introduced simply by changing
environments.

Once your public regression test has been completed,

editors can jump in and use the system to shake out any
private bugs hidden by the CMS. Your editors will find
problems not visible to the public. The goal is to create
content, edit content, delete content, and navigate the
system without error.

In the days immediately following launch, the team needs to

be hyper-vigilant for problems. If there are problems that
are going to require a rollback to a prior version of the
website, you need to find these problems before you get too
deep into editing and content creation. One of the worst
scenarios would be to create hundreds of new content items
and perform thousands of edits only to discover a
heretofore unknown problem that would require you to
scrap the current launch and all of your content changes
with it.

Production Infrastructure Configuration

There are a few things your server administrators need
immediately post-launch that are not normally running
during pre-production.

If you’d have told me I’d be a part of a book with a section called “Production Infrastructure
Configuration,” I’d never have believed you.

— Corey Vilhauer

• Backup: There needs to be some scheduled process for

backing up the resources of the website. This includes
both the database and the file system. And, it too needs to
be tested – a backup that can’t be restored is worse than
nothing, because it provides a false sense of security.
• Monitoring: Systems need to be put in place to ensure
the website is monitored for up time. If the website
 experiences an error or downtime, the server
administrator should be notified.

Until these two systems are in place, you need to consider

your newly launched website to be at risk.

Post-Launch Operational Policy

There are some immediate resource concerns that you need
to establish. We’ll talk about larger governance concepts
later, but in the short term you need to get the team together
and ensure that everybody understands the lines of
communication.

Specifically, every member of the team needs to understand

the answers to these questions:

• If they encounter an error, who do they notify?

• Where do they log that error?
• In the event of catastrophic downtime, who is the
emergency contact?
• And for that contact, who is the technical resource that can
actually bring the environment back up? You don’t want three
project managers agreeing that an issue is technical, but
not knowing who can fix it. Make sure that everybody on
the team knows what that line of communication looks
like, and whether it is internal or if it requires an external
resource.

Blast Off!
Congratulations, it’s been a long road. Your website is
launched. Hopefully it’s stable. Now you’ll be able to move
on to larger concerns – like transitioning your team and
planning out future development.

As we’ll get into in the next few chapters, this is where the
real work starts. You’ve hopefully developed a base of
functionality and process to enable you to take a long view
of your project and plan the future out so that it aligns with
your organization.

Too many people think that launch day is the finish line. In
reality, launch day is the starting line. This is where the
digital property that you just created actually starts
providing value for the organization.

This can be exciting and terrifying, all at the same time.

Inputs and Outputs

Given that this chapter comes very late in the lifecycle of
your project, it’s safe to say that the output of this phase is a
website running in production, that has been tested for
functionality and tested for working backups and
monitoring, with a communication plan in place to deal with
errors and downtime.

Another output might be an exhausted team on the verge of

burnout. Be prepared, take a beat and collectively catch your
breath.

The Big Picture

This will likely mark the end of the project. Now it
transitions into a product or a process that needs to be
managed. Instead of working toward a single point in time
and the completion of tasks, you’ll start working toward the
achievement of overall goals.

Staffing
The duties described in this chapter will require a QA or
testing staff, even if that’s just a single person. On smaller
teams, this person may actually do double duty from the
content strategy or design teams, as long as they have an eye
for detail and are well-organized. The deployment and
launch aspects of this chapter will need to be handled by
your server administration team, or the equivalent staff that
your hosting provider has made available.

129 A married couple that Deane knows actually met while launching space shuttles. She was on
the communications team, and he worked payloads. Today, they own a web development
company. Deane tried once to get them to confirm that building websites was harder than
launching space shuttles. They were non-committal on that point.
130 “QA” stands for quality assurance, and, after migrations, it might be the most overlooked
part of a project plan.
131 From a French word that means “to sort.” It refers to the process of ordering items by their
importance.
132 Commonly called “white hat hacking,” to differentiate from people actually trying to do harm
(“black hat”).
133 When we say “scripts,” we sometimes mean programmed automated testing, but we also
mean human documentation – spreadsheets listing out the agreed upon tests, or user stories of
expected functionality based on technical specifications.
134 We talked about caching in Chapter 17: Plan for Hosting. This is when the website hangs onto
responses so it doesn’t have to regenerate them, and is therefore faster. This is good, but for
testing, you usually turn it off so everything is generated “from scratch.”
135 SMTP – Simple Mail Transfer Protocol – is responsible for moving email on and across
different networks.
136 Meaning, we actually installed a program from a CD-ROM.
137 Note, however, it’s not uncommon to have the production release manually initiated. Other
environment releases might be initiated by simply checking code into source control, but a
production deployment is significant enough that it should be initiated manually by a living,
breathing human being pressing a button somewhere.
CHAPTER 23

Plan for Post-Launch Operations

SUMMARY
An effective website depends on a collection of humans
performing roles. Who are these people, what are they being
asked to do, and how are lines of communication and
reporting established?

DOES THIS APPLY?

While we can dream about a fully automated site, that’s
impossible. You need people who can work on this site,
which means people who can create, maintain, own, and
make major decisions about the site. This chapter applies in
some way to every single possible iteration of a web project.

If you’re familiar with Top Chef – the longstanding reality

television show pitting chef vs. chef in Survivor-style
culinary elimination battles – you’re already familiar with
the difficulties of website governance. You see it every year
when it comes time for Restaurant Wars.

Restaurant Wars is a Top Chef staple: an episode-long

competition in which the yet-to-be-eliminated chefs team
up in two groups to create a pop-up restaurant from scratch.
They select an executive chef, a theme, someone to run the
front of house, six unique dishes, furnishings, and
decorations. And they have two days to execute.

Top Chef is, without question, the greatest reality program ever created. It’s pure skill and
personality without relationship drama. It’s perfect.

— Corey Vilhauer

That these teams of chefs get anything done in two days is a

wonder, but they always do. They plan their dishes, and they
create systems for expediting, and they train their staff to
their restaurant’s specific quirks.

Then they go to put it into action. Hundreds show up for a

quick service, including the four judges. And it’s always
much more difficult than it looks. Meals cannot sync with
their orders. People are left waiting for hours. Front of house
staff blows up at the executive chef. It’s high drama, and it’s
(chef’s kiss) amazing.

In real life, setting up a new restaurant takes months, if not

years. Systems are developed for moving food from one
place to another, for delivering food to the table in an
efficient and consistent manner, for sourcing and ordering
ingredients and supplies, and creating fallbacks for when
those supplies cannot make it in time. Menus are a constant
source of change, as is staff, as is management, as is client
base, as is literally everything.

It turns out that opening the doors to the restaurant is the

easy part. It’s everything that happens inside that takes a mix
of the right people, the right training, and some solid rules
and regulations.

In other words, governance.

Governance and Ownership

Governance is all about decision-making; about systems that
keep things in order, like the systems that govern our
nations, or the systems that govern our organizations. When
we talk about digital governance, we’re talking about
assigning ownership, determining the people and processes
that will manage your site, and documentation and tracking
of policies and performance.

What we’re not talking about is a thing that just … happens.

Governance is not a milestone, but a spectrum of readiness.
Because every organization is different – all unique, in their
own ways, with their own problems – governance tends to
be measured on a curve.138 This is all to say that governance
isn’t an easy subject, and this is normal. Your situation might
be weird. That’s normal, too.

It sounds complicated, and it is. See, governance is people,

and people are complicated. People need guidance, and they
hate change. They have their own points of pride separate
from the organization, and they aren’t movable and slidable
parts. You can’t just change the code on people. You can’t
save a person as a draft and come back to them later. You
can’t CTRL-Z real life.
The Three Areas of Web Governance
When it comes to your site, governance often manifests in
three key ways:

• Roles and Responsibilities: Who is actually taking care of

things on your site? Top-level strategy is fine, but under
that are a set of rote tasks, and who is doing what?
• Policy, Standards, and Workflow: What systems and
rules are in place to ensure accountability, responsibility,
and consistency across your digital ecosystem?
• Accountability, Authority, and Change: Who answers for
the content, design, functionality, and decisions therein
on your site, and how does the organization shift to meet
those needs?

Roles and Responsibilities

It should come as no surprise that your website isn’t going to
run itself. And while there are always promises of
automation and efficiency, content and design take time. The
web world is always changing, and your website is no
different.

And, more than time, it needs people.

Thankfully, you’ve already made the first steps, back in

Chapter 3: Form Your Project Team. There, we highlighted
the different people you’ll need to help make decisions
about your web project. We talked about representing
business strategy and project strategy, and we introduced the
concept of the web steering committee. Now it’s time to
make things more formal.
So, who is going to end up being on your web team?

Who Owns the Site?

How an organization maintains and updates its website
can often be a crucial game of tug of war.

On one side you have the bones of the website: the

infrastructure, which requires people specialized in
coding and, more specifically, coding this specific install.
Just as the maintenance crew at a museum needs to
understand both HVAC and the particulars of the
museum’s individual HVAC system, the IT department
needs to understand the different levels of web code.

However, the other side is focused on the purpose and

guiding principles of the website, which most often show
as content and delivery. Most – if not all – content work
comes from marketing or communications. The website
is a tool for broadcasting a message, or for promoting a
product, or for organizing a policy. The bones don’t
matter to most people who visit the site, just as the
visitors to a museum don’t care about the HVAC system:
they just care that it’s not too hot or too cold.

With both of these in mind … who ends up owning the

website? Is it the IT department? Is it marketing? Is it a
dedicated digital department? We’ll touch on this in a
little bit.

The Key Team Roles

Talking about head count in a book like this is difficult,
because every organization is different. Some organizations
have the ability to staff dozens: to build a strong web team
from a diverse set of specializations. These teams might
have dedicated content analysts, web-specific designers, and
a full team of developers.

More often, a web team is built out of a small number of

generalists: people with more general skillsets who are
responsible for multiple items within the day-to-day
operations of the site.

The number of FTE139 doesn’t matter for this. Staffing a web

team is less about the number of people, and more about
successful representation of specific roles. Often, a handful
of people – and, sometimes, external vendors – will take on
multiple roles within the internal web team, especially if
your organization is new to maintaining a larger, content
managed website.

We can’t prescribe an exact list, but your organization will

more than likely need to account for someone who can fill
one or more of the following roles:

• Product or Project Management: Responsible for

managing day-to-day and project-based maintenance and
improvements of the site.
• Content Strategy, Information Design, and Writing:
Responsible for translating business needs into site
content requirements, including organization and
creation of content.
• Data Tracking: Responsible for measuring and acting
upon site analytics and testing.
• Design: Responsible for day-to-day graphics and images,
as well as updates to existing site design.
• Front-end and Back-end Development: Responsible for
maintaining the codebase and following best practices.
• Server Operations: Responsible for maintaining uptime,
server monitoring, and security.

I wish we could be more concrete about this, but unless you are an enterprise corporation
large enough to have tiered positions within each department, some crucial (but occasional)
roles will be smashed together into one unique position. My original role at Blend, for
example, was as user experience strategist, and it consisted of three roles that I was uniquely
qualified to fill: content strategy, information architecture, and site QA.

This is not a normal set of job requirements, but it’s what worked best for us. Find people who
can fill roles, even if they don’t manifest as a traditional job description.

— Corey Vilhauer

These are just high level categories: for each of these bullets,
you can go even deeper. A site dependent upon dozens of
complex integrations from external data pools may need a
web team that’s more developer heavy, while a boutique
commerce site will need someone who can dedicate their
time to producing high-quality photography, and an
editorial or policy-focused site will want to develop a full
strategic content team.

The Core and Distributed Teams

Regardless of the team, what’s important is knowing how
they fit in with the larger organization. In Managing Chaos,140
Lisa Welchman separates those who will use and maintain a
web property into four groups:

• The Core Team: Responsible for conceptualizing,

architecting, and overseeing the full scope of a project or
 initiative. They drive strategy, they measure success, and
they build the things. They are developers, designers, and
writers, but they can also be videographers, project
managers, and data analysts.
• The Distributed Team: Beyond day-to-day work, this is
the team that’s responsible for either the edges of the core
product or distribution of external forces upon the core
product. They are department liaisons who periodically
post updates to the news feed, or they are professors
ready to update their bio page.
• Working Groups & Committees: While the core and
distributed teams may live within a specific department,
the goals and application of your website belong to the
entire organization. Working groups and committees can
go in two directions: they either help oversee the core and
distributed teams in an advisory role (in order to pull the
full organization into alignment), or they serve as smaller
opportunities for outreach, such as a working group
created within the department to research user needs for a
new intranet.
• The Extended Team: In Welchman’s book, this refers
specifically to external vendors, but we find in larger,
more complicated organizations there is a kind of
“resource borrowing,” where one department reaches
across their silos to another department for help.

Not all of these groups will come into play, and you may
find variance depending on the focus of your web team, the
amount of external vs. internal staff you want to employ,
and your overall budget. As with all things web related, your
mileage may vary.

For example, for a recent project, Blend helped advise a

health-care related organization looking to hire and create
their own content strategy team. They had the scatterings of
an existing team, but this new team was to be in place by
launch of their new content platform.

Given their ability to lean on resources around the larger

organization, and their desire to actually create their own
content team, we were able to break their staffing needs into
three distinct groups:

• The core team was dedicated to aligning digital content

across the organization, as well as creating and
maintaining content within the new content platform.
These are the content strategist, information architect,
and content operations roles, as well as the main project
manager and product owner.
• The distributed content team roles were filled by
organization-wide resources. While some of this feels like
core team work we mentioned in Welchman’s list, we
have to remember that we were helping staff a dedicated
content strategy practice, so anything outside of that
practice would fall outside of the purview of the content
team. The content team doesn’t need a dedicated
designer, or a dedicated .NET developer, for example, so
these smaller “roles” are handled by a distributed team of
already focused staff.
• Two advising groups were recommended: a web steering
committee, designed to align content direction across all
departments, and a content alignment group who is tasked
with iteratively developing a process for translating
departmental content needs into real content assets
(essentially, helping create a better workflow for each
department to get their ideas to the content team).

Remember that not every role within these groups needs to

be internally sourced; in fact, if you’re starting small – or
even from scratch – you may not want to over-hire your
department. Relying on external vendors is key to helping
find your footing, especially for distributed roles.

Internal vs. External vs. Occasional

Where these people come from is a matter of organizational
choice and budget. “Building a web team” always sounds at
first like “hiring a bunch of people,” but in reality the
industry is filled with people who are willing to help.

Specialization becomes more important as sites become

more complex. In most internal teams, specialization isn’t
the most efficient prospect. For example, very few
organizations can focus on hiring a dedicated full-time
information architect. There simply isn’t enough to justify
someone spending forty hours a week working in that field.

This means there are a handful of options for these

specialized roles. An information architect might:

• Find a full-time information architect position within a

single organization.
• Work for a web design or development shop that
provides information architecture work to multiple
organizations.
• Become a freelance consultant who provides information
architecture work to several organizations.
• Find a full-time position that includes information
architecture, and supplement these core skills with
somewhat “out-of-skill-set” tasks.

This is important to discuss because it directly relates to how

you might actually find and hire people to fill your web
team:

• There are people and organizations out there who can

help you fill a more specialized gap without hiring them
to be a part of the full-time team.
• There are people out there who are easily able to take on
more than one role at a time, despite their more
specialized nature.
• There might even be people on your team right now who
have the right skills to take on some of your web roles, but
have never been prompted.

Of course, every option has its own benefits and shortfalls:

PRO CON

Hiring They’re already here! They already They may need to be trained into a level
From understand the industry and of viability.
Within culture.

Hiring They may fit a more specific set of They don’t have any organizational
From factors. history, and unless it’s a universal industry
Outside they may not even have industry
knowledge.

Contracting They can serve in a time of need They obviously cost more per unit of time,
& Vendors for situations you do not feel and they have their own schedules and
warrant a full time or part-time agendas.
employee.

Maintaining Vendor Relationships

If the decision is made to look (or continue to look) outside
of your organization to supplement your team, the answer
will ultimately depend on what kind of vendor relationship
you’re looking for. Yes, there are shops out there that
provide the full scope of web services from discovery to
launch, but you may also look for specialization to fill in the
gaps in your own team:

• Strategic Design Partners: Focused on user research,

content strategy, user experience, and graphic design,
design partners often draw the line at front-end
development, instead focusing on the who and what of
the website.
• Marketing and Data Partners: A lot of firms bridge the
gap between building the website and marketing the
organization, providing specialized services tied to
analytics tracking, paid and social advertising, and
editorial search engine optimization.
• Implementation Partners: If you need something built,
some firms understand a specific content management
system or development task so well that they’re
specialized for that specific service: essentially, you bring
them your idea, and they’ll build whatever you’re looking
for using the best standards possible.

Please remember that experience in a specific industry does not necessarily equate to
expertise in a specific web field. If you’re building a website for your university, you don’t
necessarily need to depend on a design firm that focuses only on higher education websites.
Existing domain knowledge does not equate automatic success for your specific situation.

— Corey Vilhauer

The benefit of having an outside vendor provide guidance

from outside-looking-in viewpoint cannot be overstated:
every organization, especially as their site becomes more
familiar and their process becomes more ingrained into day-
to-day work life, risks becoming isolated from the larger
web world. When we work day-to-day on the same website,
creating the same content, we begin finding solutions to our
problems, rather than for our user’s problems. We get so
bogged down in operational work that we forget to look at
outside trends.

An external vendor can help with this, because their job is to

look at outside trends. They are not focused on the day-to-
day of your organization; instead, they are focused on using
their experience to translate the larger industry’s findings
into something that works with your processes.

They can be honest about what’s working and what’s not

working, within the boundaries of your digital policy and
specific industry needs. Which brings us to the next major
part of ownership on your new site: is your digital policy in
place?

Policy, Standards, and Workflow

Having the right people – both in terms of roles and humans
– gives your website an untapped pile of stored energy: a
coiled spring ready to let loose with creativity and
productivity. But, we all know what happens when a spring is
let loose into the open; it’s unpredictable, bouncing in any
direction it sees fit.

This is where policy and standards come in. While to some

they may feel like restricting micromanagement, policy and
standards are designed to guide that coiled spring toward a
productive outcome, directing the work of the team toward
a more ordered, less chaotic web property.

Defining Digital Policy

First, let’s talk about policy.

When it comes to digital policy – specifically, digital policy

directed toward web communications tools like your website
– the focus is on rules and boundaries. Policy is often tied to
legal requirements, and while we’re specifically talking about
how digital policy relates to your website and its content,
policy commonly also includes social media
communication, files and information systems, emails,
intranets, and digital broadcasts.

Digital and content policy is likely (or should be) a branch of

your existing organizational policy – and in fact, digital
policy should be aligned with corporate policy whenever
possible. Some of this policy will be public, visible as a link
in the footer of your site, while others may be stored away in
internal documentation for staff to understand.

Digital and content policy will usually focus on:

• Privacy and Data Collection: Often linked from the site

itself, a privacy policy at minimum alerts site visitors to
what data – anonymously or tracked – you are collecting,
and how you are using it.
• Security: The security policy might be rolled into the
privacy policy, but it also focuses on data transfer,
passwords, and secure information.
• Accessibility: What is required and promised to meet
web accessibility guidelines.
• Domain and Digital Property Management: Who
manages and owns web domains and other digital
properties including the CMS itself.
• Intellectual Policy and Copyright: What is protected
through the organization’s copyrights and how can these
 things be used?
• Web Records and Archives: What guidelines and
requirements are placed on content as it’s removed from
the site – if it can be removed at all.
• Localization and Translation: What regions, languages,
and translation methods are required for the site.

Digital policies will be created in partnership with legal and

other policy bodies within your organization, but it can
ultimately take any shape. There are no specific rules as to
what you need as a whole, but we like to point people
located in the United States to resources like Digital.gov’s
Digital Governance Policy Outline, which provides a starting
point for creation of a digital policy document.141

To stay on the safe side, always confer with your legal

representatives. They will help you determine what is
necessary and what is not.

Defining Standards
If policy is the “rules” side of governance, standards are the
“suggestions and best practices” of governance. While your
privacy policy is going to define and make promises upon a
set system of rules and regulations, defining your web
standards will help provide guidance toward everyone who
is creating content and managing the moving parts of your
website.

While these are definitely part of your overall governance

plan, we’re going to focus more on standards – specifically
written style guides and design standards – in Chapter 24:
Maintain and Improve.
Workflow: From Who to How
Talk about workflow can mean one of two things; one
system-based, one people-based.

• System-based: Within your chosen content management

system, you may have various levels of workflow
functionality, allowing for pages and blocks to be assigned
for approval, locked for editing, and pushed through
various levels of editorial guidance before it finally goes
live. When CMS vendors talk about workflow, this is what
they’re talking about.
• People-based: However, the human side of workflow is
tied to moving information from person to person.
People-based workflow focuses on how content moves
throughout the organization – the steps and people
required to take an idea and turn it into an indexable and
shareable piece of content, for example.

We won’t touch on system-based workflow. CMS workflow

tools are just that: tools. They are not created to define your
content workflow as much as they are created to help
facilitate a people-based workflow.

On the other hand, that people-based workflow? It’s messy.

While documentation of workflow often looks like a flow
chart, where a chunk of communication moves through a
series of steps, in reality it’s a bit of a tangled mess. We
imagine our content working through a series of smart
decision trees and as-needed checks and balances, but in
reality they more often look like Rube Goldberg machines,
taped together and just a few steps from disaster.

And that’s okay – workflow is meant to be refined, rather

than written in stone. Sure, workflow requires definition.
And it requires specific people at specific times. But it should
also be flexible enough to allow for someone to be, say, on
vacation, or busy with other things. It has to be agile enough
to contract when a deadline gets tighter, or expand when the
deadlines are farther in the future.

Content Operations: All of the Little Things

Finally, as we’ve learned over the past dozen or so chapters,
so many other things tie into creation and upkeep of a website
– from hosting the site, to maintaining the domain name, to
making sure files are uploaded correctly. We often think of
our website as a thing that’s created and maintained as a
whole, but in reality it consists of dozens of little tasks strung
together – which means there are dozens of little tasks that
are scattered across your organization.

At Blend, we call this “content operations.” Just as the local

Best Buy142 store requires support from an operations
department – finances, transactions, scheduling, human
resources, and management – so too does your website.
Some of this ties to the creative workflow process, and some
of it also ties to existing teams within the organization, but
it’s worth having some kind of documentation on the entire
scope of content and site operations.

Blend has developed a Web Operations Management Checklist (which you can find at
www.blendinteractive.com/globalassets/whitepapers-and-pdfs/web-operations-
management-checklist.pdf) that we use to help clients identify and solve gaps in their
governance and staffing plan long before the site launches.

— Corey Vilhauer
Essentially, governance of the entire web experience will
mean assigning roles, policy, workflow, and standards to all
of the following:

• Content Development: Who comes up with ideas? Who

creates those ideas? How are those ideas turned into
functional web pages?
• Strategic Planning: Who is responsible for making high-
level strategic changes, and how do they turn into
actionable goals?
• Analytics: Who manages this data – both in terms of
reporting and analyzing but also in terms of technical
needs?
• Style Guidelines: What guidelines are in place, but also
who maintains those guidelines?
• Workflow and Approvals: How are content, design, and
technical updates approved and moved through the
organization? We’ll talk about this in Chapter 24: Maintain
and Improve.
• Content Review: Who reviews new and existing content
for accuracy, relevancy, and outdated pages?
• Archiving: How do we handle legacy content?
• Content Logging and Auditing: How are changes tracked,
and who makes these changes?
• Permissions: Who gets to see what – both from a site
user’s standpoint and from an internal standpoint?
• Training: Who is responsible for keeping the people up
to speed on all aspects of digital communication?
• Form Handling: What processes are in place to ensure we
don’t drop or mishandle content sent to us via forms?
• User Generated Content: Who is accountable for reviews,
ratings, forums, and other user generated content?
• Technical Support: Who is permitted to make changes
and approve decisions around servers, site uptime, and
development access?

Accountability, Authority, and Change

Finally, let’s address the elephant in the room: you aren’t
creating a process around a website. You’re creating processes
around people. Which means your website is going to be only
as successful as the team itself.

We want to make this perfectly clear here: despite all the

time we spent talking about web roles and who might fill
them, we’re not talking about roles and tasks here. We’re
talking about everything that flows around that: the
adjustments and changes, the differences in skill, and the
interpersonal relationships that exist within your
organization. We’re talking about stability and growth.

Because if there’s one thing we know, we know that not

everyone’s on board with this new site. And despite all the
work we did throughout this entire book – from bringing
them into the process, to making sure they were heard, to
involving them whenever possible – buy-in is always going
to be slow.

This is just … how it is. Change is always hard. Dan and Chip
Heath, in their book Switch: How to Change Things When
Change Is Hard, say:

“Change isn’t an event; it’s a process. There is no moment when a

monkey learns to skateboard; there’s a process.”
Your team is not a group of animals; they are much smarter,
and definitely better equipped. However, your content
platform and digital alignment are also not “learning to
skateboard.” It is infinitely more complicated, and
potentially affects the entire organization.

We believe there are several ways in which teams can slowly

and incrementally ensure success as a new site and new
process is brought up to speed.

Clear Ownership and Budget

We mentioned at the start of this book, and again at the start
of this chapter, that ownership of the site is often a tug of
war.

For a smaller organization, this isn’t as much of an issue: the

website is, in essence, a capital expenditure, and it’s owned
by everyone. In larger organizations, however, the tug of war
determines who has enough influence to push decision
making in their direction. While we’d like to chalk this up to
a matter of behind-the-scenes politicking, in reality the tug
of war can lead to a very public fight.

You can imagine how this affects the ability to communicate

and promote change. If the departments and managers
responsible for this new website can’t even decide who is in
charge of it, then why should we waste our time with what is
surely going to be another waste of money and time?

So, how do we solve these issues? Who should own the

website? IT? Marketing?

The answer (and we’re so sorry to continue doing this) … is

that it depends. It depends on where funding is allocated. It
depends on your organizational charts and your existing
teams and your product and your industry. As long as your
various departments can get along and work together toward
a common good – one that’s steeped both in technological
best practices and positive user experience – it doesn’t
matter which department owns the site.

As long as it’s not both. That’s when things get messy with
regards to budget, staffing, and bragging rights.

We really can’t overstate the value of top-level support within the organization. A key task of
leadership is to set priorities for the organization. If you want to expect support from the rest
of the organization, you need that support to start from as high up the org chart as you can
manage. Sometimes, someone is going to have to swing a big stick to resolve issues and get
you what you need.

— Deane Barker

Support from Leadership

A new website is a chance to begin shifting and adjusting
some inefficiencies, drive a brand refresh, and signify a
change in the overall mood of an organization, but it can
only be this way if the leadership team outwardly supports
the new site. This means making sure leadership is speaking
positively about changes and their potential benefit, being
clear with policy and governance decisions, making sure
everyone understands what they are expected to be
accountable for, and (most importantly) pitching in
whenever they can.

A web project must be a project for everyone, from the top

down. Leadership needs to promote and support and
celebrate … and even roll up their sleeves, when the time
comes. Otherwise, it’s another tool thrown down the
corporate ladder for someone else to figure out.

Messaging and Momentum

Even with clear ownership among leadership, alignment
reaches further than just the people who make the decisions.
There must also be some level of alignment and buy-in from
those who will be affected by the new site, including site
editors, department heads, and customer service.

As we mentioned back in chapter three, front-line staff

should be kept informed of site updates and progress from
the beginning, and they should feel heard throughout the
process. But this goes beyond just ownership: this is, in
essence, a marketing campaign for your new site, and it
requires the same level of planning and thoughtfulness that
any communications plan requires. It’s just that, in this case,
your audience is internal staff, and your message is one of
change, improvement, and forward thinking.

Go back to the reasons you used to sell the idea of the

website in the first place. Maybe it’s focused on efficiency.
Maybe it’s a point of pride that shows off a new brand or
new concept. Maybe it’s just as easy as saying “the old one
was … old. Now, we’re modern.” The new site will be a source
of pain, but the pain is short term. Help them understand
that it will get better.

Web Content Training

And then, follow up that messaging with action. The people
who edit the new site are going to be thrown into a very
different world, for the most part, and they will need to be
trained to understand how to use the new system.
In a perfect world, this training happens long before you are
ready to launch – months before. Web training should be a
time to mess around with a new system; to better
understand what you’re working with in a test environment,
and then gain reps through some areas of manual web
migration. CMS training is often provided by a combination
of the content management system vendor (for out-of-the-
box functionality) and the implementer (for custom
template training).

Training in the CMS can be a frustrating task, if only because you need to learn several things
at once – you need to learn how the CMS itself works, and then you need to learn about how
the different content types within the CMS work together to make whatever page you’re
trying to make, and then on top of that you need to learn about all of the additional new
tools and gadgets attached to the site.

— Corey Vilhauer

Understand that training exists on two levels — learning the

CMS itself, and learning the website that was built with the
CMS. You need both. More people need the latter, certainly,
but if you don’t have an expert external partner, then there
needs to be some people in your organization who know the
CMS down to the bones so they can help resolve issues.

Beyond learning about the tool itself, you’ll often need to

communicate a shift in other areas of your workflow:

• Internal training: understanding workflow and

communicating changes to how content is written and
maintained
• Editorial content training: understanding the basics of
writing for the web, including plain language and
accessibility
• Ongoing industry training: keeping abreast of the larger
content, digital marketing, and analytics industries

For an in-house web team to be efficient, they must have a

chance to learn beyond the office. Attending conferences,
viewing webinars, joining industry groups, and simply trying
to expand their knowledge through industry education is an
important touchpoint for growth within an industry that
changes all the time.

So when you begin talking about change, also talk about how
you will help them make that change. Talk not just about
training the CMS, but training their strategic thinking within
the industry as a whole.

People Are Hard

There’s no way to get around this: people are hard to deal
with. Trust me, you are no different. You have your own
expectations and your own routines. You feel threatened
when someone else dictates how you will do your work. You
bristle when potential change looks more like change for
change’s sake.

But your new web project? It’s just a pile of code. Like a set
of puppets, that web project only does what you help it do:
its functionality is a set of strings that you pull. And like
those fledgling concepts during Restaurant Wars, they are
utterly incapable of running without the right systems,
people, and policies in place.

But when they’re in place? Those systems, people, and

policies will help keep this new website working long past
the point you thought it could. We’ll talk about that in the
next chapter – the last chapter!
Inputs and Outputs
You’ll need a bit of knowledge around what roles you’d like
to fill before you can start filling those roles, and much of
that knowledge will be tied to understanding budget,
organizational structure, and the overall environment.
Which makes the biggest input an issue of knowledge and
ownership based on the functional needs of your new site.

And the output? It’s a team of people who own the site,
manage the site, and follow the policies created for the site.
No big deal, right?

The Big Picture

Honestly, planning and execution of site governance
happens parallel to site planning, design, and build, and in
fact should be in place (with some exceptions) and rolling in
time for the site to be launched. However, we also
understand that governance changes take time. That’s okay.

Staffing
This is all about staffing. But who staffs the staff? Someone’s
going to make the formal staffing choices, whether it’s the
human relations department or the communications
department.

138 Literally, it’s called a “maturity curve.” Lisa Welchman has a great digital governance maturity
curve in her book Managing Chaos.
139 Full-Time Employees. Sometimes “Full-Time Equivalents,” meaning two employees working
half-time are equal to 1 FTE.
140 Lisa’s book, Managing Chaos, is a stone cold classic in the field of digital operations and
governance, and it should be a must read after you’ve read this chapter.
141 Obviously, not every organization needs to dive as deep as those entrenched within the
United States government.
142 Both Deane and Corey are former employees of Best Buy store #17 in Sioux Falls, SD. Their
time working there overlapped for a single summer. Ask Corey about the Nintendo 64 launch
sometime.
CHAPTER 24

Maintain and Improve

SUMMARY
And the real work begins: how to manage the support and
maintenance process, circulate and check new content, and
keep the site fresh long after launch day.

DOES THIS APPLY?

Yes, yes, a million times yes. If you don’t maintain your site
after launch, then you might as well have given away all of
that money and time you’ve just spent. In fact, next time,
just call us up. We’ll take the money.

When you buy a new car, its value drops the second you
drive it off the lot. This isn’t just a cute saying: it’s reality.
That formerly new vehicle is now identified as “pre-owned.”
It’s potential as a maintainable investment disappears. It’s
now just a thing you’ll get rid of when it’s time to upgrade.
This is not true when purchasing a home. Again, in most
cases, a home is an investment. Home values have increased
beyond inflation every decade since before both of this
book’s authors were born, and they show no sign of dipping.
You don’t buy a house and watch its value drop. Instead, you
begin the work of maintaining and improving the value of
that home.

We have a habit of thinking our websites are cars. We drive

them to their limit and make cursory repairs when we need
to, but even if we diligently maintain them, following the
manufacturer’s suggestions to the letter, they lose value and
eventually need to be replaced. Some organizations make
replacements every two or three years. Some switch every
time the license is up. The sites are seen as disposable, which
is the very antithesis of what we’ve been talking about
throughout this book.

In a perfect situation, our websites are homes. We use this

analogy all the time – but the truth is, just like in a home,
basic and ongoing maintenance will help preserve its value,
and well intentioned improvement should actually increase
its value. It becomes a central meeting place for content, and
as the organization matures, the site is able to mature along
with it. When we do adjust design or move on to a new CMS,
we’ve done work at a base level that will carry on into the
future.

Of course, websites are not disposable, nor are they thirty-

year investments. In reality, most websites land somewhere
in between. Even with the best intentions, a website will
begin to creak and groan under the weight of new additions
and content changes, which means they do ultimately have a
shelf life. But if we’re purposely planning and adjusting a site
for the long haul, there’s little to think we can’t maintain a
site for several years.
Let’s talk about what happens once that site launches and
you’re heading into the future. When that site goes from a
one-time project to an ongoing product.

Transitioning from Project to Product

Unless you are part of a larger organization with an internal
web design and development department, you probably
view your website as a project. You have engaged in a project
timeline, you have worked with a project team, and once the
site has launched you can say the project is complete. You
started with no site (or an old, outdated site) and now you
have a new one.

This is very excellent news. Congratulations, new site owner.

But you know what comes next. The launch of a new site is
indeed the end of that particular project. But it is also the
start of your new product.

Products are designed to solve problems. They are given

value and attention, and they are given resources. Products
are here to last, and they require constant improvement to
stay competitive. Where throughout this book we’ve talked
about building a site designed to accomplish certain
organizational goals, we now adjust our strategy toward
upkeep. There are two things about upkeep, though:

1. It does not happen for free. You need to create a budget

and assign attention in order to keep things moving.
2. It does not happen on its own. You need to make sure
the website is seen as a tool and process connected to
overall organizational communication, not just another
channel.
This is a drastic change in our mindset. We had a finish line,
but that finish line was always temporary. You’ve finished the
race, but you need to keep training for the next one.

Your Web Roadmap

When you’ve got a deadline, it’s easy – and often crucial – to
create a minimum viable product,143 or the bare minimum of a
site acceptable for launch. The build of the site will go on
forever, if allowed – websites, content, and organizational
needs shift incrementally over time, no matter how much
planning you put in, and there’s a time when your team just
needs to say “this is what we’re launching with.”

While minimum viable products are okay for the initial

launch, they typically do not address the entire scope of our
communication goals – hence, the term “minimum viable.”
They are enough, and while they can be celebrated, they
cannot be rested upon. From the moment that minimum
viable product is launched, you begin the longer road toward
ongoing maintenance.

Of course, just as you can’t create everything at once when

the site is a new project, you also can’t suddenly get
everything done at once when it’s an ongoing product. You
need a roadmap to help you plan, prioritize, and budget for
ongoing and future adjustments and additions.

Depending on where your site is when it goes live, you may

have different levels of future adjustments and additions:

• Backlog Work: The stuff that didn’t get finished before

launch. Small bugs, issues with real content, etc.
• Crucial “Phase Two” Work: Often technology focused,
these are crucial features that were saved for post-launch
 in order to reach a minimum viable product.
• “Future Phase” Enhancements: Also often technology
focused, future phase enhancements are known additions
and improvements scheduled for further down the line.
They are often, on their own, entire web projects –
additions of a digital asset management (DAM) system, or
implementation of a customer relationship management
(CRM) service.
• Content Maintenance: The purpose, relevancy, and
accuracy of your content constantly shifts and changes,
and that doesn’t stop at launch.
• Organizational Maintenance and Change: Despite your
planning, you’ll never achieve fully efficient governance
at launch. People take time to change, and your new site is
a major change.
• New Technical Requirements: A new site may also bring
new technological needs, some of which you never had to
worry about before.

There’s a lot still to figure out after launch, even if you have
meticulously planned beforehand. Prioritization is key, lest
your team give up before they’ve had a chance to grow.

Prioritizing Post-Launch
Ultimately, you should treat your new site the same way you
would a company budget or employee reviews: annually
setting goals, and periodically checking in on progress
toward those goals.

This is crucial, because your site doesn’t automatically

update or notify you of concerns. You have to make
decisions from here on out. Every week your site is live,
you’ll notice something you want to change. Maybe you’ll
want to adjust a section of content, but need to wait for your
writer to free up some time. Or you’ll want to adjust some
colors. You might find a dormant bug, or something that’s
broken now that you’ve upgraded to a new version of your
CMS.

Your issues list will vary wildly as these changes sprout up;
you will have things as small as updating a line of text in the
site editor, to things as large as installing and training your
team on a new digital asset management system. In order to
prioritize you’ll need to ask about:

• Audience and Outcomes: Will this solve a major problem

for top-tier audiences, or is this a periphery issue for
tertiary site users?
• Time: Can this be done quickly, or will it take a long
time?
• Capacity: Can this be handled now, or is the
person/group responsible for it busy for a while?
• Dependencies: Can this be done by a single person, or
does a larger team need to work together?
• Complexity: Is this a basic issue that simply needs
priority, or is this a complex issue that requires a larger
plan?
• Skill: Can this be handled within someone’s existing skill
set, or do we need to hire someone to help?

We don’t explicitly talk about budget, because budget is

implied when it comes to complexity and skill – the more
complex and the higher level of skill required to bring in,
the more something will cost.
Your issues list is going to bring a sudden sense of anxiety.
Seeing all of your to-dos in one place can be frightening.
Knowing that you can’t take on everything at once, you’ll
need to begin balancing quick wins with top audience needs.

Annual and Quarterly Planning

What we’ve often suggested is treating the website as you
would any other quarterly initiative. Leaning heavily on
your web steering committee and scheduling strategic web
planning sessions every year, with check-ins every quarter.

From here, split up your tasks into long-term projects and

easy wins. If you’re working with an existing vendor or an
in-house team, long-term projects are schedulable, require
budget or time, and may require several different people
from different teams. On the other hand, your easy wins are
things that just need to be prioritized and done – an
automated update to a plugin, or getting information for a
new page, or getting some information from your analytics.

This is your web maintenance roadmap. For this quarter,

you have your marching orders, and you can see what goals
are needed for the upcoming year. Every quarter, you’re
going to revisit what you did, what you couldn’t do, and
where those longer-term goals are sitting, until you reach a
year and you kind of reset.

Serious Work for Serious Sites

These annual planning sessions are serious. They are not
just about throwing ideas around: they are about
maintaining the integrity of a business asset.
 Just as you may have a maintenance team that
determines the best time to make updates to HVAC, or a
human relations team that keeps up on workplace trends
that could potentially cause liability, your web team is
going beyond a “bells and whistles wish list.” They are
driving and maintaining the business value of your
content.

At least annually, revisit the site with a mind toward

constant evolution. Develop a high-level roadmap for
what needs to be worked on in the next year, and
prioritize budget around that. This may be a half-day
workshop with your core team, or you can bring in a
trusted support vendor to help prioritize and give an
outside-the-industry look at your existing platform.

This planning helps shape the future of the site. But what
does that future look like? Ultimately, when we talk about
maintenance and improvement, we are talking about three
key areas of your site:

• The Content: Auditing, maintaining, and updating

content on the site to help keep things as up to date as
possible.
• The People: Ongoing training and continuing education
to help maintain and build upon governance of the site.
• The Site Itself: Adjustments to design and development
to serve new audiences, new business lines, or new
technology.

The Content: Maintaining and

Creating Content That Works
Maintenance of content is, in reality, a full-time job – in fact,
it’s often multiple full-time jobs, which is why so many
successful organizations have a full team of writers, web
operations specialists, and content analytics simply
maintaining communication between your organization and
your customers.

While a large chunk of this maintenance is simply writing –

specifically, creating new content for the website – there are
a handful of tools and techniques that have become
dedicated standard practice around content creation and
maintenance.

Rolling Content Audits

Knowing the status of every page on your site might feel like
a bit of an overwhelming project, but the weight of outdated
content – how it muddles up search results, provides
misinformation, and complicated deeper-level navigation –
can be even more harmful.

We already talked about content audits in Chapter 7: Know

Your Content, but we’re taking that one step further here;
while that chapter focused on what content you have, this
chapter is focused on ongoing maintenance. The goals are
the same: looking for and rooting out ROT (redundant,
outdated, trivial) content, except that “looking and rooting”
is a part of a constant process, rather than a one-time task.

Instead of tackling the entire content audit all at once –

which requires a level of focus that most people won’t have
as a part of their day-to-day responsibilities – the rolling
content audit breaks a content audit into small pieces,
theoretically rolling it out over time.

Let’s use a university as an example. The typical university

marketing team team has serious time restrictions – both in
the amount of time they can spend on things and in the time
frame they can work. Course catalogs, recruitment season,
on-site registrations – these things take up time, and push
back the ability to focus deeply on something like a
quarterly or annual content audit.

So, instead, we break the job into smaller pieces:

• Prioritize Content: The university communications team

can refer to analytics data to determine which pages get
the most traffic, and make sure these pages (and the
sections they belong to) are a top focus.
• Delegate and Distribute: Content from the course catalog
can be checked by the communications team, sure, but it’s
already being edited and maintained by admissions, so
let’s keep them in charge of auditing site content.
• Break Into Pieces: Instead of slogging through the entire
site, the team should tackle one section per month, or
even more staggered if the schedule requires it. If the
university team knows there’s a big communications push
just before each semester, they can keep those months
free from auditing; likewise, in the slower summer
months, put a little more attention on a larger chunk of
content.

The idea of a “rolling” content audit is just that: you never

end the audit. You just continue to roll through content over
and over again. And while you may be constantly auditing,
you’re still only hitting each page once every several months
(or even years for less important content), thus keeping it a
more manageable exercise.

Editorial Calendars and Triggers

But what about new content? While some sites rely on
content that’s tied to products and services – content created
as needed and updated only when those products and
services are updated – others base their output on ongoing
updates, such as blog posts, white papers, and other sharable
and searchable content.

The most effective way to organize content publishing is

through some kind of editorial calendar, in which your
content is scheduled in advance and tracked for the future.
Editorial calendars can be detailed and complex, or they
might just be a spreadsheet on your computer with a few
months’ worth of ideas. Regardless, they will help you
schedule and organize any number of editorial content
needs, such as:

• Frequency: How often are you posting content?

• Topic: What are you writing about?
• Purpose: What are we trying to accomplish with this
content?
• Format: Is this an article, or a white paper, or a product
testimonial?
• Related Assets: Does this new content relate to any
existing content?
• Topic Categories and Keywords: What main
organizational concepts does this content cover?
• Important Dates: How does this content fit in with
industry or organizational events or trends?
• Author: In a multi-author environment, who will be
writing this content?
• Editorial Deadlines: When is this content due?
• Current Status: If being used as a workflow tracking tool,
what status does this content current hold? In process,
ready for edit, or ready for publication?
• Call to Action: Is this content directly tied to a specific
call to action?
• Social Media Channels: How will we move this across
different channels?

That’s a lot, but your results may vary. What’s important to

keep in mind is that an editorial calendar is only useful if it
ties to your organization’s workflow and content needs. You can
download dozens of different editorial calendar worksheets,
but they may not fit with your team’s design or publishing
cadence. In fact, not every site can benefit from an editorial
calendar, and smaller sites (or sites that deal with constant
change fueled by outside sources) fall victim to a kind of
“over-planning” syndrome, in which the organization of the
content is more restricting and time-consuming than just
writing when it’s time to write.

What’s more, you don’t always get to plan. For those

situations when you are writing reactively, you can turn to
editorial triggers, which are a kind of recipe for quickly and
efficiently publishing “right now” content on your site. An
editorial trigger takes key points from above – author,
editorial deadlines, format, etc. – and removes the concept
of a date.

Instead, editorial triggers are tied to immediate actionable

workflow – knowing who will handle each part and when
they will handle it. Rather than saying, “This will publish on
March 13th,” we are now saying, “This will publish five days
from completion of a new product, and these are the
timeframes we will work within.” It outlines the approval
process, image needs, and content types – essentially,
everything you need to quickly get a piece of content up. An
example might look like this:

NEW PRODUCT CONTENT:

Task Role Timing

Gather information on new product based on New Product copy Web Editor 2 Days
deck

Upload initial content to website using placeholder images Web Editor 1 Day

APPROVAL NEEDED: Initial approval of content required Product

Manager

Create product images for all sizes: 450px, 900px, and banner Photographer 1 Day

FINAL APPROVAL Lead Editor 1 Day

In short, if you need to organize a bunch of content for the

future, you might use a calendar. If you need to build a
process for timely creation of non-scheduled content, such
as posting a new product, you might use an editorial trigger.
You might need both. You might need neither. But now you
know what to do in either case.

Styles and Branding

When we talk about styles and branding, we’re really talking
about style guides and brand standards.

• Style Guides: Expectations and guidelines around

language, including accepted spellings, industry terms,
written voice and tone, and approved brand verbiage.
• Brand Standards: Expectations and guidelines around
 visual elements, including brand colors, logo treatment,
fonts, headings, images, and the context therein.

Some style and branding standards line up with the legal

trappings of your digital policy, such as accepted use of
trademarks, writing and designing for accessibility, and
providing clear notification of data collection from A/B
testing or analytics work.

On the other hand, style and branding is more likely to be

tied to maintaining voice, tone, brand colors, and logo
treatments. In this sense, style and branding define how
something should be created, rather than what can and
cannot be done.

Style guides and brand standards are, by nature, unique,

because they tie directly to an organization’s identity. At
their most simple, writing style guides are built upon a more
standard style guide – The Yahoo! Style Guide, or the Associated
Press Stylebook – with additional organization- and industry-
specific terms added on top. Brand and design standards for
the web are built upon the organization’s brand and design
standards – logo treatment, fonts, colors – and adapted to
include digital image guidelines and sizes, CMS recipes144 for
creating on-brand templates, and acceptable use of headings.

Content Measurement, Focus, and

Improvement
When we install a content management system, there’s a
good chance we’ve also installed some fun tools. We’re
equipped to collect complex data, or to A/B test our home
page design, or personalize content down to the user. And
because we’ve paid for and sometimes used these features to
sell the idea of a new CMS to the corporate suite, we’re eager
to start using them.

And you should. But within reason, and within the scope of
your existing workflow.

In most cases, getting to know and understand the new site –

and sometimes the CMS itself – is a significant enough
culture change to warrant growing pains. Your editorial
team, your writers, your leadership – they’re all figuring out
how the new system works within the larger scope of
communications. Adding new processes like maintaining
analytics data and managing complex personalization will
add an extra – and unneeded – level of stress.

You will get there, but let the site ease in a bit before you go
all out. Here are some of the things you might start working
on once you’ve settled into the site:

• Content Measurement: Referring back to Chapter 8:

Gather Insight From Your Metrics, and with a solid
understanding of what your organization needs to be
successful, you pair business needs with data from your
site users to help drive them toward their needs – and
your messaging.
• A/B Testing: Once you’ve established a baseline, you can
start making tweaks here and there and measuring their
success through A/B testing.
• Content and Usability Testing: Testing goes beyond the
CMS – it also means reaching out to actual humans and
seeing how they interpret, travel through, and connect
with your site and its content.
• Personalization: Finally, you’ll get to use all those cool
tools that are built into your content management system.
Understand that the fussier and more focused your
 personalization efforts are, the more effort (and larger risk
of failure) you build. Start with some general
personalization buckets – say, anyone arriving from
Monster.com gets a banner leading them directly to the
jobs section of the site – and dive deeper only when
necessary.

Additionally, reach out for consistent feedback from your

customer experience (CX) group, if you have one, especially
as it relates to web content and navigation. A quarterly
feedback cycle should begin at the very least, with a monthly
or bi-weekly one set up for CX-related content projects.

The Site Itself: Adjustments to Your

Big Investment
While content is king, the site itself is the vessel the content
travels in. Passengers on a ship are clearly “the point,” but
the ship itself is “the thing that keeps everyone from
drowning,” so you need to keep it in good working order.

Maintaining the Implementation

Let’s say the mechanics of your site never change, meaning
the functionality and implementation you launched with
should still work in largely the same way ten years later. You
intend to change nothing.

It’s still not realistic to think you’ll never have to do anything

to ensure this happens. Unless your website is a self-
contained technical bubble, with no external dependencies,
and it uses the lowest-level technical requirements possible
– meaning, it’s statically generated HTML running on the
most stripped down web server – then you’re going to have
to look after it.

Content Adaptation
Here are some examples of situations where content might
cause your website to change the way it functions, even
though no code has changed.

• Content Edge Cases: Your editors might publish a

content format you didn’t expect and didn’t account for.
What happens when the body of an article is just one
image? If the search indexer doesn’t find any text, perhaps
it won’t index the article at all. If not, you might not know
about it until someone calls you and says, “I can’t find my
article in search …”
• Unplanned Content Needs: Sometimes, you don’t have a
one-off edge case, but rather a genuine, continuing
content need that wasn’t foreseen. What if an editor wants
to publish 100 pages in sequence, like chapters in a book?
At the bottom of every page, there should be next/prev
links so the user can navigate through the content. It
would be nice if it would respond to swipe gestures on
mobile, too. This is a sincere need, and you can see the
value, but you didn’t account for it.
• Rogue Editors: If your editors don’t like how your CMS
works, they might “go rogue” and try to force the CMS to
fit what they want it to do. An editor who doesn’t like the
bullet style in the CSS might decide to upload their own
image and use it at the front of every line. This is fine,
until the text starts to wrap weirdly on mobile screens and
someone notices. “Whitespace hacking” is common too –
editors don’t like how some text flows, so they insert a
bunch of “hard” line breaks to make it work the way they
want. While it’s tempting to just admonish editors and
 move on, you may want to investigate why the editor felt
the need to do that – do they have a genuine need that
can be accomodated?

In each of these cases, the container – meaning, the website

– has not changed. What changed was content that caused
the container to react in ways you didn’t expect. Nothing has
“changed,” but things still changed.

Sometimes you evaluate a situation and realize you just

didn’t plan for it. It’s not a one off, but a genuine repeatable
issue. In these situations, you need to evaluate whether the
issue warrants deeper technical work.

CMS Upgrades
If you’re using a packaged CMS – which you are, unless you
built your own – then you need to account for the fact that
software will change over time. The organization behind the
software, be it an open source community or a commercial
vendor, will make changes to that software, both to fix
functional bugs and security problems and to add new
features.

New versions of software are usually packaged into what are

called releases. Most vendors will have a published release
schedule, which is a defined interval in which they bundle up
new changes and release them as a new packaged version of
the software.

Most vendors will try to remain on this release schedule,

with the exception of hotfixes, which are changes to the
software deemed so important that they cannot wait for a
scheduled release cycle. These hotfix changes are usually
always security related, as an unpatched security issue in the
wild can be disastrous, especially when the vendor has a
large installed customer base. These problems have to be
resolved before they cause widespread problems across the
web.145

Each time a new version of your software is released, you

need to review the release notes to determine what changed
and whether or not it makes sense for you to upgrade your
installation of the software. Sometimes new releases offer
critical functionality or fix bugs that are causing you
problems, but sometimes you’ve never encountered the bug
that was fixed and the new features just aren’t worth the
trouble.

Keep in mind that upgrades aren’t free, even if the software

vendor doesn’t charge for them. If you have an installed
version of the software – regardless of where it’s hosted – it
will usually take developer effort to install a new upgrade. A
developer will need to download the new code or libraries
from the vendor, install them into a development
environment, then perform a full scale regression test to
ensure that everything that was built during the original
implementation still works.

If you’re using SaaS software – meaning software you

simply rent as a service – then the upgrade might simply
be made for you, automatically. This sounds fantastic,
but know that the new version of the software will still
likely need to interact with some configuration or code
you have created, like your templating code. Breaking
changes (discussed below) can still happen, and,
unfortunately, you might not be able to delay a release.

Occasionally, you might find that a new version of your

software breaks some critical aspect of your implementation
that you cannot live without. You might need to find a new
way to accomplish whatever it was you needed. Other times
you might find a feature of the software you enjoyed has
been removed, and you need to determine whether or not
you can live without it. These situations are known as
“breaking changes,” and they’re the bane of working with
packaged software.

Vendors are normally very communicative about breaking

changes. In the release notes for a new version, they’ll
specifically call out changes that might cause existing
implementations to have problems. Additionally, good
vendors will provide long lead times for them – they’ll
notify you months in advance that a breaking change is
coming, and give you ample time to “vaccinate” your
implementation against those changes by removing or
changing code that might break.

This section should demonstrate that you have to remain connected to your CMS
ecosystem. If you’ve never read any information the CMS vendor sends you, or never engage
with the community around your open source CMS, and you just blindly install a new version
… well, then you kinda deserve what’s coming to you.

— Deane Barker

Unfortunately, software upgrades tend to be cumulative. If

you have a problem with a Release X of the software, you
can’t just skip that version and install Release Y, because the
next one will either assume you installed Release X, or it will
go ahead and retroactively install Release X for you.

Sure, you can choose to never upgrade your software, but

remember that it’s running on a “stack” of technologies – a
web server, database server, and operating system – and it’s
into a large paradigm of the web itself. Occasionally, an
underlying technology in the stack will change, or perhaps
the protocols of the web might change in such a way that the
CMS needs to change as well.

In short, the only CMS that never needs to change is one that
never interacts with the world around it. This would be a
rare and likely useless thing.

Maintaining Integrations
Integrations introduce complications. Whenever you
connect your CMS to another system, you bind the systems
together so that the functionality provided by that
combination will sink or swim as a team.

Back in Chapter 14: Know Your Integrations we discussed the

concept of “runtime risk,” which is the risk that the two
systems will have problems interacting after their initial
development and launch. Besides simple network
connectivity issues, the systems communicate via a
“protocol” which is agreement on how they intend to share
information. These protocols can change over time. One
system or another can change its architecture to require new
information, or it may release new functionality, or a limited
functionality that exists.

How an integration is architected has an enormous effect on

how stable it is over time. The riskiest integrations are ones
that require real-time connectivity. In these situations, a
human makes a request of your website which then turns
around and makes a request to the integrated system. Your
website has to wait for the external request to respond,
which means the human has to wait for both your website
and the external integration to respond.
It’s not uncommon to find situations where your website is
perfectly fine, but the external system has a problem, or the
external system is fine but the communication between the two
systems has a problem. As we said before, whenever you
connect your CMS to another system you open up an
entirely new category of problems.

Besides upgrade issues, persistent downtime or support

issues will cause you to rework some integrations over time.
And, unfortunately, sometimes you’ll find that an
integration with a particular external system is consistently
unstable, and you’ll need to back up and rethink whether it’s
worth the risk at all.

The People: Training and

Improvement Planning
If there’s been any recurring theme throughout this book,
it’s that the web process isn’t run by design trends or search
engines or content management systems – it’s run by people.
Which means the best thing you can do to maintain your
new web product is to back it with good people empowered
to learn great things.

We talked about some of this in Chapter 23: Plan for Post-

Launch Operations – to maintain a healthy site, someone
needs to be in charge of the things that matter, and
accountable for the things that don’t. This means keeping
ahead of trends, understanding the tools we’re given, and
having the power to make change when change is needed –
and to know when staying put is good enough.

Understanding Our New Tools

Understanding our site – whether it’s the content
management system, the integrations we rely on for external
data, or the tools we use to maintain editorial process –
seems a bit too obvious. But think back to other situations in
which you purchase an expensive tool. When you bought
your last refrigerator, did someone grill you on whether you
know how to adjust the temperature? When you bought a
car, did someone painstakingly teach you how to adjust the
mirrors and set the cruise control?

Yet, in the case of a website, there’s a difference between

being trained on a tool and understanding the tool, and this
is the line in which a successful site can often be drawn.
Understanding your content management system doesn’t
just mean knowing the five steps to create a blog post – it
means understanding why those steps matter.

This takes training – real training, not just a show-and-tell of

CMS functions – and it takes real documentation. Because
when it comes time to train someone else two years down
the line, you want to still know the why behind certain
settings and fields … otherwise, they’re quickly overlooked
and deemed unnecessary.

Understanding the Industry

In order to understand those tools, we often need to have a
better idea of the industry itself. Which means we need to
actively train ourselves and our team to be fully aware of the
areas in which we work. The person in charge of editing
content should know, at minimum:

• Why it matters to include proper META information.

• How to create content in a way that is easily readable and
accessible.
• How often to review content and why it’s important.
• What metrics matter and how they tie to business goals.

It’s okay if they (or you) don’t know this when they (or you)
start. Please repeat after me: It’s okay to still have things to
learn.

There’s a wide and varied set of books, conferences,

webinars, and even local groups and resources that will help
you and your team keep up to date on what’s happening in
the world of the World Wide Web, and while sometimes it
might seem overwhelming and it will often feel as though
you’re way behind the curve, know that, no matter what, you
must keep learning.

Training should focus in two directions:

1. Enhancing current skills

2. Exposing new trends and content needs

Because your team might be small, remember that

promoting a generalist agenda can be beneficial. Most teams
can’t hire a dedicated content analyst or information
architect, let alone a hyper-specialized expert. All members
of your team will need to fold in new trends, create
redundancies, and simply be ready to learn more.

Understanding Momentum
Finally, know that people are driven by example. They will
follow momentum. They will work hard on things that they
know are worth the time; things that are actively promoted,
given attention, and encouraged to be improved.
Momentum means more than just keeping a full backlog of
potential fixes. As we’ve mentioned before, the business
value of a website is directly tied to what you do with it and
how you improve it over time.

• Constantly communicate the value of the site itself and

why it’s important. Explain the goals and help people get
invested.
• Ask people to help out where they can. This does not
mean providing every frontline employee with a login. It
does mean making sure the right people are consulted on
the part of the site they care about.
• Keep people up to date on new items on the website. You
don’t have to promote every item, but be clear about
when new sections or major changes come through. Show
that the site is important and active.
• Make sure outdated content is relatively undiscoverable
or archived. Nothing says “Oh, we don’t really care about
this anymore!” than stumbling across some piece of
content that’s been outdated for three years.

More than anything, make sure the site isn’t just a thing you
use to post new promotional banners.

You’ve gotten so far. You’ve built this site as an extension of

your mission; your vision for how your organization will
communicate into the future. You’ve sweated the details in
meetings, with committees, through deadlines; you’ve
gotten into fights, you’ve maybe come to tears, you’ve stayed
up late wondering if each decision is the right one. You’ve
scoured vendor requirements. You’ve argued over which
title to keep, which page to keep, which function to keep.
You’ve written and rewritten and deleted thousands of
words, and you’ve tweaked and re-tweaked and then
returned to some design element. You have spent weeks
(months!) waiting and working and negotiating and bringing
everyone together to make one final push for this site to
become a reality. For this site to become real.

You’ve taken a break for a few days. You’ve celebrated a

launch. You’ve doled out some tasks. And now it’s time to get
back to work.

Now’s not the time to stop that momentum. Instead, it’s time
to use that momentum to keep going. Strong. Always
changing. Into the future with your new web product.

Inputs and Outputs

This seems obvious, but the input is everything you’ve learned
and handled in the previous twenty-three chapters. It’s the
mission and purpose of the site. It’s the team you’ve brought
together to handle content updates, development changes,
and design improvements. It’s the content itself, as well as
the cadence of that content. It’s people and machines and
words and literally everything we’ve talked about.

And the output? A site that continues providing business value for
a long time.

The Big Picture

By definition, maintenance of the site happens after the site
has launched.

Staffing
We talk about the team you might hire in the governance
chapter – you’ll want someone who can manage both the
content and the people who write and edit the content,
you’re going to want those writers and editors, and you’ll
probably need someone to help track and analyze how users
travel around the site and accomplish their needs. You’ll
want a design and development team, too – internal or
external, depending on your organizational makeup.

143 Often referred to as an “MVP,” as in, “What’s the least we can deliver to get to an MVP?”
144 A CMS recipe is a type of documentation that outlines step-by-step the pages, blocks, and
fields needed to create a specific template within your content management system.
145 For example, WordPress powers almost one-quarter of the world’s websites. A gaping
security hole in WordPress might allow someone to take control of an entire web server, which
means a huge portion of the computers that form the fabric of the web itself could be at risk.
CONCLUSION

The End of the Beginning

We hope we haven’t caused you a boatload of pent-up
anxiety. We hope that you haven’t gotten to this point only
to be on the verge of bursting because there’s so much to
think about that you can’t imagine how you’re going to bring
it all together.

Take a deep breath. It’s not like that.

The way the world is going these days, we tend to get

trapped in binary thinking. Something is either right or it’s
wrong. Good or bad. Success or failure.

However, the truth of anything is often more analog. Instead

of a simple true or false, the reality is usually a gradient.
These things aren’t like soccer, where the ball is either in the
goal or not, but maybe more like horseshoes where you
might not throw a “ringer,” but rather you just try to get as
close to the stake as possible.

The end result of your project is analog, not binary. Even if

you sat down before the project was planned and defined
clear, quantifiable goals, there are dozens of other resulting
factors to consider when trying to determine if you
succeeded or failed.

• Did you come in under budget? Did you launch on time?

• Did the stakeholders like the result?
• Did the result improve your brand perception among
your customers?
• How stable and maintainable is the result?
• How does it compare to what your competitors have
done?
• What is the mental, emotional, and organizational state of
the team that finished the project?
• How reasonable and considered is the plan for continued
development?

You can’t force-feed all these factors into a simple value

judgment then spit out a verdict. It’s probably more like
throwing a bunch of things into a pot of gumbo and hoping
the result tastes good. Quality ingredients and the chef’s
experience play a huge part, but no one quite knows what
the end result is until they finish their bowl.

Back in Chapter 1: Know the Scope of the Project, we offered

this as a clarifying question:

Six months after this project has ended, what has to have
happened for you to think the project was worth doing?

All things considered, was it worth it? Were the costs worth
the benefits? Maybe there were both unexpected costs and
benefits – these projects have a tendency to go in directions
you didn’t plan. But, taking everything into account, has the
organization improved enough after the launch to justify the
effort that went into getting there?

This might seem vague, but we hope this takes some of the
pressure off you. These projects are complicated. They’re a
symphony (or cacophony) of human emotion, technical
capabilities, and organizational mettle. Don’t think you need
to jump out of an airplane and land on a dime. Just get on
the ground.

The real work starts the day after you launch. Rather than a
clear, bounded project with a countdown to the end, you
start fresh, and can begin delivering on the promises you
made to the organization. You can test out new features and
capabilities, see what works, what doesn’t, and how you
should modify your people and processes.

You tweak and adjust. Stick and move. Evaluate and react.
To restate what we talked about in Chapter 24: Maintain and
Improve:

• Be prepared to concede that some things just don’t work

as well as you hoped. When it’s necessary, kill your
darlings.
• Be ready to work through human processes while people
adjust to the new state.
• Know that while these projects lead up to and end with a
Big Bang, it’s the incremental work that you do in the
following year that will reveal the true value.

Atul Gawande is a surgeon and health writer for The New

Yorker. He wrote once about his decision to become a
surgeon:

I was drawn to medicine by the aura of heroism – by the chance

to charge in and solve a dangerous problem.

This, of course, is every episode of Grey’s Anatomy, where

surgeons are rock stars, the problems are all critical, and
impossibly good-looking men and women “scrub in” and
save lives every day.
However, over the years, Gawande came to appreciate the
exact opposite type of medical care – that of “incremental
care.” He’s talking about the day-to-day, month-to-month,
year-to-year relationship you have with your primary care
physician. This is the doctor who knows you, knows your
issues, and has the long-term focus to try new things,
evaluate what worked and what didn’t, and then modify
their strategy.

Gawande continued:

Success is not about the episodic, momentary victories. It is about

the longer view of incremental steps that produce sustained
progress.146

Incrementalism is where innovation is born. Heroes don’t

waltz into projects and change everything.147

After your project launches, you begin the incremental care

and feeding of what you’ve built. Hopefully, you can
develop a long-range view of your organization’s goals and
strategies that let you course-correct in small gradients,
rather than yanking the wheel left and right to respond to
every new obstacle that pops up.

Launch day isn’t the finish line. It’s the starting line. It’s just
the end of the beginning. Go do amazing things.

Good luck.

146 Both quotes from “The Heroism of Incremental Care,” The New Yorker, January 23, 2017.
147 In politics, inexperienced candidates will emphasize their status as an “outsider” who will
“shake things up” among the politically entrenched. We invite you to think of a time when it
actually worked out that way.
Acknowledgements
Deane
I want to thank my co-author, Corey Vilhauer, for putting
up with me. I pulled him into my office almost two years
ago with this crazy idea for a book, and I couldn’t tell if he
was nodding because he liked the idea or because he just
wanted me to stop talking.

But here we are.

Thanks for the Blend Interactive team for making this

happen. Sam Otis for his incredible artwork, Ashley Bott and
Taylor Lopour for their organization and management, and
Karla Santi for taking the risk on getting this published.

Thanks to Kerrie Vilhauer for – yet again – suffering

through my writing by reviewing and editing it. Doing it
once was gracious; doing it a second time makes you a saint.

Thanks to my team at Optimizely for understanding that

this was something I needed to see to completion.

Thanks to Jeff Eaton and Karen McGrane for their foreword.

When Corey and I were thinking of people to write this, Jeff
and Karen were collectively and independently our first and
only choices.

Thanks to the industry for all the years of putting up with

Corey and me. Thanks to everyone in the content
management and strategy world that have guided and
influenced our thinking over the years. I believe we’re not
really coming up with any ideas as much as we’re just
curating them. I hope we serve as a decent mouthpiece for
everyone else.

Finally, thanks to my wife Annie, and my kids Alec,

Gabrielle, and Isabella. Thanks for leaving me alone to write
when I needed it, and interrupting me when I needed that
too.

Corey
First off, thank you to Deane Barker, who told me I needed
to write a book and then kept telling me I needed to write a
book, even when I tried and failed … twice. Thank you for
pulling me into this idea, for letting me take it and run, and
for keeping me honest.

To the other partners at Blend Interactive — Karla Santi, Joe

Kepley, Jessica Hutchinson, and Joshua Folkerts — for
making The Web Project Guide a focus; for their time and
resources and encouragement, and also for bringing a young
and hungry content strategist on all those years ago.
Additional thanks to Ashley Bott Schmidt, Laura Brown, and
Taylor Lopour for constantly leading, managing, and
pushing this project in the right direction.

To those who read initial outlines, helped with editing,

offered suggestions, and assured me that, no, I wasn’t
absolutely crazy in co-authoring a book about generalities and
context, thank you so much: Margot Bloomstein, Meghan
Casey, Amanda Costello, Jon Crowley, Cleve Gibbon,
Kristina Halvorson, Scott Kubie, Lisa Maria Marquis, Mel
Peterson, Sara Wachter-Boettcher, and Eileen Webb.

Thank you to Karen McGrane and Jeff Eaton for taking our
weird idea of a foreword and making it real.

Thank you to Sam Otis for making everything look amazing.

I’ve been lucky to meet and become great friends with some
amazing people at industry conferences, through past
projects, and random Slack channels, and even if they didn’t
know they helped shape much of this book: Relly Annett-
Baker, Chris Avore, Bill DeRouchey, Dan Eizans, Tenessa
Gemelke, Kerry-Anne Gilowey, Matthew Grocki, Kevin
Hoffman, Cathy Leamy, Donna Lichaw, Keri Maijala, Ethan
Marcotte, Mat Marquis, Aaron Parkening, Boon Sheridan,
Sean Tubridy, and Erik Westra.

Thanks to Eric Swanson, who sent me a text upon the launch

of the first chapter that assured me that we were doing the
right thing. That text was better than the gentle springtime
sound of young’uns at play.

Thanks to Abi Jones, who pointed me in the direction of web

content strategy after I asked a desperate question on
Twitter about leaving the advertising industry.

Thanks to Erin Kissane, who asked me to write an article for

the since passed Contents Magazine, and in doing so taught
me that sloppily free-handing an article is not the same as
thoughtfully constructing a usable narrative. I learned more
about my own writing and editing on that one assignment
than I had in decades before.

Finally, this book wouldn’t even be a thing without the

support of my family. To my parents — Tammy and Dennis
— for raising me to be a reader; to Grandma and Grandpa
Boyer for building character; and most importantly to
Kerrie, Sierra, and Isaac, who tolerated late night writing
sessions and anxiety-ridden imposter syndrome. I love you
all so much; thank you now and forever.

We’re done with the book, now. Time to get those last Korok
seeds.
About the Authors

Corey Vilhauer
Corey Vilhauer is
director of
strategy at Blend
Interactive, and
has gone on at
length about
documenting
procedures,
determining
audiences and
outcomes, and
the crossroads
between content
strategy and
information
architecture. He is
a recovering
advertising
copywriter and a
closeted fan of professional wrestling. He writes at length
about methodology, writing for accessibility, and shoestring
content strategy at Eating Elephant, and writes about other
things at CoreyVilhauer.com.

Deane Barker
Deane Barker
is the Senior
Director of
Content
Management
Strategy at
Optimizely, a
digital
experience
software
company. He
has been
working in web
content
management
since the mid-
90s and co-
founded Blend
Interactive in 2005. Since then, Deane has become a leading
voice in content management — to the point that he wrote
the book about it: Web Content Management: Systems, Features,
and Best Practices — and continues to write about content
management and more at Gadgetopia. From here, it’s on to
the future: breaking ground in distributed content
management; teaching the practice; reading — always
reading.
About Blend Interactive
Blend Interactive is a web strategy, design, and development
agency located in the middle of the Midwest: Sioux Falls,
South Dakota. As a company, Blend has been working full
time in the web design and development field since 2005. As
individuals, the partners of Blend have been working in the
industry since just after the invention of the Web in the early
1990s. Blend’s passion is in making great things for the web.
This book is one of those things.
Index
A
A Practical Guide to Information Architecture, 142
A/B testing, 116
Accessibility
front-end, 302
testing, 349
writing for, 182–184
media, 183–184
Aggregations, 312–314
content tree, 313
folders, 313
menus or collections, 313
tags or categories, 313
Agile methodology, 51–53
Alternative text, 183
API, 157, 332
Archetypes, 69
The Art of Thinking Clearly, 5
Atherton, Mike, 78
Atomic Design, 197
Attributes, 162–164, 307
referential, 335
Audiences, 61–62, 65–69

B
Backups, 356
Baggs, Rebekah, 181–182
Bailie, Rahel Anne, 165
Better Blocks, 153–155
Bloomstein, Margot, 36, 132
Brain Traffic, 122
Brand standards, 389
Breakpoints, 300
Brown, Dan, 59, 70
Browser compatability, 299
Budget, 48–50
communicating, 48–50
in an RFP, 49
types of, 48
Build, 295
Business Goals, 7
Byrne, Tony, 242

C
Caching, 352
Captions, 184
Card Sorting, 140
Card sorting, 140
Card, Stuart, 141
Casey, Meghan, 94, 125
Categories, 147
in aggregation, 164–165
Cognitive fallacies and biases, 5–6
Cognitive load, 171
Communication, 122–123
Content, 122–127
aggregations, 161
audit, 90, 96–99
channels, 127–130
delivery network, 261
“ROT”, 97
ecosystem, 128
marketing, 127
messaging, 130–132
pages, 160
inventory, 90, 91–96, 326
adaptive, 157–158
attributes, 162–163
balancing the model, 160–161
blocks, 161
editorial calendar, 386–387
editorial triggers, 386–387
implementing the model, 162–165
integrations, 161
migration, 323–339
modeling, 155–164
modeling within the CMS, 220
ongoing maintenance, 385–391
operations, 371–372
organizing, 137–140
rolling audits, 385–386
rough-in, 314–315
semantic, 165–166
strategy, 122–127
structured, 157–158, 165
 training, 376
writing, 170–185
The Content Advisory, 236
Content audit, 90, 96–97
maintenance, 97–99
Content Audits and Inventories: A Handbook, 91
Content channels, 127–130
Content delivery network, 261
Content Design, 70
Content ecosystem, 128
Content Everywhere, 161
Content inventory, 90, 91–96, 326
Content management system (CMS), 219–228
ecosystem, 228
features, 220–222
open source vs. paid, 227–228
pricing, 224–228, 240–241
pricing models, 226
proof of concept, 242–243
reporting, 92
selection process, 231–245
software demo, 241–242
tools, 220–221
upgrades, 392–394
training, 396
Content model, 307–311
attributes, 307
datatype, 307
editorial experience, 310–311
implementation, 307–309
types, 307
validation rules, 307, 311
Content Strategy, 165
Content strategy, 122–127
Content Strategy for the Web, 94, 131
The Content Strategy Toolkit, 94
Conversion funnel, 108–109
Corak, Chris, 181–182
Core strategy statement, 126
Core team, 364
Crowley, Jon, 105
CSS (cascading style sheets), 190, 287–288
frameworks, 290–291

D
Data, 104–105
 residency, 261
sovereignty, 261
Databases, 253
Deployment, 353–354
Design, 188–201
break points, 200
components, 292–293
definition, 188–190
elements of, 189–190
fluid grid, 199
for mobile, 198–201
front-end, 189
graphic, 189
images, 197–198
information, 189
language, 194–196
pattern libraries, 196–197
styles and branding, 389
user experience (UX), 189, 190–193
user interface (UI), 189
visual, 194–198
Designing Connected Content, 78
Development, 281–304, 305–320
agile methodology, 51–53
archiving, 320
back-end, 305–320
for browers, 299
for mobile, 300–302
front-end, 281–304
front-end accessibility, 302
front-end performance, 303
front-end vs. back-end, 282–283, 294–298
localization, 319
maintaining integrations, 394–395
marketing tools, 319
methodology, 273
operations (DevOps), 295–296, 298
permissions, 319
post-launch, 382–383, 391–395
reporting, 320
search, 320
specializations, 284
upgrades, 392–394
workflows, 319
Device compatability, 350
DevOps, 295–296, 298
The Digital Crown, 94, 128
Digital policy, 369–370
Disaster recovery, 261
The Discipline of Organizing, 137
Distributed team, 364
DNS, 262–264
Dobelli, Rolf, 5
Document object model (DOM), 289
Documentation, 45–46
importance of, 45–46
archetypes, 69
wireframes, 191–192
user stories, 69
site map, 142–144, 326
prototypes, 192–193
personas, 69
journey maps, 70
experience maps, 70
editorial calendar, 386–387
editorial trigger, 386–387
content inventory, 90, 91–96, 326
content ecosystem, 128
content audit, 90, 96–97
Domain names, 262–264
Dublin Core, 93
Dungeons and Dragons, 29

E
Eaton, Jeff, 155
Editorial calendar, 386–387
Editorial trigger, 386–387
Eizans, Dan, 71
The Elements of Content Strategy, 124
Environment, 296–297
integration, 296
pre-production, 297
production, 297
staging, 297
test, 297
Error messages, 184
Error page, 352
Everyday Information Architecture, 143
Expectations, setting, 25
Experience maps, 70
Extended team, 365
External partners, 37
F
Failure analysis, 115
Fenton, Nicole, 174
“The Five Whys”, 10–11
Fortrester Wave, 235
Frameworks, CSS and Javascript, 290–291
Frost, Brad, 197
Functional testing, 347–352

G
Gammel, C. David, 63
Gartner Magic Quadrant, 235
Gasser, Nolan, 123
Gawande, Atul, 403
Gerber Singles, 57
Glushko, Robert J., 137
Google Analytics, 105
Governance, 360–376
accountability and authority, 373–377
digital, 360–361
policy and standards, 368–373
roles and responsibilities, 361–368
Guidelines for Style Analysis, 123

H
Hall, Erika, 64
Halvorson, Kristina, 94, 122, 131
Hane, Carrie, 78
Harned, Brett, 12
Headings, 178
Hendrickson, Sue, 11
Hosting, 222–224, 249–264
account, 251–252, 254–257
bandwidth, 256
cloud, 254
owned, 254
scalable, 255
shared, 254
uptime and capacity, 257–259
Hourly rate, 278
HTML (hypertext markup language), 190, 286–287
I
IFRAME, 213
Industry experience, 270–272
Inflection points, 21
Information architecture, 137–150
card sorting, 140
categories, 147
discipline of, 149–150
navigation, 141–146
organization, 138
site map, 142–144, 326
taxonomy, 147–148
wayfinding, 141
Information Architecture for the World Wide Web, 37, 138
Information scent, 141
Initial project team, 29, 32–39
Insights, 105
related to metrics, 105
Integration partner, 275–278
pricing, 277–278
references, 276
scheduling, 275
Integration partner, 269–270
Integrations, 206–214
challenges, 207–212
client-side, 213
costs, 214–215
definition, 206–207
proxy, 213
real-time vs. scheduled, 208–212
viability, 212–214
Interface, editorial, 163
Interviewing users, 76, 117
IP addresses, 262

J
Jansen, Bernard, 109
JavaScript, 288–290
frameworks, 290–291
Jellybottom, Francis, 31, 38
Journey Maps, 70

K
Kahneman, Daniel, 75
Key performance indicators (KPI), 109
Kiefer Lee, Kate, 174
King Lear, 131
Kissane, Erin, 124
KPI (key performance indicators), 109–111
Kubie, Scott, 128

L
Lambe, Patrick, 148
Land, Paula, 91
LaRue, Jan, 123
Letting Go of the Words, 172
Lichaw, Donna, 74
Liebtag, Ahava, 94, 128
Links, 179
Linnaean hierarchy, 138
Load testing, 349
Lovinger, Rachel, 158, 163

M
Mailchimp Content Style Guide, 175
Managing Chaos, 34, 361, 364
Marquis, Lisa Maria, 143
Matilda, 137
McAlpine, Rachel, 170
McGrane, Karen, 157, 180
Media query, 300
Mendoza Line, 111
Mental Models, 83
Message architecture, 132
Message hierarchy, 131–132
META attributes, 352
META descriptions, 180
Metadata, 148, 179–180
in aggregation, 164–165
Metrics, 105, 109–111
categories of, 107–108
Migration, 328–339
automated vs. manual, 331
editorial planning, 326–328
example, 335–338
extraction and transformation, 332–333
functional planning, 328–330
 import, 334
procedural planning, 330–331
URLs, 339
users, 338
Monitoring, 356
Montiero, Mike, 23, 188
Morville, Peter, 37, 138

N
National Public Radio, COPE, 158
Navigation, 141–146
areas, 145–146
labels, 146–149
Nicely Said, 174
“The Nimble Report”, 158

O
Online and On Mission, 63
Open Graph, 352
Operations, post-launch, 356
Organising Knowledge: Taxonomies, Knowledge, and Organizational Effecxtiveness, 148
Organization, systems, 138
Organizational history, 9
Ownership, 360, 362, 374

P
Page hierarachy, 139–140
Pattern analysis, 115
Penetration testing, 349
Personas, 69
Peterson, Eric T., 108
Pirolli, Peter, 141
Plain language, 171–172
Planning, 43–46, 383–384
annual roadmapping, 383–384
operational, 46
quarterly, 383–384
strategic, 43–46
Podmajersky, Torrey, 175
Policy, digital, 356
Post-launch stabilization, 355–356
Practical Design Discovery, 59, 70
Programming language, 251–252
Programming standards, 285
Project, 13–15
charter, 13–15, 24
discovery, 58–63
goals, 23
goals, related to metrics, 106–107
inception, 4–5
launch, 353–354
layers, 20
leader, 39
manager, 39
momentum, 375–376, 397
plan, 14, 41
post-launch, 355–356
post-launch planning, 383
red flags, 11–12
roadmap, 381–382
scope, 14, 19–23
support, 274
timeline and timing, 50, 52–53
Project Management for Humans, 12
Proof of concept (POC), 242–243
Prototypes, 192–193

Q
Quality assurance, 347–352

R
Rach, Melissa, 94, 131
Rates, fixed vs. hourly, 49
Readability, 172–174
The Real Story Group, 236, 242
Reddish, Ginny, 172
Regression testing, 350, 355
Request for information (RFI), 236–238
Request for proposal (RFP), 238–242
pricing, 240–241
scenarios, 239–240
Request mapping, 316
Request-response, 252
Requirements, system, 219–221
Research, 63–69, 77–78
contemporary analysis, 77–78
focus groups, 66
 people, 63–69
competitive analysis, 77–78
Responsive web design, 300–302
RFI (request for information), 236–238
RFP (request for proposal), 238–242
Rich-text editor, 158
Richards, Sarah, 70
ROBOTS.TXT, 352
Rosenfeld, Louis, 37, 115, 138
Russell, Bill, 39

S
Schuster, Simone, 109
Search Analytics for Your Site, 115
Search engine optimization, 181–182
Search trends, 115–116
Selection consultant, 229, 235–236
Servers, 251, 259–262
caching, 259–260
location, 261
monitoring, 260–261
recovery, 261–262
request, 251
response, 251
Sinek, Simon, 14
Site map, 142–144, 326
Site search, 114–115
SMTP (simple mail transfer protocol), 352
Software demos, 241–242
Source code management, 296
Spencer, Donna, 140, 142
This is Spinal Tap, 18
SSL, 256, 352
The Stack Model, 20
Staffing, 32–39, 364–367
core team, 364
distributed team, 364
extended team, 365
external partners, 37
initial project team, 29, 32–39
integration partner, 269–270
internal vs. external, 366–367
post-launch, 269–270
roles, 363
selection consultant, 229, 235–236
working groups, 364
Stakeholders, 30–32
Strategic Writing for UX, 175
Strategy, business, 32
Strategy, project, 32
Style guides, 389
Survivor, 233

T
Tags, 147
Taxonomy, 147–148
Technology stack, 253
Templating, 291–294, 315–318
client-side, 293
language, 318
server-side, 293
Testing, 347–356
A/B, 116
accessibility, 349
content, 389–390
device compatability, 350
functional, 347–352
load, 349
manual vs. automated, 350
multivariate, 108
penetration, 349
post-launch, 355–356
pre-launch checklist, 351–352
QA, 347–352
reading level, 177
regression, 350, 355
scripts, 351
stress, 349
unit or functional testing, 349
usability, 349
user, 117
user acceptance, 349
wireframes, 192–193
Thinking, Fast and Slow, 75
Top Chef, 359
Total cost of ownership (TCO), 224–225
Toyoda, Sakichi, 10
Training, 395–398
CMS, 396
content, 376
industry, 396–397
post-launch, 395–398
Transcripts, 184
Translations, 185

U
Unit or functional testing, 349
Urbana, Noz, 165
URL, 92
canonical, 93
redirection, 339, 351
Usability testing, 349
User Stories, 69
The User’s Journey: Storymapping Products that People Love, 74
Users, 60
expectations, 75–77
interviewing, 76, 117
outcomes, 75, 79–83

V
Vendor relationships, 367–368
Voice and tone, 174–175

W
Wachter-Boettcher, Sara, 126, 161–162
Waterfall methodology, 51–52
Wayfinding, 141
Web Analytics Demystified, 108
Web browers, 299
Web Content Management: Systems, Features, and Best Practices, 155
Web crawler, 92
Web standards, 370
Web steering committee, 34
Webb, Eileen, 163
Welchman, Lisa, 34, 361, 364
Wireframes, 191–192
Wodtke, Christina, 83
Workflow, 370–371
Working groups, 364
Workshops, discovery, 76
Workstation, 296
WORM (write once, read many), 208
Write Me a Web Page, Elise!, 170
Writing, 171–184
accessibility, 182–184
 accessible media, 183–184
alternative text, 183
captions, 184
error messages, 184
forms, 184
headings, 178
links, 179
meta descriptions, 180
metadata, 179–180
Open Graph, 181
page summaries, 180
plain language, 171–172
readability, 172–174
search engine optimization, 181–182
social media, 184
style guides, 389
titles, 179–180
transcripts, 184
translations, 185
understanding, 176–177
voice and tone, 174–175
Writing for Designers, 128
WYSIWYG, 158

X
XML, 165–166

Y
Yahoo Style Guide, 175
You’re My Favorite Client, 188
Young, Indi, 83

404 not found, 352