Wireframes

Wireframes, also known as SSD’s, can be very useful for some projects. My experience is that for most projects they’re not very necessary. Wireframes are not a strict deliverable type that can fit any design project. Each project is different, each client is different. One way I look at wireframes is that they’re just a part of a design and fit somewhere in between a thumbnail sketch and a full blown production mock-up. Sometimes you just go from drawing to CSS and JavaScript. Wireframes be damned.

Andy Rutledge wrote an article that points to the pitfalls and benefits of wireframes. Pick the tools for the job. I strongly believe that you must understand your client and understand their goals before you do anything. As a designer you create for others and not for yourself.

Wireframes can be useful in situations where communication is poor. When you don’t have a chance to sit down with the client face to face. When they want one thing and their boss wants something else. Getting design patterns and content structure approved can be a critical to a project.  Reducing the noise in such situations becomes a challenge. If you’re on a project that’s swamped with use cases, wireframes and functional design with a fully documented interface description then I wish you luck, strength and wisdom. It can be great for a new design and terrible when you doing a redesign.
37 signals in known for their slightly quirky approach, no wireframes, no Photoshop and go from idea to HTML. It may sound a bit strange but in many cases this approach is very effective.

When you boil it down wireframes is a dialogue between you and the client about what they want from their site without commenting to much on the aesthetics of the project. However, sometime aesthetics is all you need.

Next entry: The design imperative
Previous entry: Vector my site