<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=344430429281371&amp;ev=PageView&amp;noscript=1">


Designing Training Focused on People, Not Features

Written by James Tacker

Published on February 12, 2016

In a recent LA Times column, featured high school calculus instructor Anthony Yom propelled his students to achieve a 95% pass rate for the AP calculus exam. The impressive part is he achieved this feat in an underpriviledged part of Los Angeles not known for high acadeic achievement.

So how did he do it?

After reading the article several times, it becomes clear that Anthony Yom chose completely embrace his students, whether they initially reciprocated or not. He chose to teach to their will and intelligence rather than just write some proofs on the board with a "survival of the fittest" attitude and call it a day. Anthony Yom truly cared about his students and they eventually believed in him along with...ya know, the most important person to believe in—themselves.

If you're an instructional designer or technical curriculum developer, how can you translate what Mr. Yom did for these kids learning calculus for your customers who want to learn JIRA Software, or NGINX, or Docker. How can you engage the students at the same level of locked-in, focused, meaningful attention?

Build for People, Not Features

When there's a new release of a product or feature, it's very easy to read the release notes and publish a quick "how to" blog or stream post (and I admittedly do this all the time) without taking into account why the product/feature was released in the first place. Accenting tutorial information with real-world context is more useful to customers than to publish a course regurgitating documentation.

To put it simply, write the course with use cases and problem-solving in mind so that product features resonate with a student's professional needs and pain points. Someone reading your curriculum wants to better their career and in order to do that they need to visualize how learning about the product or tool you're teaching will help them achieve that goal. Ideally you want the customer to walk away with a better understanding of the product features as well as practical and applicable knowledge to aid their professional/personal needs.

Build for Problems, Not Optimization

If we write a course on how to best administer your Atlassian Bitbucket Server and proceed to just list the steps on how to install and configure using "rule of thumb" values, the students won't really understand what the values indicate.

Here's a real customer example I encountered last week:

  • Finance approached the executive board in an attempt to place blame on IT negligence as the cause of slow network bandwidth.
  • The sysadmin told certain employees to stop downloading big files over the network, and not to listen to Spotify during 9-5 work hours.

The sysadmin is not wrong, but he/she should present arguments coupled with hard data rather than optimization mandates.

Below is a better approach:

  • The sysadmin conducted a load test using load testing best practices and identified that the bottleneck was due to Jenny from HR streaming old reality shows on Netflix.
  • The sysadmin proceeded to provide hard data and nice power point graphs to the company about cpu load, disc blocking operations, network bottlenecks, and other server metrics that engaged the empowered the employees.

Data needs to be translated into actionable items or problems will persist. It's not enough to just tell someone to do something without giving them the foundational knowledge to take those instructions and soar with them. If Jenny from HR doesn't understand that network bottlenecks occur when she watches her shows, the business will suffer and the problem will persist. Build presentations and curriculum that aims to identify and solve problems.

Build to Engage, Not to Thump

Often times as a subject matter expert, we will feel inclined to insert our ego into our courses. We want to thump our intellectual chests in an effort to subdue our audiences and preemptively deflect their queries. In other words, due to our own insecurity, we include mountains of tidbits of information just so "we are thorough" because how dare a student ask me such a silly question when they can clearly read this slide with 18 bullet points covering everything related to web sockets!?

It's humanly impossible to become a walking encyclopedia...at least until we get robot brains like in Ghost in the Shell (best anime ever by the way). So a better approach is to recognize what the audience will need to continue their own learning and focus on facilitating those answers. It's always better to build an engaging demonstration that covers pivotal topics and stimulates critical thinking, than to add yet another slide to your already bloated slide deck.

 You may also enjoy reading: Let's Face It: Visual Design Matters in Engaging eLearning

Originally published Feb 12, 2016 2:25:36 PM, updated Feb 12, 2016