Shopini Logistics

Context

Shopini gave customers their own address in the US, the UK and the UAE, took delivery of whatever they bought from stores there, and shipped it on to them. Behind that sat a warehouse operation and a last-mile delivery network, and behind that sat the tools I worked on.

It was small. Thirty to forty people, four of them in design, and no dedicated product manager on the internal systems.

The CEO and stakeholders would arrive with a business idea. We need to see revenue per lane daily. The warehouse team is losing parcels between scan points. Couriers need to reassign a delivery from the road. My job was to turn that into something engineering could build, which meant writing the requirements, working out what comparable products did, scoping it to what could ship, building the prototype, and then running the build with the engineers.

Four surfaces came out of that: the warehouse operations app, the courier platform, the executive dashboards used daily by the CEO and operations, and the customer-facing app and dashboard the whole operation existed to serve.

The problem

Three internal systems, built at different times by different people, with no shared language. The same status meant different things on different screens. Operations staff moved between tools that looked and behaved like three different companies' software.

And every new business idea landed on the same small team with no process for turning it into a spec.

What I did

Took the product management work, because it was on the floor

For each initiative:

• Sat with the CEO or the stakeholder and wrote down what they were actually trying to see or stop.
• Looked at how comparable products handled it.
• Wrote the requirements: what is in, what is out, and what done means.
• Prototyped it and tested it with the people who would use it, which meant warehouse leads and operations staff, and the CEO for the dashboards.
• Handed engineering a spec and a clickable prototype, and stayed on the build until it shipped.

I was never titled product manager and I am not going to claim it. This is the product work that usually sits with a PM, done by the designer because there was nobody else to do it.

One initiative, end to end: Items Fulfilment

A customer with four parcels sitting in the US warehouse wanted one box shipped, holding some of what was inside them rather than all of it. Combining whole parcels was already possible. Splitting the items inside them was not, so the request came back to operations as an email and somebody did it by hand.

I wrote the feature document. It carried one line as the measure of success, that a customer can combine multiple parcels and separate the items under them into a new parcel, and two user stories: one for the customer making the request, one for the warehouse operator receiving it. Both, because a feature like this does not exist until both halves do, and the half nobody specifies is the one that gets built badly.

The scoping decision that mattered was refusing a new section. Items Fulfilment became a second button beside Ship selected, on the screen customers were already on, appearing only once more than one parcel is selected. Requested items move to In Progress and leave the shipping list, so nobody can ship a parcel that is being taken apart. When the warehouse marks them Ready, a bar appears on the dashboard with a count and a link. Each record carries item name, quantity, parcel ID, value, last update and status. I named all six in the document rather than leaving them to be discovered during the build.

The warehouse half is the one that usually goes missing. An operator opens a fulfilment request, picks a parcel out of it, splits the quantity per item, assigns each split to a fulfilment area, and saves, which generates the ID the customer's new parcel is built from.

Engineering got the document, a flow diagram that crossed both roles, and two prototypes, one for the customer app and one for the handheld. Buy it for Me, a buying assistant for customers who wanted someone else to place the order on a US store, went through the same loop and launched.

Designed the dashboards for decisions, not for display

The parcel and revenue dashboards were open on the CEO's screen every morning. The design decision that mattered was leading with exceptions rather than totals. Totals tell you the business exists. Exceptions tell you what to do today.

Built the design system

Standardised the design language across all three internal systems: shared components, a shared status vocabulary, and shared patterns for tables, filters and exceptions. Built so it could take new tools as they arrived.

This was the first design system I built, and it is why the ones after it look the way they do.

Stayed through the acquisition

Shopini was acquired by Lyve. I stayed through the transition, kept the internal tools stable, and left in January 2024 once the handover was done.

Outcome

• Three internal systems on one design language.
• A repeatable loop from idea to spec to shipped, where there had been none.
• Dashboards in daily use by the CEO and operations through to the acquisition.

What I'd do differently

Write the status vocabulary down on day one. Half the design system work turned out to be untangling what delivered, completed and closed meant on three different screens. That is a data model problem wearing a UI costume, and it should have been fixed in the schema before anyone fixed it in the interface.