In my old office I had a sign behind my desk that said “Training is Not an Excuse for Poor Design”. It was a bold statement to make to my new company that had never had any trained professional mediating between the software developers and the clients. I had decided one day that it was necessary when I heard on a conference call one of my teammates say “Yes, we can do that. We’ll plan our training to take this into consideration.” He said this to one of our clients, and my draw dropped. Let me explain.
When a client, customer, or user requests a feature, they tell you what they want, thinking this will help them with what they need. We, as designers, need to know what they need and why they need it in order to provide the best solution to satisfy them. In Human Computer Interaction, where the user is king, we must always balance “The customer is always right” with “The user never knows what they want”. More often than not, software developers and salesmen back themselves into a corner because they don’t know how to deal with feedback and this delicate balance. The developers either give the user exactly what they ask for, or worse, give the user what the developers themselves think makes sense.
For those of us that don’t work on consumer web applications that can interact with their users through tools like UserVoice, usability studies and surveys, we often have to listen to the customer instead of the user. The customer is the person paying for the development, such as a VP of some division in an organization, and the user are those people working below the VP. Often we can perform more formal requirements collection with the VP and stakeholders, but with very little access to the actual user. Without good feedback, we’re left to our expertise and experience to build good usability into our products.
On one project, I was repeatedly denied access to the users, and in an interview with one manager, I asked how we were going to address user adoption if we didn’t know anything about nor did we design for the users’ preferences. He said to me unequivocally that “They’ll use the application because it is their job, and if they want to keep their job, they will do what I say.” This was clearly the wrong attitude. Last I heard (I had been cut from the project because they didn’t want to put more money into user adoption) the roll-out and subsequent use fell flat on its behind. And we still have the gall to ask “Why Are Enterprise Applications Underused?“
More recently, in conversation with a customer, he suggested a solution based on unfounded assumptions about the user. When I pointed out that it was unclear how much time would lag between when a user was finished with one step in the business process and would start the next step he said “Oh we can train them to do both sequentially.” Since we have an ongoing relationship, I paraphrased a line from a recent CIO interview of Harold Hambrose from Electronic Ink: “Good design means not having to train, and not having to invest in user adoption, so lets figure out the best solution before moving forward.” I think Cindy Alvarez (Product Manager at Loomia) simplifies this by saying “If something is difficult to do, people will not do it” in her recent article arguing for better usability in business processes.
The solution is very simple. When the user tells you what they want, ask them first what they are trying to accomplish. With detailed goals, the designers and architects can propose a solution that will help the user achieve those goals without inconveniencing them. Then we can extend the statement that “The user never knows what they want until they see something” which is a primary argument for agile development, rapid prototyping, and iterative user-interface design.
Training is not an excuse for poor design. And poor design is a result of misinterpreting user feedback.
Related posts: