# Khang Hy Product Designer & Builder working across AgriTech, childcare apps, mobility, B2B SaaS, e-commerce, PropTech, industrial. ## I design complex systems and ship products from rough briefs. I define the business rules, craft the UX/UI, and direct AI workflows to take 0→1 products to production. - 7 products designed - 3 live products you can open today - 3+ years, solo or as the sole designer - 60h DStore, from brief to handoff ## Who I work with - Founders shipping an MVP: Product thinking and a frontend build in one loop. - Teams on workflow heavy products: Where clarity and operator confidence matter more than trends. ## Seven products, in domains that rarely overlap. - [A fashion store with admin and VietQR checkout, built by one person in 60 hours.](https://studio.khanghy.work/work/dstore): DStore needed a storefront, an inventory admin and lookbook content on a startup budget. I designed it, wrote the spec and directed an AI-assisted build from brief to handoff. - [A ride-hailing MVP for Cambodia, across rider, driver and admin.](https://studio.khanghy.work/work/btaxi): I owned the design, the product logic and the build: directing two contract developers, external QC and an AI agent in Cursor, and checking every build against the business rules I wrote. - [An operator interface for a wafer grinding machine, where one wrong screen state can destroy a wafer.](https://studio.khanghy.work/work/semiconductor-hmi): I joined three years into development, with no brief and no UX docs. As the sole designer among about 30 people across three vendors, I turned years of hardware logic into an interface operators can trust and frontend teams can build. - [An internal tool, redesigned into a SaaS clients can set up themselves.](https://studio.khanghy.work/work/feedbackme): Every new client used to need a developer editing the database by hand. As the sole designer, I redesigned the configuration system, the admin and the onboarding, so basic setup now starts from one spreadsheet upload. ## Rules before screens. My build has no code layer to quietly absorb a vague spec, so the spec has to be tight. That is where I spend the first days of every project. 01. Understand the product and its limits: Most briefs arrive with missing context. I map the roles, flows and edge cases, and write the business rules down before anything is drawn. 02. Structure first, polish second: Flow, hierarchy and reusable patterns come before visual detail, so the design system holds up when the product grows. 03. Direct the build, check every screen: I direct the AI agents and developers who write the code, and QA each screen against the rules we agreed on. You see progress in a weekly Loom. ## Pick what you need. See the price as you go. Starting prices, no retainers. Every change updates the total on the right, so there are no surprises on the call. ### 0 → 1 · Build an MVP - UX Audit: $200 (3–5 days). Recorded Loom walkthrough, written UX issues and prioritized fixes. - Website Design & Build: $600 (1–2 weeks). Landing or small site: Figma design + Next.js build, deployed. - AI Workflow: Contact (Scoped after call). Map the workflow, design an AI-assisted flow, simple automation setup. - Product Core: $1,900 (3–4 weeks). Rules-first definition, core flows in Figma, working Next.js build. - Full Product: $3,500 (3–4 weeks). Everything in Product Core, plus more roles, deeper system and polish. - CMS setup (Extra): +$350. So your marketing team can edit content. - Payment gateway (Extra): +$600. Stripe or a local provider. - Standard: 3–4 weeks. Quality uncompromised. - Rush: +$700. 7–10 days. Drop everything else. Included: - Rules-first product definition - Core flows designed in Figma - Working Next.js build (main user journey) - Basic design system / components - Deployed + handover (Supabase, PayOS when needed) Standard timeline 3–4 weeks. Included (Website Design & Build): - High-fidelity design in Figma - Next.js build, deployed (Supabase when needed) - Responsive layout - Basic SEO meta - Handover docs Included (AI Workflow): - Current workflow mapped - AI-assisted flow designed (rules, prompts; Zero-UI when it fits) - Simple automation or agent setup - Handover docs ### 1 → N · Fix a live product - UX audit: Quoted. A review of the full experience, with the gaps ranked by impact on the users you are losing. - UI system refactor: Quoted. Restructure the UI into a consistent design system and fix the UX gaps, without rebuilding everything. - Design-to-frontend: Quoted. Designs turned into working Next.js and React through an AI-assisted build I direct and review, ready for your backend. Quoted after a short audit call. Starting estimate, not a quote. Written proposal within 48 hours. ## Send me the messy version. No commitment. Here is exactly what happens after you reach out. 1. Send your brief: Message or email me, or book a call and bring the messy version. 2. 30-minute call: We go through the idea, the users and the must-haves. 3. Proposal in 48 hours: A written scope, price and timeline. 4. Build starts: After a 50% deposit, with a Loom update every week. Not a fit? The deposit is refunded. - Email: hyntk.work@gmail.com --- ## DStore: A fashion store with admin and VietQR checkout, built by one person in 60 hours. URL: https://studio.khanghy.work/work/dstore - Role: Design, spec, build direction - Industry: Fashion, e-commerce - Team: Just me - Timeline: 60 working hours - Delivered: Storefront, admin, checkout - Stack: Next.js, Supabase, PayOS - Status: Live, catalog pending - How did I help: Product design, Brand & UI, Spec & business rules, AI-directed build, QA ### Small budget, full store. A founder with products to sell, a small budget and no team. DStore needed a storefront, an inventory admin and lookbook content, and all of it had to fit the budget. ### Sell the local way, from day one. - Fit storefront and admin into a tight budget, cutting everything that wasn't needed to sell. - Let the client make lookbook images in-house, with no money for photoshoots. - Take payment the way shoppers in Vietnam pay: PayOS and VietQR. ### Spec first, then the build. I write down the flows, screens and business rules before anything gets built. That document is the spec the AI agents build against, and I write the rules they follow so their output matches the spec, the design and the business logic. Then I test every screen and flow against the spec. What fails goes back into the pipeline, gets rebuilt and is tested again until it passes. Only then does the build go to the client for acceptance. 1. Docs: Flows, screens and business rules, written first. 2. Build pipeline: The AI agent pipeline that turns the spec into a build. 3. Agent rules: Rules that keep agent output on spec. 4. Test: Every screen and flow against the spec. 5. Rebuild & test: What fails loops back until it passes. 6. Acceptance: Handover for review and sign-off. ### The decisions that mattered. 1. A custom build, not a platform. The client owns the data and can shape the store freely, with no platform subscription and no per-order platform fee. The cost: 60 hours up front, and the store needs its own upkeep. Until the catalog launches it runs on the free Vercel and Supabase tiers, so the client pays $0 a month; a weekly scheduled job keeps the free database from pausing. Hosting moves to a paid plan once orders start. 2. Six admin screens, not a full back office. A full admin would not fit a 60-hour budget. Six screens cover the core inventory tasks the client needs day to day. 3. Local payment from day one. Checkout runs on PayOS and VietQR, the way shoppers in Vietnam expect to pay. 4. Lookbooks without a photoshoot. A Figma Weave AI workflow turns one product photo into lookbook images, so the client makes new content without booking a shoot. ### What the store costs to run - Plan: Shopify Basic $25 a month, or $19 a month paid yearly; Haravan Omni Pro 680,000 VND a month (promotion; listed at 1,000,000 VND); DStore $0 a month on the free Vercel and Supabase tiers until orders start - Fee on each order: Shopify Basic 2%: Shopify Payments isn't offered in Vietnam, so PayOS counts as a third-party provider; Haravan Omni Pro None listed; DStore None - Who owns the store: Shopify Basic It runs on Shopify; Haravan Omni Pro It runs on Haravan; DStore The client owns the code and the data ### Rules in the code, not in a manual. A small shop has no one to catch mistakes by hand, so the store does it. Each rule was written in the spec first, then built and tested against it. - Pick a colour, see that colour: Rule: Every colour has its own photos, so tapping a colour dot swaps the main picture. A size that is sold out stays on the page, crossed out, and can't go in the cart. My part: The rule and the page, and the admin that groups photos by colour. - A changed cart can't check out: Rule: The cart is kept on the shopper's phone, so a product can go off sale after it was added. The cart greys it out with a red line, keeps it, and locks payment until the shopper removes it. The server checks again before it creates a payment link. My part: The rule, written so nothing leaves a cart without the shopper seeing why. - Prices come from the database: Rule: The browser sends only products, sizes and quantities. The server reads each price from the database, adds 30,000 VND shipping below 1,000,000 VND (free above), and keeps the price paid on every line. Two ways to pay: Cash on delivery, or PayOS by QR or bank transfer. A cash order goes straight to Processing. - Orders only move forward: Rule: Awaiting payment, Processing, Shipping, Completed: one step at a time, never back. Only an order awaiting payment or in processing can be cancelled. Automatic: A PayOS order moves to Processing when the payment webhook arrives. One still unpaid after 30 minutes is cancelled by a scheduled job. - Every size in every colour: Rule: Colours come from a fixed list, so the data stays clean; sizes are typed as tags. The admin builds every size and colour pair, each with an on/off switch. Photos: Up to 1 MB each, uploaded per colour and dragged into order. On save they go to every variant of that colour. ### Live, catalog pending. The store is live at dstore.studio. The catalog is still waiting on the client's licensing: I checked the tech constraints, not the legal ones. ### Code can't fix compliance. So I check it before the first screen. On DStore I checked the tech constraints and not the legal ones. The store is live, but the catalog is still waiting on the client's licensing. Now these questions come first on every e-commerce build. - Is the business registered for e-commerce with the Ministry of Industry and Trade? - Can the product sourcing pass an IP check? - Can checkout legally take payments on launch day? --- ## Btaxi: A ride-hailing MVP for Cambodia, across rider, driver and admin. URL: https://studio.khanghy.work/work/btaxi End-to-end build · Mobility · Cambodia · Client UAT passed · launch on hold on the client's side I designed it and I built it: I wrote the spec and the business rules, ran the AI agent in Cursor that writes the code, worked with two contract developers and external QC, and shipped only what passed my tests. App screens from my Figma file, admin screens from the live build, all shown in English with demo names, places and prices. Map data © OpenStreetMap contributors. - Role: Product designer & builder - Team: Me + an AI agent, 2 contract devs, external QC - Surfaces: Android, iOS, admin web - Year: 2026 - Status: Built, launch on hold ### One market. Three apps. Local constraints. The product had to work for locals, expats and tourists at the same time, on a startup budget. - Three apps that must stay in sync: Rider, driver and admin all have to agree, or riders stop trusting the system. - No budget for custom infrastructure: So I reused an existing ride-booking and GPS platform, and spent design time on the parts that needed local thinking. - The payment people expect isn't available: ABA Bank integration wasn't legally possible at MVP stage, even though it's how most people expect to pay in Cambodia. ### Rules first, screens second. Each of these started as a rule in the spec, then became the screen that makes the rule obvious. - A coupon comes off the base fare: Rule: The discount applies to the base fare of the vehicle the rider picks, and the fare is fixed before booking. My part: The rule, and the rows that show the base fare crossed out once a code applies, so the rider sees what the coupon saved. - Tuk-tuk first: A tuk-tuk, a 4-seat sedan and a 7-seat SUV, each with a fixed price shown before booking. The tuk-tuk comes first, with its own icon, so the product reads as Cambodian, not a clone. My part: The vehicle line-up and the local tuk-tuk icon. - Admins approve every top-up: Options: In-app ABA Bank payment, automated transfer checks, or manual approval by an admin. Why this: Bank integration wasn't legally possible at MVP stage, and automated checks would have grown the scope before the MVP proved itself. Manual approval works without the bank. Cost: Top-ups aren't instant. Admins have up to 4 hours to approve, and drivers are told this up front. - A referral is a phone number: Rule: A new driver types the inviter's phone number. The inviter is rewarded only after the new driver finishes a first ride, so fake accounts earn nothing. My part: The rule, the optional sign-up step, and the admin list used to settle referrals each month. ### No bank integration? Design a deposit flow admins can trust. A semi-automated deposit with manual admin approval, so drivers can top up before a bank integration is legally possible. - Expected: in-app bank payment (Not legally possible at MVP stage.): Driver: Tops up through ABA Bank in the app → Bank: Confirms instantly → Result: Balance topped up - Built: bank transfer with approval (Working payment flow without the legal blocker.): Driver: Requests a top-up in the app → Driver: Transfers to the Btaxi account, with their phone number in the note → Admin: Matches the transfer and approves on the web, within 4 hours → Result: Balance topped up ### Inside the two apps. Book a ride, ride it, drive it, and top up the driver's wallet. - Book a tuk-tuk with a coupon: Pick a destination, choose a vehicle at a fixed price, add a coupon, book. My part: The booking path, the ride options and the coupon sheet. - From finding a driver to rating them: Each trip state has one clear message, and the fare at the end shows the coupon as its own line. My part: The trip states, the payment summary and the rating. - One button per step: Drivers work with one hand on a budget Android phone, so every step of a trip is a single large button at the bottom. My part: The offer, the eight trip steps and the cash confirmation. - Top up by bank transfer: The driver picks an amount, copies the account, transfers with their phone number in the note, and waits for an admin. My part: The wallet, the transfer details and the pending state. ### One admin behind both apps. Top-ups, drivers, rides, fares and coupons are run from one web admin. Captured from the live build, shown in English with demo data. - Approve a driver's top-up: Every bank transfer a driver reports waits here, with the amount and the time, until an admin approves or rejects it. My part: The approval queue, its tabs and the totals above it. - Approve new drivers: Every driver with their rides and a status: approved, waiting for review, or locked. My part: The driver list and its statuses. - Every ride in one list: Rider, driver, ride type, fare and status for every booking, with search, filters and export. My part: The ride list and its status labels. - What needs attention first: Drivers online, rides in progress, money approved and the top-ups still waiting, on the first screen an admin sees. My part: The dashboard cards and the top-up queue on it. - Fares per ride type: Each ride type has its seats, a minimum fare, a distance included and a price for every 100 m after that. My part: The service table that sets the prices the rider app shows. - Coupons with limits: Each code has a discount, a cap on users and the dates it is valid. BTAXI50 is the code used in the rider app. My part: The coupon list and its form. ### I build with an AI agent. I don't hand-write the code. I write the spec and the rules, the agent writes each change, and nothing ships until it passes my tests. 1. Spec: I define what gets built: the screens, flows and states for all three apps. 2. Business rules: Pricing, payments and permissions written down as rules the build has to follow. 3. Build with the agent: An AI agent in Cursor writes each change and opens a pull request. The contract devs build against the same spec. 4. Agent-assisted QA: I test each build against my rules, with an AI agent helping to check behaviour. 5. Fix: Anything that breaks the spec goes back with the correct logic written out. 6. Ship: A backend developer merges it, it deploys to staging on its own, and a smoke test checks it. ### Three months, written down. Counted from my Notion logs, July to October 2026. - 130: updates done across the rider app, the driver app and the backend - 13: blocking bugs fixed in the backend - 52/54: test cases passing, the other 2 not applicable - 6: languages for push messages ### A coupon that replaced the fare. Because I owned the pricing rules, I could see the build breaking them, write out the correct logic and get it fixed before handoff. - Build as delivered (What the spec did not allow.): Input: Base fare → Bug: Coupon overwrites the base fare → Output: Wrong final price - After the fix, per the rule (What the pricing rule says.): Input: Base fare → Rule: Coupon applied to the base fare → Output: Correct final price ### Three bugs, traced to where they started. When a ride failed, the ticket only closed once the cause was found, the data was repaired and a fresh test passed. - Booking failed halfway (Fixed · smoke test passed): Symptom: Riders were told no drivers were available, even with drivers online. Root cause: Booking saved the order, then called a live-update service that had been deleted, and broke. Each failure left a driver stuck as busy. Fix: The backend now carries on when that service fails, and 6 stuck records were repaired. Proof: A smoke test on staging passed. - New drivers got no rides (Fixed · real booking accepted): Symptom: New drivers were approved and online, but riders never saw them. Root cause: 34 drivers had no ride type set, so matching left them out. Fix: Repaired to 0 drivers without a ride type. Proof: A new test driver accepted a real booking. - Cancel during a trip (Fixed · smoke test passed): Symptom: A rider could cancel a ride already under way. Root cause: The backend never checked the ride's status before a cancel. Fix: The backend refuses a cancel once the driver has accepted, and still allows it while the ride is waiting. Proof: On staging, a cancel after accept is refused and a cancel while waiting goes through. ### When the happy path breaks. - A wrong verification code: A wrong code turns every box red and offers Resend, instead of a message the rider has to read. My part: The error state of the code entry. - A coupon that doesn't apply: An invalid code says so at the top and leaves the base fares as they were. My part: The error message and the unchanged price rows. - Ask why, in one tap: Cancelling asks for one reason from a short list, with Go back as the bigger button. My part: The cancel sheet and its reasons. - A top-up waiting for an admin: Until an admin approves it, the request shows as Pending at the top of the history, with the wait time above. My part: The pending state and the history labels. - A new driver's first day: Offline with no rides, the home still shows earnings and balance, and says there are no rides yet. My part: The empty state of the driver home. ### The spec is the product. The devs and the AI agent only build what I actually write down. When I wrote the logic tightly, the build came back clean. When I left a rule a little fuzzy, QA is where it came back to bite me. So writing the rules is the real work, not the warm-up. - Invest selectively: Reusing infrastructure freed design time for the parts that build local trust. - Script is a technical problem: Khmer support meant testing layout and rendering on budget Android, not just translating. - Admin risk is product risk: The biggest blocker wasn't design or code. It was paperwork: the Apple Developer account and the business licence the SMS sender needs. ### A multi-app MVP, scoped piece by piece. Three connected apps are priced by what each one needs. Pick the pieces, and I send a written proposal within 48 hours of our call. --- ## Semiconductor HMI: An operator interface for a wafer grinding machine, where one wrong screen state can destroy a wafer. URL: https://studio.khanghy.work/work/semiconductor-hmi Design & system work · Semiconductor · NDA I joined three years into development, with no brief and no UX docs. As the sole designer among about 30 people across three vendors, I turned years of hardware logic into an interface operators can trust and frontend teams can build. NDA project. Every interface shown here is an illustration, not the product's real UI. No real machine data or client IP is shown. - Role: Sole designer, in the front-end team - Team: ~30 people, 3 vendors - Joined: Year 3 of the project - Validation: Passed hardware validation - Status: Closed: development paused after the client changed its business strategy ### Three years of hardware logic, and no brief. The machine already worked. My job was to make the screen match it exactly. - No brief, no UX docs: Everything had to be reverse-engineered from Confluence pages, sensor layouts and backend status codes. - Zero tolerance for error: A wrong state on screen can waste a wafer and time on very expensive equipment. - Multi-vendor: Hardware from a Japanese manufacturer; software split across three Vietnamese vendors under strict NDA. - No access to the machine: It sits in a cleanroom. I designed every machine state without touching it. ### From specs to screens - What I had: Confluence pages; Sensor layouts; Backend status codes - What I did: Found every machine state the screen must show; Designed how each state looks and behaves; Checked each one with hardware engineers - What came out: An interface operators can trust (Glove-sized controls and readable alarms); Specs frontend teams can build (Component states and data expectations) ### Nothing reached frontend without an engineer signing off. Under the NDA, hardware engineers were the experts every screen state was checked against. 1. Read the spec: Work through the specs to find every machine state the screen must show. 2. Propose the UI state: Design how that state looks and behaves on the operator screen. 3. Engineer review: Review it with hardware engineers. Nothing moves on without their sign-off. 4. Hand off to frontend: Pass the approved state to frontend with clear component states and data expectations. Rejected at step 3: back to step 2. Approved: on to step 4. Repeats for every state. ### Three calls for the cleanroom. - Glove-optimized UI: Problem: Operators wear cleanroom gloves, so standard tap targets are too small. Why this: The sizes came from the Japanese hardware team's reports on how operators use the machine day to day. Outcome: All touch targets scaled beyond 50px, with simpler layouts so operators hit the right control without hesitating. - Hierarchical alarms: Problem: Raw hardware codes are unreadable for operators. Why this: The hardware team defines every error; the front end only receives and shows it. Each error matters differently: some are minor, others affect a whole sequence. Outcome: Sensor signals turned into prioritized, readable alarms: what's wrong, how severe, and what to do next. - React-ready specs: Problem: Frontend teams couldn't guess how a machine state should look. Why this: The front end only shows the states the hardware sends, so developers needed every one defined up front. I gave them the full set of UI states to code from. Outcome: Documented component states and data expectations, so teams could wire machine logic to the UI without ambiguity. ### Start from the state diagram, not the documentation. I spent my first months reading specs front to back. Most of what I read early on never reached the screen. I should have mapped the machine states first and used that map to decide which specs mattered. Machine states: Loading → Aligning → Grinding → Rinsing → Unloading. Alarm: Any state can raise one. - Precision over creativity: In industrial HMI, familiarity and accuracy matter more than novel UI. - NDA is a design constraint: Without the real screens, the work has to come through in illustrations, reasoning and process. - Design as translation: The job was turning hardware constraints into operational safety. ### Bring the specs. I’ll find the interface in them. For hardware, data-heavy or multi-vendor products where the UI has to match the system exactly. --- ## FeedbackMe: An internal tool, redesigned into a SaaS clients can set up themselves. URL: https://studio.khanghy.work/work/feedbackme Design & system work · B2B SaaS Every new client used to need a developer editing the database by hand. As the sole designer, I redesigned the configuration system, the admin, the onboarding and the landing page, so basic setup now starts from one spreadsheet upload. - Role: Sole designer - Team: 2 mobile, 1 backend, 2 QC - Timeline: 12 months - Phase: 0 → 1, first release - Status: V1.0 launched ### Built for one team. Sold to many. FeedbackMe started as a tool for one internal environment. When it became a commercial SaaS, every new client's setup landed on the developers. If your product grew the same way, this may sound familiar. - Onboarding eats developer time: Each new client meant a developer changing data structures by hand, instead of building the product. - Clients can't shape it to their workflow: There was no configuration UI. Every client-specific need became a support ticket. - Flexible, but not breakable: The config had to fit very different client structures without breaking the shared infrastructure underneath. ### Logic before screens. A polished onboarding flow is useless if the configuration underneath is broken. So discovery mapped the data first. The PO and CEO owned the what and why; the team and I owned the how. 1. Logic mapping: Went through the legacy tool with the backend dev to decide which fields had to become dynamic, such as regions and locations. 2. Depth calibration: Agreed with the team how far clients can customise: their regions and locations, plus theme, logo and display labels, without breaking the shared system. 3. Feasibility sync: Reviewed the designs with engineering every Thursday, so every layout matched what the backend could actually do. ### What made it self-serve. - Excel-driven onboarding: Problem: Multi-day manual setup blocked new clients from getting started. Decided by: The PO chose Excel import, and I agreed: clients already keep this data in spreadsheets, so importing is faster than typing it in again. My part: The import flow. The backend dev and the BA defined the template and file format; I designed the upload, the error messages and the success state. Outcome: Clients upload their spreadsheet and it is translated into live data structures. Basic setup starts from a single upload. - A flexible config layer: Problem: Hardcoded fields couldn’t adapt to different client data models. Outcome: Clients set their own regions, locations, theme, logo and labels without developer help. - The public face of the SaaS: The marketing site for FeedbackMe as a commercial product: features, industry use cases, pricing tiers and a contact form, in Vietnamese, English and Japanese. - A design system for what comes next: Problem: Future modules needed a clean foundation to build on. Outcome: A design system handed off to the developers as the base for later modules. ### Beyond setup: the product flows. - Report an issue: Scan or search for the device, rate it with a face, then confirm before the feedback is sent. - Follow it to the end: The status from New to Confirmed, a history of who did what and when, and the details of each update, with a note and a photo. - Who does what: Each step lists the roles allowed to act on it; a process chains an action to the next one. - Scoring formulas: A formula is built from the criteria tree: each issue has a code and a weight factor. ### Next time, I'd watch a client's first upload before calling it done. The config logic held up in review with engineering and the PO. On the next 0 → 1, I would add one more check: sit with a client through their first upload, so self-serve is something we have seen, not only reasoned. - Logic dictates UX: The biggest decisions here were structural, not visual. - Autonomy is scalability: Every routine setup a client does alone frees dev time for the product. - Guardrails make it usable: Total freedom breaks the experience. Limits are what let it scale. ### Start with an audit, not a rebuild. For live products that are losing users or eating dev time. I audit the full experience, restructure the UI system and fix the gaps without rebuilding everything from scratch. --- ## Construction Tech Platform: One construction platform for five roles who each see the project differently. URL: https://studio.khanghy.work/work/construction-tech Design & system work · PropTech · Web Customers, architects and builders each look at a different part of the same house. As the only designer on a 7-person team, I turned the wireframes and specs I received into the final UI and flows, and checked them against the rules of the service, so all five roles work from one project record. Partial NDA: the client, the product's name and real project details are withheld. The screens are the real designs, in Japanese, with the brand mark and place names replaced. Some screens carry a tag. Rebuilt: the admin shipped from wireframes, so its screens are rebuilt in the product's final UI kit. Recreated: the final file wasn't archived, so the screen is recreated in the same kit. Added: the confirmation dialog on Disagree was added for this case. - Role: Sole UX/UI designer - Team: 7-person project team: 1 designer, 3 devs, 2 QC, 1 PM - Timeline: 13 months - Platform: Web (responsive, shipped as an app) - Status: Live since Sept 2025 · Tokyo area ### No layers of middlemen. One platform, one director. Custom homes usually pass through layers of middlemen: owners pay more, while architects and craftsmen work to tight deadlines for little. The platform connects them directly, with a director and an engineer in between, and every role sees the same project steps. - Director / Engineer: Partner portal. The director runs the project through all 13 steps: introduces real estate companies when the customer asks, proposes up to three architects and sends them the request to join, assigns the builders and completes the project once every member is done. The engineer supervises the site. - Customer: Customer portal. Asks for a free consultation and says whether they want a real estate introduction, asks the proposed architects for plans and decides on one, follows the project step by step, agrees or disagrees with the rough estimate and reads the progress posts. - Real estate company: Partner portal. Proposes land to customers who don't have any. The director introduces one or more companies only if the customer asked for an introduction; each accepts or declines, then sees the basic information and the chat. - Architect: Partner portal. One of up to three architects the director proposes; accepts or declines the request to join, sends the customer a first plan and, once the customer decides on them at step 7, moves on to the design contract, the design and the estimates. - Builder (Meister): Partner portal. Assigned by the director at step 9; contracts directly with the customer, without a middleman's margin, and posts progress updates with a title, text and a photo. Large home builders and materials suppliers also work with the company, but outside the platform, so they have no role here. ### The wireframes had gaps. I closed them. I worked from wireframes and specs handed to me. Where a wireframe disagreed with the rules of the service, I redesigned the final UI to follow the rules. - Check the wireframes: Read each wireframe against the written spec and flagged where the two disagreed or stopped short. - Design the final UI: Turned the customer and partner wireframes into finished screens, one flow per role, on the component set I extended. - Map where roles meet: Checked the rules where one role's action changes what another can do, like a disagreement that stops every later step. - Hand off directly to devs and QC: As the only designer, I handed off straight to the 3 devs and 2 QC, so questions came straight to me. ### When one role's action changes what another can do. Four rules from the spec. Two live in the internal admin. - When the customer disagrees: Disagreeing with the rough estimate means no contract, and every later step stops, so the customer confirms it first. Decided by: The spec: the red note on the screen is its own. My part: I designed the final screen from the wireframe. Its file wasn't archived, so it is recreated here, and the confirmation dialog was added for this case. - Finishing a project: The director's Complete button stays disabled until every member's status is Done. Decided by: The spec: the note above the button is its own. My part: I designed this screen too. It is recreated from the wireframe because its final file wasn't archived; the greyed-out button was added for this case. - When a director reaches their limit: The admin sets how many projects a director can take at once. At the limit, the director shows as Full. Directors can change their own limit, but not below the admin's value. Decided by: The spec. The admin was built last, straight from its wireframes. My part: None on the shipped admin; I didn't design it. I rebuilt these screens in the final UI kit for this case, to show the rule. - Sending an application back: The admin reviews each architect's application. Sending it back needs a reason: the dialog won't go through with the field empty. Decided by: The spec. The admin was built last, straight from its wireframes. My part: The admin isn't my design. I rebuilt this review and its dialog in the final UI kit, only to show the rule. ### What kept five roles on one system. - A starting screen for each role: Problem: Each role needs a different starting point in the same projects. Decided by: The spec: each role gets its own dashboard. My part: I designed the screens each role starts from, like the customer's project list and the architect's project details. Outcome: The customer starts from their project list, the architect from the details of the project they work on. - One project page for everyone: Problem: Each role works on a different part of the same project. Decided by: The spec: one project record that every role works from. My part: I designed the project page, with the step rail, the members, the contract files and the progress posts in one place. Outcome: The customer sees where the project stands, who is on it and what was posted, on the same record the partners update. - A reusable UI system: Problem: Five roles meant the same parts drawn many times. Starting point: The Japanese team built the first component set. My part: I extended it and reorganised it so the whole product shares one set. Outcome: One component set behind the customer and partner portals, for all five roles. - A join request partners can answer: Problem: In the wireframes, the request to join always came from the operator, and the director's version had no way to decline. My part: I named the director as the sender, put Decline next to Join, and designed the dialog after joining that says chat is now open. - Room for every builder: Problem: The wireframe had room for one builder, while the contracts table on the same page listed three builder contracts. My part: I changed it to a member grid that holds every builder, because from step 9 a project can have several. ### Inside the product. - Ask for a free consultation: The customer sends the free consultation form; updates then come in as messages on their My page. My part: The consultation form and the customer's My page. - Follow the build: On the project page, the customer opens a progress post to read it. My part: The project page and the dialog that opens each progress post. - Vet a new architect: The admin opens an architect's application, reads it through and approves it after a confirmation. My part: The admin isn't my design; these screens are rebuilt in the final UI kit for this case. - Join a project: At step 4, the director sends the request to join to the architects proposed to the customer. One tap on Join confirms it, and the customer is told who is in charge. My part: The request on the architect's project page, and the dialog that confirms they joined. - Talk in the project: Each project has its own chats, one tab away from its details. My part: The chat tab: the project's chats on the left, the open conversation on the right. - Follow a project on the phone: From My page, the customer opens a status notice, scrolls the project down to its progress posts and opens one. My part: I designed the responsive web that ships as the app, so the phone UI is the web UI at phone size. ### Validate with people on site, and measure the change. The team was my only feedback loop. It caught plenty of logic gaps, but edge cases were checked against what the team believed users did, not what they really did. Next time I'd test with people on site and measure the change after launch. - Different views, same project: The hard part was agreeing what is shared and what stays role-specific. - Five roles, five starting points: Each role needed its own entry point into the same data. - Fix contrast in the palette: The error red in the original palette didn't pass contrast. On the screens rebuilt for this case I used a darker red (#C4472F); next time I'd fix it in the palette itself. ### Find the gaps before your users do. For platforms where several roles share the same data and every missing state becomes a support ticket. --- ## Aotomatic: A shrimp farm diary where one day's entry went from 24 screens to 7. URL: https://studio.khanghy.work/work/aotomatic Design & system work · AgriTech · Aquaculture Aotomatic is Forte Biotech's app for shrimp farmers to log each pond, every day. The first version, built by another team, asked one question per screen. The client hired ARIS, the agency I work at, to redo it. As the only UX/UI designer, I grouped the questions into five forms, then designed the add-ons that followed in 2024 and 2026, including an AI chat. The screens are the real designs. The first version was built by another team, and its screens are labelled that way. Screens tagged Rebuilt are chat states put together for this case from parts of the real design. Place names, the address and personal details are removed or blurred, and two typos in the web admin are fixed. The demo readings were adjusted to realistic values, and antibiotics in the demo data were replaced with Vitamin C and a probiotic. - Role: Sole UX/UI designer - Team: 2023: 2 mobile, 2 web, 2 QC - Timeline: 2023, ~3 months · add-ons in 2024 and 2026 - Platform: Mobile app + web admin - Status: Live on the App Store and Google Play ### Where a day's entry lost time. - One reading per screen: Water quality alone asked 13 readings on 13 screens, plus a title screen. - A calendar, not the day: The pond page opened on a calendar. What had been logged that day wasn't on it. - Tests kept apart: Test results sat in a separate Testing area on the farm page, outside the daily entry. ### Group the questions by the job. I was the only UX/UI designer on the ARIS side, working with 2 mobile devs, 2 web devs and 2 QC. 1. Audit the first version: Went through every screen of the live app and listed each question it asked and where it led. 2. Group them into forms: Put the questions into the five forms a farmer fills in at the pond: nutrition, water quality, feeding tray (vó), medicine and RAPID test results. 3. Check with engineering: Checked low-fidelity flows with the mobile and web devs for feasibility before handoff. Considered and rejected: Keep one question per screen and restyle it. Faster to build, but one day's entry would still take 24 screens. ### Before and after. - Water quality in one form: Why: One form keeps every reading in view, so a missed field is easy to spot. My part: One water quality form with every reading in one scroll, and Next pinned at the bottom. - The day's entries on the pond page: Why: The day's entries are in view before you add another. My part: The pond page lists what was logged that day, by section and time, with Add an entry at the bottom. - Every pond's day at a glance: Why: A farm owner can see which ponds still need today's entry without opening each one. My part: A card per pond, with a tick for each section logged that day. Test results moved into the daily entry as the RAPID test form. - Setup in one form: Why: Every answer stays visible before Confirm, so a pond is set up in one pass. My part: Creating a pond is one form, from its photo to its feed brands and medicine. ### Inside the 2023 app. - Log one pond for one day: From the pond page: Add an entry, five forms in a row, then a confirm screen. Seven screens in all, against 24 in the first version. My part: The whole entry flow: the five forms and the confirm screen. - From a farm to one of its ponds: The farm list, a farm and its ponds, then the pond page with the day's entries. My part: The farm list, the farm page and the pond page. - Farms, ponds and revenue in the admin: The admin lists every farm and every pond, with each pond's condition, and a revenue table per pond: quantity, weight, price and yield. My part: The whole admin, including the side menu, the farm and pond tables and the revenue table. ### An AI chat. Photos and RAPID PLUS too. Add-ons the client asked for, shipped in 2026, inside the same design system. - A tab for the AI chat: Problem: The chat needed to be one tap away from any screen. Decided by: Forte Biotech (change request) My part: An AI tab between Statistics and Profile. - Ask with one tap: The chat gives farmers a place to ask about their own pond data, at any hour. It opens with suggested questions about the farm; one tap sends one, and the answer can be stopped on its way. Decided by: Forte Biotech (change request) My part: The suggested questions, so a new chat never opens on a blank screen. - Go back to a past chat: The menu opens Chat History, where past chats are named by topic and can be searched. Decided by: Forte Biotech (change request) My part: Chat History as a drawer, so the open chat stays in sight behind it. - Send a photo with the question: A sick shrimp is easier to show than to describe, so the chat takes photos. Decided by: Forte Biotech (change request) My part: The plus menu in the message box, so a photo goes out with the question. - Disease tests with a Ct value: RAPID is Forte Biotech's disease test. RAPID PLUS is the more advanced test, with the lab's Ct value: the lower it is, the more virus in the sample. In its tab, each disease is Positive, Negative or Not tested. Decided by: Forte Biotech (change request) My part: The Ct field, which appears only under a positive result. - The same results in the admin: Each pond's page in the web admin shows the RAPID PLUS results next to the day's other entries. Decided by: Forte Biotech (change request) My part: The RAPID Test Results Plus box, with each disease's result and Ct on one line. - Profit per farm and per pond: In the web admin, Profit lists each farm's revenue, operation cost and profit, then each pond's, with the cost split into nutrition, medicine, hatchlings, RAPID tests and other. Clicking a cost shows what it is made of. Decided by: Forte Biotech (change request) My part: Each cost opens its breakdown in place, so the table stays one row per pond. ### When something goes wrong. - When the connection drops: If the connection drops, the chat says so where the answer would appear, with a Retry button under the message. My part: The error message and its Retry button. - A Ct value outside the usual range: Type a Ct value outside the usual 10 to 40, like 45, and a hint appears under the field. Next still works, because a lab sheet can report an unusual value. My part: The hint under the field. - When the microphone fails: If voice input can't use the microphone, a red line under the message box says so. My part: The message box's error state. ### Put the five forms in front of farmers earlier. The forms held up in walkthroughs with QC and engineering. Next time I would test them with farmers at the pond before handoff. - Count the screens: Counting the screens for one real day's entry showed where the time went, before any visual change. - Add-ons on the same system: The 2024 and 2026 add-ons used the 2023 tokens and components, so the app still looks like one product. - Check the brand colour early: White text on the brand teal is about 3:1, under the 4.5:1 that small text needs. Next time I'd add a darker teal for buttons and text. ### Regroup the flow around the real task. For products where people push through too many steps. I audit the flow and regroup it around the job they came to do. --- ## Waku Navi: A play-ideas app for Japanese parents, and the admin that feeds it. URL: https://studio.khanghy.work/work/waku-navi Design & system work · Childcare · Japan Parents pick their child's age and get short play ideas: watch the video, save it, try it, rate it. As the only designer, I designed the mobile app and the web admin where the team writes every post. Real screens from my Figma file, in Japanese. Photos, names, sample posts and dates are demo content, replaced for this case. - Role: Sole designer - Team: 1 Flutter dev, 2 backend devs - Final UI: Dec 2024 – Feb 2025 - Platform: iOS, Android, web admin - Status: Shipped ### Scattered ideas, a hard deadline, a market abroad. The goal was simple: help young parents find play ideas their child is ready for. The inputs were not. - Scope creep: New requests kept arriving, and the deadline was the first thing at risk. - Designing from abroad: Designing from Vietnam for Japanese parents, so research had to work remotely. - A cultural gap: I had to read Japanese childcare habits and UI expectations without field research. ### Four moves, from research to scope. 1. AI-assisted research: Used AI to synthesise Japanese parenting culture, childcare app patterns and mobile UX expectations. 2. One path for parents: Pick the child's age, watch, save, try, rate. Every screen in the app serves one step of that path. 3. A structured admin: Posts, categories, age tags and review sets live in the admin, so the team adds content without a developer. 4. Scope negotiation: Pushed back on requests that would have cost the deadline, and kept the first release to that one path. ### Start from the child. Sign-up asks for the child's birthday, so the app can open on ideas for that age instead of one list for everyone. - Recommendations that start from the child: Why: A one-year-old and a four-year-old need different play, and tired parents won't set filters every time. My part: The banner that asks for a child, and the Recommend tab that opens with that child's ages already picked. - First the parent: Why: A list of 47 prefectures is hard to scan on a phone, so the area is picked region, then prefecture, then city. My part: The parent form, the three-step area picker and the birthday wheel. - Then the child: Why: The birthday is what the app needs to suggest ideas for the right age, so it sits in the same short form as the name. My part: The child form and the list of children. ### Inside the mobile app. Watch, save, rate, search by age and sort saved ideas into folders. - From the grid to the steps: A card opens the video full screen; 詳しく見る (see details) opens the materials and the steps. My part: The two-column grid with age chips, the video screen with its save rail, and the detail page. - Rate it in three sliders: Three questions, each a slider between two faces, then an optional photo and note that other parents can read. My part: The slider sheet, the experience-report sheet and the shared experiences list. - Search inside the child's ages: Results keep the child's ages selected, so a search never shows ideas the child isn't ready for. My part: The search screen with recent searches, and the results grid under the age chips. - Sort saved ideas into folders: Parents save ideas by situation, like a rainy day, and come back to them when it happens. My part: Select mode, the folder picker, the create-folder sheet with its character count, and the folder page. ### The content system behind the app. A small admin laid out like a blog editor: posts, categories, age tags and review sets, at desktop, tablet and phone width. - One editor for everything a post needs: Video, carousel, text, category, age tags, related tags, a review set and a download, with the publish date on the side. My part: The two-column editor: content on the left, publishing and sorting on the right. - Edit many posts at once: Ticked posts open an edit panel inside the table: category, tags and status for all of them at once. My part: The posts table and the inline bulk edit panel. - Categories with a colour: Categories nest under a parent and carry a colour, so a group of ideas reads as one. My part: The category list, the add and edit dialog, and the colour picker. - Ages as tags: The ages in the app's chips are tags here, so the team manages the age bands in one place. My part: The tag list and its add dialog. - The questions parents answer: A post picks a review set in the editor; the sets and their questions are written here. My part: The review set list and the question builder. - The admin at three widths: Every admin screen was designed at 1440, 768 and 375 wide. My part: The three layouts of every admin screen. ### When there's nothing, or too much. - Say which field is wrong: A failed login outlines the email field in red and says 不正なアカウント (invalid account) right under it. My part: The error state of the login form. - An empty Saved tab: Before anything is saved, the tab says what it is for instead of showing a blank list. My part: The empty state. - A folder with nothing in it: An empty folder offers the next step, コンテンツを追加する (add ideas), where the list would be. My part: The empty folder state and its button. - Delete one with a swipe: One idea goes with a swipe, the way lists work elsewhere on the phone. My part: The swipe action on saved ideas. - Confirm before deleting many: Deleting several at once asks first and says it can't be undone. My part: The confirmation sheet. ### Plausible is not verified. AI research got me to a plausible read of Japanese parenting UX. Whether those patterns fit how Japanese parents actually behave is something I still can't answer. On a foreign market next time, I'd budget for a handful of remote sessions with real parents before launch. - AI as a research partner: Useful for closing cultural gaps quickly. - Design is negotiation: Half the job was saying no to protect the timeline. - The admin is product too: A content app is only as good as the screens the team writes it in. ### Find the first release inside them. For founders with a clear goal and a growing list of requests. I shape the first release, design the app and the admin behind it, and hand off a system devs can build from. --- ## I started with design. Then I learned to build the system around it. URL: https://studio.khanghy.work/about I'm a product designer and builder in Ho Chi Minh City. I take products from a rough brief to shipped: I own the design, define the product logic and business rules, and direct an AI-assisted build. I don't write the code myself. I direct the agents and developers who do, and check every screen against the rules. Most of my work comes from outsourcing, in domains that rarely overlap: semiconductor HMI under NDA, a Japanese childcare app, a five-role construction platform, aquaculture, ride-hailing, B2B SaaS and e-commerce. Most of it shipped under tight constraints, so I validate every decision with the team, and with domain experts and the client's own team when the project allows. ### When the problem is complex, multi-role, or hard to hand off. - Rules before screens: My build has no code layer to quietly absorb a vague spec. So I write the flows, roles and business rules down first. It is the real work, not the warm-up. - Working inside real constraints: NDAs, tight budgets, markets I design for from abroad, projects joined three years in. I check every step with the engineers, and with domain experts when the project allows. - One person across the loop: Product thinking, design and build direction in one loop, so less gets lost between hand-offs. ### Three years, seven products. UX/UI designer at ARIS Vietnam since May 2023, alongside independent builds. Tap a year. - 2023, ARIS Vietnam · from May 2023: Getting grounded in regulated, data-heavy work. First project: an aquaculture platform. Learned to design for data-heavy field workflows fast, and redesigned a 24-screen daily entry into 7 screens. - 2024, ARIS Vietnam: Three product contexts at once. Designed a Japanese short-video childcare app as the sole designer, and a feedback tool that became a self-serve SaaS, while the aquaculture work continued. - 2025, ARIS Vietnam: Five roles, then a machine. A long-form construction platform with five stakeholder roles. Late in the year, onboarded to a semiconductor HMI: the hardest context switch so far, from workflow UI to an industrial machine interface. - 2026, ARIS Vietnam + independent: Precision work, and building end to end. Operator interfaces for a wafer grinding machine, where a wrong screen state wastes expensive equipment time. Alongside it, an independent ride-hailing MVP for Cambodia, built through an AI-directed pipeline. - Solo, Independent: Brief to deployed, on my own. End-to-end builds for my own clients: I design, write the spec and business rules, direct the AI-assisted build and QA it. DStore went from brief to handoff in about 60 working hours. ### Design core Figma, FigJam, Figma Weave, Design tokens, Auto layout ### Builder stack Next.js, Supabase, PayOS, Cursor AI I direct the build and QA it against the spec. The agents and developers write the code. ### Certificates - Google UX Design Professional Certificate - MindX UI/UX Design Certificate ### I have a project Tell me what you're building. You'll get a written proposal within 48 hours of a 30-minute call.