Construction Supply Chain & Ops

Turning startup operations into scalable delivery tools

Role: Product Designer
Company: RenoRun
Domain: Construction supply chain, warehouse operations, delivery logistics
Users: Warehouse managers, pickers, QA teams, loaders, dispatchers, operations leaders
Methods: User research, workflow mapping, Design Studio, prototyping, usability testing, Figma handoff, cross-functional facilitation
Keywords: B2B operations, supply chain UX, internal tools, warehouse workflows, delivery logistics, design systems, product discovery, service design

Overview

RenoRun promised fast delivery of construction materials. Behind that promise was a complex operational system: orders, shipments, picking, quality assurance, loading, dispatch, and delivery all had to work together.

The challenge was to help move the company from startup tools — including Google Sheets and manual coordination — toward a more scalable ecosystem of operational applications.

The design work focused on one core question:

How might we help warehouse and delivery teams plan, track, and assemble shipments while keeping every shipment connected to the original customer order?

1. Situation

Fast delivery depends on operational clarity

RenoRun’s customer promise was simple: get construction materials delivered quickly and reliably.

But internally, delivery speed depended on many teams working from the same operational truth. Warehouse staff, pickers, QA, loaders, dispatchers, and managers all needed to understand:

what had been ordered
what had been picked
what was ready for loading
what belonged to each shipment
what needed to leave the warehouse next
how every shipment related back to the original order

The existing workflow relied heavily on manual tools, shared documents, operational knowledge, and coordination between teams. That made it harder to scale, harder to track status, and harder to create a reliable end-to-end delivery experience.

The product challenge

The initial problem was framed as:

“We need to track shipments while maintaining the relationship to the original order.”

Through discovery, that problem became more precise:

RenoRun needed a shipment planning tool connected to a broader ecosystem of operational apps — including fulfillment, picking, QA, loading, and dispatch.

This was not a single-screen UI problem. It was a systems problem.

Mapping the delivery workflow helped the team see where information moved, where it broke down, and how different operational roles depended on one another to keep shipments moving.

2. Actions

Understanding the real workflow

I started by working with the Product Manager, stakeholders, subject-matter experts, and end users to understand the current operational flow.

The goal was to clarify:

who was involved in the shipment workflow
what tools they used
where information broke down
which decisions were time-sensitive
what needed to be tracked at each step
which KPIs and operational outcomes mattered most

Because I was not the subject-matter expert, I used early wireframes, existing tools, screenshots, workflow walkthroughs, and user interviews as conversation starters.

This helped surface not only what users did, but where the current system created friction.

Research and synthesis

I used lightweight, fast research methods suited to a startup environment:

semi-structured interviews with key users
workflow walkthroughs
analysis of existing tools
user quotes
flow diagrams
sketches
opportunity mapping

The goal was not to produce research documentation for its own sake. The goal was to make the problem visible and actionable for the team.

Key insight:

The shipment workflow could not be designed in isolation. It had to connect to a larger ecosystem of tools used by different teams, on different devices, at different moments of the delivery process.

The Crazy 8s and Design Studio created alignment between Product, operations experts, and engineering. Instead of designing in isolation, we used shared research and structured ideation to converge on a direction the team could understand and build.

Facilitating alignment

Once the team had a clearer view of the problem, I facilitated structured ideation with people who understood the operation: Product, SMEs, engineering, and stakeholders.

I used Design Studio methods to move quickly from research insights to possible solutions:

shared user findings through stories, quotes, photos, and screenshots
helped the group build empathy for the operational context
ran Crazy 8s to generate multiple solution directions quickly
had participants present ideas and capture useful patterns
combined the strongest ideas into more detailed solution sketches

The value of this step was alignment. Everyone could see the same problem, contribute ideas, and understand the trade-offs before design moved into high fidelity.

A/B Testing to evaluate a Card vs. a List approach to handle split orders.

Designing and testing the solution

After the Design Studio, I worked with PMs and stakeholders to decide what direction should be prototyped and tested.

The design work included:

high-fidelity wireframes
workflow prototypes
interface patterns for operational dashboards
shipment tracking flows
integration points with the surrounding app ecosystem
task-based usability testing
refinement of labels, icons, and interaction patterns

When a solution was clear, we tested task completion with users. When the direction was still ambiguous, we compared alternatives and used feedback to converge on a more useful design.

Video presentation and update – prototype walkthrough and new design decisions shared with engineering team.

Supporting engineering delivery

The work did not stop at the Figma file.

We added a storytelling ritual before sprint kickoff, where Product and Design presented semi-approved designs, epics, and stories to engineering.

This gave engineers space to challenge assumptions, identify technical constraints, and improve the solution before development began.

For handoff, I used:

Figma files and prototypes linked to epics and stories
Confluence documentation when needed
walkthrough recordings to explain design updates
close collaboration with PMs and engineers during implementation

The goal was to make the design buildable, understandable, and easy to evolve.

3. Results

A clearer operational product ecosystem

The work helped shape a connected ecosystem of internal tools for RenoRun’s warehouse and delivery operations.

Designed solutions included:

a desktop / TV dashboard to track daily orders and dispatch assignments
a loading dashboard to track shipments across orders and prepare them for delivery
a mobile picking app to replace paper-based workflows and support picking by zones and waves

Together, these tools helped move RenoRun toward a more structured, scalable operational system.

Business and product value

The design work supported RenoRun’s ability to:

reduce reliance on manual coordination
improve visibility across the delivery workflow
connect shipments back to customer orders
support faster operational decisions
align product, operations, and engineering around a shared workflow
create MVP-ready designs that could be tested, refined, and delivered

What this project proves

This project shows my ability to design for complex B2B operations where the user experience is not limited to one interface.

The real product was the system: people, tools, data, devices, decisions, and timing.

My contribution was to make that system easier to understand, easier to coordinate, and easier to build.

Relevant strengths:
Product design for complex systems · Operations UX · Supply chain workflows · User research · Workshop facilitation · Design Studio · Prototyping · Usability testing · Cross-functional alignment · Design-to-engineering handoff

Home

More Projects

Top of Page