Shamel360 — Case Study

Snapshot

Role: Product Designer. Co-design with a second designer.
Team: Two product designers, BitBang engineering, PM, client stakeholders.
Timeline: Five months. Launched.
Platform: Web. SaaS. Arabic and English, RTL.
Status: Live.
What was mine: Dashboard, inbound, outbound, people, products, configuration, bulk SKUs, offers management, and the Shamel360 marketing site. Shared ownership with a second designer across the rest of the system.

Overview

Shamel360 is a fulfillment platform for merchants and logistics providers who cannot afford enterprise WMS software and cannot survive on spreadsheets either. Four modules. Warehouse, orders, inventory, transport. All of it in one system, in two languages, in five months.

The obvious problem was speed. Orders moved too slowly through a shift. The real problem sat underneath it: in the tools these teams were using, a warehouse worker could not do anything without a supervisor confirming it first. Every decision travelled up before it travelled forward.

That is the problem this system was built to solve.

Fig. 02 — Inbound · stage pipeline

Context

Small and mid sized merchants, 3PLs, and online retailers. Saudi Arabia, UAE, Egypt.

The category they were stuck in is ERP style warehouse software. Built for enterprises with dedicated operations teams and a training budget. Priced and structured accordingly. What these clients actually had was a floor supervisor, a handful of staff, and a phone.

So they improvised. Spreadsheets, WhatsApp, a whiteboard, whatever held. Orders got lost between the sales channel and the shelf. Stock counts were true on Monday and fiction by Thursday.

For Shamel360 as a business, adoption speed was the product. A powerful system nobody could learn was worth nothing here. That constraint drove more design decisions than any feature request did.

My Role

Mine. Dashboard. Inbound and outbound. People. Products. Configuration. Bulk SKUs. Offers management. The Shamel360 marketing site.

That list is most of the operational surface. Inbound and outbound are the two ends of the warehouse. Products and bulk SKUs are what everything else acts on. Configuration is where the system gets shaped to a client. Dashboard is where a manager decides what to do first.

Shared. The design system, the Arabic layer, and the broader architecture, with a second designer. Two designers on one system for five months means the boundaries are real but not clean. We reviewed each other's work daily and both of us changed our minds because of it.

Set by others. The product scope. Four modules, the integrations, the compliance requirements. That came from the client and BitBang leadership. I did not decide what Shamel360 should be. I decided how a large part of it works.

Fig. 03 — Inventory · stock list, pinned column groups

The Problem

What people struggle with. We observed warehouse managers and staff at work. Three things kept showing up.

Staff could not act. Not because they lacked the skill, but because the software made every action feel like a decision that needed approval. So they waited. And the manager became a bottleneck standing in his own warehouse.

Managers could not see stuck work. Order status lived in tables. A table tells you what state an order is in. It does not tell you that nine orders have been in that state since this morning and one zone is drowning.

And the software did not match the building. Staff think in aisles, racks, and zones. The interface thought in rows and IDs. That gap is where the training time goes.

How we framed it. Not “how do we make fulfillment faster.” Faster is an outcome, not a problem. The question was: can a warehouse worker with no training and no supervisor standing behind them move an order forward correctly? If yes, the throughput follows. If no, no amount of interface polish saves it.

Approach & Success

Research was real, and it was operational rather than academic. We spoke with warehouse managers and observed staff working. We ran a competitor analysis across the existing WMS category. Both of those were front loaded, before layouts, because on a five month timeline you get one chance to be pointed in the right direction.

What the competitor scan told us was useful in a negative way. The category was full of systems that were powerful and slow to adopt. Nobody was designing for the first week. That gap became our target.

Success was judged on adoption, not on a dashboard. Could a new staff member work a shift without asking. Could a manager find the stalled order without hunting.

Fig. 04 — Inventory · storages, normal view

Fig. 05 — Inventory · storages, drone view

Process & Exploration

Kanban is a pipeline, not a layout.

The order board is a Kanban board, which sounds like a pattern decision and is not one. The columns are the fulfillment stages. Which means the column set is an architectural claim about how a warehouse works, and if you get it wrong the whole system lies to its users.

Getting it right meant deciding what counts as a state versus what counts as an attribute. Priority is not a state. Ownership is not a state. Blocked is not a state either, it is a condition that can apply to an order in any state. Those go on the card. Only the actual stages of physical progress get a column.

The result is a board where the shape of the work is visible before you read anything. A column that is too tall is a bottleneck. You do not need a report to know that.

Ownership belongs on the card, not in a permissions screen.

This is where the authority problem gets solved. Every order carries its owner, its priority, and its state on its face. Not buried in a detail view, not derived from a role table somewhere.

Once a worker can see that an order is theirs, and can see what it needs next, the supervisor is not required for the transaction. He is required for the exception. That is the entire point.

The zone map exists because the warehouse does.

A digital view of the physical floor. Zones on screen match zones in the building.

The fork here was real. The efficient thing to build is a filter: let the manager filter the order table by zone and be done. It costs a fraction of the effort and it technically answers the question.

We built the map instead. Because a filter answers a question you already thought to ask, and a map shows you the thing you did not know to look for. A manager glancing at the floor view sees an overloaded zone in half a second. With a filter he has to already suspect it.

A configuration layer, so the system does not have to be rebuilt per client.

Every merchant runs their warehouse slightly differently. Different zones, different SKU structures, different roles, different offer rules. The alternative to designing for that is a custom build every time, which is how software houses die.

Configuration is where we put that flex. It is unglamorous work and it is the reason the system can be sold twice.

Fig. 06 — Products · catalogue and custom view

The Solution

Order board. Kanban pipeline. State in columns, ownership and priority on the card.
Warehouse zone view. The digital floor mapped to the physical one. Load and activity visible per zone.
Inventory. Live stock, batch tracking, automated replenishment.
Transport. Route planning, courier integration, delivery status.
Merchant portal. The merchant's window into their own orders, so the fulfillment center stops answering the phone.
Compliance and payments. ZATCA invoicing, GoPay integration for collections.

The design system is what lets four modules read as one product instead of four products sharing a login.

Fig. 07 — Returns · return and reverse orders

Key Decisions & Tradeoffs

Design for the first week, not the hundredth.

Shamel360 was being sold to merchants and small 3PLs with no operations team and no training budget. The reason they were still running on spreadsheets and WhatsApp was not that the ERP-style systems lacked features, it was that nobody on the floor could learn one. So we designed for the first shift: working defaults instead of a setup phase, the next action visible on the order card instead of buried in a menu, one path through inbound and outbound instead of three.

Tradeoff: a supervisor who has run Shamel360 for a year will want bulk shortcuts and depth we deliberately kept out of the primary flow, and will hit a ceiling faster than they would in an ERP. For a merchant with one supervisor and six staff, that ceiling is above their head. It was the right customer to lose.

Build the zone map instead of the zone filter.

The cheap version of this is a filter: let the manager filter the order table by zone and move on. We built the storages view instead: zones, racks, and bins laid out on screen the way they sit in the building, with load and condition legible per bin, in two densities: a dense grid for scanning a whole zone at a glance and a card view for reading capacity and status on a single bin. It is the point where the interface stops speaking in rows and IDs and starts speaking the language staff already use to say where something is.

Tradeoff: weeks of build time, two view densities to design and maintain instead of one table, and a layout that has to be re-derived per client through configuration because no two floors match. Worth it because a filter only answers the question you already thought to ask, while the map shows an overloaded zone in half a second to a manager who did not suspect it.

Put authority on the card.

Ownership and next action visible on every order, so staff can act without escalating.

Tradeoff: more responsibility pushed to people with less training. Which means the cost of a bad state transition goes up. We accepted that and paid for it with clearer state design.

RTL in the design system, not on top of it.

Bilingual components from day one rather than a mirroring pass at the end.

Tradeoff: slower start. Every component costs more to build. But five months does not survive an RTL retrofit, and the Arabic version is not a second class version of the product here. It is the product.

Fig. 08 — Configuration · user management and roles

Impact & Results

It launched. That is the honest headline, and on a five month timeline for a four module bilingual platform, it is not a small one.

The product is live and now in its investment raising phase.

What I can speak to:

Real time status across the system. Stock, orders, zones. What is happening is visible as it happens, not on a refresh cycle. That is a system fact, not a marketing claim.
The bilingual layer held. Arabic and English, RTL, without a fork in the codebase or the design system.
The design system carried four modules. It is still carrying them.
Authority moved to the floor. Ownership, priority and next action sit on the order card, so a staff member can move an order forward without a supervisor confirming it first. That was the problem we set out to solve.
The system can be sold again without a rebuild. The configuration layer absorbs the per client differences in zones, SKU structures, roles and offer rules, instead of a custom build each time.