How to Understand the User

If you haven’t read Robert L Read’s How to be a Programmer: A Short, Comprehensive, and Personal Summary, do yourself a favor and read it. I want to highlight one sections in particular that illustrates my belief about what makes an effective technical artist/tools programmer:

How to Understand the User

It is your duty to understand the user, and to help your boss understand the user. Because the user is not as intimately involved in the creation of your product as you are, they behave a little differently:

• The user generally makes short pronouncements.
• The user has their own job; they will mainly think of small improvements in your product, not big improvements.
• The user can’t have a vision that represents the complete body ofyour product users.

It is your duty to give them what they really want, not what they say they want. It is however, better to propose it to them and get them to agree that your proposal is what they really want before you begin, but they may not have the vision to do this. Your confidence in your own ideas about this should vary. You must guard against both arrogance and false modesty in terms of knowing what the customer really wants. Programmers are trained to design and create. Market researchers are trained to figure out what people want. These two kinds of people, or two modes of thought in the same person, working harmoniously together give the best chance of formulating the correct vision.

The more time you spend with users the better you will be able to understand what will really be successful. You should try to test your ideas against them as much as you can. You should eat and drink with them if you can.

Guy Kawasaki has emphasized the importance of watching what your users do in addition to listening to them.

It is no surprise this section is under “Advanced.” This is a skill that takes time to acquire and some people will never acquire it. Even more dangerous are people who think they have acquired it, but do not have developed programming skills and thus lack the ability to ‘create’ and truly solve the user’s problems. Likewise, the people who do have these technical skills but are not deeply enough involved in understanding the user’s problems operate at a fraction of their capacity. I’ll discuss more about the ‘tech art model’ in future blog posts.