Days later I would present the client with one or two visual directions, get feedback, make revisions, and start coding the site in xhtml. The best designers at the agency made the best looking websites.
As my career progressed, I learnt that showing the client a wireframe before I started on a visual design could save us both time. Wireframes, however, felt awkward. Their intent was to facilitate a space for ‘quick revisions’ before the client and I ‘decided on a direction’ and started the ‘design process.’ They were supposedly quicker to create than visual designs, and thus, quicker to change. However, wireframes sketched on paper were considered too unpolished to present to a client, so I would spend time creating digital wireframes. After presenting the wireframes, rarely did I find that they inspired any meaningful conversation. In fact, seeing the digital wireframes almost never led us to change direction.
Does your wireframing process look like this? This paragraph was extra painful to read because it reflects how we’ve used wireframes in the past – as a way to “sign off” on designs to ensure the client doesn’t make changes later on in the process.
Looking back, I didn’t find wireframes valuable because I used them to solve the wrong problem. They were used as a checkbox to move a project from ‘exploratory’ into ‘ready for design’—to prevent a client from changing their mind at a later date.
It’s important to remember that wireframes are just one of the tools in your disposal. In the article, Dustin Senos argues that wireframes should be used to explore ideas really quickly and aid in narrowing down to the best solution.
To add on, I think of wireframes as primarily a communications tool. A designer may be able to interpret paper and whiteboard sketches, but a business stakeholder might need something more high fidelity. It’s all about finding the most appropriate medium to communicate your design thought process.