How might we better the onboarding experience for the state's unemployment website?
What I improved

This case study will be reimagining the onboarding experience for the unemployment state website & creating a mobile app experience in response to the global pandemic

My Role

Project Manager & UX Designer,
Research, Information Architecture, Visual Design, Interaction Design, Prototyping


3 weeks



Final Prototype
The goal was to design a user friendly & accessible onboarding experience for the state’s unemployment website and provide a mobile app.
Overview of project
A comprehensive onboarding experience to file a claim
A step-by-step process that guides the user to sign up with ease
Quickly access resources
With as little as 2-3 clicks users can access resources and check claim status all in the palm of their hands
Checking your claim status has never been easier
Live updates on your claim keeps the user informed & relieves stress
Renew a claim at the push
of a button
A streamlined user experience to make filing a claim easy & simple
Current challenges
Under close examination, I found that the essential information and structure of the website failed to meet basic graphic standards. Confusing language and excess of information creates a frustrating user experience leading to calls handled by multi-faceted departments.
Existing image of unemployment website
Analyzing the existing site and taking note of the onboarding & sign in functions to file a claim brought many issues that quickly confused the user in being able to navigate the site efficiently.
User Persona
Empathizing with users
Upon synthesizing the qualitative & quantitative data from online research, a persona was created to align with the user's needs, goals, & frustrations in order to understand how to enhance the user experience.
Persona image
Oregon is using an employment claims system built in the 1990s, with some components dating to the Reagan administration. The creaky old system cannot make automated adjustments to process claims for many new workers and lacks the necessary guidance to process claims efficiently.
Problem Space
Design challenges
Applying for unemployment sucks.
The common denominators for our interviewed users are:

1) The current system is hard to use.

2) The methods of application are unclear and/or muddy.

3) Solid mobile support is near non-existent especially when it comes to
long form data input.

4) Onboarding is confusing and unclear for the user to file a claim and
access resources.

Problem image
The current system is outdated, confusing, and frustrating for users. This is especially frustrating for the users who are already struggling and stressed out.
Research Insights

Improving the graphic standards for the state’s website will allow proper navigation and legibility. Improvement of hierarchy can guide users and also help with navigation.


Complex language and overlapping benefit programs, plus extraordinary stress make a difficult task even harder and more prone to error.


Basic information and guidance is very difficult to come by. Self-service for correcting small errors is impossible.


Ensuring proper color and font size meets WCAG for accessibility. All fields and buttons need to be labeled and kept out of any areas that users input text.

It was clear that the unemployment information and systems are confusing, rigid, and cumbersome. The complexity of re-designing a user friendly & accessible website was significant and warranted attention. It was also clear that providing a fluid onboarding experience had the potential to lessen that burden and increase user confidence.
Make the problem suck less
One of the key factors that needed to be taken into consideration when designing a solution for this problem is that the user has to input a ton of data, which causes friction in the application process.
Solution image
To get around this, the solution was to guide the user to their destination as quickly as possible. The existing website gives the user too many choices creating confusion. With guided narration we can streamline the users to their destination more efficiently.
Let the user supply the absolute bare minimum of required information for the system to recognize them.
strategy image
The goal was to allow users to input as little data as possible to create and manage claims, this came down to funneling all information onto a database to access information, quicker for validation.
User Sitemap
Streamlined experience
Before jumping straight into iterating our wireframes, I wanted to further envision a contextualized user case of our concept. Efficient information architecture is everything. I wanted to make sure there was a good understanding of where data was coming from and going to.
On boarding experience
The design of this product had to be clear, convenient, and easy to use. Something that just gets out of the user’s way, and lets them do what they need to do.
Image of sketch
Low-fidelity mockups
I created low-fi wireframes of this envisioned mobile application to test the ease of signing up and filing a claim.
High-fidelity mockups
I went with a soothing color palette, humanizing the typeface, and a clean UI that distinctly divides sections of the application into cards to make it more easily digestible by the user.
Design discovery
I discovered that both filing a claim and signing up could be done in the same operation. By providing a simple first name, last name, and SSN number, the system could identify the person without the need for lengthy, long-form content entry.
Design guidelines
1) Using a minimum of 16 px font size as standard.

2) Maintaining a contrast ratio of 4.5:1 at least as per Web Content Accessibility Guidelines (WCAG).

3) Using a minimum of 44*44 px for interactive elements/buttons.

4) Providing enough visual clearance between elements to avoid accidental interaction.

5) Using visual cues to help navigate and naming icons to avoid cognitive load.

Designing efficiently
Having a robust design system was absolutely imperative. By designing a clear & easy to use interface, we can reduce user/technical error allowing for claims to process, reducing user phone calls to the departments.
Mobile app screens
Beginning with rough sketch ideas and fine tuning the logo in illustrator. The concept was to keep the logo minimal and clear for the intended audience.
Style guide
The style guide aids as a visual reference throughout the design process.
High Fidelity Prototype
In this scenario we see the onboarding experience from signing up for the first time to filing a claim. The prototype shows job resources, job openings, and setting up interviews.

Click below to interact with figma prototype.
1) Task Oriented Design integration

2) Robust System Architecture for efficient data input & validation

3) Design Guideline implementation for streamline user experience & information efficiency

4) Desktop & mobile app for on the go experience

Bottom line
I’ve talked to the users and the numbers don’t lie. We have an unemployment system that is fundamentally not equipped to handle the volume of claims that it has during the pandemic.

By implementing the proposed set of changes, we could expect that call times may drop commensurately, claims could be processed faster, and users would experience a system that works better for them.
Next Steps
I would like to take 2-week sprints to interview users about the design. Then conduct a/b testing to test the assumptions I made based on research & online interviews.

Expanding on error screens and troubleshooting the product for better accuracy of data being transmitted. Integrating a data standardization funnel to synchronize data input and validation.
Proposed Product
This front-end could theoretically be developed in React Native, Flutter, or Quasar, for a cross-platform application that is easier to update and maintain.

The back-end would take a little more doing, and would essentially require both a main server and the standardization server as well. Requests would be pushed from the application to the main server. All additional information would be garnered from 3rd-party servers and routed through the standardization server before being processed by the main server, and sent back to the application.