Training

Getting specific and understanding the customer’s approach mindset

Whatever product, program, service, or system you’ve designed, you’re going to need to train people how to use it. Whether that means designing a simple walk-through to onboard new users or familiarizing employees who will take in data submitted by customers or partners, offering some sort of training is a best practice for successful delivery.

There are three practical advantages to creating training:

1. Designing training helps you and your team reorient your mind from that Design mindset to the Delivery one.

Thinking about training requires that you take your eyes off the product, program, service, or system you’ve focused on for so long and to consider it from an external perspective: the perspective of people who don’t necessarily have the investment you do, but who will invest in it because they’ll need to use it.

2. It builds a connection with the folks who connect directly to your target audience [link], helping solve the Specificity and the Hostess problems from the outset.

If the people who will use your designed thing are front line workers, for example, they can tell you more specifics about your target users than any market research or survey ever will. They can tell you how people express themselves at the moment of interaction, what they’re feeling, and how they like to be addressed.

3. It widens (or begins, if you haven’t begun it) the process of change management in the organization.

Training people and accepting their feedback through the training design process familiarizes folks with what you’re doing, increasing the chance that your work will be accepted by the organization and achieve long-term sustainability. The tension between new ideas and organizational inertia is a real and substantial one;¹ it must be dispelled through transparency, knowledge creation, and re-investment in the organization.

Do’s and Don’ts of Training

Do pressure yourself to make the training as user-friendly as you’ve made the product, program, service, or system. Get this training right, and you’ll have users suggesting updates and new features to you in the future, instead of having to discover them all yourself.

Don’t treat training as a passive walk-through of the features of your product. Instead, consider the input you get from training to inform final tweaks to your product. So as you train folks, make sure you retain the capacity to make changes to your offering.

Do build in a feedback loop on the training itself with the people who will administer the offering to the public. If there’s a team that’s going to consume inputs through the form you designed, or a group that has to confirm the completion of submissions to a program, bring them in not only to the design tests, but into the training design as well. This will help iterate the offering forward, and ensure the training develops at pace with any changes to the offering.

Don’t pressure yourself to make the training include everything. Ask yourself the same question in this phase as you did in the initial design rounds: does the user need to see this? Is this language necessary? Put into the training only what is actually useful to the user.

Do provide a continuous feedback loop to the people who will administer your offering. As time goes by, your team might move away from the day-to-day functionality of the product, program, service, or system, but if you build a formal feedback loop, you can be alerted when features break, semantics shift, or even to consider suggested improvements.

Up Next