Why The Web Project Guide Matters

Websites are complicated.

Even if they’re simple, they involve a lot of steps. A lot of phases. A lot of “moving parts,” as some might say.

Regardless of the website — regardless of whether it’s a site spun up on SquareSpace, or a complicated multi-site content management system installation integrated with a legacy digital asset management tool — it’s going to be complicated.

It’s complicated because the tools are complicated. But it’s also complicated because of everything that happens around that tool. The decisions, and the people. The designs and the rework. The content, the changes to the content, the adjustments to the content, and the rework of that content.

I’ve been doing this for ten years — connected in some way or another to nearly every phase of a web project, by nature of my role as a web architect and QA lead, and now as a director of strategy. Even with a decade under my belt, I still don’t know everything that happens from day to day on a large-scale web project.

Well, that’s not entirely true. I now know a lot more than I used to. Because I helped write a book about that process.

Let me tell you about that book.

Understanding the Language of the Web

Within each industry, there is a language.

Auto mechanics. Librarians. City planners. The people who stock stereos at Best Buy. Each of these unique jobs employs an understood cadence, vocabulary, and shorthand.

Likewise, within each industry, there is a process. Auto mechanics have known and repeatable best practices to overhaul an engine, and they understand the different parts and stages that go into ongoing vehicle maintenance.

Both of these — industry language, and industry process — create a kind of line that can be difficult to cross. They create separation between those who know and those who don’t. In some cases, this is okay — most of us don’t need to know how the stereo section at Best Buy is organized, or what a city planner does day-to-day; the results are enough.

But in some industries — especially in the industries we rely on for some kind of service — it creates a lack of confidence. At times, it manifests as actual fear.

For example: the auto repair industry. Most of us (myself especially included) don’t understand our cars well enough to fix them ourselves. More than likely, we have trouble just communicating what needs to be fixed. We make some vague hand waving, and we try to mimic noises, but we’re really just hoping that our mechanic can translate our odd performance into an actual solution.

(And, we’re hoping our mechanic doesn’t screw us over.)

Now take that story and replace “vehicle” with “website.” Those of us in the web industry? We’re those auto mechanics.

We’re the ones who might frustratingly explain why this stage needs to be done before that one, and why it costs this much to provide ongoing support, and why that feature can’t be included because this CMS doesn’t include it.

And our clients are the frustrated customers who just want it know why things don’t work. No surprises, no issues.

They don’t want to be experts. They don’t want to know every detail. They just want to know enough to make good decisions and trust our process.

They know websites are complicated. They just want help understanding it.

A Book About Context

For the past year, Deane Barker and I have been writing a book called The Web Project Guide — a high-level look at the web industry, from the initial scheming to the final launch and beyond.

We’ve been writing it because it’s needed.

The web industry (ourselves included) has a tendency to write for other practitioners. A content strategy blog is written for content strategists, or for people who are taking on some aspect of content strategy. A development book is written for other developers. Project management books, design books, books on web governance; all the same.

Which means if you are a one-person marketing team and you want to better understand the larger scope of the web industry, you’ve got dozens of books and articles and conferences to get through, none of which designed to help you see beyond that specific practice or technique.

More and more — and especially with our smaller clients — Deane and I find ourselves explaining the overall web process, helping organizational directors and private universities and non-profits understand that it’s not enough to just throw a few thousand at a web designer and hope things work out — that there are necessary steps between the start and the end that help ensure efficiency, longevity, and usefulness.

Up until recently, we would always try to find resources — to point them in the direction of a more simple solution. Again and again, we’d strike out; we’d find that, unless our client wanted to dive deep into a bunch of fragmented disciplines, there wasn’t a resource that provided enough context at the full project level.

So Deane wrote an outline. It was from this that The Web Project Guide was born. To help bridge the gap between industry-specific experts and the people who simply need to know enough to make decisions. To help navigate the language of the web industry. And to help people be a little more confident.

A Few Words on Being Multidisciplinary

My college degree is in biology education. For five years, I was officially licensed to teach middle and high school biology and life science in the states of South Dakota and Minnesota.

By its nature, mine was a double major: a degree in secondary education, with all of the trappings and coursework of a teaching degree — foundations of education, child development, student teaching — and a degree in biology, which provided endless lab time soaking in the scent of agar.

Beyond that, though — much like anyone else who has a good old-fashioned Bachelor’s degree from a liberal arts state college — I took courses in film and english. Algebra. Ancient literature. Physical education. I checked boxes in dozens of different disciplines, and came out a somewhat well-rounded and somewhat well-functioning young adult. These courses didn’t teach me how to do my job better, but they allowed a bit of context within what I was doing.

And, it allowed me to easily pivot. Despite my degree, I found success in completely different disciplines: in writing, and in organizing. I took what I knew from teaching, and what I knew from scientific theory and method, and I adjusted to a different focus: the world of content and information architecture. I was multidisciplinary in a discipline I didn’t even know existed.

The key to working with others in the web industry is understanding some level of context. It’s more than just being a “designer who codes;” those of us who have landed on our particular discipline, whether that’s project management or front-end development, have both a responsibility and a duty to understand how our work affects those around us.

You don’t need to be an expert in every stage. You just need to understand the context. How you fit in. What’s more, those who are just entering into the industry needs to understand how they fit in. That kid who’s looking to break into web design, or that aspiring developer finishing up their senior year of college, or that writer shifting focus and moving in a new direction.

Understanding context is important, not just for those clients who will encounter one project every few years, but for all of us. For you. For me.

Which is to say The Web Project Guide isn’t just for clients who need help. I feel strongly that it’s also for all of us. Even if it’s just a reminder. Even if we know everything. Context matters, and collaboration relies on it.

A Few Final Words

The Web Project Guide will not teach anyone how to make a website.

It won’t teach anyone how to design, or how to understand web analytics. You won’t read it and become proficient in any development language or project management process.

But that was never the point.

Our book may not teach you how to make a website. Instead, The Web Project Guide will help teach how a website is made. What goes into the process, who you need to bring in to help, and what decisions are made along the way. It will help frame discussions. It will help build confidence.

I’m really proud of it — I think it’s going to be a great resource. I think it helps people step over that line; to begin to make better decisions about their website. To know what to ask for. To know how to move forward.

I also think it will be good for those of us firmly entrenched in the industry. To remember how the things we do affect other disciplines. How our work matters as it’s picked up down the line. How every decision around territory and definitions and labels and titles is ultimately in service to a larger goal of collaboration, communication, and good work.

You can read it now, if you’d like. It an always-changing work in progress, until it’s ready for print. You can read it then, too.

I hope it helps. And I hope it’s not arrogant for me to think that it really will.