UI/UX Designer HCDE, University of Washington Seattle

Zerui Guan

A UI/UX designer with roots in data and informatics, shaping everyday systems into experiences that feel clear, usable, and human.

Open to Summer 2026 Internships
Get in touch Résumé
01 / About

From data to human-centered design.

I turn complex systems into experiences that feel clear, calm, and human.

I grew up in Hohhot, Inner Mongolia, China, a city shaped by both Mongolian and Chinese cultures. Moving from there to Seattle, and later completing my B.S. in Informatics (Data Science Track) at the University of Washington, made me more aware of how people interpret systems, spaces, and information differently depending on their context.

For years, I worked closely with data, including analysis, databases, and visualization. But I kept coming back to the same realization: the hardest part was not the numbers themselves, but making them understandable and useful for the people who needed to act on them.

That realization pulled me toward human-centered design.

Today, I'm a first-year master's student in Human Centered Design & Engineering at the University of Washington, working toward a career in UI/UX design. I'm interested in how people interact with everyday systems, from digital products to physical spaces, especially in moments where design can reduce friction, clarify information, and make decisions feel easier.

My data background still shapes how I design. I move between user research, interaction design, prototyping, and systems thinking, and I'm comfortable collaborating with engineers, analysts, and cross-functional teams. I like turning messy problems into clear structures, then refining ideas through feedback instead of defending a first guess.

I care about clarity over cleverness, evidence over assumption, and designing with respect for the people behind the data. Outside of design, I enjoy working out, rock climbing, traveling, and noticing the small details of everyday life.

Seattle's Space Needle
Seattle's Space NeedlePHOTOGRAPHY
My desk setup
Where the work happensWORKSPACE
Bouldering at the gym
On the wallCLIMBING
A temple after snow
A temple, after snowTRAVEL
OSL Serves wireframe
OSL Serves, wireframedPROCESS
02 / What I do

A toolkit shaped by research, code, and craft.

03 / Selected Work

Selected projects, told end‑to‑end.

04 / Contact

Let's build something clear.

I’m interested in thoughtful product, service, and interaction design work where research, craft, and systems thinking come together. If that sounds like your team or project, let’s talk.

Get in touch Résumé
Emailgzr2004@uw.edu Phone+1 (206) 618-4780 LinkedInin/zerui-guan Read.cv@zerui
Case 01 // Ride Later
Mobile UX · Trip Planning2025

Ride Later

A predictive reservation feature that helps shared e-scooter and e-bike users plan future trips with more confidence.

View interactive prototype
Role
UX Researcher
Interaction Designer
UI Designer
Project Type
Course Work
Team Project
Timeline
Autumn 2025
Methods & Tools
Survey · Interviews
User flows · Prototype
Figma · FigJam
01Overview

Making future micromobility feel predictable.

Shared e-scooters and e-bikes are commonly used in Seattle for short and medium-distance travel, especially as a flexible last-mile option. Current apps make it easy to find a nearby vehicle in the moment, but they do not help users know whether a vehicle will still be available when they need to leave later.

Ride Later explores how the Lime app could support more predictable trip planning by allowing users to check future vehicle availability, reserve a vehicle in advance, and receive guidance when the vehicle is ready.

Diagram explaining last-mile transportation options including walking, car sharing, bike sharing, ride sharing, and site-specific shuttles.
Context: Shared e-scooters and e-bikes can support last-mile travel, but planning around them becomes difficult when future vehicle availability is uncertain.
02Design Question

How might we support reliable trip planning for shared e-scooter and e-bike users in Seattle by increasing predictability and transparency around future vehicle availability?

03Problem

Real-time availability is not enough for planned travel.

Shared micromobility works well for spontaneous trips, but it becomes unreliable when users need to plan ahead. Through our research, we found that users often check vehicle availability earlier in the day, only to arrive later and find that no vehicle is available nearby.

For time-sensitive trips, this creates stress, delays, and last-minute transportation changes. The core problem was not simply helping users locate a vehicle right now. It was helping users feel confident that they could rely on shared micromobility for a future trip.

04Research

Understanding what makes shared mobility trustworthy.

We used secondary research, a survey, and in-person interviews to understand what shapes trust in shared e-scooter and e-bike use.

  • Secondary research surfaced systemic barriers.
    Safety risks, inconsistent bike infrastructure, limited helmet access, pricing concerns, and uneven vehicle distribution all shaped the broader problem space.
  • Survey responses revealed different barriers for users and non-users.
    Among non-users, safety and cost were the strongest barriers. Among current users, negative experiences were more often related to finding available vehicles, parking, and vehicle condition.
  • Interviews clarified the planning problem.
    Participants described shared micromobility as useful when available, but difficult to rely on for time-sensitive trips.
Key insight

Trust depends on predictability. Users were not only asking, “Where is a vehicle now?” They were asking, “Can I rely on this option later?”

05Design Direction

A new “Ride Later” workflow inside Lime.

We designed Ride Later as a new workflow inside the Lime app. The feature allows users to enter a future location, date, and time, then view predicted vehicle availability through a heat map. If predicted availability is low, the app recommends making a reservation. After reserving, users receive preparation updates and guidance to locate the correct vehicle when it is ready.

Step 01
Check future availability

A heat map helps users compare predicted vehicle availability by location and time.

Step 02
Reserve when risk is low

When predicted availability is limited, the system recommends making a reservation.

Step 03
Find the reserved vehicle

Notifications and map guidance help users locate the correct scooter or bike at pickup.

Customer user flow Customer user flow diagram for the Ride Later feature.
Mapping the trip-planning flow. We mapped the Ride Later experience from checking future availability to making a reservation, receiving vehicle-ready updates, finding the reserved vehicle, and starting the ride.
06Key Design Decisions

Designing transparency across the full planning journey.

  • Future availability heat map
    Instead of only showing real-time vehicle locations, the heat map helps users compare future availability across nearby areas and make a decision before arriving at the departure point.
  • Reservation recommendation
    When predicted availability is low, the system suggests a reservation within the planning context. The goal was to make the feature feel helpful rather than pushy.
  • Three-step reservation flow
    Entering trip details, completing purchase, and confirming the reservation are separated into clear steps so users understand where they are in the process.
  • Vehicle-ready notifications and pickup guidance
    Status updates, map guidance, and a “Ring the Bike” feature help users trust that the reserved vehicle is being prepared and can be found when they arrive.
Ride Later screen showing low availability recommendation and reservation actions.
Reservation recommendation. When predicted availability is low, the app explains the risk and gives users a clear next step without forcing the decision.
Vehicle ready notification on a phone lock screen.
Vehicle-ready status. Notifications make the reservation feel visible and trackable before the user arrives.
Ride Later pickup guidance screen with Ring the Bike and Scan to Ride actions.
Pickup guidance. “Ring the Bike” and map guidance help users identify the correct reserved vehicle when it is parked nearby.
07Final Solution

From spontaneous riding to planned mobility.

The final prototype introduces a complete Ride Later experience inside the Lime app. Users can check predicted future availability, reserve a vehicle, receive status updates, navigate to the reserved vehicle, unlock it, ride, temporarily lock it, and return it in a valid parking zone.

The design turns shared micromobility from a mostly spontaneous option into something users can plan around with more confidence.

08Interactive Prototype

Explore the full Ride Later flow.

This embedded prototype demonstrates the complete experience, from checking future availability to reserving a vehicle and finding it when it is ready.

Figma Prototype
View in Figma
09Outcome
43
survey responses informed the problem framing
5
in-person interviews explored trip planning behavior
4
core flows defined the end-to-end reservation journey

This project resulted in a high-fidelity mobile prototype, a complete user flow, and a design specification document explaining the rationale behind the main interactions. Although the prototype was not implemented with live prediction data, it demonstrates how historical trip patterns, real-time fleet data, and operational information could be translated into a user-facing planning experience.

09Reflection

Narrowing a broad problem into a designable opportunity.

At first, shared micromobility involved many overlapping issues, including safety, pricing, parking, vehicle condition, infrastructure, and trust. Through research synthesis, we realized that not every important problem was equally actionable through interface design.

Focusing on future availability gave the project a clearer direction. It also helped us think about trust as something built across the entire experience, from checking predictions to making a reservation to finding the vehicle at pickup.

If I continued this project, I would test the prototype with users who regularly rely on shared micromobility for commuting or time-sensitive trips. I would also explore edge cases, such as what happens if a reserved vehicle is moved, damaged, or unavailable before the user arrives.

Next case →
Case 02 // OSL Serves
Web UX · Information Architecture2026

OSL Serves Website Redesign

Turning a sprawling nonprofit website into an intent-first front door that helps people find food, give, and get involved in seconds.

View interactive prototype
Role
Design Lead
Project Type
Client Website Redesign
Team of 5
Timeline
Spring 2026
12 weeks
Tools
Figma · FigJam
Google Stitch · Google Drive
01Overview

A 37-year nonprofit, with a website that could not keep up.

OSL Serves is a Seattle nonprofit that, since 1989, has delivered more than 21.5 million meals, recovers over 2 million pounds of food a year, and now coordinates with 50+ partner organizations while preparing 7,000+ meals a day. Their work is dignified, medically and culturally sensitive food for people facing hunger.

But their website had not grown with them. It was organized around OSL's internal programs rather than what visitors actually came to do, so people got lost and staff fielded constant phone calls. Our 5-person team partnered directly with OSL leadership to redesign the site into a clear, action-oriented experience.

My role · Design Lead I set the design direction and held it together across a 5-person team. I helped turn our research into three personas and a journey map, led the information architecture shift from organization-first to intent-first, shaped the visual system, and drove the wireframe-to-prototype work in Figma, partnering with our content strategist, product manager, and visual designers along the way.

8 to 3
user groups synthesized into core personas
6
intent-based categories replaced an org-first menu
3
clicks or fewer to complete any primary action
02Situation

A site organized around the org, not the people using it.

OSL's existing site buried the things people needed most. Content was structured around internal programs and entities, key actions were hard to find, and dense walls of text made it difficult to take anything away at a glance.

Before · oslserves.org The original OSL Serves homepage, showing dense paragraphs, an embedded video, and a large photo grid.
The original homepage. Long paragraphs, an autoplaying kitchen video, and tiles of photos competed for attention, with no clear path for someone who just needed a meal today.
  • Organization-first architecture
    Content was arranged by OSL's internal programs and entities instead of user intent like "find a meal" or "volunteer."
  • Unclear user task flows
    Key information was difficult to find, which pushed people to call staff directly, often after business hours.
  • Cognitive overload
    Walls of text and grids of photos made it hard to take away essential information quickly.
03Task

Three benchmarks for a 24/7 digital front door.

We framed the redesign around three measurable goals, so success was about user outcomes rather than visual taste.

Goal 01
Intent-based navigation

Connect 8 diverse user groups to their correct pathway within 10 seconds of landing.

Goal 02
Frictionless conversion

Make critical actions like donating or volunteering completable in 3 clicks or fewer.

Goal 03
Trust and transparency

Build confidence with clear impact data, honest logistics, and a consistent visual identity.

04Actions · Research & Personas

Eight very different visitors, distilled into three people.

I grounded the redesign in stakeholder interviews with OSL leadership (including founder Beverly Graham), a heuristic evaluation of the current site, and a content audit. Synthesizing these surfaced eight distinct user groups, from someone seeking a meal today to a farm selling surplus produce. To keep the design coherent, I focused them into three primary personas around the site's core intents.

Key insight

People arrive with a goal, not knowledge of OSL's internal structure. They are asking "where can I get food today?" or "how do I help?", not "which program handles this?"

HS
Hailey Smith
People who need help
GoalFind and receive a meal quickly and confidently.
Key needClear locations, hours, and eligibility.
Pain pointInformation scattered across pages; phone-first workflows.
JH
James Hu
Individuals who want to help
GoalGive time or money and see it makes a difference.
Key needVerified impact and an easy way to give or volunteer.
Pain pointHard to compare options or trust where help goes.
KO
Kelly Ortega
Organizations that want to help
GoalEstablish an ongoing food donation partnership.
Key needClear pickup logistics and a partnership pathway.
Pain pointThe partnership process is buried; coordination is slow.
05Actions · Cross-Journey Insights

Where every journey broke down the same way.

Mapping each persona across their full journey surfaced the same friction again and again, which pointed clearly to where the redesign could help most.

Shared pain points
  • Information fragmentation. Critical details scattered across disconnected pages.
  • Unclear action pathways. Next steps buried in walls of text.
  • Coordination friction. Heavy reliance on phone tag and slow email.
Shared opportunities
  • Intent-based navigation. Reorganize entry points around explicit actions.
  • Simplified intake flows. Build self-service forms for scheduling and giving.
  • Impact communication. Surface proof of impact to build trust and retention.
06Actions · Information Architecture

From organization-first to intent-first.

This was the heart of the redesign. Through card sorting, we replaced a menu built around OSL's internal programs with six high-level categories mapped directly to what users come to do. The shift turned a confusing directory into a set of clear front doors.

Before · organization-first
  • Open Meal Service
  • Food in Motion
  • Meal Partnership Coalition
  • Next Step Program
  • Workforce Development
  • About / Programs / Entities
After · intent-first
  • 01 Find a Meal
  • 02 Donate
  • 03 Make an Impact
  • 04 About Us
  • 05 Careers
  • 06 Contact Us
07Actions · Wireframes & Prototyping

From early structure to a clickable prototype.

We moved from early wireframes into higher-fidelity website templates, using Google Stitch as an exploratory tool before refining the clickable prototype in Figma. We also developed a more consistent visual system and rewrote dense legacy content into clearer headings, shorter copy, and scannable sections.

OSL Serves visual system exploration with color primitives and typography
Visual System Exploration A consistent color, type, and component system to replace inconsistent legacy styling.
OSL Serves wireframe of the Food Rescue Program page
Wireframes to Prototype Low-fidelity structure refined into a clickable, testable prototype in Figma.
08Results · Website & Prototype

A homepage that routes people by intent.

The redesigned website acts as an immediate routing system, giving each visitor a clear entry point based on why they came to OSL: get food, donate, volunteer, partner, or learn more.

  • Urgency callouts
    Two above-the-fold primary actions separate immediate food needs from ways to help.
  • Goal-based action tiles
    Distinct tiles bypass deep pages and lead visitors toward the forms and information they need.
  • Plain-language naming
    Internal program names were translated into clearer descriptions for first-time visitors.
  • Embedded impact metrics
    Visible numbers build trust without overwhelming the page with long copy.
  • Scannable structure
    Large click targets, concise headings, and shorter sections make the redesigned site easier to read and act on.
Final Prototype

The clickable Figma prototype brings the intent-first structure to life, from the routing homepage to simplified donate and volunteer flows.

View interactive prototype
10Reflection

What I would carry into the next redesign.

The hardest part was taming OSL's complexity. Terms like "partner" meant different things to different user groups, so a lot of the work was translating internal language into plain, action-based words people could navigate by.

A few lessons stayed with me. A deeper content audit up front would have made card sorting sharper. Our card sort also leaned toward one persona, so future testing needs more diverse, synchronous participation. And while AI-generated templates were a fast starting point, the first drafts carried redundant content and inconsistent imagery that took real time to rework. If I continued, I would prioritize the mobile experience next, since people seeking a meal are most likely arriving on a phone.

Next case →
Case 03 // Optimizely Opal
UX Research · Usability Testing2026

Optimizely Opal Agent Builder

A formative usability study of Optimizely's no-code agent builder. Six marketers tried to build an AI agent, and their friction pointed to one clear pattern: the tool has a translation problem, not a capability problem.

Role
UX Researcher
Full-cycle contributor
Project Type
Client Usability Study
Team of 4
Timeline
Winter 2026
Methods
Moderated remote testing
Think-aloud · SEQ · Affinity mapping
01Overview

A no-code promise that did not feel no-code.

Optimizely Opal Agent Builder lets marketing teams build custom AI agents to automate everyday work, and it is marketed as no-code for non-technical users. Optimizely wanted to reduce how often customers need a Forward Deployed Engineer just to get an agent running, so the real question was simple: can a marketer build one alone?

Our team of four ran a formative usability study on the agent-creation workflow, from opening a blank agent to inserting variables, attaching tools, and running a test. One finding held across every session: the platform is powerful, but it speaks a developer's language to a marketing audience.

My role · Full-cycle contributor I worked across the whole study. I helped design the task script and study plan, recruited and screened participants, and both facilitated and took notes during sessions. In analysis I ran affinity mapping and coding with the team, built the data visualizations including the SEQ chart and task-performance matrix, and co-authored the final report and client deck.

4.0/7
average SEQ score, against a 5.5+ usability benchmark
1 of 6
discovered the core insertion command without a hint
100%
were confused by terminology like String and Boolean
02Situation

The first screen asks a marketer to think like an engineer.

When a user clicks Create Agent, they land on a single dense page of fields: a prompt template with raw [[bracket]] placeholders, a Variables panel, a Tools panel, and settings like Inference Level and Creativity. Everything appears at once, with no order of operations and no clear place to start.

The blank-slate Agent Builder The Optimizely Opal Specialized Agent form, a single dense page with name, description, prompt template, variables, tools, inference level and creativity fields.
The starting screen. Every configuration field appears at once, framed in developer terms, before the user has any sense of what to do first.
  • Systems-first, not task-first
    The interface asks users to configure logic and define variables, while marketers think in terms of the outcome they want.
  • No guided sequence
    Nothing signals what to set up first, so participants attempted steps in the wrong order.
  • Developer vocabulary up front
    Terms like Variable, String, and Boolean greet users before any plain-language explanation.
03Approach

Six marketers, five tasks, one honest think-aloud.

We ran six 1:1 moderated remote sessions over Zoom, each about 60 minutes, rotating the facilitator and note-taker roles across the team. Participants were marketing professionals with a range of GenAI familiarity but little to no coding experience, exactly the audience the no-code promise targets. We used concurrent think-aloud, collected a Single Ease Question score after each task, and closed with a Magic Wand question.

Task 01
Create an agent

Find the entry point and open a new blank agent.

Task 02
Create a variable

Set up a reusable input and place it into the prompt.

Task 03
Use the slash command

Insert a variable from inside the prompt editor.

Task 04
Attach a tool

Find and add the web browsing tool.

Task 05
Run a test

Execute the agent and interpret the output.

04Findings · Language

"Variable" is a foreign concept.

The single biggest conceptual barrier was vocabulary. The word Variable carries a programming connotation marketers do not share, and the data-type dropdown of String, Boolean, and DateTime read as pure jargon. One participant failed the task outright, unable to connect the bracket placeholder in the prompt to the Variable panel beside it. Even participants who succeeded kept second-guessing themselves.

In their words

"As I click into it I have no idea what any of this means." Another put it plainly: "Someone unfamiliar with variables or ChatGPT might not understand what they are."

Add Variable dialog The Add Variable modal asking for a Type such as String, a Name, and a Description.
Type before meaning. The first thing the dialog asks for is a data type, a concept that belongs to engineers, not marketers.
05Findings · Discoverability

The slash command was effectively invisible.

The primary way to insert a variable is to type a forward slash in the prompt editor to open a menu. Only one of six participants found this without help. Others hovered, hunted for an Insert button, right-clicked, or tried to drag text from the sidebar. That drag-and-drop instinct was telling: people expected a visible, physical way to connect a variable to the prompt.

Found it unprompted
1
Needed first hint
2
Needed second hint
2
Never discovered
1
Why it matters

This is one of the most frequently used actions in the entire tool, gated behind a hidden shortcut. A core mechanic should never depend on a developer convention to be discovered at all.

06Findings · Tools

The Tools panel hides its own function.

Attaching a tool such as web browsing should be easy, but only about half of participants did it cleanly. Tools were grouped by backend system, with categories like Campaign Tools, CMP Tools, and CMS SaaS Tools, rather than by what a marketer wants to do. Search was exact-match, so one participant typed "browser" and got nothing because the tool was named Browse. Descriptions explained the mechanism instead of the use case.

Add Tools registry The Add Tools dialog showing tool categories grouped by backend system such as Campaign Tools, CMP Tools, and CMS SaaS Tools.
Sorted by system, not by goal. The categories mirror Optimizely's internal architecture rather than user goals like Research or Scheduling, which left people scanning blindly.
07Findings · Cognitive Load

Configure blindly, then run to find out.

Showing Variables, Tools, logic, and the prompt all at once overwhelmed users before they could form a working mental model. With no real-time validation, people had to configure blind and wait until they ran the agent to learn whether anything was correct, which turned setup into trial and error.

Test Run panel The Test Run side panel showing input variables and an output area that stays empty until the agent is executed.
The only feedback loop is execution. Users could not tell whether their setup was right until they ran the agent and read the output.
What broke down
  • Cognitive overload. Too many unfamiliar elements on a single screen.
  • Delayed feedback. No validation until execution, so users configured by trial and error.
  • Lost connection. The link between the sidebar Variables and the prompt canvas was unclear.
What they expected
  • A guided sequence. A clear first step instead of a wall of fields.
  • Live preview. Seeing the output take shape before running.
  • Familiar patterns. The visual, step-based ease of Mailchimp, Canva, and Notion.
08The Data

Performance at a glance.

Two views made the pattern hard to argue with. Subjective ease stayed below the usability benchmark for nearly everyone, and the task matrix showed exactly where people needed hints or failed.

Benchmark 5.5
3
P1
6
P2
2
P3
3
P4
3
P5
3
P6
Single Ease Question, 1 (hard) to 7 (easy)Team average 4.0Benchmark 5.5+
P1P2P3P4P5P6
T1 · Create agentPassPassPassPassPassPass
T2 · Create variablePassPassFailPassPassPass
T3 · Slash commandHintHintFailHintPassHint
T4 · Attach toolPassPassPassPassHintFail
T5 · Run testFailPassFailFailPassFail
SuccessNeeded a hintFailed
09Recommendations

Make the tool speak the language of the marketer.

Our recommendations centered on translation and progressive disclosure rather than rebuilding the engine. The most direct win is renaming system concepts into words marketers already use.

System termMarketer-friendly
Variable→Custom Input
String→Text
Boolean→Yes / No
DateTime→Date
Run→Test My Agent
Execution ID→Run Reference #
  • Make insertion visible
    Add an inline Insert button and drag-and-drop from the sidebar, and surface the slash command instead of hiding it.
  • Demystify the tools panel
    Use synonym-aware search, recognizable icons, and outcome-based descriptions grouped by user goal.
  • Rethink the start
    Open with pre-built templates so the mental model becomes customizing, not building from scratch.
  • Guide, do not dump
    Replace the single page with a step-by-step wizard and a visible progress indicator.
10Reflection

What I would change next time.

Pre-filling the prompt with example brackets gave participants a visual crutch, so a few tried typing brackets by hand instead of looking for an Insert affordance. A truly blank starting line would have given a cleaner read on discovery. I would also screen more strictly for zero coding experience, since two of our participants had some technical background and still struggled, which suggests the baseline marketer struggles even more.

As a next step, I would run a larger unmoderated study to see whether the slash-command discovery rate holds at scale, then re-test the highest-priority fixes against this baseline. The clearest lesson stayed with me: when capable users feel stupid, the interface is the problem, not the person.

Next case →