I'm teaching again for the first time in a long time, a course with the romantic and evocative name of Web Page Construction. This means that instead of my thoughts being a swirling morass of bits and pieces, of jquery, user testing, code quality, and responsive design, I need to try to organise things up there. You can probably see from the design of my blog that I'm not a designer, I'm a geek who wants to get better at the non-geek stuff.

The first thing I'm trying to answer for myself is, what does it take to make a web site? The common answer when teaching this in a computer science context is that you throw some HTML, CSS, and Javascript together, with varying degrees of care. And at a very high level, that might be a reasonable technical answer, but it definitely shouldn't be the whole story.

My answer is that there are three broad steps to making a web site:

  • Work out what you need to do and how to do it well.
  • Implement things based on your planning.
  • Work out how to do things better.

The final important thing about this process is that it's cyclical, so the "make it better" step feeds back into "work out what it's about". There should definitely be at least a full iteration before a site goes live, and after the site is live you have access to much more data in the final step. You might also choose to have a staged "go live" step, opening up to a few real users before you throw the doors open to all your target audience, so that you can take advantage of the extra data for another iteration or two.

Work out what it's about

You can't build anything until you know what it's for, so the first step is to work out what you're trying to achieve. Who are the target audience, what are their needs, and how will you meet them? A useful technique is to develop personas, fictional people that represent the major users of the site. If this is a site you're creating for someone else, talk to them about what they want and get their help to develop the personas and their goals.

In the context of the personas and their goals, consider the functional requirements of the site, what it should do, and the data required to make that happen. Think about how the users will interact with elements of the user interface.

I can't stress how important it is to talk to people. The least effective development process is "tada development"1 where you turn up to a client with a "finished" system and hope that it will magically meet their needs.

As I said, this isn't just something that happens at the start of the project, you need to make sure you carefully plan what you're doing each iteration. It also doesn't just have to be about user interfaces, it could be about planning what technologies are most appropriate for the particular needs of the site, or how to solve a performance issue you've discovered in the "make better" step below.

Build stuff

The actual stuff that gets built depends on where you are in your iterations. At the start, this step should include sketches or prototypes of the planned user interface, then you might mock up some HTML and CSS, maybe add some interactivity with Javascript. It could even be implementing database replication and sharding to solve that performance issue.

Make it better

Each step of the way, you should be gathering data to see if what you've built so far is meeting the goals you set out to meet, and to identify where you're going wrong. Those prototypes you built? Show them to people and get feedback. Perform some user testing to see how real people actually use the interfaces you've built. If you're not sure that your new and improved interface actually makes things better for people, do some A/B testing and get some hard data.

You can get all sorts of data freely through services such as Google Analytics or what elements of your user interface people click on with services like the not-free CrazyEgg. Or work out what's slowing down your users' experience with Google Page Speed or YSlow.

There are hundreds of things you can analyse and measure, which can in turn feed back into the next iteration and help you meet the goals of your users. And if you're anything like me, the data itself is a source of fascination.

My explanation of these steps is not supposed to be exhaustive. In fact, many, many text books have been written about each one and it wouldn't even be fair to say I'd scratched the surface.

The Web Page Construction course I've inherited definitely focusses on the middle step, and that's fine. My job when teaching the course is to make sure that it's clear that the technical detail should be taken in the context of all three steps. We'll see how I go with that.

  1. Thanks to Donal for this phrase.