Selected Work
Design decisions, in three projects
Projects Rachel Cho delivered in previous roles, before starting Second Context. Client names are not disclosed, and the screens are recreated to illustrate the design decisions.
- 01 Scheduling
- P1P2P2P302 Priority triage
- ENKO03 Korean localization
Recreated for illustration · Sample data
Scheduling UX for a U.S. home healthcare SaaS
Designed complex eligibility conditions, scheduling rules, and exceptions so users could understand them and act right away.
- Problem
- An AI scheduling platform that U.S. home healthcare operations teams use to coordinate clinician visits. Schedulers had to weigh patient eligibility, visit frequency, and staff availability together, which led to repeated questions and confusion.
- My role
-
- Joined as the founding designer (Senior Product Designer).
- Defined the product design vision and strategy for the core AI scheduling platform with the CEO, translating business goals into end-to-end design direction from 0 to 1.
- Built the company’s first Figma design system with the CTO and 6 front-end engineers.
- Established the company’s first end-to-end design process shared by design, product, and engineering.
- Key design decisions
-
- Because overlapping eligibility, visit-frequency, and availability rules caused repeated questions and confusion, the design shows bookable dates and status first instead of explaining the rules.
- Replaced internal codes with wording users could understand.
- To improve both decision speed and confidence, defined how AI-generated schedule recommendations are surfaced, validated, and adjusted.
- Screens and flows changed
-
- A calendar of bookable dates and schedule status indicators
- UI wording that replaces internal codes
- A flow for reviewing, validating, and adjusting AI schedule recommendations
- Confirmed results
-
- User rating Schedule-planning confidence 5.8 → 8.2 in the pilot
- Work outcome Task time 180 sec → 60 sec after several improvements were applied together
- Work outcome Manual validation reduced by 35% in the AI-assisted scheduling workflow
- Adoption scope Scheduling recommendation experience used by 3,000+ clinicians
- Adoption scope Design system adopted by all 23 developers as the org-wide standard
- Work outcome Release cycles accelerated by 50%+ after the design system was adopted
Recreated for illustration · Sample data
- Available
- Blocked
- Selected
The 10th can’t be booked
This week’s visit limit (2 visits) has already been used.
FREQ_LIMIT_WK → shown as a sentence users can understand
Recommended: Fri the 12th, morning
This date fits both the visit frequency and the assigned clinician’s availability.
1. Pick a date Instead of explaining the rules first, the calendar shows which dates are available and their status.
2. See why it’s blocked Choosing a blocked date explains the reason in plain language instead of an internal code.
3. Next step The AI-recommended date is shown, and the user confirms it or adjusts to another date before booking.
Operations monitoring and incident management UX for a global pharmaceutical company
Connected severity, scope of impact, and investigation priority across a large volume of information.
- Problem
- An enterprise monitoring platform supporting vaccine operations, used by the company’s engineering teams. To investigate an incident, operators had to move between 8 dashboards to work out severity and impact.
- My role
-
- Joined as a contract Senior Product Designer through a UX design agency.
- Designed a generative-AI incident management system with a global IT company’s AI/ML teams, translating model outputs into actionable signals for enterprise users.
- Conducted 15 stakeholder interviews to define how AI insights such as risk predictions, alerts, and confidence levels are surfaced and prioritized.
- Key design decisions
-
- Because operators had to piece together severity and impact across 8 dashboards themselves, the information architecture was redesigned around severity and downstream impact.
- Rather than listing risk predictions, alerts, and confidence levels with equal weight, set criteria for showing them by investigation priority.
- Aligned with engineering on a list-browsing approach that accounts for performance.
- Screens and flows changed
-
- An incident investigation flow centered on severity and downstream impact
- Decision-support screens that surface AI insights by priority
- Performance-aware incident list browsing
- Confirmed results
-
- Work outcome Incident investigation time 30 min → 3 min, as reported in the project
- Work outcome Incident triage time reduced by 80% after redesigning decision-support workflows and clarifying signals
- Work outcome Developer internal-tool ticket processing time reduced by 40%
- Research scope 15 stakeholder interviews
Put what needs action first, first.
Technical signals and business impact are read together, so the incident that needs action first sits at the top of the list.
Recreated for illustration · Sample data
Criteria: technical signal (anomaly score) + business impact (blocked teams, owner assigned)
P1 Sample incident A · Escalate now
- Affected teams
- Sample team 1 · Sample team 2 · Sample team 3 (3 of 5 teams)
- Related signals
- Anomaly score 0.42 · Recurred 3× this week
- Owner
- None yet — a responsible team needs to be assigned
- Records
- 2 related tickets · 1 earlier incident
P2 Sample incident D · Monitor
- Affected teams
- No teams blocked
- Related signals
- Anomaly score 0.66 · Memory usage rising
- Owner
- Sample owner 1 (SRE)
- Records
- 1 earlier incident
P2 Sample incident B · Track and log
- Affected teams
- Sample team 4 (1 of 5 teams)
- Related signals
- Anomaly score 0.38 · 2 backup retries
- Owner
- Sample owner 2 (GCC)
- Records
- 1 related ticket
P3 Sample incident C · Log only
- Affected teams
- No teams blocked
- Related signals
- Anomaly score 0.21 · Request volume rising
- Owner
- Sample owner 3 (GCC)
- Records
- No related records
1. Many alerts When alerts are listed in the order received, all with equal weight, responders have to work out for themselves what to check first.
2. Priority to the top Even with a low anomaly score, an incident becomes P1 when several teams are blocked and no one owns it. This movement only demonstrates the principle; the real screen opens in this order from the start.
3. Click to investigate Selecting an item shows affected teams, related signals, owner, and records in one place. Select another item to compare.
From past records, the signals to watch next.
AI finds recurring patterns in the past records connected for the project, and the summary above the list flags risks that may come next.
Recreated for illustration · Sample data
AI summary
- ObservedRecurring pattern
- In sample service X, processing delay alerts were followed by data update tickets and sync delay incidents, twice.
- ForecastRisk that may follow
- If the same alert appears again, this sequence may continue and could affect downstream work.
- EvidenceCheck related records
These sample records support the summary. The same rows are marked in the table below.
- Operations data D-01 processing delay alert → Ticket T-01 data update delay question → Incident history E sync delay
- Operations data D-03 processing delay alert → Ticket T-03 missing report question → Incident history G sync delay
A forecast is a possibility, not a confirmed outcome. Responders review the evidence and decide whether to act.
| Past operations data | Related tickets | Incident history |
|---|---|---|
| D-01 Processing delay alert | T-01 Data update delay question | E Sync delay |
| D-02 Disk usage alert | T-02 Access request | F Certificate renewal |
| D-03 Processing delay alert | T-03 Missing report question | G Sync delay |
In commonProcessing delay alert → data update ticket → sync delay recurred twice in the same order.
1. Gather related records Past operations data, related tickets, and incident history connected for the project are brought together.
2. Find the pattern What the records have in common is found, and sequences that recurred in the same order are marked.
3. Forecast summary The AI summary above the records shows the result first. It separates the observed pattern from the forecast, and “View related records” shows the evidence.
Korean product localization for a global tech company
Adapted the product experience to the language and its context of use.
- Problem
- A project adapting content for a 5K-display desktop product to the Korean market, keeping the global brand’s expression while making Korean copy and layout read naturally.
- My role
- Over 6 weeks in 2019, worked with a global production agency in the U.K. and the client’s Korea and U.S. teams to localize UX copy and design assets and support communication between teams.
- Key design decisions
-
- Because both the global brand’s expression and natural Korean had to be preserved, name, date, and time formats were matched to Korean conventions, not just the copy.
- For the same reason, typography and spacing were adjusted for Korean text.
- Supported communication so the U.K., Korea, and U.S. teams stayed aligned.
- Screens and flows changed
-
- Korean UX copy
- Name, date, and time formats
- Localized layouts reflecting Korean typography and spacing
- Confirmed results (deliverables)
-
- UX copy and design assets tailored to the Korean market
- Localized layouts
Recreated for illustration · Sample copy, not actual project screens
Original
Hi, Jimin Kim
A display that brings every detail to life.
Delivery: Tue, Jun 4, 2019
Pickup after 3:30 PM
한국어
김지민 님, 안녕하세요
모든 디테일을 생생하게 담아내는 디스플레이.
배송: 2019년 6월 4일 (화)
픽업: 오후 3:30 이후
1. Original screen The English original’s name, date, and time formats and sentence length are the starting point.
2. Korean screen The same information is carried over in the order and formats Korean users expect.
3. What changed
- Names: family name first, with the honorific 님
- Dates: year-month-day order, with the weekday in parentheses
- Times: 오전/오후 (a.m./p.m.) before the numbers
- Copy and line breaks: breaking lines at word boundaries, with spacing suited to Korean text