Turning our design process upside down

Posted on 18 July 2011 by Pete Duncanson Tweet

Our design process, like many agencies was based on older technique and practice, we turned that completely on its head and embraced "content first", quick iterations and rapid HTML & CSS prototyping. The results were amazing and incredibly liberating.

It's fair to say we're incredibly pleased with the feedback we've had from the web community towards our exciting new venture Cutting Edge Knives.

We used this website as a demonstation of us putting our money where our mouth is and practicing what we preach but also building a website using a content first approach and rapid HTML prototyping instead of time consuming designing in Fireworks and lots of back and fourth of png's to change colours and font sizes.

Just want the process steps?

1. Paper prototyping and content planning
2. Rapid prototyping with HTML & CSS
3. Design, visual flourish & client involvement
4. Finishing up
5. The results
6. Possible difficulties to consider

What's our new design process then?

It's pretty straightforward really. If you're involved in the day to day planning of websites your process was or is probably pretty similar to our old one which involved taking the brief from a client, creating some visuals with lipsum text, going through rounds of feedback and then building it and finally after weeks of chasing - getting copy to fill in the gaps.

That process worked pretty well for a long time for us and I'm sure most of the other web agencies out there but it's no longer good enough or practical for us and it may not be for you either.

Step 1: Paper prototyping and content planning first

Sounds weird now we've swapped round but content first truly is the only way to go. In the past like many others we've tried to lead a project from a visual start point.

What we did for Cutting Edge Knives was to sit down for 2 days before we even turned on our machines and tried to write out the content the site was going to include.

I want to stress at this point that "content first" doesn't literally mean we wrote out every line of text for our all our products.

It means we worked out what the site would include. An example of that would be a product page where we wanted to include standard things like Product Name, Price etc but also the "To the point" section, the technical info from manufacturers, cross sale products and all those other little nuggets of information tucked neatly into the page. It's like a sitemap but on page level and because it's sketched on paper, it's quick and easy to edit (you'll see that being a theme here - paper = cheap + quick).

Working in this way also lets you start planning the structure of your markup even at this early stage.

Step 2: Rapid prototyping with HTML & CSS

This project is the first opportunity we've had to just rewrite our own process from scratch so the next step following on from some wireframing on the whiteboard and in notepads was to start prototyping in HTML with a bit of CSS.

On this occasion I realise we're lucky that we were our own client on this so we weren't subject to the usual signoff and back and fourth that you typically have on client projects.

However, we were always aware of this and didn't feel that there was anything we were doing that a client wouldn't understand or grasp.

Wireframing on paper is fine for an initial sprint, if we had to present to a client we would have quickly mocked up the wireframes in Balsamiq.

Initially all that freedom went to our heads, we sketched out some amazing javascript powered awesomeness.

We built 3 quickfire versions before settling on the site we built

We were aiming for a single page front end that had some (we thought) pretty snazzy and unique UX touches while remaining easy to use and visually impressive.

We actually started building the basic layout and functionality of our page but even with some fairly minimal markup, we found the initial idea was just too complicated and asked more questions than it answered when it came to how users would interact with the site and what would happen if they did this and that.

It was great to actually to spend some time prototyping like this and ruling out ideas after a quick sprint. To give you an idea of timescales involved, I put together the first two "sites" (effectively 2 static homepages with basic CSS) in less than 2 days.

Imagine designing something you were sure was awesome and getting to the build stage weeks down the line only to find it's just not feasable!

Step 3: Design, visual flourish and client involvement

At this stage you've probably thought "how the hell would I communicate some wireframes and scribbles to my client for approval?"

Again, with us being the client we already had a discussion about look and feel and were agreed on the basic look we wanted. Unfortunately that's not exactly how it works on projects with clients and stakeholders who want to see what's going on and make their mark on the project.

It's worth reiterating at this point that this process absolutely requires a change in mindset and methodology from both us as designers and the client because the "old" way just doesn't cut it.

The client has to be totally engaged with the process

You'll remember in step 1 and 2 above we talked about content, wireframing and rapid prototyping, well, don't forget the client has been deeply involved in the site from the very beginning. They've had to be.

This process can only really work when a client engages with it. They can't remain distant and expect occasional emails with designs.

The "old" method of firing over visuals was very stilted - send visual, wait for list of changes, make changes - repeat. Remarkably inefficient, time consuming and costly for all involved.

This way they get a better feel for how the site works and how the content lives within the layout at this point.

We add visual flourish at this point and get into Fireworks (or Photoshop if that's your bag) and send over visuals because you've got something to work towards in terms of a wireframe and content areas. The design is then just that, a visual layer on top of a site that you know is correctly laid out, has well structured content and works.

Step 4: Finishing up

This is the best part of the process, because we've streamlined everything and we work in tandem with our client rather than back and fourth - we found the whole site was developed and populated much quicker (remember we can give the client access to the CMS much earlier working this way) so chances are you could slash production and design time if you work with a client who embraces the process.

Working in rapid iterations is also liberating because it builds a level of trust that you're constantly improving on a site. It's a fluid thing, ever changing (hence a CMS) so it's not a one shot deal as many clients are still finding difficult to embrace.

Step 5: The results

We found this process certainly worked for us! Here's some of the feedback we got last week from fellow web designers and developers  when we launched (you're all so kind!). On top of that, from nothing at all, the site has already started actually started making money.

Bear with us, the site and our new working process are just out of the wrapper and there's lots to refine and iterate in both but I hope this gives you some food for thought on your next project.

By my estimates, we slashed a good 25-30% off design & development time compared to working in the "old" way so it's certainly the way we're moving forward with.

Step 6: Possible difficulties to consider

The process is not without its drawbacks. Here are some of the potential stumbling blocks you might encounter. Feel free to make a suggestion in the comments on how you'd handle these!

1. Providing a fixed quote for a client using this approach (Check out Carl Smith's article on why they now bill hourly for ideas on this - we also bill hourly so this isn't such a big issue for us)
2. Clients not seeing visual elements / design until later in process (is this an older mindset issue as they are involved from the beginning with content + wireframe + HTML prototyping?)
3. Dealing with stakeholders who want a graphic to show off and ammend (Again, perhaps more an issue with client involvement and their influence being a little back to front in the "old" process?)