Navigate Here

The thoughts, opinions, and assertions here are wholly my own and do not reflect those of my employers (past or current), their partners, or customers.

Navigate Elsewhere
« Behind Every Website is a Hypothesis | Main | Working with Developers »
Saturday
Mar052011

Making Websites

Starting a website with comps and code is a bad approach for content-centered sites. Instead, start by clarifying your goals and aligning your team around them, working to understand your audience, and honing your messaging to suit your audience and goals. From there, there’s a whole production process that should include content strategy and user experience design before you actually build a site. Read on to learn about the motivations behind this process or skip ahead to see my ideal process outlined.


I have been making websites since 1995 or ‘96. My family got its first computer in 1995, and once I got confident using it, I wanted to make things with it. I scraped together some money from cutting grass and got myself a QBasic book, and a few months later my parents got me an HTML 2 book (no tables for this guy) for Christmas. I’ve made websites ever since; back then, it was for fun; in college, it was for classes and occasionally for a favor; for the last six years, it’s been how I’ve earned my living (with the occasional favor still thrown in).

From the get-go, I’ve approached web projects from the perspective of a developer; the QBasic book did come first. I’ve always wanted to dive in and make something, because I love making things. Because I have brought a programmer’s perspective to projects, I’ve thought in terms of execution; when I hear an idea, it’s hard for me not to imagine how to make it concrete with code. This has typically been what people expect out of talking about a website — except maybe the designers who see images of the site’s interface instead of the logic and software stacks I imagine. But people who want a website are typically excited about it, and they want to see progress quickly, and so my approach has met their hopes well. The Internet still has a hint of glamour; to people I help, getting a new website is a creative expression (even when it’s for their business), and they are excited to see their expression live on the Internet for all to see.

Over the last few years though, an awareness has been growing inside of me about some deficiencies in my process. I’ve always been looking to solve computer problems, but I’m coming to think that what I actually need to solve are people problems. So, here, I’ve taken a closer look at a naive (and, I suspect, commonly used) process for making websites, and then I've outlined the improved process I’ve been refining for the last few years. In this post, I’m going to focus primarily on the problems of content-rich sites without ecommerce or advertising; the method described in this post should also apply to other types of sites, but my experience and passion primarily deals with content-rich sites (so more Wikipedia than Amazon).

A Rough, Suboptimal Process for Making Websites

Boiling it down, I think I can define the process I’ve encountered in the past into nine "easy" steps:

  1. Talk to your client to get a rough idea of what s/he wants; this “talking” could actually be reading an RFP, or it could be a sit-down meeting or two.
  2. Make some drawings of what the site could look like. If you’re feeling ambitious, the first set of these drawings will be called “wireframes.”
  3. Implement in code the drawings that the client liked. If the discussions from step (1) yielded any features that go beyond interface (e.g., some fancy search, a game, etc.), write those as best you understand them.
  4. Post the content that the client has written in MS Word to the website you coded.
  5. Have the client click around the site a little, get his/her blessing, and take it live.
  6. Send some reports to the client about how many people looked at the site.
  7. Post updated content you pull from MS Word files every so often; these might be on a schedule but are more likely driven by outside events and freetime.
  8. One day, field uncomfortable questions about why more people don’t come to the site and why the people who do come don’t stay.
  9. Redesign part or all of the site (you may or may not get to participate in this step). This is step typically not mentioned earlier in the process.

I realize this is a bit of a caricature, but I don’t feel like it’s terribly far off the mark; I've certainly worked on sites with more thoughtful processes, but I've definitely seen sites go live that start at (3) and stop at (5).

What Motivates this Process?

This process has a couple things going for it:

  • For the client, it makes spending feel more predictable — you expect that the web developers can give you an estimate for the cost at (1) and will do work up to that estimate in (2) to (5).
  • It gets the web team making things early; in projects I’ve worked on, there is nearly always substantial deadline pressure, and nothing makes you feel better about your deadline than having the comps and code.
  • For the client, it makes a messy, complicated process feel like buying a normal product, like a car.
  • It minimizes the number of meetings the client has to attend and therefore appears to reduce the work required of the client in producing the site.
  • On sites without a ton of content or very complicated features, it moves quickly enough that there’s good enthusiasm from everyone through launch.
  • For the client, it appears to contain post-launch costs — that is, until you see step 9.

I can see why these features are attractive. No one has unlimited resources, so of course clients want to know what they’re getting for how much. And web teams want satisfied clients and projects that they can deliver on time and under budget, so it makes sense that they want to dive right in and get the project dispatched. It assumes that you can know what will be effective at the outset, which is nice for all parties; the client feels like they've hired experts, and the site creators feel like they are experts.

HOWEVER, and there is always a however, there are some problems here, too.

The Trouble with the Existing Process

The trouble is that the process described above dives in to tackle the technology problems associated with a website without handling the really important part: it ignores the needs of actual people. People are complicated and hard to predict. And although clients are typically excited about their sites once they get them (I’ve been lucky to work with good designers and to be able to provide good technology), eventually they come to realize that they don’t really know whether what they've paid for is actually successful; do people find it useful? You see numbers of visitors, but it’s hard to tell if it’s a lot or a little — and even if you have benchmarks, the numbers still feel meaningless. You see “engagement” numbers about stay times and bounce rates, but they always feel too low and too high (respectively) — not that you can have a great sense of what the ideal would be. It’s hard to know whether the content you’ve provided is useful or whether people are even actually reading it.

The above process elides some useful tools that we have at our disposal if we so choose when creating a content-rich website:

  • Although professional expertise is brought to bear on the design and implementation of the site, the content of the site is left to people who are likely not web content experts.
  • Although the process brings in outsiders (assuming you bring in a design/development firm), no one actually talks to the target audiences for the site to see what they could use.
  • Measurement and analysis only enter the picture as an afterthought.
  • The process assumes that the goals for the site are made explicit upfront and does not offer support for turning desires into measurable outcomes.
  • The process assumes that the site will work correct at launch; there’s no structured plan for determining how the site should be tested and incrementally improved.

My Ideal Process for Making Sites

A picture is worth a thousand words (not that I won’t write another thousand after the picture)

My ideal web process

This process breaks into four major phases, and, importantly, it has a loop in it to imply that it is iterative:

  1. In the first phase (Inception, Audience Research, and Message Development), you figure out where you’re going, working to clarify your goals for the site and align your team to those goals (Inception), to figure out to whom you will be talking (Audience Research), and to express what you’re planning on saying (Message Development).
  2. In the second phase (Brainstorm Features, Content Strategy, and Outreach Strategy), you plan how you’re going to get there, putting together a picture of what exactly your new website needs to do to be able to reach your audience (Brainstorm Features), what content you’re planning to put on it and how you’re going to maintain that content over time (Content Strategy), and how your audience will learn about this content and contribute to it (Community and Outreach Strategy).
  3. In the third phase, you develop your first version of your website, starting with the navigation and interactive elements (User Experience Design), moving to the look and feel of the site (Visual Design), and then finally into the actual creation of code and copy in Production. Note that if you're doing things right, you're testing the outputs of this phase with real users to verify that you're making a product they can actually use.
  4. In the last phase, you analyze how you’ve done and look for insights for how to improve the site. Because analysis is an integral step and flows back into the others, you should have been planning for how to analyze your results in all the other phases so that your results here are more than just reports; they are actionable insights about what you need to improve on your site to meet your goals.
  5. From the analysis, you can brainstorm new features to make the site more effective, which will then change your content strategy and outreach strategy, which will then require you to modify your navigation and add or remove elements from the site, which means more design and then development to implement these changes. The process is inherently iterative, acknowledging that any website is at best a hypothesis about what an audience wants that can be improved through further analysis and refinement.

The diagram is of course an abstraction of a real process, and it disguises a lot of real complexity and fluidity in its neat boxes and arrows. For example, new ideas for features will emerge at each stage; content strategy, community strategy, and user experience design will happen almost concurrently and will often be hard to solidly differentiate; once production kicks off, it’ll likely run continuously for the life of the site, creating new features and content, modifying existing code and copy, or performing necessary maintenance. Additionally, it’s not like once you’ve done your audience research you’ll never return to it; however, I expect things will leach back into the audience research and messaging much more slowly than the rapid pace of iterations to improve the site.

That Looks More Complicated, What's It Get Me?

The big thing about this model is that it is goal and audience oriented; you start at inception by clarifying your goals and then dive directly into understanding your audience. The rest of the phases are basically about refining these understandings to reach your audience to realize your goals. These goals might be things like "teach people how to prevent crime" or "help activists promote my new program." The important thing is that you have a goal and then start breaking down the groups like "people" and "activists" into smaller groups that you can actually understand.

Additionally, the process proceeds to clarify the path from goals and audience to a site that you can measure and maintain. By including phases like content strategy, you will actually think in a structured way about what to include on your site and how to maintain it. And by thinking about outreach before the site is deployed, you can design your site to encourage outreach instead of figuring out how to retrofit it.

Finally, the process admits that what you create won't be perfect at launch. As Alistair Croll and Sean Power say, "Web design is a hypothesis." You will learn about your audience (and a bit about yourselves) after the site goes live; it is imperative that this real-world knowledge is analyzed and used to improve your site so that your site improves. It is wonderful to have experts writing your copy and developing your code; it's hard to imagine how you could turn insights into actions without professionals. HOWEVER, these professionals are going to be professionals in creating things for the web, not in your problem space or about your audience; you will learn with them what is actually effective in the real world by being a part of it with a live site that you monitor and analyze.

Ok, That Does Look Better, What’s Next?

Each of those boxes hides its own little process, full of work that needs to be done. Honestly, each box is its own discipline (yes, even inception, at least for some project managers). Additionally, thinking through many of these stages in terms of goals and eventual measurement is not natural for most people I meet; that’s where having people with experience running the show is really helpful. From these broad outlines, I’ve been working to develop a more detailed process for working your way from “I need a new site or to fix a really confusingly broken one” to “I have a vibrant, effective online communications program.” I look forward to sharing my approach as I refine it.


References (1)

References allow you to track sources for this article, as well as articles that were written in response to this article.

Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>