LIMBITLESS SOLUTIONS

2026

From spreadsheet to shared system

Role

Product Designer Intern

Timeline

Summer 2026

Team

1 PM 1 Designer 2 Engineers

SKILLS

Product Design User Research Prototyping

Role

Product Designer Intern

Timeline

Summer 2026

Team

1 PM 1 Designer 2 Engineers

SKILLS

Product Design User Research Prototyping

Overview

Bringing inventory and request reorders into one place

Limbitless’ Finishing & Quality Team relied on a shared Google Sheet to manage materials, but reorder requests were handled separately through messages and in-person conversations.

I worked with the Finishing and Production teams, my manager, and two engineers to design and ship a centralized system for monitoring inventory, submitting reorder requests, and tracking decisions.

Problem

Where the old system fell short

Reorder happened outside the system

When something ran low, a team member had to text a manager or find them in person. Once a request was sent, there was no way to track whether it had been seen, approved, or was still pending.

1. reorder happened outside the system flowchart 2. request status was difficult to track

Low stock had no clear next step

A low quantity in the spreadsheet was just a number and nothing prompted anyone to act on it.

3. low stock had no clear next step

Design Constraints

Keep the team’s existing Google Sheets workflow

Turn low stock into a clear next step

Keep everyone informed throughout the reorder process

PROCESS

Mapping, Sketching, Iterating

01

Mapping the existing system

I reviewed the Google Sheet and interviewed the finishing and manufacturing teams to understand how materials were tracked and what happened when something ran low.

This revealed a gap between identifying low stock and taking action: inventory lived in the spreadsheet, while reorder requests happened through texts or in-person conversations.

I reviewed the Google Sheet and interviewed the finishing and manufacturing teams to understand how materials were tracked and what happened when something ran low.

This revealed a gap between identifying low stock and taking action: inventory lived in the spreadsheet, while reorder requests happened through texts or in-person conversations.

reorder workflow before

02

Sketching the system structure

I sketched a two part system that kept inventory and reorder requests connected while giving each task its own view.

The inventory table made it easier to review, compare, and update materials, while the Kanban board made request status visible at a glance.

1. order tab 2. inventory tab

03

Iterating hi-fi with stakeholder feedback

After reviewing the first high-fidelity prototype with the finishing team and management, I refined two parts of the experience to better match how the team requested reorders and organized materials.

ITERATION 01

Request Reorder flow

I added a Request Reorder button to every inventory row for quick access. Selecting it opens a request form already connected to that specific material.

Request Reorder button on each row → quantity form → confirmation sent to manager

ITERATION 02

Refining Kanban card details

I updated the Kanban cards to include the requester’s profile and name, along with a kebab menu for editing the order quantity and changing the request status.

Kanban card with requester info and kebab menu for quantity/status edits

FINAL PRODUCT

Manage and organize in one place

Team members can search and organize 200+ materials, view key details, and switch to Orders to track reorders all in one place.

switching between inventory and orders tab

Request and track orders

Team members and managers can view and change status of a request directly from the order tab. Managers are notified, and the request can be followed through Pending, Accepted, or Rejected states.

updating request order card

Reflection

What I learned

Designing for more than one team.

Different people cared about different parts of the product. The Finishing Team focused on the daily workflow, while my manager and developers focused on what was realistic to build. I learned to consider both sides instead of designing from only one perspective.

Simple designs take a lot of work.

The final workflow looks straightforward, but getting there meant working through existing habits, stakeholder feedback, and technical constraints. I learned that my role as a designer is to understand that complexity and turn it into something that feels simple to use.