MTC Tools

User Research Case Study

Duration: Mid 2017– mid 2018
Platforms: Web App
Team/Role: UX Designer on a team of 3 UX Designers and 20 Developers
Website: Unfortunately, this site is exclusive to Missionary Training Center (MTC) employees globally

Overview

I worked for the Provo Missionary Training Center (MTC) on its MTC Tools product for just over a year and the project below is a sample of the work I did there. None of it is perfect, but this particular project was an area of learning and growth that significantly improved product adoption and task completion times for our main user group.

MTC Tools is a non-profit enterprise app created in-house by the Provo Missionary Training Center (MTC) as a tool for employees to manage and complete their tasks, mostly revolving around the travel, accommodations, and training schedules of missionaries for the Church of Jesus Christ of Latter-day Saints.

Problem

MTC Tools was constantly having features added to eventually be able to replace various legacy software from the 90’s that was still being used by MTC employees. A core feature MTC Tools lacked was the ability to create and manage orders for name tags, language learning materials, and gospel materials. Our largest user group at the time, the Scheduling department — which consisted of a mix between part time college students and those managing the department who were in their 40’s — 60’s — was in charge of ordering and organizing various materials preparatory to thousands of new missionaries entering the MTC each week. This process took hours to complete.

Solution

We created a partially automated ordering process that could be fully maintained and altered by the Scheduling department. As part of this, we introduced 3 new tools that would allow the Scheduling department. The first tool would allow Scheduling to create rules and exceptions that would assist them in ordering materials for a variety of missionaries in differing situations. The second tool helped Scheduling coordinate with translators to translate name tags into their proper language. The third tool compiled rules, exceptions, and translated name tags into orders which could then be reviewed and submitted by Scheduling.

Challenges

Complexity
The orders process is incredibly complicated and would be difficult to understand fully.

Complacency
The Scheduling department had been doing orders the same way since the 90’s and they were comfortable with how long the process took, but the MTC wanted to speed up their workflow and move all their tools into the new MTC Tools app. It would be critical to create a tool that the Scheduling department would be willing to adopt and use.

Result

Initially, the end result was catering to an experience that was slightly less efficient than other designs we produced, but had enormous impacts on user adoption and acceptance. The scheduling department was able to reduce the average time it took to complete an order from roughly 6 hours with the old system down to 30 minutes total with the first released version of Orders.

Discovery

This feature was a team effort at the early stages. Brainstorming was done by the whole team, but all high-fidelity screens and prototypes were created by me. User testing was also conducted by myself.

Observations

We spent several days observing our users, taking notes, compiling information, asking questions, and generally trying to ensure we had a good understanding of what our users were doing and what they needed. We realized that the issue was much bigger than it first appeared. The Scheduling department was spending hours and hours every single week using multiple tools and websites to gather information which would then be entered into spreadsheets. These spreadsheets were then emailed to our vendors. Scheduling didn’t mind having to do all this work and at first was apprehensive and skeptical that we could create something better in MTC Tools.

Analysis

After analyzing what we had learned for several days we synthesized what we knew into all the tasks Scheduling would need to complete using the Orders feature.

1. Scheduling needs to be able to order three different types of products. Printed schedules, ministerial certificates, and name tags.
2. Missionaries are assigned schedules that coordinate with a district (group of missionaries speaking the same langauge) they are assigned to.
3. Districts are grouped first by MTC arrival date, then language, then mission location.
4. Ministerial certificates have specific rules about the language they are printed in based on mission location.
5. Name tags for missionaries speaking a language with a foreign character set may need to have their names translated depending on mission location.
6. Name tag translations are done by a set of designated translators at the MTC.
7. Name tags have many rules and exceptions about what order the information is displayed in, what language the information is displayed in, and specific missions require multiple different types of name tags with different requirements.

In summary, Scheduling needed a way to manage a list of translators at the MTC and assign/track their name tag translations. Scheduling also needed a way to keep track of the ever-changing exceptions to name tag and ministerial certificate rules. Lastly, Scheduling needed to be able to order name tags, ministerial certificates, and printed schedules for thousands of missionaries weekly.

Ideation

Brainstorming

As part of our analysis and brainstorming, we filled an entire glass room with notes and drawings. The image below doesn’t do much to illustrate just what our various ideas were, but it hopefully depicts the amount of thought that went into this feature.

I know. These pictures suck at showing what we actually drew. But hopefully they give some scale as to how complex this problem was.

Eventually, we stumbled upon the realization that the entire Orders experience could be completed automatically without needing much input from Scheduling. Each week, MTC Tools would automatically query the database for incoming missionaries expected to arrive the following week and would execute the rules and exceptions created by Scheduling to create an accurate order ready to be submitted. The only human input necessary would be in creating and maintaining the rules and exceptions as well as translating the name tags.

Iteration 1

Design

Principles
Speed
Accuracy

Features

The autonomy of app would provide the speed by reducing the amount of human input necessary in the Orders process.

Our database would provide accuracy. Rather than having the Scheduling department manually re-enter information, the information is pulled straight from our database into the order.

Prototyping

Testing
I tested a prototype of our first iteration with the managers of the Scheduling department who traditionally completed the orders each week.

Results
It went horribly. The managers hated the idea that the computer would complete the orders for them. They felt like they couldn’t trust the computer to accurately complete the orders.

This prototype depicts the only part of the automated process that would require input.

Iteration 2

Design

Principles
Increase Perceived Control
Progressive Iteration

Features

Though the Orders experience would’ve been extremely reliable, our users needed to perceive that they had more control to help them be comfortable using this feature.

Our next iteration needed to backtrack slightly to create a series of iterative “stepping-stone” releases that would prepare the Scheduling department for eventually embracing the fully automated system.

Prototyping

Testing
I went back and retested the new designs with the same users.

Results
With the slight tweaks to increase perceived control, Scheduling was suddenly excited to use the feature and could much more easily see it fitting into their current workflow.

This screen was added to allow users more control over the orders.

Conclusion

What was the end result

Initially, the end result was catering to an experience that was slightly less efficient, but had enormous impacts on user adoption and acceptance.

Though I no longer work for the Provo MTC, I’ve been informed that in early 2019, a new release introduced the originally designed fully automated version of the Orders experience and was met with excitement from the Scheduling department.

How did the change effect user’s

The scheduling department was able to reduce the rough average time it took to complete an order from roughly 6 hours with the old system down to 30 minutes total with the first released version of Orders.

What did I learn through this process

I had my knowledge of the importance of prototyping and testing reinforced. We were certain the fully automated version was perfect, but had we not tested, massive amounts of development time would’ve been wasted.

I also learned the value of Progressive Iteration. I don’t know if that’s an official term, but it definitely should be. We utilized a less automated version of our design to prime the Scheduling users for eventually being willing and excited to accept the fully automated version.

What would I do differently?

Given we didn’t come up with our idea for an automated experience until ideation, I don’t know if there would’ve been a realistic way to extract information during our initial discovery that would’ve indicated users wouldn’t like automation. That being said, if I were to do this project over again, I would have tested the idea as a paper prototype or at least something more lo-fi before spending time on screen design and hi fidelity prototype creation.

Thanks for reading! Check out my other work and let me know what you think! Critiques and feedback are more than welcome. Leave comments or contact me at jackson.lloydlp@gmail.com.

Thanks,

— Jackson

Chatbooks

Sany

Embark — Language Learning