Back to selected work
RISEKIT • UX DESIGN
TIMELINE
2 years
ROLE
Lead UX Designer
TEAM
Engineers
Summary
RiseKit is a company that helps underrepresented people find jobs by connecting them with resources, events, and training. The primary way to access customers was through external partnerships using an inclusive mobile experience. With this redesign, I led the V1 end-to-end design, focused on building clearer flows and improving usability, while creating an in-house accessibility and usability documents.
33%
user retention
3.3%
increase from a 1.78% click through rate
3 new enterprise clients
increased focus on accessibility allowed broader audience
50%
new users completed onboarding
Overview
RiseKit is a company that partners with non-profits organizations to prove under-served communities equal access to jobs.
People are brought on to RiseKit’s platform through partnerships and are guided through the process of finding a job or resource.
What we needed was a mobile app that guides jobseekers in their process of landing employment.
PROBLEMS & CHALLENGES
High drop-out rates
Operational costs are rising due to heavy reliance on support calls. These are numbers from a company in Chicago that I had to redact.
83.7% drop-out rate
233
enrolled
34
applied
Accepted into Program
Apply to Program
Conversation with Nonprofit Staff
Current Employment
Desired Skills
Drug Test
Education Level
Household Count
How did you hear about us?
Intro Confidence Check-in
Job Applications
Job Links
Last Employer
Program Completed
Proof of Employment
Resume Upload
Total drop-out
4
2
6
1
1
2
127
2
3
21
1
2
2
3
10
12
199
Mistrust & external variables
Outcomes from research and from our Career Navigator.
01
It is very difficult to engage and build trust with candidates who have not heard from RiseKit in a very long time — we need reminders / consistent communication with candidates.
The silence between touchpoints is where candidates disengaged
02
Many RiseKit candidates also “fell off” after the first 3–5 questions of the journey intake survey.
Candidates had no drive to continue with account set up
03
“I learned the more meaningful interactions I have with candidates (one-on-one coaching), the more transparent and trusting they are — allowing me to better serve them by providing resources that are best suited to suit their needs.”
Candidates did not have enough trust with the platform, meaning we needed stronger contact methods
Fixes needed often
Fixes result in the platform needing to double back and fix UX issues so that users could use Risekit's potential fully. Double-backs wasted time and effort
Email click-through rate (Q3)
Now
Accessibility & Interface checklist
Standards I wrote along the way
Nobody asked for this work.
For me, the perfect time to understand accessibility constraints is before building the product. We save production time, also with a product that was already in danger from large bounceback rates, we couldn't affored to not be able to cater to those users who go through the Risekit platform. If it were breaking, it wouldn't retain users. by reducing the iteration
My in-house accessibility guide
I wrote this for the whole team: developers and designers. Contrast guidelines, AA thresholds, text and graphical objects, and pass/fail examples to copy from.
My usability checklist
I created a UI checklist for ideation, hierarchy, spacing, typography, color, and interaction states, so that accessibility is verified at every step rather than retrofitted at the end.
Design needs
Auditing the platform
Due to Risekit already having a mobile experience, I needed to know where to start when it came to the basics. I ran an audit across the platform, making notes so that I could rebuild our design system.
System creation
Colors and semantics
Colors had been defined as standalone values rather than part of a system, which made it difficult to scale and apply consistently across the product. Without defined roles or tokens, designers and engineers had to make judgment calls, leading to inconsistencies in the UI.
So, instead of defining colors by appearance alone, I mapped them to clear semantic roles. I created primary actions, feedback states, text, and backgrounds. This made the system more intuitive and easier to apply across different context.
I also documented the WCAG rating of every color, so that different use cases were considered (is color-black better than color-white when considering this color?)
Components
The old component library held a few reusable elements, but the library was small. Inputs, buttons and other UI components were treated as one-off designs rather than part of a cohesive system.
Due to having to redesign the experience, I believed it was the best time to finally build a system-driven foundation, where every component was standardized with a clear structure and defined states. Due to rapid relaunch, I filled the library with “must-haves”.
(See how I would've incorporated AI if I had access to it back then! They’re live further down…)
Icons
There were only a handful of icons available that followed UI guidelines. All other icons on the platform were gathered from resources that were quickly accessible, rather than built in-house for a consistent feel.
The new icon library supports a wider range of user actions and states, each with a specific purpose and usage guidance. This allowed me to reduce any ambiguity, and make interfaces easier to implement and ship.
The new library icons are also created on a 44px by 44px grid hotspot, complying with accessibility guidelines.
Typography and roles
As shown earlier, Risekit’s typography system went unused. Different fonts and weights were used together, causing misalignment and inconsistent line heights.
The hierarchy across sections was thrown off, and associating headers with sections became difficult to follow.
The new scale that I created defined roles (headlines, subheaders, body, labels, buttons) with sizes, weights, body line-height, dp, and letter spacing, giving designers and engineers clear guidance on how text behaves in every component. Selected were: Work Sans and Inter.
Motion
RiseKit's original interactions were static and sudden — screens just appeared, with no sense of continuity between states. I wanted motion that felt intentional without slowing anyone down.
That meant answering three questions: Should one motion carry the whole experience, or does it vary by context? If it varies, what's the reasoning? And how do we actually land on the curve itself?
Most users don't want to sit through a slow ease-in or ease-in-and-out — they want to finish the task, not wait for the animation to catch up. So I built a custom Bézier curve: fast enough to feel responsive, smooth enough to feel considered. It's the curve behind every interaction detail in the file, and it's what drives the drawers and sliding pages you see on the Home page to the right.
Preliminary research
Competitive analysis
We walked the mobile job-seeking flows of Indeed and Snagajob end to end, from first screen to first application. Both are built for someone who already has a résumé and the vocabulary to describe their work. Six patterns shaped what we designed next.
01
You need a resume
The user has no choice but to establish a resume for their profile: if they choose not to upload an existing file, they’re immediately ushered into the creation wizard, ensuring users are unable to browse listing or apply for a job without a resumé on file.
02
Boxes assume experience
The generalized description box with 2 list-formatting choices indicate that this service is not geared towards inexperienced job-seekers. It also does not provide guidance for the best way forward.
03
Unclear hierarchies
Field are marked as required, but are followed by a checkbox allowing them to skip the step. This creates confusion over the necessity and benefit of the information being asked of them.
04
Mixed signals
No information or suggestion is provided to the user as to what “additional information” they could be providing that is not covered in the other categories. It lengthens the form and creates confusion.
05
User progression
An incentive to complete the profile, this time offering the incentive of receiving more relevant job postings after the provide more personal information
06
Statistics over coaching
“Filling out 2 or more work experiences will double your chances” puts overwhelming pressure with a success figure, that a user may not have. It may highlight that they won’t be successful without more than 1 job under their belt.
Persona
Her phone is her main job search tool
80% of her time is spend on her phone. Between her commute to work and home, Kimberly uses it to browse jobs and resources.
Barriers and guidance
Thought she has been promoted to shift lead, her employment history doesn’t read as “professional”. She is also unfamiliar with white-collar hiring etiquette, resulting in a need for guidance.
She values steps over decisions
With children at home and a part-time work schedule, Kimberly needs realistic, structured steps to reach her end goal: a full time job with benefits. She needs to avoid being overwhelmed.
Her time is filled
Long hours and unstable childcare makes Kimberly anxious about availability for interviews. She needs resources to support her current life so she can focus on her job search.
Outcome: Existing job-seeking tools struggle to care for first-time professionals like Kimberly
Building blocks
Sitemap
The sitemap was created to organize the content and hierarchy of the new application in a logical and user friendly way.
Wireframes
I created and tested wireframes prior to building out the high-fidelity screens. This helped me have realistic discussions around feasibility with the development team and point out any scope-creep with the product team.
Designs
Final designs
Here are Risekit's final designs.
01
Invited users only need to verify what their organization already provided. They don't need to re-enter education, address, or employment info at this point. I deliberately cut that from the old flow because the data showed that when those questions were asked all upfront, we lost 127 of 233 users at the education field alone. I moved anything non-essential into onboarding once the user had completely signed up and trusted the product. The trade-off was in order to gain more sign-ups, we had to let go of some of our information gathering.
02
Instead of a form, onboarding continues through a scripted chat: education level, job-seeking status, certification were the first questions asked in a multiple choice format. By framing it as conversation, the questions feel lighter, and the multiple-choice format keeps users moving forward with only taps, instead of giving them a static field to abandon. And it worked! 50% of new users completed onboarding, a upward tick from the drop-off we saw in the old form.
03
During their job search, users are connected to a live career coach. Our research data showed something worth designing around: users open up more in one-on-one coaching, and that trust lets coaches match them to better resources. Bookmarks holds all the information that's needed between a job seeker and their coach. It has their next Steps (containing completed steps with chat anchors), Files, Links, and Pinned. Depending on the message content, the tabs auto-populate as the conversation happens. So, a resume sent, a job link shared, or a completed step is never lost.
04
Toggle to see old design
With an 83.7% dropout rate across the broader job-search journey, I felt the risk boiled down to users being uncertain of what to do next. I wanted the Homepage to guide them directly and with way to take action. I didn't want it to just be informative. "Complete your Profile" and "Job Readiness" sit at the top with a progress bar, so the next action is ready for the user to pick up where they left off or request documents knowing what is up next.
05
The job search process can feel like a really open-ended experience with no visible finish line. Pathway Progress gives users a fixed structure to move through and a general overview showing which step they're on and what that step involves.
The user journey status is also communicated through explicit labels, "Active" and "Not Active" and not just color.
06
Due to the earlier change in sign-up requirements, users hadn't stated the details of their education, their past or current employment details, and any barriers (criminal records, lack of transport, etc) they may face. Profile is where that information can be fully filled out: basic info, job-seeking status, current situation, and settings, organized as expandable sections a user can open one at a time rather than a single long, overwhelming page.
Users can also revise any answer they gave during onboarding or to their coach, never locking them into any part of Risekit's process.
Outcome
Results
33%
log in more than once
40%
submit two or more applications
50%
complete the journey intake questionnaire
50%
finish their work experience section
Email click-through rate (Q3)
Past
Now!
1.78%
3.3%
What I'd do differently
Updated with AI
When building the new component library, I relied on our use cases and the platform's historical usage. This meant that I had the basics (default, secondary, hover, disabled), but they were all stuck in a Figma file along with their colors and states.
So, now that AI is being incorporated, speeding up parts of the design process that would otherwise take hours, I tried my hand at prompting. This is what happened.
PROMPT:
Result:
Four fills on one artboard. Everything below came out of naming them.
OUT OF MY 4 BUTTON COMPONENTS CAME:
3 variants
3 sizes
2 shapes
Icon family
I'd be able to ship a demo, a live, working page to prove the states work, not just Figma artboards.
What's next
Work closely with developers
With RiseKit initially being a developer-built platform, it was helpful to work off a skeleton. The important tools were there, but the UX and the research behind the decisions was missing. I learned here that even if the idea is solid, the relationship between development and design is especially important in building good UX; not just the designer. This saved iteration time.
Touch base with takeholders often
Keeping in touch with stakeholders helped keep the scope tight. I didn't drift into spaces that didn't need attention, or build unecessary tools. I was able to directly focus on the problems at hand, while being able to back my design decisions based on org needs.
Collect qualitative feedback
Institutions already knew that RiseKit had the tools it needed; the problem was how frequently the users were dropping off. We used this as our guiding light for our rapid launch. Because I didn't have enough user interviews to produce helpful outcomes, I had to use assumptions based on audience and competitive analysis to understand how RiseKit could retain more users. I'd love to be able to test the launched product with real users and get not only quantitative feedback, but qualitative.
Want to talk more? Contact me!