Program fit was difficult to judge
Prospective mentors could understand the broad purpose but still had to search for eligibility, responsibilities, time commitment, and compensation.
PROJECT 01
Northwestern University · UX Research · 2024
Mapping the hidden workflows behind STEAMbassadors and eLEAP
I researched how prospective mentors, parents, district employees, and program staff moved through two connected educational programs. The work exposed where unclear eligibility, inconsistent opportunity listings, and invisible backend decisions caused users to lose confidence.
- Role
- UX Research Intern
- Scope
- Research, synthesis, workflow mapping, and design direction
- Collaborators
- Researchers, designers, developers, and program staff
- Deliverables
- Research findings, service flows, site structure, and prototype
The visible usability problems were being created by a larger service system. Information existed, but users could not always tell what applied to them, what was still active, or what happened after an application entered staff review.
Why this mattered
STEAMbassadors connects mentors with STEAM learning opportunities, while eLEAP supports application and scholarship workflows. Both programs depended on people making informed decisions before moving into processes that were partly invisible from the user side.
Opportunity status was ambiguous
Open gigs, closed gigs, and general program information were not separated strongly enough for users to know what they could act on.
Progress disappeared after submission
Applications and nominations entered staff-controlled workflows without consistently communicating confirmation, review status, timing, or next steps.
The system behind the interface
The work crossed more than one website and more than one user type. I mapped the experience as a connected service rather than treating each page as an isolated usability problem.
Understands the program, checks fit, and begins an application.
Presents requirements, collects information, and signals progress.
Verify eligibility, review records, coordinate funding, and communicate outcomes.
Receives a decision, next steps, or reimbursement information.
My central research question became: where does the experience depend on knowledge that only staff or the backend system can see?
Research approach
I focused less on whether participants liked the interface and more on whether the system gave them enough information to make a decision and predict what would happen next.
What we needed to understand
How I investigated it
What it informed
Could new users explain the program and determine whether it applied to them?
User interviews, observation, and usability testing
Content hierarchy, eligibility, and role expectations
Could users distinguish an actionable gig from a closed or informational listing?
Task analysis, heuristic evaluation, and cognitive walkthrough
Opportunity status, filtering, and repeated listing structure
What happened after an application, nomination, or cancellation?
Journey mapping, workflow mapping, and staff-side synthesis
Confirmation states, notifications, ownership, and edge cases
User Interviews
Usability Testing
Participant Observation
Heuristic Evaluation
Cognitive Walkthrough
Task Analysis
Journey Mapping
Workflow Mapping
What the research changed
The findings were translated into product requirements rather than left as general usability feedback. Each recommendation addressed a specific moment where the system made users interpret too much.
01
Bring role and eligibility information forward
Observed
Users recognized the mentorship and STEAM focus but still searched for what they would do, what was required, and what the commitment involved.
Risk
People had to invest attention before knowing whether the opportunity fit their situation.
Design response
Move eligibility, responsibilities, benefits, location, hours, and application expectations higher in the page hierarchy.
02
Turn the gig board into a comparable set of opportunities
Observed
Closed gigs appeared close to current listings, and opportunity pages did not always organize information in the same way.
Risk
Users could spend time evaluating an unavailable role or struggle to compare two active opportunities.
Design response
Separate active and archived gigs, add explicit status labels, introduce relevant filters, and standardize listing content.
03
Make staff-side progress visible to the applicant
Observed
After submission, responsibility moved to staff and administrators without always giving the applicant confirmation, timing, or a visible next step.
Risk
A completed form could still feel unfinished because the user could not tell whether the system had accepted it or what would happen next.
Design response
Define confirmation, review, approval, rejection, cancellation, and reimbursement messages around the actual backend workflow.
Parent application workflow
Mapping the parent journey exposed the gap between submitting an application and receiving an outcome. The interface could collect information, but staff still needed to verify eligibility, review records, and determine how the result would be communicated.
From findings to site structure
The redesign retained the program's identity but reorganized the experience around the questions participants needed answered first. Eligibility, mission, role expectations, FAQs, resources, and application steps became distinct destinations instead of competing within a long informational page.
Operational edge case: cancellation
Cancellation was not a single action with a single outcome. Responsibility changed according to the organization deadline and whether eLEAP funds had already been disbursed. Mapping that rule clarified what a future confirmation screen or status message would need to explain.
Condition
Cancellation timing
The system must know whether the request falls before or after the organization's deadline.
Condition
Disbursement status
The response changes depending on whether program funds have already moved.
Interface implication
Visible responsibility
The user needs to know who is handling the reimbursement and when to expect follow-up.
A second entry point: district nomination
The D65 journey began with an employee nominating someone else rather than applying for themselves. That introduced a three-sided handoff between the employee, an administrator, and the family receiving the opportunity.
Important distinction
Open the complete nomination journey
This artifact contains assumptions as well as mapped steps. It was used to identify what still required validation, not to present every part of the nomination journey as established fact.
Outcome
The project converted recurring moments of uncertainty into a documented model of the service and a set of interface requirements. The resulting work connected research findings to a revised site structure, clearer opportunity organization, and more explicit application states.
Parent application, website structure, cancellation logic, and district nomination.
Eligibility, listing consistency, opportunity status, confirmation, and follow-up communication.
A clearer information architecture and clickable website concept grounded in the research.
What this outcome does not claim
The work established research-backed requirements and a redesign direction. It does not claim measured changes in application completion, staff workload, or program participation because those outcomes were not evaluated after implementation.
What I learned
I entered the project expecting most of the usability issues to live within page structure and content. Mapping the application and nomination journeys showed that several of the most important breakdowns occurred after users left the visible interface, when information entered staff review or funding decisions changed behind the scenes.
The project taught me to treat missing feedback as a system problem, not simply a content problem. In future research, I would map user-facing and staff-facing states together earlier so operational rules can become explicit interface requirements before visual design begins.