XiwenPRODUCT DESIGNER
UIUXVisual
LinkedIn ↗Resume
← UI/UX Work
PRODUCT DESIGN / INTERNAL OPERATIONS

JKD Project
Workspace.

From being the bridge.
To building the connection.

At JKD Brands, I coordinated packaging projects across design, sourcing, sales, accounting and overseas factories. Progress depended on the context I carried between them.

I designed a shared workspace and guided its implementation, connecting project status, ownership and decision evidence so each handoff has a clear next step.

Workflow designB2B collaborationEnd-to-end product
Explore the case study ↓
JKD Brands — packaging & design
One project.
Shared context.
A clear next step.
JKD PROJECT WORKSPACE
Dashboard preview · Scroll within the screen
DESIGN · SOURCING · PRODUCTION · DELIVERY
PROJECT ROLEProduct Designer · End-to-End Project Owner
Design & Production Manager at JKD Brands
END-TO-END OWNERSHIPProduct definition · Workflow & UX/UI design · Implementation direction · Functional validation · Iteration & release
STATUSInternal test release, Sep 2026
Impact not yet measured
ACT I The operational problem
01 / OVERVIEW

A shared record for
the next person to act.

I turned the coordination gaps I encountered as a Design & Production Manager into a workspace for packaging projects—from the initial brief to delivery.

THE CHALLENGE

Context lived across channels.

Long-running projects relied on one coordinator to reconnect requirements, prices, approvals and next steps.

THE RESPONSE

Make every handoff explicit.

Connect the current revision, responsible people and supporting evidence within one project record.

THE DELIVERY

A working web application.

Three service routes share four lifecycle stages. Released for internal testing in September 2026.

MY CONTRIBUTION

From product definition
through release.

I defined the product, designed the experience, and guided AI-assisted implementation from concept to release.

Product & design
Problem framing, workflow mapping, requirements, information architecture, UX/UI and access rules.
Implementation & validation
Translating designs into functional requirements, guiding implementation, validating key workflows and interface behavior, iterating and deploying.
Application stack
Python · SQLite · JavaScript · CSS

Designed for design, sourcing, sales, accounting, management and factory partners. These are the workspace’s operational roles. I led product design and delivery independently. Operational impact has not yet been measured.

02 / THE PROBLEM

Project continuity depended
on personal follow-up.

I carried requirements, quotations, invoice requests, production files and shipping updates between teams. The project could span months; its context was distributed across WeChat, LINE, email, Teams and a shared spreadsheet.

BEFORE / PERSON-DEPENDENT CONTEXT
DesignFactoriesManagement
Me / coordinatorRecall · relay · remind
AccountingSales

Every handoff required me to reconstruct and relay the project context.

DESIGN INTENT / SHARED CONTEXT
DesignFactoriesManagement
Shared project recordOwner · next action · evidence
AccountingSales

The next person can find the action, owner and evidence in the project record.

Coordination model · The coordinator remains responsible for coordination; the record preserves context between handoffs.
01

Unclear next action

A message could communicate a request without making responsibility explicit.

02

Uncertain current version

Artwork, specifications and quotations could refer to different revisions.

03

Incomplete decision evidence

An invoice could be issued while payment was still awaiting verification.

04

Fragmented factory communication

Factories used different communication channels and inconsistent project records. Quotations were often missed or linked to the wrong project.

Why existing tools did not fit this workflow

Constraints from my evaluation for JKD’s workflow and budget.

Tool evaluatedConstraint in this workflow
Shared ExcelManual maintenance became difficult across long project cycles and repeated revisions.
HubSpotFunctional coverage was sufficient, but the annual subscription cost was not sustainable for the business.
Free Trello and Jira plansFree plans did not fit the complete sequence of design, pricing approval, invoicing, production and delivery.

DESIGN DIRECTIONMove the project context into a shared record, with a clear owner for every next action.

ACT II From workflow requirements to product decisions
03 / WORKFLOW → REQUIREMENTS

Map the work.
Then define the product rules.

I mapped activities, responsible roles and required outputs from my day-to-day coordination work before designing the interface.

01 / OPERATIONAL WORKFLOW

Three phases, connected by a concrete output.

  1. 01

    Intake & planning

    Consultation → initial quote → follow-up

    HANDOFF OUTPUTComplete project brief
  2. 02

    Design & approval

    Design ⇄ feedback & revision → approval

    HANDOFF OUTPUTApproved revision
  3. 03

    Production & delivery

    Final quote → deposit → production → delivery

    HANDOFF OUTPUTProduction & delivery records
02 / TRANSLATING OBSERVATIONS INTO DESIGN

Each requirement leads to a specific product response.

01 / OWNERSHIP

Requests lacked a clear next owner.

Design requirement

Separate the action owner from the reviewer.

Product responseTask-based handoffs
02 / EVIDENCE

Invoice issuance did not establish receipt of funds.

Design requirement

Record billing and payment as distinct events.

Product responseIndependent financial records
03 / VERSION

A previous approval could be mistaken for a current one.

Design requirement

Link each decision to the revision it approves.

Product responseRevision-specific approvals
04 / ACCESS

Shared context included commercially sensitive pricing.

Design requirement

Match information access to operational responsibility.

Product responseRole-based quotation views
04 / SHOWCASE

Three routes.
One consistent project structure.

A shared lifecycle makes projects recognizable. Route-specific requirements determine the work needed at each stage.

LIFECYCLE / SELECT A PROJECT ROUTE3 routes · 4 shared stages

The complete service route—from design deposit through production and delivery.

  1. 01

    Design deposit

    Invoice issuance and payment verification tracked separately.

  2. 02

    Requirements & quote

    Design, specifications and client pricing tied to the current revision.

  3. 03A

    Production & delivery

    Review readiness, then track production, dispatch and receipt.

  4. 04

    Completed

    Review settlement and unresolved issues; retain project history.

New revision → return to requirements. Previous decisions remain in history; the current revision requires its own approval.

INFORMATION ARCHITECTURE

One record connects the work.

FIND

Workspace views

Dashboard · Projects
Workflow board · My tasks

UNDERSTAND

Project record

Scope · Owner · Current revision
Next action

ACT

Connected evidence

Quotes · Approvals · Finance
Files · Delivery · Updates

INTERFACE EVIDENCE

Status, responsibility and next action in one record

  1. 01
    Current stage

    The lifecycle places the project in Invoice & production.

  2. 02
    Current owner

    The responsibilities panel identifies Kelly as the person acting next.

  3. 03
    Next action + owner

    The next step pairs the action with its owner: Kelly reviews the production checkpoint and confirms dispatch readiness.

KEY DESIGN DECISIONS

Four rules that make
the handoff actionable.

Ownership identifies who acts. Evidence establishes what is ready. Revisions identify which decision applies. Access determines who can see it.

01 / OWNERSHIPWho acts and who reviews?Distinct responsibilities02 / EVIDENCEWhat is invoiced or received?Independent financial events03 / VERSIONWhich approval applies?Revision-specific decisions04 / ACCESSWho can see it?Responsibility-based access
01 / OWNERSHIP

Separate doing the work
from reviewing it.

Context

The person completing an action is not always the specialist responsible for the next review. Accounting verifies payment; the designer reviews the factory proof.

Decision

Assign the action owner and reviewer separately, so both participate directly in the handoff.

Trade-off

Two explicit assignments require more setup, but avoid making one person responsible for relaying the work to another specialist.

HANDOFF MODEL
01

Action owner

Completes the assigned action

Shared task + evidence

Owner · reviewer · due date · result

02

Reviewer

Reviews the submitted result

Responsibilities are assigned to the action and review required at that stage.

CONSIDEREDOne combined responsibility

One contact still needs to coordinate with the other specialist.

SELECTEDSeparate owner + reviewer

Each specialist is involved directly in the system.

INTERFACE EVIDENCE

An actionable task, with a named owner and due date

  1. 01
    Specific action

    The task names the deliverable: review and send the design deposit invoice.

  2. 02
    Visible accountability

    The task list displays the owner and due date alongside its status.

  3. 03
    Recorded result

    The approved scope task retains its result: specifications attached.

02 / EVIDENCE

Distinguish billing progress
from verified payment.

Context

Client payment arrangements and schedules vary. A single financial status obscures what has been invoiced and what has actually been received.

Decision

Keep invoice issuance and payment verification as separate records, each available for internal tracking and follow-up.

Trade-off

Two records need to be maintained and linked. In return, the team can track flexible payment schedules without treating an invoice as proof of payment.

TWO RECORDS / DISTINCT MEANINGS

Invoice issued

The payment request has been sent.

Enables requirements coordination

Payment verified

Receipt of funds has been confirmed.

Enables paid design work
Issued ≠ received

Accounting tracks both events independently.

See the production readiness review below ↓
PRODUCTION READINESS / BOTH CONDITIONS REQUIRED

Bring financial and design evidence together.

The confirmation action becomes available only after both conditions are met.

01

50% down payment received

At least half of the project payment has been received and recorded.

Accounting
02

Latest factory proof approved

The latest proof version has an approved review status.

Designer
Production release reviewBoth conditions met → confirm entry into production
INTERFACE DESIGN / PRODUCTION & DELIVERY

Clear conditions for entering production

  1. 01
    Invoice & payment

    Add the invoice first, then record the 50% down payment and full payment separately.

  2. 02
    Purchase order

    The record stays empty until the order reference, factory, quantity and issue date are added.

  3. 03
    Factory proof

    Add a proof to begin its version and review history. The latest proof must be approved before production.

  4. 04
    Shipping & tracking

    Add the carrier, tracking number and delivery dates when shipping is arranged.

03 / VERSION

Make approval valid
for a specific revision.

Context

A previous quotation or approval could be interpreted as valid after artwork or specifications changed.

Decision

Associate quotations, prices and approvals with a project revision. New revisions return to requirements and require current approval.

Design implication

Keep earlier decisions accessible as history, while making the current revision the reference for proceeding.

REVISION MODEL
HISTORY

Revision 01

Quotation + approval retained for reference

Requirements change
CURRENT

Revision 02

Updated requirements + current approval required

A reorder becomes a new linked project with its own quantities, prices and dates.

INTERFACE EVIDENCE

Each approval identifies its revision and supporting file

  1. 01
    Approval type

    Production-file approval and designer production approval are distinct records.

  2. 02
    Revision reference

    Each record identifies Revision 1, the responsible person and its recorded date.

  3. 03
    Supporting evidence

    The approval retains a linked attachment. This view shows current approvals; it does not demonstrate an older approval being invalidated.

04 / ACCESS

Share the project.
Scope access to the responsibility.

Context

Job titles alone did not describe operational access needs. A sourcing manager, for example, also needed project-management permissions.

Decision

Separate shared project context from sensitive quotation data. Give each role the pricing information needed for its work.

Configuration

Management, PM and sales can view factory cost. Designers see approved client pricing; factories see their own quotations. Accounting access is explicitly configured.

ACCESS PRINCIPLE
01

Project membership

Which assigned project can this person access?

02

Record visibility

Which quotation records support their responsibility?

Same project ≠ identical information

The comparison below shows the resulting views.

ROLE COMPARISON / SAME PROJECT, DIFFERENT ACCESS

One project. Three quotation views.

Hungry Bear — Jam Box · JKD-2026-002 · Revision 1
The project stays connected; each role receives only the quotation records relevant to its work.

Same project revision / quotation visibility by role
RoleFactory quote
USD 2,580		Approved client quote
USD 3,741
Project manager✓ Visible✓ Visible
Designer— Not available✓ Visible
Assigned factory✓ Own quote only— Not available
Request pricing and compare factory responses

Kelly · PM permissions

FACTORY QUOTEUSD 2,580
APPROVED CLIENT QUOTEUSD 3,741
COMPARE QUOTATION ACCESS BY ROLE
Separate requests, comparable quotations
  1. 01
    Price request

    Choose factories and define quantity, material, finish and sample requirements. The same specification goes into each comparison.

  2. 02
    Factory quotations

    Compare unit prices, tooling, sample fees, lead times and order totals. Earlier-specification quotes stay separate.

  3. 03
    Approved client quotation

    The approved client price remains a separate record, with its own terms and revision.

05 / END-TO-END WALKTHROUGH

Follow the handoff,
from setup to closure.

The design + production route brings the four design decisions together. Each stage has a defined output and a responsible role.

  1. 00

    Set up the project

    Project lead

    Route, brief, next owner and next action are recorded.

  2. 01

    Track the design deposit

    Accounting

    Invoice sent → requirements. Payment verified → paid design work.

  3. 02

    Confirm the current revision

    Pricing approver · Client decision recorded

    Design, specifications, samples and approved client price refer to the same revision.

  4. 03A

    Review readiness & produce

    Accounting + designer · Sourcing coordinates delivery

    Confirm payment and proof approval before starting production; then track dispatch and receipt.

  5. 04

    Review & close

    Project lead + accounting

    Review delivery, settlement and unresolved issues. Preserve the project history.

View full stage-by-stage responsibilities

Reminder rules PLANNED

TriggerWaitIf unresolved
Client feedback requested3 daysReminder + follow-up task
Down-payment invoice sent5 daysFollow up on payment
Client approval requested2 daysSigning reminder + follow-up
Factory proof uploaded2 daysRemind the reviewer

Early automation concepts. Scheduled email reminders remain a future iteration.

ACT III Iteration and validation
06 / ITERATION

Refine the model around
real operational exceptions.

Imported records, task execution and implementation exposed six areas to refine. Each change addresses a specific breakdown.

DESIGN PRINCIPLEKeep the primary workflow clear and operational exceptions traceable.

07 / OUTCOME & NEXT STEPS

Implemented for internal testing.
Ready to evaluate in practice.

The release brings project context, ownership, revision-specific records and quotation visibility into one workspace. Operational improvements still need to be measured.

IMPLEMENTED

Internal test release

Working application with the core workflow and role-based quotation views.

NEXT

Focused operational pilot

Coordinator, designer, accounting representative and factory partner.

TO BE MEASURED

Handoff effectiveness

Record a baseline and sample size before evaluating impact.

THE VALIDATION QUESTION

Can the next owner continue the project
using the record alone?

PLANNED MEASURES

Evaluate speed, clarity and evidence quality.

HANDOFF SPEED

Submission → review

Elapsed time between submitting a task result and its review.

QUOTATION TURNAROUND

Request → usable quote

Time required to obtain a quotation the team can act on.

OWNERSHIP CLARITY

Owner + next action

Share of projects with both fields explicitly recorded.

EVIDENCE QUALITY

Missing or incorrect files

Required supporting files that prevent a reliable handoff.

Measurement plan only. No baseline, pilot results or quantified improvements have been recorded.

Next product priorities
  • Final balance checks before closure
  • Hour-refund and adjustment records
  • Visible reasons for manual overrides
  • Notifications, file versions and restore drills
REFLECTION

Design for the transfer of responsibility.

The critical interaction happens between roles: a person needs enough context, current evidence and appropriate access to continue the work. Designing that transfer became the organizing principle for the whole system.

I started as the bridge every project had to cross.
The goal was to give the work
a shared place to continue.

Interface detail