Pinning down the Process

Rather than making a start on the specifics of the project this week, I decided to spend some time pinning down my own design and development process. Although this process reflects the way that I already work this is the first time I’ve taken the opportunity to really think about what I do, and why.

I am, fundamentally, a scatterbrain. If I want to be organised and methodical I really have to work at it. In my previous life as an English student I tended to be all over the place. My essays would be a series of unconnected paragraphs, notes, quotations and references which would miraculously come together ten minutes before they were due in. This worked fine for me at the time but it’s not an approach that would work in any other situation and certainly not in web design. I can only imagine the look on the face of a client if, the day before their website launched, I presented them with a seemingly unrelated collection of sketches, paperwork and broken code and a promise that ‘it will all come together in the end.’

To counter my natural tendencies I’ve come up with quite a detailed eight stage process: 1. Research and requirements, 2. Sitemap and content planning, 3. Sketches and wireframes, 4. Mockups, 5. The build, 6. Testing, 7. Deployment, 8. Review.

By forcing myself to work through each stage of the process in turn I find that I work more efficiently and to a higher standard. I’ve also found that there are naturally occurring incentives. The more time spent on research and planning, the better the design and development stages tend to go, and the better they go the more fun they are. This little bit of hard-earned knowledge tends to stop me getting ahead of myself.

Of course it’s not always possible to stick rigidly to a process because in any project there are always variables outside of your control (also known as ‘other people’) and there are times when you have to move onto the next stage in the process before fully completing the previous one. So, although it has to be tempered with a bit of pragmatism, I find that as long as I stick as closely to the process as the circumstances allow, then it works for me.

I admit that I’ve idealised things slightly in the write up below. Up until now I’ve never done proper user testing but, based on what I’ve read since starting this course, I’ve added it in to the process where I think it should be done.

The process

Stage 1: Research and requirements.

Broadly speaking there are three things which need to be researched at the start of a project: the client, the user and the market. The first stage would be to research the client, and I would expect this to happen at the pitching stage. After all, you need to know who you’re pitching to! I find it helps to provide them with a tailored questionnaire, partly to find out about them and partly to encourage them to start thinking about what they want from their website. Whether this happens before, at the same time as, or after an initial meeting would depend on the client but ideally it would be in conjunction with a face-to-face meeting.

If they already have a website this is also the time to look at any statistics they have to find out how people are using it. If this isn’t possible, some more general research can be done on who they think will use their site. In the case of the bed and breakfast project, it might be a good idea to ask them about their guests: where they come from, how old they are, how long they stay. I would also want to find out in what direction they want to take their business. They may have cater for predominantly older guests and they may want to keep it that way, or they may want to attract younger guests. The more information you can get, the better.

Researching the market is important as you can find the strengths and weaknesses of their competitors, how they compare to other local businesses, and spot any gaps in the market. Coincidentally I overheard a conversation at Reading station this week discussing Fowey as a surfing destination. If the bed and breakfast has a large outbuilding which could be used to store surfboards, why not use it as a selling point and a way to attract that section of the market?

Stage 2: Sitemap and content planning.

Once the research stage is completed I would then put together a sitemap for the client, based on what I now know about them, their users and their business. I would then forward it to them for comments and revisions. Once the sitemap is agreed the next task is to work out where the content is coming from. To keep track of this I use a content document with notes on what we have, what we’re missing and who’s responsible for providing it.

These two documents are the foundations of the whole project and it’s good to make them as definitive as possible. There will always be changes throughout a project, but hopefully all the hard work up to this point will mean that the fundamentals are in place and that any changes are minor.

Stage 3: Sketching and wireframing + user testing

This is when the fun bit starts! The first thing I would do (preferably away from the office) is to sit down with my notes, a pencil and some squared paper and start working on some sketches. Once these are done I create two sets of wireframes. The first set is hand-drawn and not to scale, and is just to review the ideas and make sure that the basic site structure works.

The second set is done in a wire-framing application (I have recently started to use Balsamiq Mockups). These will be much more representative of the final site, and more or less to scale although they don’t have to be pixel perfect. Ideally the wireframes will then be shared with the client, so that they can see how the site is shaping up and how it will work. From experience though I’ve found that some people don’t like wireframes and if this is the case then sharing them can be counterproductive. So whether or not they are ever shown to the client depends on the project.

This is a good time to start user testing, to make sure that you’re on the right track. The further into the project you get the harder it is to change things. This can be done quite easily with a program like Balsamiq Mockups because it lets you produce interactive wireframes, either within the application or exported to a hyperlinked PDF.

Stage 4: Mockup + user testing

Once the wireframes have been agreed it’s time to move on to Photoshop and start working on full colour mockups. How many pages I mock up depends on the project: if it’s a small project I’ll probably mock up every page, if it’s a large project I’ll mock up as many as I need. There have been occasions  when I’ve mocked up too few pages, and have had to make it up as I go along when it comes to building the site. This has always had a detrimental effect on the project.

Another round of testing would be good at this stage, to make sure that you’re still heading in the right direction.

Stage 5: The build

By this stage I should be working with finished and agreed designs so it’s a case of translating this into a working website. As long as I have all the content by this point then the build can be done properly: XHTML first, then CSS, then JavaScript.

Stage 6: Site testing + user testing

Once the site working in a standards compliant browser then the next thing to do is more user testing. That way you can identify any problems with the structure or the functionality before you start worrying about other browsers. It would be demoralising to spend a lot of time getting a complicated layout working across all browsers only to find that it needs changing because it isn’t easy to navigate. This is when you get a return on the time spent user testing so far as hopefully any major problems will have been identified and fixed already and anything that comes out of this round of testing will be more of a tweak than a tear-it-down-and-start-again.

Once that’s done, then it’s time to start ironing out the wrinkles from the other browsers. I fully agree with the principles of ‘Progressive Enrichment’ as described in Handcrafted CSS so the aim is not to make the design look the same in every broswer, but to  provide as good an experience as each browser will allow.

Stage 7: Deploy.

Once the site is tested then it’s time to copy it over to the live server, and then test it all over again! Hopefully there won’t be any cross- browser issues at this point so it should just be a case of checking that the links work, that the images are where they should be, that all the forms and other interactions work. Once that’s done I’ll revalidate the site and run it through a link checker.

Stage 8: Review.

This is part of the process never really ends, although who reviews the website and when is very much down to the agreement between you and the client. After the website has been up and running for a while it’s good to spend some time looking at as much analytical data and user feedback as possible. This gives you the chance to assess the project and whether the site is achieving its goals, and being used as expected, or whether the site is being used in a completely different way from how you had imagined. You can then use this information to continue to develop the site.

« »