Designing for the Web

Chapter 3

Understanding Workflow

One Mockup or Many?

I’m going to talk about the design process a bit later on in this book, but there are certain parts of the process that generally fall outside a designer’s role, stuff that happens during a project lifecycle that’s useful to know about.

One Mockup or Many?

About eight years ago, I’d moved to Cardiff from London, and worked in a company that predominantly produced design for print. I was part of an expanding web team that produced web sites for clients who came to the agency for print work. It was assumed that web design followed the same process as print design. So, the agency would, as part of their pitch for the work, produce speculative designs and present them. This included designs for the web. Then, upon winning the work, we would generally go back a step and then produce three different design directions for the client to pick their preferred route.
This was bad for the client, and bad for the agency. When designers go through that process, they will always produce a preferred design. They will produce a design that they feel best solves the problem. Any other design produced is just playing lip–service to the process and nothing more. For many years now, following a brief from a client, I’ve been producing one design and then iterating and amending to improve it.

This has several advantages:

  1. No time is wasted. The process I described would see lots of wasted time – first the speculative work, and then the other two design directions.
  2. More involvement and understanding from the client. The client is involved earlier in the process. Working iteratively means more contact with them and a shared direction.
  3. No time is wasted. The process I described would see lots of wasted time – first the speculative work, and then the other two design directions.
  4. If the design is inappropriate, you can start again without too much time and money being wasted on other design directions.

Design Meets Development

Those of you who work in-house, or even within large agencies, will be well aware of the tensions between designers and developers. In part, these tensions have been created by a lack of understanding by designers early on in the web’s history. As I mentioned in earlier chapters, designers thought they could apply print-based design methods and characteristics to web design. We all thought it was fine, but we didn’t have to build the sites. Developers would receive the designs and, at the time, despair at the thought of trying to interpret the layouts and create HTML pages. It wasn’t until I sat next to a developer for over two years that I began to appreciate the value in communicating with developers as much as possible through the design process. Corporations spend thousands and thousands of pounds every year trying to achieve efficiency in departments where, in my opinion, a simple seating change would suffice. If you’re a designer working in a large agency, do yourself a favour, and don’t sit next to other designers. Likewise, if you’re a developer, or project manager, sit next to your project team members, not your discipline peers. In two companies that I’ve worked, we did this. And I continue to share a studio with a web development company. Even if you don’t work on projects directly, the shared interests and passions for the web are invaluable at raising the understanding of the two different aspects of web design and development.

The Perfect Design Methodology

There isn’t one. There, I’ve said it. In all of the agencies I’ve worked, each had their own way of doing things. In the BBC, we tried a few different methodologies, such as Agile and SCRUM, but I’m coming round to the idea that applying a blanket process to every project you work on just doesn’t work. In a large agency, it’s important that everyone – from client services, to strategy – understand the web design and development process that is being adopted. That way, when they speak to the client, the client will understand. Having a strong, transparent process is always helpful for clients, too – it puts them at ease. However, for all of this efficiency, transparency and project management rigor, a rigid process is dangerous for any designer or agency.

I take a simple view on this. Every design problem is different, so how can every approach to solve the problem be the same? A cookie–cutter approach to web design and development is about maximising profit and efficiency with minimal innovative and original thinking or problem solving. For example, an architect cannot apply the same design and building process to every building. Various factors determine the approach, from the client’s wishes, the local government regulations to the constraints of the building materials. All of this shapes the process and the same can be said for web design. An example of this would be a recent process my studio worked on, the Drupal.org redesign. The Drupal.org website is primarily a community site representing an ecosystem surrounding the open source content management system, Drupal. Our job was to redesign it. The new Drupal.org would be built and updated by the very community that created it, and to do that, we needed to engage with them in a completely different way. We couldn’t adopt a traditional design approach. We needed to bake the community involvement into the process from the very beginning. We did this through many channels:

  1. Twitter accounts
  2. Flickr – for sharing wireframes, logo ideas, and site maps
  3. Blogs – both mine (markboulton.co.uk), and Leisa Reichelt’s, the user experience design consultant on the project, (disambiguity.com)
  4. Online card sorts
  5. Remote usability testing
  6. The Drupal.org website
  7. IRC
  8. and a few more…

With this continued involvement from the community, along with iterative design development in the form of weekly prototype releases, there is just no way we could adopt a traditional agency production model. It would have been a disaster and the project would have failed. In this instance, the project defined the process – we were just along for the ride! Understanding web design and development workflow is as much about understanding the design problem as anything else. Being adaptable to new approaches, to question and revise your approach is as much a part of web design as creating layouts in Photoshop or HTML.

More from this part

Back to Table of Contents

Download the book

Download your FREE copy of Designing for the Web.