Behind Every Website is a Hypothesis

Behind every website is a hypothesis about how to solve some problem people have. Being explicit about that yields benefits in clarity of thought, insights into process, and easier measurement.

In my last post, I talked a great deal about what an effective process for making a website looks like, describing a useful framework for approaching the complicated problem of making a large content site. I'd like to take a step back today, to thinking about why you might be creating a site in the first place.

Serious websites solve problems. If you're not solving a problem that real people have, you're wasting your time (and likely money). However, in my experience at least, people are not terribly explicit about what problems they are trying to solve. Behind every website, though, is some hypothesis (really a collection of hypotheses) about how the Web could be useful in solving some need real people have, and the site itself is an experiment testing that hypothesis. This applies to both content sites and web applications, although as usual I'll focus on content sites. Being explicit about the fact that you're making a hypothesis and conducting an experiment yields benefits in clarity of thought, insights into process, and easier measurement.

To give credit where it is due, the phrase "Web Design Is a Hypothesis" came from Alistair Croll and Sean Power in Complete Web Monitoring: Watching Your Visitors, Performance, Communities, and Competitors. Croll and Power focus mostly on local hypotheses — the idea that as designers work on specific pages and features, they should keep in mind that each decision they make is, at best, a guess as to what will work effectively for site visitors, and as such designers should plan to test their designs and refine them in the face of real world data. Later, reading Alan Cooper's "If users could lead innovation, they wouldn't be users," I came across his compelling analogy comparing web product designers to doctors, and realized that really, a website is a prescription to cure some diagnosed problem, and that web development is actually hypotheses all the way down, from the high-level product vision to the individual links on a page.

Your Site is an Experiment to Prove a Hypothesis, and That's the Way it Should Be

There are a lot of ways to conceive of a website. Typically, I see people think about it like a gadget — it's a cool thing like a kindle that will have a beautiful look, do some neat things, and reflect well on the people who guided its development. But that's not concrete enough. For content sites, the site is a vehicle for communication — more voice mail message than iPhone in the end.

There's a deeper level than just communication though — there's problem solving. You don't just communicate; that doesn't make any sense. You communicate to change the state of the world in some way. And if you want anyone to hear what you're communicating, you need them to have a reason to listen; you need to be helping them solve some problem, so that they can help you change the world the way you need it changed. So you make a hypothesis: if I develop a site that has « information, then «people will visit it and take « action and provide value « for us, because knowing «and doing « solves problem « for «. Then you can start pulling out things like beautiful design and fancy features, assuming that those things convey your information more effectively and allow the action to be taken more easily. But you need all those variables filled in — you need to know what people you're trying to reach, what information you have to offer them, what action you want them to take, and what problem they need to solve that your information helps them with. The goal here is to connect what real people need with what you have to offer. For web apps, this means some useful task that a computer can help people do. For content-centered sites, this means information that people need that you have a perspective on that you'd like to convey.

The greater the specificity with which you can fill in the blanks, the easier it will be to design an experiment to test your hypothesis, because your hypothesis will be more clear — and by "design an experiment," I mean "build a website." And using this way of thinking about your project will help guide the steps you take in executing it, helping you build better sites.

My Kingdom for an Example

For an example, I'll take my favorite fashion blog, I Found the Perfect (IFTP). IFTP takes on fashion like a design project, bringing to bear a formal creative process with tools like mood boards and careful resource planning to make expressing yourself through fashion easier for people who have an interest but not necessarily an inborn talent. Disclaimer: IFTP Is written by my lovely girlfriend, Laura, and I contribute photography and technical support — but I can talk about it without violating an NDA!

Although we weren't as explicit as I would be now, the site started with a couple hypotheses, one of which was

  • If Laura develops a site that «explains how to approach fashion problems like general design problems», then «women who are interested in fashion»will visit and «use the tools provided»and provide value «by helping us understand what tools are valuable to women who are interested in Fashion»because knowing «how to approach fashion problems like general design problems» and «using the tools provided»solves the problem of «the trouble of planning a personal "look"»for «women who are interested in fashion».

Now there's a higher level goal here — Laura wants to know which tools are actually valuable to women for other reasons, otherwise known as a "business goal." And that is again a hypothesis; Laura sees potential value in knowing which tools are valuable and understanding how to make it easier for other women to approach fashion, and whether she can really turn that knowledge into real value for herself will require other experiments and hypotheses. Because, as I said, it's hypotheses all the way down.

What if People Don't Realize They Have a Problem

It's possible that you want to solve a problem that either isn't top of mind for most people or that people don't even realize they have. I know when I first heard the concept of "wearable computers," I thought, "I don't want a stupid computer with me all the time; that sounds annoying." It took getting an iPod touch, which solved a specific set of computer problems well and was marketed to make clear what it could do for me; that convinced me that having a computer in my pocket was actually a great idea. Now, when my droid runs out of batteries, I feel hobbled without a wearable computer.

This is where tools like marketing and PR come in — sometimes, you need to make a case for the tools and information you're providing to convince people how you can help them. So, you end up making more hypotheses about how to convey the value of your site to people using the outreach you have available.

This is also a good signal to check yourself, though. First, if the problem you're trying to solve isn't obviously a problem or isn't one that many people care about solving, it means you're going to have more variables to understanding whether your site is working; you'll need to figure out how to measure your outreach efforts and then measure the performance of your site taking those outreach efforts into account. More importantly, you need to confirm that you're actually solving a problem and not just dreaming that lots of people have the same goals you do. If you think real people have problems like "they don't use my product" or "they don't visit my website," and that is the whole problem, then you're doing it wrong. Determining whether you're deceiving yourself about things that people need is complicated, though, and will have to wait for another post.

Working from a Hypothesis Motivates a More User-Centered Process

Stating your hypotheses explicitly shows that there are lot of variables in what you're doing. Once you realize you're solving a problem for some audience, you start to wonder "do they even have this problem?" Or, at least you do if you're me. You also might want to know what other, related problems they might have that you can help them solve. And then actually solving the problem well is going to require a good bit of work on its own — you need to be sure your site is actually usable by real people (not just you and your developers), that the information you're conveying is clearly articulated, etc.

This is where process comes in, and what motivates some of the steps in the process for developing a successful website that I described last time. A hypothesis is an educated guess; in this case, it's an educated guess about how I can solve some problem people having by creating a website. So, I want a well educated guess.

This desire to make a better educated guess makes me want to understand my audience better and focus my efforts on solving their problems; I know that's what I'm doing no matter what, so my process for creating the site should give me tools to understand my audience and validate my assumptions about what they need. I want to start learning about my audience so that I can understand how they understand the things my site will focus on. I want to know what tools they're currently using to solve the problems I'm interested in, to know with whom I'm competing, even indirectly. I want to use tools like usability testing to try to eliminate some of the variability in executing my site; I have enough to worry about with whether my my overall idea for the site is a good one.

Remembering my hypothesis also means that I realize, in the end, I am making an educated guess about what people will find useful. This means I'm going to need to (1) find some way to measure to know how good my guess was and (2) make changes to my site as after it's launched, because I'm going to learn things from my site's performance in the wild and therefore make better educated guesses in the future. First, this makes my analytics process a good bit more clear; if I'm thinking about my hypothesis at the outset, I'm less interested in vanity numbers like "visitors" and "pageviews" and more interested in how specific content is performing and how various segments of my audience are hearing about my site at all. This also means I want to find the easiest way to (in)validate my hypothesis that I can as early in the process as I can; tools like prototypes and generative user research become much more attractive when thinking about sites this way.

Realizing that the Hypothesis Matters Shows Process does not Ensure Quality

There's a flip side though. What really matters is the insight of your hypothesis and the strength of your execution. A good process can help you refine your hypothesis, and it can help hone your execution, but it cannot save you from a totally off-base hypothesis. It will, hopefully, help you identify where you're off base earlier and save you from sinking a lot of cost into a misguided "solution," but there's no guarantee. Poor execution can sink a good idea for a site, but great execution cannot save a site that doesn't solve a real problem. No amount of process can change that.

What's next?

Keeping the ideas from this post in mind can be useful for helping bring what you're trying to accomplish into sharper relief. I feel like the hypothesis template above ("If I develop a site that has...") could use some tightening though. There's also still the problem of figuring out how to detect when you're deceiving yourself about the reality or magnitude of the problem you're trying to solve. I'd love any suggestions on either of those topic in the comments.