This case study is password-protected. Reach out and I'm happy to share access!

My Contribution

What I accomplished during my 3 month internship

1. Owned end-to-end

   Claude Design → Figma hi-fi

   Started with Claude Design mockups to get a rough MVP on screen fast, then rebuilt them into real Figma hi-fi so the team had something concrete to build from.

2. Collaborated

   Requirements into real product logic

   Worked with PMs and engineering to reshape those early screens against the FRD. We clarified gaps like ordered vs. received quantities and missing shipment or exception states until the designs matched how operators would actually use the product.

3. Deal contribution

   Partnership-ready MVP

   Compiled the final hi-fi into a product brochure presented to a prospective partner. That presentation helped secure a $10M partnership. The design created real business value before production code shipped.

Design Process

How the work actually moved

The internship moved fast. We worked from real requirements toward a deal-ready MVP, not a classic research → synthesis → ideation → iteration loop.

1. 01

   Understand the problem and the value

   Got up to speed on SuppliFlex’s value: one source of truth for SMB operators syncing inventory across Shopify, QuickBooks, Excel, and warehouses. Design decisions started from the real ops problem and what the product needed to prove, not a blank canvas.

2. 02

   Start fast with AI-powered design tools

   Used Claude Design to generate early product mockups. It was a quick way to get a rough MVP on screen and open the conversation with the team.

3. 03

   Rebuild for real operators

   Worked with PMs and engineering to reshape those screens into Figma hi-fi grounded in how operators would actually use the product, matching the FRD and closing gaps a first pass always leaves behind.

4. 04

   Pressure-test every requirement

   Went through FRD/PRD requirements line by line with PMs and engineers, catching ambiguities early, like ordered vs. received quantities or missing shipment and exception states, until the designs held up to real product logic, not just visual polish.

5. 05

   Make the MVP deal-ready

   Compiled the final hi-fi into a product brochure presented to a prospective partner. That representation of the MVP helped secure a $10M partnership before production code shipped.

My Work

Hi-fi screens, FRD-driven features, and the partnership brochure

These are the high-fidelity screens I designed for the MVP. The features were shaped around how operators actually work and what the FRD required. At the end is the partnership brochure that pulled it all together for the deal.

Part 01

Core Ops Dashboard

Operators had no single screen that summarized the health of the whole operation. Key numbers like total inventory, warehouses, and recent activity weren’t shown, and the dashboard displayed metrics that didn’t help with daily decisions.

• Top-level summary metrics Total SKUs, Total Units, and Total Warehouses, each with a short trend (“+12 added this week”) so the numbers have context, not just raw totals.
• Inventory movement panel Units received, sold, and adjusted over the past 7 days, with trends visible at a glance instead of requiring a separate report.
• Morning Briefing Surfaces only what needs action that day (open exceptions, late orders, at-risk items) instead of making operators scan the whole dashboard for what’s urgent.
• Recent Exceptions on the homepage Color-coded feed so critical issues are visible immediately without navigating to a separate page.
• Channel health ≠ sync health Split into two panels, sales channel connectivity vs. inventory sync accuracy, because they’re different problems operators need to reason about separately.
• Quick Actions Links straight to the relevant task (resolve exceptions, review orders, sync channels), so the dashboard is a starting point for work, not just a summary to read.

Part 02

Inbound Shipment Tracking (ASN)

No structured way to track shipments between PO placement and arrival. Suppliers shared details informally, with no logged carrier, tracking, or shipped-quantity data.

Shipment list Record ASN

• Ordered vs. Shipped, structurally clear Ordered is read-only from the PO. Shipped is the only editable field, which answers the FRD’s question about shipped-vs-ordered clarity.
• Inline discrepancy detection Real-time amber highlight plus plain-language warnings (“SKU-3113 is short by 20 units vs the PO”) before submit.
• Row-level Record ASN Action stays tied to a specific shipment, with no extra top-of-page CTA competing for attention.
• Visible side effects + shared language Delivery-date note surfaces the PO update behavior, and status labels stay consistent with PO language (Created / In Transit / Received) on purpose.

Part 03

PO Lifecycle & Receiving

Operators needed a strict forward-only PO pipeline (and safe cancellation), plus a structured way to record received vs. ordered quantities with a clear discrepancy trail when shipments arrived.

PO Management Receive PO

• Visual status pipeline Created → Confirmed → In Transit → Received on every row, so the current stage is obvious without opening the record (EN-186).
• Primary vs. destructive weight Forward actions use a filled gradient CTA. Cancel stays outlined and lighter, so it’s available but hard to trigger by accident.
• Distinct Cancelled state Red badge with an empty pipeline, visually separate from Received, so a cancelled PO never looks like it progressed through the flow.
• One receive model + discrepancy banner Reused Ordered / Received columns from ASN, with a plain-language under/over warning and warehouse as read-only header context.

Part 04

Proactive ETA / Delay Alerts

Late POs were only discovered after they missed delivery. There was no early warning, and no way to tell “about to be late” from “already late.”

Active alerts Empty state

• Urgency tiers, not a flat list Grouped Late / In Transit / Not Shipped with counts and color weight that scales with real risk (red / amber / gray).
• Scannable alert cards Each card shows PO ID, supplier, expected date, days overdue/out, and affected SKUs inline, enough to act without opening another page first.
• Deliberate empty state “All purchase orders are on track,” so a quiet screen means the system is working, not broken or unconfigured.
• Configurable warning windows Admin-set day thresholds for Not Shipped and In Transit, with helper text that states exactly when each alert fires.

Takeaways

What I’ll carry forward

• Cross-functional collaboration as the actual job

  Every design decision ran through PMs and engineers before it was final. When something was ambiguous, like where a feature should live or whether an action should change system state, I asked directly instead of guessing. I stayed open to being corrected by the people who knew the data and the user best.

• Using AI tools to move faster without skipping rigor

  AI-generated mockups and tools like Claude Design got a rough shape on screen fast, freeing up time for what actually mattered: checking every screen against real requirements and edge cases. AI was great for first drafts and layout, but it still needed a person catching data mismatches and gaps it missed.

• Treating requirements as a checklist, not just a starting prompt

  Early designs sometimes technically met a requirement but missed its intent. For example, a warning that only caught one type of discrepancy when the spec called for both. That pushed me to build reusable patterns once they worked, and reuse them consistently instead of solving the same problem differently each time.

• Designing without shipped code still has to stay technically honest

  Since this MVP was headed into a pitch deck, not straight to engineering, it was tempting to design the "ideal" version without checking feasibility. I learned to keep designs grounded in what the real system could actually support.