UX/UI designer, Ho Chi Minh City

Hello, I am Thảo

I untangle complex things, gently, until they feel clear enough to act on.

start here

See my work

About

nice to meet you

that’s me

I’m Dương Nguyễn Phương Thảo

I came to design through Management Information Systems. A web design course during my degree was the first time I opened Figma, and I haven’t stopped since. Because of that background, I usually map the process and the data behind a product before I design its screens.

Experience

Nov 2025 to present

UX/UI Design Intern

Tiger Tribe, a Heineken company

Education

Class of 2026

Management Information Systems

University of Economics and Law, VNU-HCM

Work

small worlds I’ve helped shape

01/05

Shelf Price Intelligence

Web platform

A retail price intelligence platform that turns competitor shelf prices into decisions.

View case study

02/05

Draught Analytics

Desktop dashboard

A desktop analytics dashboard for understanding draught performance across many outlets.

View case study

03/05

Water Treatment Plant Inspection

iPad + Web

A paperless inspection and approval flow for technicians and plant managers.

View case study

04/05

Sustainable Returns App

Mobile app

One place to handle returns from several marketplaces, with greener choices built in.

View case study

05/05

ClayCo

E-commerce website

A ceramics shop where a personalised request travels from cart to the store’s orders.

View case study

Plant manager's Submissions page on the web

Play

a small pause, if you need one

rally0

best0

A rally in the park

Hit the shuttlecock on your side. Hit it while it is still high for a power shot. Park buddy tires as the rally goes on.

Contact

write me a few lines, I read every one

Name Email

Message

PlayLab Innovation Challenge 2026

Shelf Price Intelligence

A platform that collects competitor shelf prices automatically and turns them into pricing decisions.

01. Overview

A global beverage company sells to distributors in the US and never sees what shoppers actually pay. Specialists copied shelf prices by hand, at an estimated $16,000 a month, and covered only two or three SKUs per store visit.

Role: Sole UX/UI Designer
Team: Seven people across backend, AI, frontend and product
Timeline: 2 months
Confidentiality: Names, data and visuals changed

My role

As the only designer on the team, I designed the product from the process maps to the final UI.

The design problem

The brief was to capture shelf prices, and we widened it to helping commercial teams act on them.

02. Key decisions

01 / 03

One product, two roles

Problem: Commercial managers and data admins needed the same data but very different controls.
Decision: One product serves both roles. Managers see the commercial layer, and admins also get data configuration and monitoring.
Why it matters: People making pricing decisions never have to manage a scraping schedule.

Manager dashboard: KPIs, price gap map, price trend and alerts

Compare prices, not just list them

Problem: A single retailer can carry a hundred SKUs across nine brands, too many to scan one by one.
Decision: Our SKUs and competitor SKUs sit on one axis, with a portfolio view above. A trend by ZIP code below lets users drill into one market.
Why it matters: Managers see the price gap against competitors instead of reading each price on its own.

Design for the failure case

Problem: When a scraper returns a product that matches nothing, a silent guess would corrupt the data.
Decision: The record is flagged and sent to an admin queue. Admins can accept it, map it to another SKU or create a new one.
Why it matters: Bad matches are fixed by a person before they reach any pricing decision.

Flagged records with fail reason, suggested match and three actions

03. Final solution

The same data serves two jobs: deciding on prices and keeping the data right.

Spot a competitor move

A manager goes from an alert to the SKU detail behind it.

Fix a bad match

An admin reviews flagged records before they reach the dashboard.

04. Outcome

The project won first place at the PlayLab Innovation Challenge and was presented to the company's Chief Digital & Technology Officer. The business case estimated that automated collection across four retailers could cut monthly cost from about $16K to $2.7K, a projection rather than a measured saving.

what I learned

I worried the Brand Detail table was too dense, but in UAT people who read pricing data every day scanned it faster than simplified cards. I learned not to simplify a data-heavy screen just because it looks dense to me.

Ongoing product work

Draught Analytics

A desktop dashboard for comparing draught beer performance across many outlets, not one venue at a time.

01. Overview

An existing mobile app helps an owner check one bar. The desktop product had to help teams compare outlets, brands and custom groups, using metrics like yield: the share of beer leaving the keg that is actually served.

Role: UX/UI Designer, working with a Lead Designer
Timeline: July 2026 to now
Platform: Desktop web
Confidentiality: Names, data and visuals changed

My role

I designed the desktop screens and worked out the comparison rules behind the charts.

The design problem

Make every comparison easy to read, and make the same metric mean the same thing everywhere it appears.

02. Key decisions

01 / 03

Compare groups by average per outlet

Problem: A group of sixteen outlets and a single bar can't share a chart on total volume, because the group drowns out the single outlet.
Decision: When groups and single outlets share a chart, the metric becomes average volume per outlet. A single outlet stays the same, since its average is its total.
Why it matters: Groups and outlets sit on a comparable scale.

Volume performance chart and group table

Remove the ambiguous comparison

Problem: "Previous period" could mean the days just before, the same dates last month, or the whole previous month.
Decision: I removed it and kept year over year. Its meaning stays the same for any date range.
Why it matters: The comparison means the same thing for any date range, so the metric is easier to read.

Keep the benchmark still

Problem: Search recalculates the visible page, so a benchmark that recalculated too would move with what it measures.
Decision: The group average responds to filters and time windows. It stays fixed when search narrows the view.
Why it matters: The average stays a fixed reference point while users narrow down the list.

Search state: outlet compared with a fixed group average

03. Final solution

Four tabs take a team from a daily health check down to single pours.

Check the network

A daily view of how every outlet is pouring.

Find where beer is lost

From a drop in yield to the outlets and pours behind it.

04. Outcome

The product is still in active revision. A working prototype is being used for stakeholder review and testing while rules and terminology are refined.

what I learned

Dashboard work turned out to be less about drawing charts and more about defining what the numbers mean. A small rule, like how a benchmark reacts to search, can decide whether a comparison is useful at all.

University practicum hosted by FPT Software Japan

Water Treatment Plant Inspection

Designing a paperless inspection and approval flow for water treatment plants: an iPad app for technicians in the field and a web app for plant managers.

01. Overview

According to the client, equipment inspections were still paper-based: technicians recorded readings by hand, retyped them into Excel, and waited for managers to approve printed forms. Rejections were verbal, abnormal readings were easy to miss, and past records were difficult to trace.

Role: UX/UI Designer, within a five-person Business Analyst practicum team
Timeline: May to July 2025
Platforms: iPad app for field staff, web app for plant managers
Status: Concept, not built or tested

My role

I designed the iPad and web interfaces from the team's requirement analysis and client Q&A.

The design problem

Connect field inspection and desk-based approval in one traceable flow, while catching abnormal readings before they disappear into paperwork.

02. Key decisions

01 / 03

Start inspection by scanning the device

Problem: Picking the right form and typing device details by hand is slow and risks logging readings against the wrong device.
Decision: Scanning the device's QR code confirms it is assigned to the technician and opens a checklist with device, staff and area already filled in. An unassigned device asks for a rescan, and creating a checklist manually stays available.
Why it matters: Fewer fields to type, and the wrong device is caught before any data is entered.

QR scan result on iPad: device TB-01, Water pump, Zone A, assigned to you, with Start Inspection

Catch abnormal readings inside the form

Problem: A reading beyond its limit went unnoticed until someone read the paper.
Decision: An out-of-range value turns red with its limit shown underneath, and the disabled submit button says why. Submission waits until the technician confirms an incident report.
Why it matters: Every abnormal reading becomes a recorded incident before the checklist reaches the manager.

Device Metrics tab with the flow rate flagged red and submission disabled

Confirmation tab asking whether to generate an incident report

Separate a working draft from a submitted record

Problem: Technicians need to save partial work, but a manager must approve exactly what was sent.
Decision: Save Draft and Save and Send for Approval are separate actions, with a Draft label in the header. A submitted checklist locks and receives an auto-generated ID.
Why it matters: What the manager approves cannot change afterwards, and the ID makes the record easy to trace.

Checklist marked Draft with Save and Send for Approval

03. Final solution

Checklist status and record IDs keep the technician and the manager working on the same record.

Abnormal reading

A reading over its limit is flagged on the spot, becomes a linked incident, and turns into corrective work once the manager approves it.

Flow rate flagged red on the Device Metrics tab

Confirmation tab asking for an incident report

Rejected checklist

The manager rejects a checklist with a written reason, and it goes back to the technician to fix and resubmit.

Submissions page with today's checklists by status

Checklist review with status set to Rejected, a note and a signature

04. Outcome

I delivered iPad and web mockups for both roles and revised them after the host company's review. This is a concept: it was not built or tested with users.

what I learned

I designed from the client's answers, not from watching technicians at work, and nothing was tested with real users. So the assumptions behind QR scanning, blocked submission and field conditions like poor light or patchy network still need validation, ideally in a pilot at one plant.

Student research project on sustainable reverse logistics

Sustainable Returns App

A mobile concept for handling returns from several marketplaces in one place, with greener packaging and transport built into the return.

01. Overview

Our research team surveyed 337 online shoppers in Ho Chi Minh City. Green packaging, green transport, return cost and customer service were significantly associated with their satisfaction with returns, and the study proposed a returns app as its practical solution.

Role: UX/UI Designer, within a five-person student research team
Timeline: October 2024 to March 2025
Platform: Mobile app, in Vietnamese
Status: Concept, not built or tested

My role

I designed the app interface, using the team's survey findings as input.

The design problem

Take a shopper from reporting a problem to receiving a refund in one flow, with the greener choices the research pointed to built in.

02. Key decisions

01 / 02

Build the green choices into the return form

Problem: Green packaging and green transport were linked to satisfaction, so the return needed a place for those choices.
Decision: The return form asks for a packaging type, such as biodegradable, and a return method. Doorstep pickup adds a green vehicle choice shown as three large tiles.
Why it matters: Shoppers see the greener options while arranging the return, without going to a separate page.

Create return, doorstep with green vehicle

One place for returns across marketplaces

Problem: Shoppers buy across several marketplaces, each with its own return flow (our design assumption, not a research finding).
Decision: One list with Orders and Returns tabs shows every return with a status label. A filter narrows it by marketplace and by stage, from pending to refunded.
Why it matters: A shopper can find any return without switching apps.

03. Final solution

One return, from reporting the problem to getting the money back.

Request a refund

The shopper says what went wrong, adds proof and sees the refund amount before sending the request.

Send it back and track it

The shopper chooses how to hand the item over, then follows the return until the refund arrives.

04. Outcome

I designed an end-to-end return flow for mobile, with greener packaging and transport built into the return. It was proposed in the team's research report in March 2025 and was not built or tested.

what I learned

The survey showed which factors were linked to satisfaction, not how shoppers would use a returns app, and its sample was mostly students. Before building, I would test whether shoppers pick one app over each marketplace's own flow and whether they notice the green options.

Business Website Development course project

ClayCo

An e-commerce site for a fictional ceramics brand, where a personalised order stays intact from the product page to the store's admin.

01. Overview

ClayCo is a fictional brand our team created for a university course: handmade ceramics that customers can personalise, sold alongside plants and flowers. Personalisation was the brand's core offer, but a standard online shop only sells fixed products.

Role: UX/UI Designer and Frontend Contributor, within a five-person course team
Timeline: Submitted November 2024
Platforms: Customer website and store admin
Status: Course project, designed in Figma and coded

My role

I contributed to the Figma design and the frontend build, working from the team's business analysis and competitor review.

The design problem

Sell a custom request as easily as a standard product, and keep it attached to the order all the way to the store's admin.

02. Key decisions

01 / 03

Make personalisation a step on the product page

Problem: Personalised pieces were the brand's core offer, but a standard product page only offers Add to cart.
Decision: Customisable products show Customize next to Add to cart. It opens a panel for placement, text, an optional image and extra details, then adds the item to the cart.
Why it matters: The request travels with the item, so the cart shows the engraving right under the product name.

Support the three payment paths in the checkout flow

Problem: The team's order flow defined three ways to pay: cash on delivery, internet banking and MoMo.
Decision: Checkout offers all three, and MoMo opens a Scan to Pay screen with the order number and amount. A note field under the delivery details holds gift messages and delivery instructions.
Why it matters: Every payment path in the flow has a place in checkout, and extra instructions travel with the order.

Checkout with three payment methods and a note field

MoMo Scan to Pay card with order number and amount

Keep the customer's request visible on the admin side

Problem: After checkout, the store works with the order from the admin area, not the customer's screens.
Decision: The admin order detail shows the payment method, items, buyer details and order note in one view. A status dropdown under the order handles updates.
Why it matters: The engraving the customer typed reaches the store intact, and the admin updates the order from the same screen.

03. Final solution

One personalised order, followed from the product page to the store.

Place a personalised order

The shopper engraves a mug, checks the cart and pays with MoMo.

After checkout

The order reaches the admin with the engraving in its note, and the shopper can follow delivery.

04. Outcome

Our team delivered wireframes, high-fidelity mockups and a coded website (Angular, NodeJS, MongoDB) for both the customer site and the admin area. It was submitted with the course report in November 2024, with favourites, reviews and promotions left for later.

what I learned

The design came from the team's business goals and a competitor review, and no shoppers tested it. I would start by checking whether shoppers find Customize and can describe what they want with text and an image alone.