The Design Process - Part 2

[webnetics]

Here are a few of the questions I like to ask in initial client meetings even if I’ve already answered them myself via a search engine:

What does the company do?
What is your role in the company?
Does the company have an existing logo or brand?
What is your goal in developing a web site?
What information do you wish to provide online?
Who comprises your target audience?
Do its members share any common demographics, like age, sex, or a physical location?
Who are your competitors and do they have web sites?

Sometimes I start off with more questions than those listed here—use your imagination and try to come up with some creative queries that will really give you more insight into the client organisation. If you’re a programmer, avoid the tech jargon. If you’re a designer, avoid talking specifically about design. Sure, that may be all you’re thinking about, but semantic markup, fluid and fixed layouts, and color schemes will likely mean very little to the client. Worse still, these types of conversations can bring misguided design opinions your way even before you get a chance to start thinking about the design yourself.

Implementation

The next step in the design process is to take what you’ve learned from the client and use it to create a design. Regardless of the project, try not to get caught up in the technology associated with building web sites—at least not at first. At this point, it shouldn’t matter whether the site is going to comprise straight HTML, a template for a content management system, or a PHP application; the bottom line is that we have an interface to design and a blank sheet of paper. “Paper?”

That’s right, paper. Did you really think I was going to let you get back to your precious computer right after the client meeting was over? No way.

Here’s why: it’s easy to lose focus on the design if you start thinking about the layout in front of a computer. If you start out on paper, you can ignore the technical limitations of browsers and CSS, and focus on how you want the final product to look. Now you might think that all good designers carry around fancy hardbound sketch books in which they use expensive markers and paint to design masterpiece renderings of web page layouts. For me, the equivalent is a 59p spiral-bound notebook from Asda and any writing instrument I can find on my desk that still works.

I start out by sketching a few possible layouts. After a few of these sketches, I decide on one I like, jump into Fireworks, and use the rectangle tool to block out the areas I’ve marked down on my paper. Once I’ve defined my layout, I experiment with foreground and background colors until I have a solid color scheme. I continue twiddling the Fireworks knobs and pushing around pixels until, finally, I have a comp to show the client.

Simple, right? Okay, perhaps I skipped a few steps in that brief description. Honestly, though, when people ask me how I do what I do, they usually get a similar explanation. The truth is that there are bundles of now-subconscious information from my past experience and those old college design and art classes that have helped me to define my own design process.

Learning how to design is like learning how to program. Some people have a bit of a knack for it, but anyone can learn. Just as there is good code and ugly code, there is good design and ugly design. Learning some of the principles and conventions that are associated with design will help you to understand the difference between the good and the ugly, and help you toward establishing your own design process.

To be continued ….