User Experience
BYU-Idaho
Switch Day: Changing 30,000 users authentication in one day
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.
Quick Overview
My Role
UX Designer / Researcher
Duration
1.5 Years (Jan 2023 - March 2025)
The Team
|
Goal
|
Two teams, one big challenge
The goal
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.
Connecting BYU-Idaho to the Church Authentication is a CES initiative
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.
Who will be 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.
Flow mapping out the types of users involved
This isn't just a digital change
On-campus experiences will be affected
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.
Time to dive in
How will we help users connect their accounts?
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 I started with mapping out all user interactions that were required technically, and seeing what was possible.
Developing a flow map for the connection process
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?
Houston, we’ve got a problem
Early on I identified that the "Guest Accounts flow was different than the other experiences. I mapped out the problem and brought it to the team to workshop a solution. This jumpstarted some development needs and added to our workload…but better safe than sorry later on.
Solution mapping to get the team on the same page
Designing the "Account Connection" flow
We need a step-by-step process
This project involved a complex technical change that I needed to explain to the user in a simple and approachable way. To do this, I chose a step-by-step method that guided the user through the process.
It was essential that I built the solution within the required technical specifications, which included:
Integration with the Bootstrap design system
Connection to the authentication system
Implementation of two-factor authentication (2FA)
Before "Switch-Day": Connecting accounts flow
Before "Switch-Day": A user has connected their accounts already
After "Switch Day" and student has not connected their accounts
A prototype for every situation
In a large technology like this, it's important to have a prototype for every situation. I developed more than 17 prototypes. These covered situations, such as a user failing to connect, trying to connect twice, or a device already being connected, etc.
Example screens from over 17 prototyped scenarios
User testing until it clicks
Types of users to test
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. We tested day students, potential students, faculty, staff, and student employees.
User 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
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.
Conducting user interviews on campus with the help of a student team
The communication plan
Let's call it "switch day"
We needed something that was catchy, explain the change and easy to communicate. Our team created a communication plan that included campagining this change to faculty, staff and departments. This change would create distruption to students, so the change date was carefully selected. Anncoumeets were made campus wide, emails sent out,
Switch-Day graphic created to explain concept to campus
Switch day announcement in weekly devotional
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.
