Wireframes May Cause Prototyping Headaches

April 15, 2005 | by Martin | in Blog | 1 comment

I've just finished reading very nice article by Keith Robinson called Page Description Diagrams where he summarizes how problematic wireframes can be in website prototyping process:

If you’ve shown wireframes to more than a few clients or stakeholders you probably know what I’m talking about. No matter how hard we try, no matter how much we say, “don’t pay too much attention to the design,” clients can’t help themselves. Place a wireframe in front of a stakeholder and they will forever-more have some sort of pre-conceived notion of your design. They’ll “thin-slice” it.

And then he offers solution to this problem:

A narrative can be used to solve this issue. What a Page Description Diagram attempts to do is tell the story (Ah, storytelling, on of my favorite topics of late) of the page, and lay out its design goals—without actually showing the form of the page—thus allowing for the creativity of the designer. A wireframe can still be created, informed by the information contained in the Page Description Diagram, but at this point it’s closer to the design.

We've spent many hours with tweaking our prototyping process in recent months. Prototyping is essential part of our overall approach to website development. I can even call it corner-stone of our process since development of each client's website starts with it.

At the beginning, we also used wireframes blended with interactive html prototypes. It was big step forward - final websites were much better and communication with clients was improved. It helped us to quickly create clickable site prototypes before working on the visual design. We were suddenly able to capture client expectations in easy-to-change and flexible html pages. These simple html pages contained zero graphical elements and used only faux texts and placeholder images. Clients were pleased by the ability to actually see and click through their upcoming sites so early. They provided us good feedback (but not great as you will see) and consultations were mostly to the point.

However, we soon realized some drawbacks of this approach. Firstly, we were also solving layout issues on the pages as advocated by wireframes. This resulted in stepping on the designers' toes as well as in time wasted on unproductive discussion (try to move that featured photo to the right and center the headline etc.).

We wanted to focus on solving content structure issues and not content positioning ones. Layout and positioning must be the responsibility of the designer - only this can lead to clear separation of responsibilities in the team (this doesn't mean team members will stop sharing their insights together, of course). Also, faux texts and placeholder images proved to be restrictive since they were not easily understood by the client.

In summary, we paid too much attention to layout issues. This is off-topic during prototyping phase. As a side-effect designers had to follow these early positioning decisions to meet client expectations. What should be designers responsible for if not for information design?

We were aware of these problems and knew that ideal prototyping process should meet following assumptions:

• make communication with client easy and straightforward
• focus on content structure and page goals
• describe functionality requirements on pages
• model site navigation paths
• serve as an ideal site blueprint for design and development team once finished
• draw clean separation line between prototyping and designing / development phase

I will continue with page descriptions diagrams idea coming to rescue in the next part. But, hey, it will not be as simple as implement this technique and forget it. We tried to enhance it and blend it with the advantages of another method.