Training: A Dirty Word in Product Design

In my old office, I had a sign behind my desk that said: “Training is Not an Excuse for Poor Design”. I couldn’t help myself; a bold statement had to be made after I heard a sales representative say, on a conference call, “Yes, we can do that. We’ll plan our training to take this into consideration.”

“Training” should be a dirty word in product design. When we rely on training to teach a user how to do something we are missing key opportunities for creating better user experiences. And, we’re expanding the cost of adopting our software. The best design should be intuitive because it sets the user’s expectations then meets those expectations. A great design understands what the user is trying to accomplish and greets the user with an easy way to do so. Real user experience understands the Gulf of Evaluation (the time it takes for someone to figure out how to use your product) and how to keep it small.

Training Should be the Last Resort

If you’re a designer or software developer and your teammate suggests training for the interface you designed, you must have not done your job. You need to find out why your interface has to be explained to your users.

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 user feedback and the delicate balance these competing tenets create. The developers either give the user exactly what they ask for, or worse, give the user what the developers themselves think makes sense. This is a product design problem systemic to the industry, from the workspaces of top start-ups to the board rooms within corporate giants. We end up with a lot of messy software because we don’t filter requests through sensible design and usability heuristics.

Let’s start with the basics: collecting requirements. When a client, customer, or user requests a feature, they will tell you what they want. They’ll try to describe it to you by detailing the exact functionality. “I want a dropdown that allows me to select all the fruits and vegetables I need for dinner tonight.” You can (1) go off and design a drop down that has multi-select checkboxes inside it, or (2) you can clarify what the user is trying to accomplish, coming to the conclusion that a simple list of checkboxes without a dropdown will solve the problem.

That’s an easy example, but one I hope illustrates your approach to conversations with clients and users. As designers, we need to know what users need and why they need it in order to provide the best solution to satisfy them — this is the information you need to develop a product that truly helps users accomplish their goals.

Design for the User, which might not be the Customer

For Product & UX Designers in B2B environments or on massive IT consulting projects, you 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 users are those people working below the VP that will interact with your software. Often you can perform more formal requirements collection with the VP and stakeholders, but with very little access to the actual user. It is pivotal that the designer gets to talk to the users, not just the customers. Without this insight, designers have to rely on their own expertise and experience to build good solutions. A successful design solution is really that which has been imagined by users, but filtered through the UX process of a great designer.

On one project, I was repeatedly denied access to the users. In an interview with one manager I asked how we were going to address user adoption if we didn’t know anything about his employees’ preferences. He wanted our product design to be innovative and creative, but without giving us the information we needed there was no way to make it user-centric. 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.”

Dictating to Users How to Do Things is Expensive

Working on this project was a pivotal experience in my career as a designer. I was in the midst of working on this $1.5 million project for a California utility while the company was funding a $250 million project with Accenture. My program manager went to meet with the CIO to gain sign off on keeping me on the team. In that same meeting, the Accenture representative explained that this HUGE project was a failure because they did not do user research or testing during the development of the project. That’s $250 million dollars of tax payer money down the drain because the consultants on the project did not involve users in their process, and foolishly believed they could “train” the utility workers to use their solution.

Meanwhile, on my small project, I was cut from the project. They didn’t learn their lesson and decided not to put more money into user requirements and adoption. The last I heard the roll-out and subsequent use of the system fell flat on its behind. And we still have the gall to continue to ask "Why Are Enterprise Applications Underused?" in 2009 and keep asking this question in 2016. In fact, we now have a name for it: Shelfware.

Keep Your Ears Perked for the Dirty Word

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 I felt comfortable with this customer, 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 let's figure out the best solution before moving forward.” Likewise, if something is difficult to do, people will not do it. Good design has to ensure that the program is intuitive and accessible because every moment it’s not easy for the user is an opportunity for the user to give up, jump ship, delete the app, or find another way to accomplish what they need to do.

Avoid Training by Talking About the User’s Goals

What you need to do is very simple. When the user tells you what they want, ask them first what they are trying to accomplish. It’s one of the core tenets of usability engineering. With detailed goals, the designers and architects can propose a solution that will help the user achieve those goals without being difficult. As the designer, you need to filter their goals through usability principles and software design best practices.

Once we propose a solution, we can add context to one of our major tenets: “The user never knows what they want until they see something.” This then justifies agile product development, rapid prototyping, and iterative user-interface design. We ask the user what they’re trying to accomplish in research, we design something we think will help them get to their goals, and then we test it with them to see if they can use our interface to get where they want to go.

You cannot use training as a way out of solving a difficult problem— training should be avoided at all costs when trying to teach someone how to use software. Don’t be the designer whose software requires training because it just shows that you were lazy in applying usability principles or you misinterpreted user feedback. Plus, your software rollout now costs more money — your company has to develop and pay for training, then struggle with user adoption.

After reading what I’ve wrote so far, doesn’t this Salesforce training seem like an oxymoron?

This article first appeared on Medium at

https://medium.com/@LindsayT/training-is-the-lazy-designers-easy-way-out-d7291978f4ba