Separating the Why from the How

When deep in discussions with a client over wireframes for highly complex systems, I've developed a simple way of defusing discussions regarding aesthetics:

Wireframes are the why. Visual design is the how.

If a client disagrees with why a specific bit of functionality is on the page, or has concerns regarding the types of content described in your documentation, then you're having a productive discussion that will contribute to the quality of the end product.

However, if you expending a substantial amount of energy describing how that functionality will be expressed, you have an option to recommend the following:

"In this meeting, we are looking to confirm that we've included the appropriate functionality, and determined its use for your customers/users in the right contexts and task flows. Upon approval of these wireframes, we will show you how that functionality will manifest to the user in a UI design on [deadline/date]."

Separating these two activities can help you move your functional ideas more swiftly into back-end development, and afford your visual designer a bit more freedom in expressing the how of the final result.

Now, if there are details you're presenting that the client keeps questioning—meaning that they are concerned about behavior, animation, and other attributes that contribute to the usability of a documented feature—a quick "grey box" motion study or disposable prototype built in a tool such as Flash, Photoshop, AfterEffects, Expression Blend, etc. can help move your discussion along. At the lowest fidelities, it's even appropriate to demonstrate an interaction using a few pieces of paper with pencil sketches. Whatever can help you show the proper attributes of how as part of your why will help you and your client agree on what's being built.

And if your design goal doesn't warrant wireframes? Answer for the why and the how with simple, annotated visual comps.