Skip to main content
Product Design Engineer

I design
clear
products
for complex
work.

Choose a signal, then move directly into the corresponding project.
View Tho8
Projects
About
Contact
Resume

THE PRACTICE

I turn research, system constraints, and edge cases into clear flows, interfaces, and product decisions.

ABOUT

I came to design through computer science, drawn less to the code itself than to the people, decisions, and systems behind it.

PROCESS NOTES

University of Michigan capstone knowledge graph focused on a selected note and its surrounding connections
THO8 · RESEARCH TO INTERACTION
Designing context into a knowledge graph

Six interviews and two testing rounds shaped graph focus, explainable links, and recovery paths for ideas people could not recall by title.

Current dark Lumen SaaS reference with a logistics workspace, KPI row, shipment table, activity feed, command search, and primary shipment action
LUMEN · ONE VISUAL LANGUAGE
Turning a brand language into a product system

A shared visual foundation made product, marketing, mobile, and operator tools feel like one coherent experience.

Warp Tracking shipment journey with current state and next action

OpenFreeMap© OpenMapTilesData from OpenStreetMap

WARP TRACKING · STATE CLARITY
Making shipment status feel obvious

Complex rules become clear when the interface shows priorities, ownership, and the next useful action.

WORKING PRINCIPLES

What does the decision need to clarify?
Start with user context, operating constraints, edge cases, and the outcome the interface must make clear.
How is scope constrained?
Focus on the workflow with the highest risk, the states users must distinguish, and what the current phase can genuinely resolve.
How does the design hold together?
Carry the rationale into flows, states, and component rules so important decisions survive from concept through delivery.
Which states must the system explain?
The system must explain loading, empty, success, warning, conflict, failure, and recovery states, along with the priority rule when more than one state is true.
What has been tested?
State whether the learning comes from concept evaluation, moderated testing, handoff, review, or live use. Those are not interchangeable.
How is impact described?
Describe what changed, who was involved, and where the learning came from. Product reach stays separate from individual contribution.