hello
it’s Tung

A product designer with a curious mind and a playful spirit. At Connext, I design ERP software for groups of companies, for the moments when things don’t go to plan.

Explore my work

Selected work

ConnextBulk approval for a multi-company ERP, from rules to a checked buildProduct design - 2026 to present Spendable balanceShowing what’s really spendable, after checkout proved out of reachTeam concept - 2026 Household billsEvery share of a household bill, linked to the rule behind itConcept with a developer - 2025

Further explorations

Headset recoveryDesigning recovery for a headset that drops mid-callSolo concept - 2026 Student requestsSeparating sending a request from accepting itSolo concept - 2026

A bit about me

I studied Finance in Hanoi and FinTech in London before moving into product design. Today, I design software at Connext and explore other ideas through side projects.

A little more about me

Tung Do standing by Gullfoss waterfall in Iceland, wearing a dark winter jacket and beanie

A little curiosity goes a long way.

I’ve always liked seeing where a new idea might lead. In design, that means exploring what technology makes possible, while holding onto the qualities that made me love digital experiences in the first place.

I’m drawn to things with character. A sense of familiarity, an unexpected detail, a little room to play. I bring that same sensibility to my work, with a fondness for expressive interfaces and the careful structure behind them.

My path into product design took me through Finance in Hanoi and FinTech in London. Today, I’m at Connext, designing tools for everyday work.

Get in touch View resume

A few things you’ll notice in my work

Structure first.

Interfaces feel lighter once the logic is sorted. In Household bills, everyone can see how their share was worked out.

See the project

Calm when it’s busy.

At Connext, batch results show managers what went through and what still needs a look.

See the Connext work

Playable prototypes.

For Headset recovery, a live prototype replays a device dropping out, so you can feel the recovery mid-call.

See the prototype

Where I’m working

Mar 2026 to present
Product Designer
Connext - Remote / Hanoi
Designing ERP software for groups of companies, from the business rules to the finished, built interface.
Selected work at Connext Education and full history

Pixels to plates

When I’m not pushing pixels in Figma, I’m out enjoying experiences designed by wonderful restaurants. Because great design isn’t just on screens, it’s on plates too.

Open the photo collection

Shared table with Korean dishes and drinks

Dishes and drinks spread across a restaurant table

Hot pot ingredients arranged for sharing

Shared meal with greens, soup and condiments

Lunch plate with an egg and small dishes

Tung Do

Product Designer - London, UK

doxuantung3501@gmail.com linkedin.com/in/dooxtungRight to work in the UKEnglish and Vietnamese

Save as PDF

Experience

Mar 2026 to present
Product Designer
Connext - Remote / Hanoi
Designing ERP software for groups of companies, with a Design Lead, business analyst, product owner and engineers.
Selected work at Connext

Selected projects

Aug to Oct 2026
Student requests
Solo concept - service mapping and product design
Jun to Jul 2026
Headset recovery
Solo concept - event-replay prototype built with Claude Code
Mar to May 2026
Spendable balance
UX Designer and Team Lead - four-person concept team
Sep to Nov 2025
Household bills
Product design and responsive interface prototype - with one developer

Education

Sep 2023 to May 2025
MSc FinTech
Coventry University London - Distinction
Sep 2019 to Jun 2023
BSc Finance
National Economics University - Distinction

Design learning

UX Foundation Certification - 2026
Google UX Design Specialization, Coursera - 2025
UI Design Certification, Capi Demy - 2022

Designing bulk approval for the requests that don’t go through

The business analyst set the approval rules and sketched the main path. I designed how it works, and what managers see when part of a batch fails.

Role: Product Designer
Team: Design Lead, business analyst, product owner, engineers
Time: Mar 2026 to present
Status: Production work under NDA. Screens reconstructed with illustrative data

Bulk approval result in Connext: the banner 8 approved, 2 need review lifted out of the Requests list, with Mai L.’s row (Updated during review, Review latest version) and Alex N.’s row (Permission changed, View details) lifted beside it. Reconstructed with illustrative data.

My part

Designed how bulk approval works on screen, from the confirmation step to the batch result.
Designed every state a stopped request can be in, and what each one lets the manager do next.
Handed it to engineering in enough detail to build, then checked the build.

Scope

The business analyst and product owner own the approval rules.

Requirement

The spec set the rules and sketched the main path

Managers approve leave, overtime, attendance corrections, shift changes and any other request type a company sets up. Each step has a deadline. Once an attendance period locks, a late approval only reaches pay in the next payroll, so a request that quietly doesn’t go through can leave someone waiting a month.

The spec let managers select 1 to 20 requests on the current page, each rechecked on approval. Its wireframe ended with “Action complete”.

Business analyst’s wireframe, reconstructed in greyscale: the All tab with Action complete above the list, Mai L. and Alex N. still selected and still Pending, and a bar reading 10 selected with Approve and Decline. Markers 1 to 3 sit beside the message, the status column and the bar. — It covered the main path, which is its job, but left these three questions once two of ten stopped.

Flow

I designed the whole flow, not just the result screen

Bulk approval stays in the first list managers see. I renamed its tab from All to Pending, because it only ever holds requests waiting for them. A confirmation step comes first, because approving many at once is high-stakes.

Flow from the Pending tab: select 1 to 20, confirm, batch result with 8 approved and 2 stopped, then four branches. Edited during the batch leads to Review latest version, Permission changed leads to View details, a date outside the adjustment window stays on the row as its reason, and Couldn’t approve leads to Try again. All end on the same list with the selection cleared, drawn as the blue return path. — Edited and permission-changed requests get their own branch, and a connection error offers Try again. A request in a locked period is still approved inside the adjustment window, and the change lands in the next open period. Only a date older than that stops, with its reason on the row.

Decision

I separated the batch result from each row’s status

The banner only counts. Each stopped row carries its own reason and the one action that still makes sense.

Final Requests list after the same batch, same frame as the wireframe: the banner 8 approved, 2 need review, Mai L. marked Updated during review with Review latest version, and Alex N. marked Permission changed with View details. Markers 1 to 3 sit beside the banner, Mai’s status and the next action. — Same frame and data as the wireframe above.

Trade-off

I kept partial results instead of stopping the whole batch

Once a request can stop mid-batch, the rest of the batch needs a rule.

Not taken
Stop the whole batch
Safe, but one edited shift holds up eight valid approvals.
Not taken
Show a count only
Leaves the manager to hunt for the two that stopped.
Chosen
Keep each row’s result
Approve what passes, and keep the two that stopped in the list.

Recovery

Every stopped row says why, and leads on when it can

Besides a lost connection, which only needs Try again, a request can stop for three reasons. For each, I decided what the row shows and where it leads.

An edited request can still be approved after review, so its row opens the latest version. A request that’s no longer yours to approve can’t go through, so it links to details instead. A date in a locked period, past its adjustment window, can’t be fixed in this flow, so its row only explains why. The steps follow the first case, with Mai’s edited request.

Open the latest version from the row.
Compare the old and new times, then decide.
Back on the same list, with Alex’s row still in place.

Four row states cropped at the same scale: Processing (Approving, 4 of 10 done), Edited during the batch (Updated during review, Review latest version), Permission changed (No longer yours to approve, View details) and Error (Couldn’t approve, connection lost, Try again). — Each state shows what happened, and the next step when there is one.

Patterns

One rule for anything that can partly fail: show the item, its state and the next valid action together

I applied it to two other flows in the product, so engineering builds the pattern once.

The same rule in three modules: 1, a stopped bulk-approval row with its reason and action. 2, an import conflict for Quan N.’s check-in on 4 May, Keep existing 09:00 or Use file value 09:15, or Leave unresolved. 3, a locked April attendance period, where a fix for 28 April becomes an adjustment request paid in the May payroll.

Measures

How I’d know it works

I can’t test with users here, but the system already tracks what would tell us. Next time, I’d write these into the ticket from the start.

Once we agreed this design, the business analyst added it to the BRD as an acceptance criterion: a manager can tell which requests didn’t go through, why and what to do next, without opening any.

Signal	Good sign
Overdue requests	Fewer when an attendance period locks
Late approvals	Fewer paid in the next payroll
Stopped rows	Dealt with in the same session

Delivery

Engineering got every state in writing, and I checked the build

The confirmation step catches the manager’s own mistakes. It can’t stop a request changing afterwards, so the result screen does the other half.

The spec now documents this design. One rule is still open with the business analyst and product owner: partial results only hold if requests in a batch don’t depend on each other.

Handoff excerpt, reconstructed: a row state table listing each state, its reason on the row and its one action, behaviour notes for after the batch, and a Given, When, Then example for a request edited mid-batch. — I checked the build against this table, state by state.

Appendix: shared patterns

Table, form and feedback guidance

Written with our Design Lead and used across HR and admin.

Pattern	Rule	In practice
Table	Keep the row identifiable	Sticky name column, aligned numbers
Form	Keep valid work when something fails	Error at the field, input kept
Feedback	Name the object and the next step	“2 requests need review”, linked

Next project

Spendable balance

From a manager’s batch of requests to one person’s spending decision.

Read the case study

All work About me Back to top

Explaining every share of a household bill

Sam moved into a four-person house halfway through November, so an equal split of the £120 electricity bill would charge him £30. In this concept, built with one developer, every share stays linked to the rule the household agreed.

Role: Product design and responsive prototype
Team: One designer and one developer
Time: Sep to Nov 2025, part-time
Status: Concept and prototype built with Claude Code, no payments or bank connection

Sam’s £17.14 share on a phone in front of the household’s November cycle table on a laptop. His row lifts out of the table as a paper slip, linked to the rule Split by days in the house. Labelled Concept, made-up housemates.

My part

Shaped the billing model with the developer, from agreed rules to monthly cycles.
Designed the mobile share view, its explanation and the partial-payment flow.
Built the responsive cycle view with Claude Code, on top of the developer’s calculation module.

Scope

The developer built the calculation module, and payments, accounts and storage were out of scope.

Problem

A total in the group chat didn’t say which rule it used

Bills look simple until the household changes: a bigger room, someone away, a new housemate mid-month. The total in the group chat doesn’t say which of those were counted.

The bill payer needed a record they could explain without reopening the same conversation, and everyone else needed to see where their share came from.

Detail	A total on its own	A share linked to a rule
Event	Sam moves in on 16 Nov	Sam moves in on 16 Nov
Rule	Not recorded	Split by days in the house
Amount	£30.00 each	Sam £17.14, 15 of 105 person-days

Only the second says which rule produced the amount. The problem comes from my own time in a shared house in the UK, and the housemates here are made up.

Decision

I attached one agreed rule to each bill and each cycle

I compared three models. An expense ledger, like most splitting apps, records each amount but not the rule behind it. Automatic collection needed payment infrastructure we couldn’t build. A household agreement with monthly cycles answered the question from the problem, where each share comes from, so every bill links to the rule that made it.

Changing the rule needs everyone to confirm, and it only applies from the next cycle. A settled month never recalculates, so its explanation stays true.

Agreement model for November electricity: the agreed rule, days in the house, applies to the cycle and makes each share. A proposed room weighting reaches December only once agreed, and November stays as settled. — A new agreement changes the next cycle and leaves the last one as it was.

Calculation

Real numbers showed a problem the mockup hid

My mockups showed tidy shares. On the real calculation module, rounding each share separately added up to £120.01.

We take the extra penny off the bill payer’s share, because they need the shares to match the real bill.

Person	Days	Rounded share	Adjustment	Final share
Alex, payer	30	£34.29	−£0.01	£34.28
Linh	30	£34.29	£0.00	£34.29
Jo	30	£34.29	£0.00	£34.29
Sam	15	£17.14	£0.00	£17.14
Total	105	£120.01	−£0.01	£120.00

Someone away uses the same rule, with fewer days in the house. Room weights and meter readings are separate rules.

Explanation

I put the explanation right under the amount

Most visits start with one question: how much do I still owe? So the amount comes first and the calculation one step deeper, close enough to check if something looks wrong.

Sam’s electricity share: £17.14 remaining, unpaid, due 12 Dec, split by days in the house, his 15 of 105 person-days, with a link to the calculation. Callouts 1 to 3. — The explanation names the currency and the period, so it still makes sense read aloud.

How this was calculated: bill £120.00 times your 15 days divided by everyone’s 105 days equals your share, £17.14. Alex’s row shows the −£0.01 rounding. — The explanation names the currency and the period, so it still makes sense read aloud.

Payments

A partial payment stays attached to one person’s share

A partial payment stays against one person in one cycle, or the bill payer ends up doing the subtraction again.

Reminders became drafts the bill payer reviews before sending, so the app never speaks for a housemate or treats a delay like debt collection.

November cycle ledger: share, received, remaining and last payment for each housemate. Jo’s row is marked: £20.00 of £34.29 received, £14.29 remaining. £31.43 remaining in total. — Jo has paid £20.00 of £34.29, so £14.29 stays on her row and nowhere else.

Result

The calculation runs, and the four shares add up to the bill

The cycle view runs on the developer’s calculation module, so every amount on screen comes from the agreed rule.

Check	Value	Result
Four shares	£120.00	Match the bill
Rounding	£0.01	Taken off Alex’s share
Sam’s days	15 of 105	From his move-in date

Next, I’d check whether people can explain a mid-cycle share, log a partial payment against the right share, and tell a future rule change from a past cycle. The first bar is that most people explain Sam’s share on their own.

The original runs on the developer’s calculation module. This version is rebuilt for the page with the same rule and numbers. No payments or bank connection.

Next project

Headset recovery

Another plan that changes halfway: a headset that drops mid-call.

Read the case study

All work About me Back to top

Helping people see what’s really spendable, before the urge to buy

Young people in their first jobs told us payday feels like plenty, and by mid-month the money is gone. In a four-person course project, I led the scope and structure of our answer: a breakdown where the biggest number is what’s really left to spend.

Role: UX Designer and team lead
Team: Four people, shared research
Time: Mar to May 2026, course project
Status: Concept, not tested with users. Illustrative data, not affiliated with Timo

The 5,000,000₫ spending estimate lifted straight out of the May breakdown on a phone, with balance, commitments and goals floating either side. Labelled Concept, not affiliated with Timo.

My part

Led the scope and information structure for the team.
Designed the editable commitments and the purchase preview.
Built the prototype the team reviewed, using Claude Code.

Scope

Research was shared with Huyen, Thu and Khiem, and we chose the new direction together. The concept has no link to Timo or to real accounts.

Research

Unplanned spending was the hardest job to deal with

We interviewed 12 students and young workers in Hanoi and Ho Chi Minh City. Trouble came right after payday, or when something tempted them.

Spotting unplanned spending wasn’t frequent, but of the jobs 6 or more people raised, it was the hardest. Sometimes impulse won, like a family gift that beat the budget. Sometimes the warning came too late. So we focused on the moment the impulse wins.

“At the start of the month there’s money, so I spend freely. By mid-month I open the bank app and wonder where it went.”

Duong, 23, a persona built from the interviews.

Jobs 6 or more people raised, scored for frequency and difficulty. Spotting unplanned spending, highlighted, is the hardest at 3.3 of 5. — Spotting unplanned spending is the hardest at 3.3 of 5, yet only 2.5 for frequency.

Four interviewees had already built their own spendable number by hand. Each method broke somewhere once spending started.

What they did	Where it broke
Kept a separate account for spending	Limit set by feel, topped up by hand
Split pay in their head on payday	Nothing kept the split once spending started
Filled savings jars by feel	Only noticed overspending when a jar was nearly empty
Moved fixed percentages out, spent the rest	Couldn’t tell where the rest went

Our audit of Timo, MoMo and Money Lover found all three show spending only after it happens. Two cities show patterns, not the whole country.

Root causes

The loop starts on payday, not at checkout

Duong’s month is a loop that restarts every payday. Asking why at each pain point left two root causes.

The balance makes bills due later feel lighter than they are. At the moment of buying, the joy is vivid and the cost isn’t. Our first concept answered both.

Root cause 1
Payday feels like plenty
A high balance, so she spends freely.
Tempted while scrolling
Feeds and livestreams to unwind.
Root cause 2
Talks herself into it
The balance looks big, so no budget check.
Pays in a few taps
Happy now, regretful when it arrives.
Notices too late
Mid-month, she can’t recall where it went.
Cuts back, then plans again
Borrows until payday, then tries a new app.
Gives up
A few days later, and payday restarts it.

Root cause 1

The total balance hides money that already has a job

Rent and bills are due later, so they weigh less than the balance.
Present bias makes the number on screen feel like the whole story.

70% in Vietnam would rather enjoy money now than worry about the future (UOB, 2025).

How might we show, right after payday, what’s really left to spend?

Root cause 2

At the moment of buying, only the upside is visible

Feeds make the want vivid, and digital payment removes the pain of paying.
The joy fades fast, and the next want restarts the loop.

91% in Vietnam say social media ads influence what they buy (PwC, 2024).

How might we show what a purchase trades away, and still leave room for the feeling?

Pivot

We kept the goal, but changed where, when and how we step in

Future Self Fund locked away money for upcoming bills on payday, showed what was really spendable, and added a checkpoint that paused checkout before Buy now. A feasibility review ruled out both the lock and the checkpoint. Interviews made us doubt the checkpoint too, since people talk themselves into purchases once they want something.

So we kept the part that needed neither, a new number to anchor on, and put it where the bank app already reaches people.

Layer	Can	Can’t
Phone OS	See when an app opens	See inside a shopping app
Open Banking	Read the balance, move money	Stop a payment
Shopping apps	Nothing we could rely on	Partner, since they earn from orders

Future Self Fund’s checkpoint right before Buy now, marked as the dropped concept. — The first concept, dropped after the feasibility review.

Same month, two rows: where Future Self Fund stepped in and where the final direction does.

We lost a direct answer at checkout, since the preview only works if someone opens it. That’s a bet, and the first thing I’d test.

Decision

The biggest number is what’s spendable, not the balance

The balance caused the first root cause, so the estimate is read first. A bank can’t change the balance it shows, so the real balance stays visible, just not first.

We built on Timo’s jars, which most Vietnamese banking apps don’t have. The estimate only shows money and never moves it, so people keep control.

Commitments

A forgotten commitment gets added inside the breakdown

Leaving to add something forgotten breaks the decision in progress, so Duong adds the wedding gift she promised a friend right in the breakdown.

Spot what’s missing.
Add it in place.
See what changed, then carry on.

Preview

The preview is for purchases people already hesitate over

Going ahead stays a normal action, and the preview never calls a purchase good or bad.

Purchase preview for May: 1,200,000₫, with the plan at 4,250,000₫ before and 3,050,000₫ after. — A preview of the plan, not an approval.

States

The estimate also has to say what it doesn’t know

Fixing one missing commitment doesn’t make the number certain. Each unknown gets its own wording and next step.

Four estimate states cropped at the same scale: amount missing, never entered, stale balance, changed commitment. — Never a warning colour on its own.

Open

What’s still open

Do people trust the estimate? Does seeing it earlier change what they buy later in the month? And how does this meet the emotional need Future Self Fund set out to handle?

First test: after the breakdown, ask how much they can spend until next payday. It passes if most people, say 4 of 5, answer with the estimate and can say why. Then give them a purchase and see who opens the preview unprompted.

Appendix: AI explanation

AI explanation of the estimate

I also explored an AI explanation beside the breakdown, using the same model. It flags a missing commitment or an old balance and points to the input to check. It stays out of the main story because the prototype doesn’t yet show a question the breakdown fails to answer.

Built with Claude Code. No bank connection or money movement.

Next project

Household bills

From one person’s money to a household that shares it.

Read the case study

All work About me Back to top

Keeping a call going when the headset drops

A small menu bar concept for switching a desk between focus, calls and presentations. It’s an example of designing states and recovery with a playable prototype, replaying what happens when a headset drops mid-call.

Role: Product design and a prototype built with Claude Code
Team: Solo project
Time: Jun to Jul 2026, part-time
Status: Event-replay prototype, no hardware control

Press play. When the headset drops, switch to laptop speakers. Opening sound settings is only simulated, and the whole thing is a browser replay, not a hardware integration.

My part

Designed the ring panel, the change preview, device states and recovery.
Worked out the layout in wireframe drafts, changing one decision per draft.
Built a browser prototype with Claude Code that replays device events, including interruptions.

Scope

This is a solo concept, and nothing in it controls real hardware. Device names are real products, used as examples.

Drafts

Four drafts took the device list off the panel

A dropped headset gets lost in a list of rows, so I moved the state onto a ring where the failure is one red segment. Each draft changed one decision, and the panel went from 940 px to 408 px.

Not taken
Names beside the ring
Readable at a glance, but each name competes with the failure.
Chosen
Names in the popup
Less to read during a failure, but the device in use is one step away.

Hover to read a name isn’t drawn yet, and only a test can settle this.

Decision

The preview shows what will change before the mode is on

I kept the device, what it supports, the mode and the result of each attempt apart, so a Call label can’t look successful when only the audio switched.

Call preview in the panel. The display says Call not on yet, Focus still on. Two changes are listed, Bose QuietComfort Ultra Headphones from MacBook Pro Speakers, not connected, and Logitech BRIO from FaceTime HD Camera, ready. The button reads Apply 2 changes, Mic and display stay as they are, with Cancel below. — Readiness is shown before the attempt and results after it, so a ready device is never counted as changed.

Recovery

Switching audio and opening settings are separate actions

Switching to laptop speakers and opening sound settings are different actions, so they stay separate instead of one Retry. The display then waits for macOS before it says the output changed.

The headset drops, and the panel offers two separate actions.
While it switches, the display says what it’s waiting for.
Once macOS confirms, the panel says where the sound goes now.

Proposed copy for the speaker option, which warns that people nearby may hear the call.

Edge cases

The warning that affects the call keeps the button

When the headset and the camera fail together, only the headset turns red, because it’s the one breaking the call right now. At a larger text size the panel grows instead of shrinking the text, and long device names wrap inside the popup.

Two warnings at once. The Headset segment is red with Headset disconnected in the display, the Camera icon is crossed out, and the button still offers Switch to laptop speakers. — The camera is crossed out, while the red segment and the button stay with the headset.

The same dropped headset at a larger text size. The whole panel is taller and wider, and every label is whole. — The dropped headset at a larger text size, at the same scale as the panel above.

Appendix: segment states and presentation assets

Segment states

State	Shows	Offers
Connected	A green dot, and the pointer on the device in use	Change, from the popup
Working	A spinner, and what the display is waiting for	Nothing, to avoid a duplicate
Needs attention	A red segment, and what broke in the display	The relevant recovery
Not supported	Manual control only, on the device card	The right external control
Unavailable	A crossed-out icon, and why on the device card	The reason stays visible

Light and dark

The dropped headset panel twice, side by side, in dark mode and in light mode. — The panel follows the system setting. Every state was drawn in both modes.

Presentation assets

I also made a landing page and store-style images for the concept. They’re presentation assets, not evidence of a released app.

Next project

Student requests

Following a request through the handoffs between university offices.

Read the case study

All work About me Back to top

Tracking a student request across offices

A student request can move between several offices while its status still says “processing”. This independent concept follows one exam-remark request, SR-1048, through those handoffs and links what the student sees to the staff action that makes each update true.

Role: Service mapping and product design
Team: Solo project
Time: Aug to Oct 2026, part-time
Status: Independent concept, no university commission or live integration

SR-1048 from both sides: the department’s queue card with Accept transfer lifted out of a laptop, beside the student’s tracker lifted out of a phone, their two Department review lines level on one line. Labelled Concept, made-up university.

My part

Mapped how an exam-remark request moves across the offices involved.
Designed the shared case model, the student tracker and the document checklist.
Designed the office queue so handling a case updates the student view.

Scope

The university would own the policies the concept depends on, including who accepts each handoff.

Decision

I separated sending a request from accepting it

SR-1048 sat in the department, unaccepted, while its status said “processing”. In the proposed workflow, a transfer stays visible to the sending office until the receiving office accepts it.

I had no access to a real university’s process, so the current steps are an assumed baseline.

Student tracker for SR-1048: stage 3 of 4, Department review, held by the Mathematics department, accepted 21 Sep at 10:42. Usually next, the marker reviews the script. No action needed. Last confirmed update 21 Sep at 10:42. Callouts 1 to 4. — “No action needed” is a status, not the absence of a button.

Returned case cropped to the one item: supporting evidence needs a new file, the Exams office’s note that page 2 of the letter is missing, the current file and Replace file. — A returned case names the one document to fix.

Office side

One staff action updates what the student sees

A timeline is only useful if the office keeps it accurate, so accepting SR-1048 is the same action that moves the student’s tracker.

The department accepts SR-1048.
The student sees the confirmed stage.

Before any of this is built, the university would need to settle who owns each handoff, whether a processing time is a commitment, and which steps can stay online.

Next project

Connext

The production work behind my interest in states and handoffs.

Read the case study

All work About me Back to top

There’s nothing here.

The page may have moved. You can return to the work and find your way from there.

Back to the work

helloit’s Tung

Selected work (C:)

Further explorations (D:)

A bit about me

A little curiosity goes a long way.

A few things you’ll notice in my work

Structure first.

Calm when it’s busy.

Playable prototypes.

Where I’m working

Product Designer

Pixels to plates

Tung Do

Experience

Product Designer

Selected projects

Student requests

Headset recovery

Spendable balance

Household bills

Education

MSc FinTech

BSc Finance

Design learning

Designing bulk approval for the requests that don’t go through

The spec set the rules and sketched the main path

I designed the whole flow, not just the result screen

I separated the batch result from each row’s status

I kept partial results instead of stopping the whole batch

Stop the whole batch

Show a count only

Keep each row’s result

Every stopped row says why, and leads on when it can

One rule for anything that can partly fail: show the item, its state and the next valid action together

How I’d know it works

Engineering got every state in writing, and I checked the build

Table, form and feedback guidance

Spendable balance

Explaining every share of a household bill

A total in the group chat didn’t say which rule it used

I attached one agreed rule to each bill and each cycle

Real numbers showed a problem the mockup hid

I put the explanation right under the amount

A partial payment stays attached to one person’s share

The calculation runs, and the four shares add up to the bill

Headset recovery

Helping people see what’s really spendable, before the urge to buy

Unplanned spending was the hardest job to deal with

The loop starts on payday, not at checkout

The total balance hides money that already has a job

At the moment of buying, only the upside is visible

We kept the goal, but changed where, when and how we step in

The biggest number is what’s spendable, not the balance

A forgotten commitment gets added inside the breakdown

The preview is for purchases people already hesitate over

The estimate also has to say what it doesn’t know

What’s still open

AI explanation of the estimate

Household bills

Keeping a call going when the headset drops

Four drafts took the device list off the panel

Names beside the ring

Names in the popup

The preview shows what will change before the mode is on

Switching audio and opening settings are separate actions

The warning that affects the call keeps the button

Segment states

Light and dark

Presentation assets

Student requests

Tracking a student request across offices

I separated sending a request from accepting it

One staff action updates what the student sees

Connext

There’s nothing here.

hello
it’s Tung

Selected work

Further explorations