Quick terminology note that may help: a local congregation is based on geography and is called a ward. A group of wards is organized into a stake. Stakes are organized into regions. Regions are organized into areas. Areas fall under general Church leadership.
The typical process for registering students before this tool was often done in the local congregation (ward) by making an announcement in Sunday services and then gathering in the back after the meeting and hand-filling out a form that was then placed into an envelope, handed to a stake leader—known as a High Councilor—charged with gathering all the forms from all wards in their stake. This process typically started in March each year and could linger for months up until the beginning of the next school year.
Once all paper forms were collected, they were delivered to an administrative assistant who then manually entered the data.
There were multiple ways for the information to become corrupted due to human error. It also provided a challenge to plan for staffing needs with a large population of eligible students.
The desire was to move the process to an online intake form to remove errors in data input, speed up the registration process, and enable better planning for staffing and instruction.
Users and Audience
There were 3 distinct audiences on which we focused our efforts:
- Parents and guardians registering their students.
- Local ecclesiastical leaders (ward and stake) who were responsible for encouraging and overseeing student registration.
- Church administrative staff who were planning for class sizes and where to assign teachers.
Roles and Responsibilities
I was the UX Designer for the project. The rest of the team consisted of a program manager/analyst and a dedicated team of software and QA engineers.
The program manager and I gathered requirements from business stakeholders before determining the project strategy to meet the delivery timeline.
Scope and Constraints
The project’s initial scope was to focus our efforts on registering US students who attended release-time Seminary programs. This would capture about 120,000 of nearly 400,000 worldwide students and felt like an achievable goal given our tight timelines for delivery. We had about 3-4 months to design, engineer, test, and release the registration form and an accompanying leadership dashboard.
Given the tight timeline, there wasn’t much time for solid UX discovery. As a compromise, I was given 2 weeks to do some guerrilla user interviews, make some generic personas (an emerging tool at the time), and create an experience journey map (another emerging tool). I also built out the initial wireframes to review and validate with stakeholders and the engineering team before designing high-fidelity screens.
During this compressed discovery window, we discovered a few interesting things:
- Parents were busy, and sitting down at a computer wasn’t always feasible. Sometimes, they only had an internet-capable mobile phone. This needed to be a responsive, mobile-first solution and it had to be something they could do quickly!
- Parents might have to register multiple students at the same time. Often, at least one was a returning student. How could we pre-populate data so their experience was faster and more efficient?
- We had most of the data already since we had access to membership records.
- Leaders wanted to monitor the progress of their congregations.
- As a result of the organizational structure of Church units, this data could be rolled up to higher levels quite easily. Bonus!
These proved to be my guiding principles for the UX. I set simple goals:
- All registration tasks by a parent or guardian must be simple enough to complete in less than 1 minute.
- The key experience would be on a mobile phone. This meant that we would need to focus on what elements were “must haves” to successfully register a student but also help our business stakeholders feel comfortable with having such a simplified experience.
- Ward and stake leaders should be able to tell quickly who they needed to reach out to complete the registration process and be able to do so.
As I was completing the research, we reviewed things as a team to assess the engineering feasibility and identify areas where the UX needed to be modified. We also reviewed areas where the dev team would need to focus their discovery efforts while I worked on the UI design.
The design was analyzed regularly, not only by key business stakeholders, but the engineering team and program manager to make sure the configuration wasn’t going to make assumptions about certain data that couldn’t be delivered in a performant manner.
The leadership view was nearly cut as we evaluated things for delivery, but we were ultimately able to keep it as a simple view.
Once we all felt comfortable with the design, it was validated with a few potential users and then we moved into the final push to build and launch.
To answer anticipated questions from the engineering team, we leveraged something we nicknamed “D.I.G.” or Design Implementation Guidelines. It consisted of deconstructed and documented UI components (before design systems became a big deal). This was a living file that we reviewed regularly and proved extremely helpful not only for the engineers building the experience also for the test engineers tasked with doing QA.
Outcomes and Learnings
The project launched in the early spring of 2014 and was largely successful.
- Registered 75% of the 120,000 targeted students within 6 weeks.
- Within 9 months, 250% of targeted students were registered (over 300,000 students which represented more than 75% of all eligible students worldwide.)
- That nearly cut leadership view? It was a hugely popular feature and solicited a considerable amount of positive feedback!
- The D.I.G. file was cemented as a required deliverable to the engineering team.
Afterward, I visited with a few people about this project. One comment that seemed to pop up a lot was, “It was so easy! We were done and had everyone registered in a week. I loved it!”