30,000 Users, 1 Day, 1 Change
Helping thousands of students, faculty, and staff seamlessly switch to a new church-wide login system in one day — through thoughtful design, user testing, and clear communication.
My Role
UX Designer
Duration
1.5 Years (Jan 2023 - March 2025)
The Team
Cross functional team of 12 from CES, BYU and BYU-Idaho (IT, development, management, etc.)
Goal
Help 30,000+ users smoothly connect to the new church-wide login (OKTA) without disruption
Two teams, one big challenge
The challenge
Switch all current and former BYU–Idaho (20,000+) users to the new church‑managed OKTA login system. To avoid being locked out on switch day, users need to connect their campus accounts to their church accounts ahead of time.
What kind of users are involved?
It was important in this project to detect all possible users and their specific experiences during this change. I mapped out this experience and shared it with the dev team for solutions.
Day Students
Online Students
Pathway Students
Potential Students
Transfer Students
Pathway & CES Transfers
Graduated Alumni
Faculty / Staff Employees
Returning Employees
Student Employees
Guest Account Holders
Potential Employees
Things to consider
Users connecting wrong accounts
Confusion around multiple accounts
The possibility of users missing communication efforts
The original solution
Originally the team planned on sending out an email. This email would include links for users to click and change accounts. This is a great start, but far from what a user would need in order to understand the process.
This isn't just a digital change
Two different logins means confusion
Because of some technical limitations, on-campus experiences like the library computers and wifi will still use the BYU-Idaho username and password. It was my job to discover and suggest solutions to this problem.
Storyboarding the experience
Scenario: Student has never needed to use their "On-Campus Account"
Time to dive in!
Users need to connect their accounts before "switch day"
We needed a foolproof way for users to connect their BYU–Idaho account to their Church account — something a simple email couldn’t explain. So, we designed a clear, step‑by‑step “Connect Your Accounts” flow and built it in‑house with our developers to guide users through the process.
My process
Ask the right questions
Understand technical restraints
Map out flow & user journey
Workshop solutions
User test like crazy
Houston, we’ve got a problem
What about new students and guest accounts? This flow was a bit different than the average current/past student. I mapped out the problem and brought it to the team to workshop a solution.
Addressing the what-if's
What about people who are applying to BYU-Idaho currently? What is the onboarding process?
What about people who are “guest” account users? What will change for them?
What if a user doesn’t connect in time?
What if they try to connect their account twice?
What if they already have a church account connected to another BYU-Idaho account?
What if they try to log into the church account and we don’t recognize that user login?
Designing the "Account Connection" flow
Constraints and considerations
We had a few specific qualifications for this project. It needed to be built using the Bootstrap Design system, communicate the "why" and include a step-by-step process.
Final "Account Connection" flow
A prototype for every situation
In a large technology like this, it's important to have a prototype for every situation. These solutions addressed situations like a user failing to connect, trying to connect twice, a device already connected, etc.
User testing until it "clicks"
Types of users tested
I tested the flow with students, faculty, and staff to spot confusion points, then refined wording and design to make it clearer and easier to follow.
Day Students
Potential Students
Faculty / Staff Employees
Student Employees
A testing plan is powerful
I ran planned qualitative tests, observed real users, and shared findings with the team to keep our design grounded in actual user behavior. This brought a level of confidence in our team and for the stakeholders invovled.
Testing Rounds
Round 1: faculty prototype user testing / interviews
12 faculty - moderated with interviews
Round 2: current student user testing / interviews
16 current students - moderated with interviews
Round 3: administrative employees beta user testing
6 full time admin employees - moderated live beta connection
Round 4: faculty beta user testing
10 faculty - moderated live beta connection
Round 5: current student beta trials
6 current students - unmoderated testing live beta connection
Round 6: IT beta testing large user round
20 faculty and students - unmoderated testing live beta connection
The results
So, did all that work pay off?
Connecting accounts ahead of time prevented thousands of users from being locked out of essential systems on switch day. Early connections meant fewer help desk tickets, less downtime, and a smoother campus-wide transition.
Accounts connected metrics
5 days before go-live
30,000 accounts connected
1 week after go-live
40,000 accounts connected
Total accounts connected
62,000 accounts connected
What would I have done differently?
There was an oversight when it came to Pathway students. The help desk mainly had issues with pathway students and technical difficulties. I would have dived deeper into that user persona and not taken "its fine" as an answer.
