In recent weeks I suffered what I consider to be the most grievous insult ever spoken by a client to a designer. A client of mine said, “Thanks for the work you did. Don’t worry about the revisions. Our IT guy will take it from here.”

Two weeks later, my tech partner and I were invited back to the client’s office to review the wireframe changes completed by the unidentified IT guy. We had a productive conversation and asked several questions, pointing out issues and challenges to the user interface they had drawn. We made helpful suggestions to improve the experience and smooth out the development process. And then the conversation turned to one particular feature that we didn’t understand. The feature and our issues are unimportant. What’s important is the client’s response to our questions. We suggested the functionality would not be clear to his end users. He replied, “Well, that’s a training issue.”

That client expected his end users to figure out how the non-intuitive interface worked because he was unwilling to either A) ask his end users how they thought the system should work or B) design the system based on best practices and insight offered by his user experience designer ( i.e., me).

I sat quietly thinking through the options. We couldn’t talk to their end users. The client wasn’t going to take my word for it. And he was totally uninterested in doing what made sense. Because in this case, doing what made sense meant changing the business rules of the system. Business guys don’t do that. They don’t question the business rules. It just isn’t done. So I bit my tongue that day and three days later when he said to us (again), “That’s a training issue.”

Here’s my real problem with all of this. My client resembles a reasonable person. He is intelligent and well-intentioned, which is a good combination in my book. I think he’s even good at his job. (Although, I could be wrong. His job falls into that category I call jobs I wouldn’t want and therefore I hesitate to criticize.) He’s a business guy and therefore he’s a penny pincher, which again I can both understand and appreciate. But his math is wrong. He took up two weeks of his IT guy’s time not just updating my wireframes, redrawing them from scratch because he didn’t ask me for the design file. The changes they made to my drawings were so minimal I could have turned around the revisions in under two hours. Then he scheduled six of us in two review meetings that required follow-up emails and phone calls totaling way more hours than it would have cost had I been allowed to gather proper user requirements from the people who would be using the Web application or to have them check our work after sketching the user interface.

And that’s my real problem. Gathering end-user requirements and/or doing a quick usability test doesn’t have to be a whole big thing. Sometimes it can be as simple as walking around the office with paper print-outs of wireframes and talking to whoever happens to be in that day. It can be as easy as asking a question.

Asking one simple question is sometimes all it takes. If I could just find a way to convince the client to let me show the wireframes to his end users, we could sort out this feature that follows business rules that nobody understands. I would simply point at it and ask them, “What do you think this does?” And then we could make it do what everyone thinks it does. And viola, a well-designed interface is born.

To make a short story long, it is a training issue. I need to train my clients to understand that a little usability goes a long way. And I need to convince their budget-controlling bosses and accountants that I am not trying to sell them more hours. In fact, I am probably trying to sell them fewer hours. After a long lunch with their end users, I could have answers to all of our questions. And we could skip all those review meetings, follow-up emails, and phone calls and get on with bigger and better things, like teaching them how to break their (business) rules.