Designing for the Web ~ Getting Started
Understanding Workflow 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: ß 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. ß 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.
ß 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.
licensed to Denis (1 user license)
Designing for the web