Awardco · Product Design Internship
Reducing authentication friction at Awardco
How might we get people signed in when every company authenticates differently and users have to guess which method is theirs?
Before and after usability testing. Not production analytics.
- Discover
- Test
- Design
- Prototype
- Handoff
Discover
Act 01: Users were not entering the wrong password. They were choosing the wrong method.
Awardco is an employee-recognition platform where every customer configures authentication differently. Depending on their company, users might need SSO, a password, MFA, or a login code. The existing experience made users figure that out themselves.
My PM brought me a known pain point: login generated heavy support volume. I worked with our technical lead, account managers, and customer-success team to understand how large the problem really was.
Three situations from the research. Restated, not quotes.
Entered a code on the universal page, reached the company page, and was asked to authenticate again
Chose password login without realizing the company used Google or Microsoft SSO
Got a login code sent to a work inbox they could not open from their phone
This sparked a key question:
How might we route users to the method that works, instead of asking them to choose?
The evidence a year of login telemetry
The problem was not simply that users forgot their credentials. Awardco was presenting several authentication methods and expecting users to understand which one their company supported. Password login alone accounted for 6.7 million failures.
- 16.7M failures
Password login failed nearly two out of three times. - 234.6% success
The method most users reached for was the one least likely to work. - 398% for SSO
Guided methods succeeded. The fix was routing, not a better password field.
Success meant routing each user to the method most likely to work, then proving it in before-and-after testing.
Who it was for three people the old login failed
The SSO-company employee
Their company uses Google or Microsoft. The login page showed a password field anyway, so they used it.
The deskless worker
Warehouses and theaters, where the phone is the only screen and the work inbox is out of reach.
The company admin
Fielding the support cases. Login help was the top topic, 9,275 cases in 90 days.
Test
Act 02: The faster design reinforced the wrong behavior
I tested three login directions with 75 people across Awardco: the existing experience, an SSO-first design, and a password-first design.
The existing experience took users an average of 27 seconds to decide where to begin. The SSO-first design reduced that to 5.9 seconds. Password-first was even faster at 4.6 seconds and scored slightly higher on confidence. I still chose SSO-first.
- 1Control, 27s
Attention scattered across the page. Hesitation before the first tap. - 2SSO-first, 5.9s
Focus lands on the SSO button. The chosen design. - 3Password-first, 4.6s
Fastest in the test, but it reinforced the method that failed most in the product.
Password-first performed well because it emphasized the option users already recognized. But password login failed nearly two out of three times in the real product. Optimizing for the fastest test result would have reinforced the behavior causing most of Awardco’s failures.
The fastest design was not the one most likely to help users sign in.
Design
Act 03: The real fix was a token, not another screen
The universal login page originally identified the user but did not carry that authentication into their company’s login experience. Users could enter a login code and then immediately be asked for another code or password.
The flow users had six screens, two codes, two trips to the inbox
Universal login
One field, asking for the work email.
Identification code
Code 1Leave the product, open the inbox, come back with six digits.
Domain selection
Pick the workspace. So far, so reasonable.
Company login page
Asks againThe company page does not know who you are. It asks for the email again.
A second code
Code 2Back to the inbox for a different six digits.
In the app
Two codes and two trips to the inbox after the first field.
The flow I proposed four screens, one code
Universal login
Unchanged. The same single field.
Identification code
Code 1The same six digits, entered once.
Domain selection
Pick the workspace, carrying the authentication along.
In the app
The company page has nothing left to ask.
The same three screens the old flow opened with, and then straight into the app. The company login page and the second code are gone, because the first authentication now travels with the user.
If the company only requires a login code, the user is already authenticated. If it also requires a password, their email is already populated and they only complete the remaining step.
I mapped the system as states and transitions, then worked through the proposal with engineering, architecture, and security. It passed review without material changes. Engineering owned the implementation details, while I owned the concept and end-to-end experience.
Deskless workers got codes in inboxes they could not open from their phones
SMS verification, and only the methods the company supports
Many Awardco users work in warehouses, theaters, and other environments where mobile is their primary access point. The redesigned mobile experience introduced SMS verification and only displayed authentication options supported by the user’s company. It also replaced the generic “SSO Login” label with the provider users actually recognized, such as Google, Microsoft, or Okta. Users no longer had to know which authentication method their company supported.
One layout, any brand the constraint every screen had to survive
Awardco’s login pages are white-labelled. Every customer’s page carries their logo, their button colour, and their link colour, so one layout had to hold up in all of them. I designed against the two hardest cases I could find rather than against Awardco’s own comfortable blue.
Awardco
The easy case. Awardco blue reads as a safe primary action anywhere on the page.
Cinemark
The hard case. A saturated red carries error and destructive meaning in almost every interface, so the layout has to make Continue read as the safe next step on its own.
Accenture
The strict case. Accenture held the tightest brand standards of any customer I designed against, so the page had to be right with no latitude.
Prototype
Act 04: Coded prototypes exposed the forgotten flow
A Figma prototype could show navigation, but it could not reveal where users struggled to type, validate a password, or enter a verification code. I built working prototypes with real inputs, validation, and code entry. Testing them with more than 20 admins and end users exposed friction around email entry, verification codes, and especially password recovery.
Reset was a disconnected page with a blind password field and no visible requirements
Inline validation, live password matching, show-password, and the same visual system
Working in code made the edge cases visible earlier and gave engineering something closer to the final interaction model. I later contributed the workflow to Awardco’s AI-prototyping guide and helped introduce it across the design team.
One blind field, no requirements shown, and no way to see what you typed.
Handoff
Act 05: Validated, approved, and handed off
In before-and-after usability testing, the redesigned system produced 25% faster login, 4.5% more successful sign-ins, a 78% reduction in login-method decision time, higher confidence, and lower reported difficulty. One guided experience now spans mobile and desktop.
The token-based flow passed architecture and security review, and the completed designs were handed off for implementation after my internship.
- The token-based flow, mapped as states and transitions
- SSO-first login for desktop and mobile
- SMS verification and provider-named sign-in for mobile
- The redesigned password reset with inline validation
- Coded prototypes with real inputs and code entry
- The workflow behind Awardco's AI-prototyping guide
I learned not to follow a metric without asking what it was actually rewarding. The password-first design won the task test, but it worked against the larger product evidence. Choosing the slightly slower direction produced the better system.
The biggest improvement was not a cleaner login page. It was changing how authentication state moved between two parts of the product.
One limitation remains. Some deskless workers cannot carry phones during their shifts and access Awardco through shared kiosks. SMS does not solve authentication for them. If I continued the project, kiosk research would be the next place I looked.
What would come next?
- Kiosk research for deskless workers who cannot carry a phone on shift
- Watching the production numbers once the handed-off system ships, against the 34.6% and 98% baselines
- Carrying the coded-prototype workflow into the next flows the team tests
Read next
Find or summarize a document...
What are you looking for today?
Find or summarize a document...
Find docs
Locate files by person, timeframe, or canvas text
Summarize
Get the gist of a doc or a group of them
Build a diagram
Create flowcharts and visual layouts from a text prompt.
Catch up
Summarize your recent workspace changes
