The idea of customer education is frequently thrown about as something to aspire to. Is this the case? In some instances it is – when we are educating a customer on a fundamental design or usability principal, for example. In other instances, however, it’s necessary to educate the customer so that they can understand the design document, but this shouldn’t be something to aspire to.
##Client education isn’t required if design documents speak their language.
We’ve just been involved in some discussion of wireframes. A traditional wireframe consists of text, lines, certain premade elements and a variety of shapes. They look like a newspaper layout. Our wireframes are similar in that they don’t have a visual design applied to them, but they are created to look like a potential HTML page. I like this better for two reasons:
**First, clients understand wireframes that look like HTML pages.** Usually accompanying a presentation of wireframes is an explanation of what they are and how to read and understand them – the conventions and models used to build them. Unsophisticated clients frequently take a look at wireframes and wonder what they are supposed to do with them. A wireframe designed to look like HTML brings down the understanding border and allows the client to truly understand the design.
**Second, HTML-style wireframes enable fast prototyping.** Obviously, it’s easier for a programmer to throw together something that’s already done.
**Educating a client to understand a deliverable is like conducting a meeting in Esperanto and explaining that in order to understand what we were talking about they’d first come take a course.**