HERO Image of RADR


2021 - PRESENT

2020 R&D Winner

A customized satellite data watcher for natural disaster relief

Target audience

Natural disaster scientists

The experience

For natural disasters, people watch potential areas over time.

Project goal

To help notify people when satellite data comes in for a region they select. Additionally, people can choose to process the data as soon as the server receives it.  

MY ROLE & responsibilities

UX Lead
1. Lead the team to move forward on decisions and deliverables
2. Distributing tasks and budget
3. Responsible for the event creation feature


Department of Energy
Pacific Northwest National Lab.

Context & Outcome

Project background

Adding new perspective

The sponsors specifically asked for no UX designers on the project since the scope was only for an API explorer. With the connection of developers, they decided to include my team and me in the process.

We are confident with the practice of user-centered design we can optimize the experience for them even if they don't think they need it.

Design question

How might we help natural disaster relief scientists to monitor geological data from their regions?

Our developers have developed an API to define map areas and process data. However, asking scientists to remember command lines is not always easy.

From learning what the problem is and how the API is structured, we created an experience to translate the API to a smooth experience.

Project outcome

Winning a seat at the table

After the experience is close to solidified, we had a couple of meetings with our sponsors to walk them through.

With the relationship with the sponsors, we are working on the second iteration involving users to the experience so we can create something that fit their work life.

The product is currently under development.

User research

problem space

Understanding the APIs

With a programming background and multiple sessions of talking with the main developer, we learned the story of building the API and its core functionalities.

Navigating the programming concepts isn't easy, however, I led the team sorting through our notes and came up with the design requirements.

Design requirements

Translating programming language

I facilitated and participated to extract design requirements from our stakeholder interviews:


Manage all events


Create an event with selected data-processing method


View / edit event details page for guests and event owners



Settling on an experience

We ideated and came together using a working session to define the general direction of the experience.

As the UX lead, I facilitated and participated to converge our ideas.

Design & Prototyping

conceptual idea

Lo-fi design

I distributed different features for each of the team member to create lo-fidelity design on.

I also set up meetings to review our work with some of our senior UX designers, developers and PMs.

Below are my work for the dashboard & creating an event to follow / watch.

better present

Lo-fi prototype

I wanted to test out whether the experience makes sense. Therefore I made a quick lo-fi prototype to help me envision and present to others about the experience.

Function & emotion check

Hi-fidelity design

With the feedback we got and minor ideation in lo-fi, I moved the team to hi-fi design.

I invited the developers and PMs to review our work functionally. It gave the developers a chance to review the feasibility and discuss possible limitations with us before we solidify our iteration.

I also invited other people on the team to go through the experience for an emotion check. We want to make sure the experience doesn't bring in any frustration.

RADR MockupRADR MockupRADR MockupRADR Mockup

Some of my hi-fi design work

full experience & handoff

Hi-fi Design & Dev Handoff

In this last iteration, we answered some of the devs' concerns and documented our process so developers can develop based on our descriptions. I also hope the documentation can help future designers to onboard or reimagine the experience.

The "handoff" is not entirely hands-off. We remained available to the developers for any difficulties and confusion they might have.

For documentation, I asked my team to work with the developers to make sure we delivered targeted and useful information.

Below are some of my work and documentation.


Building trust through a transparent process and reasoning

Given UX are just getting recognized in the tech industry, it was a novel term for the scientific community.

To gain trust from our subject matter experts (SMEs), I led the team to be transparent with our process, answer every question SMEs have, and explain each design decision with evidence.

I understand people dislike explaining themselves but I found it particularly helpful when talking to SMEs to build trust. With trust, I secured a smooth collaboration for our team.