Those Who Can, Do. Those Who Can Also Teach

One of the joys of working on something as new as usability and user experience design is that most people have no clue what you do. Say you’re an architect and most folks have a good grasp of what your job is, say you’re an information architect and people stare at you blankly. So I’ve found that I spend fair amount of time teaching people what I do and why I do it. There a few things I’ve learned from my experiences about the what you should and shouldn’t do when trying to explain or justify your work to a boss, client, or co-worker.

1. Don’t preach

It can be very easy to go on and on about everything you have ever learned about usability while those who listen fall slowly into a deep coma. You may be extremely passionate about your work and eager to share, but most of the time the person you’re talking to is eager to get the gist of it and move on. Don’t just launch into your spiel never to look back. Provide brief focused answers and ensure there is a give and take between you and those you are talking to.

2. Know the classics

It never hurts to be able to cite a classic study or seminal work when you are trying to support your ideas. Name dropping at a party makes you a bore, name dropping in support of your work makes you informed. Don’t go overboard by providing a complete bibliography for everything you do, but go back to your old Herb Simon or Marcia Bates articles and make sure you know where the ideas you are applying come from. This gives you ammunition against people with a feeling or suggestion that you know is wrong.

3. Don’t talk down

Most people are okay with taking advice from an expert but nobody likes to feel stupid while doing it. Even when you are dealing with the cognitively challenged or folks who just don’t know a PC from blender you must resist the urge to talk down to people. This means treating people as partners that you are sharing information and expertise with, not as simpletons. If you are using industry jargon or acronyms just provide a quick and easy explanation at the level of the listener like “we’ll be using one external style sheet sitewide, that’s a file that stores the information like font size and color for all the web pages”.

4. Don’t dictate, justify

There is a big difference between saying “we should move to using CSS” and saying “moving to CSS formatting would allow us to update the formatting sitewide by changing a single file, this will save lot’s of time and money in the long run”. There are two big differences, the first is that you are making a statement of fact that leaves discussion open but little doubt as to the correct choice. The second is that you have provided an explanation, in this case it is saved time and money which is about as good as it gets. This approach will make others feel like they are a part of the decision making and that gives you allies later on when it comes time to promote or defend your decisions.

5. Know your audience

This one should sound familiar. There is a big difference between the developers you have to collborate with, content providers, graphic designers, managers, and your mother-in-law. You should be able to provide the detailed, technical answer and explanation to the developers, the non-technical explanation to the content providers, and the financial justification to your boss. This may take some practice to get used to but it is part of the job and in the end it will pay off as people start to understand what you do and why you are doing it.

Kevin Hall
Latest posts by Kevin Hall (see all)