← Back to Home
Warehouse Item Requests cover

Case study · Bulut

Warehouse Item Requests

A PWA for requesting goods, now connected to cataloging

Role
Product Designer, the only designer on the project, working with the product owner and developers
Context
Bulut
Tools
Figma

The result, first

What changed because of this work

519

Active users in the last 30 days

1.91K

Sessions in the last 30 days

80.2%

Of searchers submit a request

53.9%

Of browsers submit a request, from the home page

01

Context

The problem

Requesting goods from the warehouse is something almost every team does. This is the PWA version of that flow, built on top of the cataloging system so that requests, reviews and allocations all speak the same language.

What was broken

The previous web version was not connected to cataloging. Users requested whatever they wanted in free form, so the warehouse had to interpret each request, answers took long, and there was no reliable way to report on what the company was asking for.

02

Approach

How I got there

  1. 01

    Field research and talks with the stakeholders to understand the real work, desk research on similar products and best practices, and business meetings to agree on the problem and find the solution. I did the full product-design scope: research, solution finding and design.

  2. 02

    Mapped how requests moved from the requester to the warehouse in the old web version, and where they stalled.

  3. 03

    Redesigned the requester side as a mobile PWA: categories, search, request registration with urgency, and tracking.

  4. 04

    Designed a specialist workspace for reviewing each request: approve, reject, edit the quantity, change the item or write an opinion, with a comparison view and a signing timeline.

  5. 05

    Designed how reviewed requests continue to the warehouse or return as rejected.

03

Thinking

Key decisions

I decided to

Connect requests to the cataloging system

Because

In the old web version users could ask for anything in their own words. Choosing from standardized categories and items keeps every request clear and comparable.

I decided to

Add a specialist review step between the user and the warehouse

Because

The specialist can approve an item, reject it, change the quantity or replace it with a better match, and only then does the request go to the warehouse or come back rejected.

I decided to

Show the request status and signing flow to the requester

Because

A tracking list with clear statuses (in signing, awaiting allocation, allocating, completed, rejected) answers 'where is my request?' without anyone having to ask.

04

Impact

Results

  • Requests move faster and the process is more cohesive from request to allocation.
  • Because requests now use cataloged items, the company can produce reports on them.
  • Within 30 days, 519 people used the app and 80.2% of those who searched went on to submit a request.
  • A mobile-first experience for requesters and a focused workspace for specialists.

Requester side

Mobile app (PWA)

Pick a category
Track requests
Request details
Register and review

After launch

Usage analytics

Usage dashboardOver the last 30 days: 42.9 daily visitors on average, 1.81K sessions, 36.7K pageviews and about 20 pageviews per session. Most sessions come from direct visits, and the busiest pages are the categories, the home page, the follow-up list, request submission and search.
Product analytics overview519 active users, 478 of them first-time users, 1.91K sessions and an average of 43.6 daily active users. The average session lasts 8m 10s. The comparison period was before launch, so the growth percentages mostly show the move from almost no usage to real usage.
Funnel: home, categories, catalog, item, request473 people started on the home page and 255 submitted a request, a 53.9% conversion with a median time of 3m 12s. Almost everyone opens the categories (99.4%). The largest drop is from categories to the catalog (69.4%); once an item is open, 91.4% go on to submit.
Funnel: search, item, requestStarting from search, 199 of 248 people submitted a request: 80.2% conversion in a median 1m 24s. Search users are more decided and reach a request faster than people browsing categories.
Funnel: request, follow-upOf 369 people who submitted a request, 256 (69.4%) went on to the follow-up screen, a median 52 seconds later, so most requesters come back to check their status.

Why so few screens? Most of this work is under NDA, so I can only share a small part of it. I am happy to walk through the rest in a conversation.

The craft

Screens

Screen 01
Screen 02
Screen 03
Screen 04
Screen 05
Screen 06