The Rule of Firsts

Our tendency as humans is to find the easiest way. Throughout history, most inventions and breakthroughs are about ease – making things faster, more intuitive, less of a hassle, less likely to kill us in a freak flash fire. Etcetera.

While we spend our time inventing for ease, we also add ease into the process of inventing itself. We spent decades perfecting the horseless carriage, and then we spent the next century trying to perfect the process of creating a horseless carriage. On the web, developers and designers spend hours learning techniques that will save them minutes. We hone our processes so that we can hone our inventions, and in turn our inventions help us recalibrate our processes.

It’s a vicious circle. It’s a necessary circle. But it’s a circle all the same.

Like all circles, this process has no end. There is no one true process, because it’s always changing.

The cult of “first.”

Because the web is a very very complicated field, filled with weird shades of grey, we as an industry are obsessed with simplifying it.

However, there are levels of granularity in the web. On one end is high-level planning; on the other, the details. In between lies a spectrum of progressive focus – where dreams and aspirations become functional, usable things.

Part of our job is to flesh out that spectrum for each project – to choose tools and narrow the focus. Sometimes it means doing rounds and rounds of research, followed by a gradient of approvals and fidelity. Sometimes, it means taking a sketch and skipping right to the chase, brevity and passion replacing research and strategy.

But how do you explain the complexity and always-changing nature of a web project in a way that resonates with stakeholders and co-workers who, let’s be honest, don’t need to understand the finer details? You summarize through philosophy: mobile first, content first, users first.

Each “first” has its own function and its own specialty. Each provides a simple methodology – a standard container into which we can pour an effective website, like a Jell-O mold or an ice cube tray. Someone may understand what we mean when we say “content first,” but are we communicating the right thing?

Is it okay to present that Jell-O mold when, in reality, we’re reshaping the mold with each project?

Confusion first.

Which means with simplification comes confusion. No two-word term can sufficiently sum up the entire web process, and for that reason many of our “firsts” are often misunderstood. “Mobile first” is sometimes read as “mobile priority.” “User first” is boiled down to “user only.”

What we’re really doing when we write blog posts and tell clients about “mobile first” and “content first” is that we’re using over-simplified two-word methodologies. We’re positioning these phrases as the One True Path when, as we know from every project we’ve ever worked on, there is no One True Path.

In my field of content strategy, the biggest stumbling block is when “content first” is misconstrued as “copy first,” as iAquire’s Devin Asaro pointed out in a tweet a few months back:

Seems like 'content-first' design is pretty frequently misunderstood as 'copy-first' design.

— Devin Asaro (@copydev) October 29, 2014

Yet, there are even gradations within what we mean by “content first” itself.

1. Copy as law: Every page is written before design starts, leading to a design that applies literally to the copy itself. Useful for small sites with specific language that will rarely change.
2. Content templates and examples: Where each major content type is created using example copy (oftentimes real copy) that will make the final site. Not every page is written beforehand (naturally, a good fit for larger content managed sites) but enough that a designer and developer can understand real-world content during the build.
3. Representative placeholder copy: Example copy that relies on strategically designed lorem ipsum, allowing for final copy to be created while the CMS is being designed but not necessary for actual design itself. Flexible and forgiving, and based in research and user needs.

Which of these is the clear “content first?” Are all of them? Is it some mix between the three?

The answer: it depends.

It’s more complicated than that.

Projects require audiences, and audiences are always different, and because of that they need different things. The “first” for your project may depend on who you are building it for, and that “first” may pull in thoughts and pieces from every direction, borrowing from every other “first” that came before it.

A university website for a small school has users, and those users need to be able to register for classes, and the university needs them to register for classes because that is how it makes money. The university can begin in several different places.

1. Content first: make sure the site begins with an engaging content concept that works for the student – clear labels that drive the potential student to gather the information he or she needs to begin the registration process.
2. Mobile first: make sure the site begins with all contexts in mind, so that a user on any screen can access the content, built using responsive design and progressive enhancement to confirm the basics are always available no matter the size.
3. User first: make sure the site begins with in-depth research and questions from potential, current, and past students, asking what they look for in particular and pairing this with the university’s unique advantages.
4. Goals first: make sure the site begins by addressing the needs of the university itself – the need to drive potential students through the admissions and registration process in order to help fund future educational pursuits – including the website itself.

The thing is – and this is why projects are complex, and why research matters, and why design iterations and adaptable processes are key – all four of these points are necessary. All four of them are viable “firsts” for our project. All four of them work together to make a better website.

Maybe instead of “content first” and “mobile first” and “user first,” we should be talking about “project first.”

Yeah, but words are words.

But does it matter? Why are we arguing the semantics of catchphrases and philosophies when it’s clear to those who understand the process that they are generalities? Why bother with all of this differentiation when we as professionals all understand the true methods?

For some, it might not matter at all. Internal teams may understand each other’s language, and that’s okay. Words are words, and as long as communication still works you can call your process “Oranges and Potatoes First” for all I care. A horseless carriage by any other name is still a horseless carriage.

But when wandering into a new situation, where someone has read an article about mobile-first design, or about content-first processes, the communication barrier can sometimes break apart. Our job as professionals is to make sure we don’t use buzz words like this, instead carefully explaining what we mean when we say “content first.”

To some “content first” means writing copy and then designing. To others, “content first” means creating high-level content aspirations and marketing goals before anything else is even discussed. To even more, “content first” means “mobile first” – developing content in a way that works best on mobile.

The words will mean what we want them to mean, but we have a duty to make sure they are clear – and we have an obligation to help our clients and partners and colleagues understand that any “first” is really just one iteration of an ever-changing methodology.

Call it “mobile first.” Call it “agile.” Call it “Steve’s Plan.” Whatever you call it, make sure it’s clear. Make sure it’s understandable. And make sure it’s part of a circle – always changing, always a part of everything around it.