My team and I redesigned a 25-year-old retail platform from the ground up, starting with the POS.

The company's retail platform had grown for 25 years. It was one large system, so nobody could change one part quickly without risking breaking another, releases took a long time, and the cost of running it in the company's data centres kept growing.

So the company decided to rebuild the platform as separate products, each built for the people who use it and where they use it. Storefront, the new POS, came first, because it's the in-store experience and everything else depends on the sales that come through it. Hub, the new back office, came next, starting with inventory, security and permissions. Customers still ran their business on RQ, the old platform, so everything Storefront did had to be pushed back into RQ.

Making a sale on the old platform showed how much had built up over the years. Quotes, orders, sales and refunds each had their own workflow. Whenever a customer needed something new, it was built onto those flows as custom work, and then built again for the next customer. The diagram below shows the old flows.

Underneath all those workflows, every transaction ended in one of three states: open, complete or cancelled. Whether it was paid for, fulfilled or refunded was a detail of that one transaction, not a different kind of transaction.

So the platform didn't need a workflow for each channel or each customer. It needed one model, with those details layered on top. The whole team designed around that model from then on. The diagram below shows the model.

My team and I designed Storefront together, and I owned the order model. For the first version, the team built on Google's Material Design 3 component library, with no changes, so the team could move fast. It covered sales in store, online orders picked up in store, refunds, discounts, cash management and inventory, and it runs on phones, tablets and computers.

Here is what the model looked like for a rep. The screens below show a rep building an order: adding services, then the customer, with the order on screen the whole time. Products are added the same way.

Hub was designed as the answer to all that custom work. Instead of the company building a new version for each customer, each customer could switch on the apps its business needed, with billing to match: the company's own, like Storefront and Repair, and its partners', like Shiftlab for staff scheduling and Statflo for texting customers. Clients with their own developers could build their own apps, or hire the company's enterprise services team to build them.

I designed every page of Hub, and built the prototypes with Figma Make, an AI tool that turns designs into working prototypes, so people could click through the vision instead of imagining it. The screens below show how a manager adds a partner's app, from the apps their business already uses to installing a new one.

The company launched Storefront on the main stage at its annual Summit, for customers, prospects and partners. In a smaller session, I presented the vision for Hub to a room full of the back office people it was designed for.

Repair, the first new app, had its own prototype at Summit. The prototype got one enterprise customer excited about working with the company on the new Repair app instead of the old repair module, and drew interest from a repair business with over 300 locations.

During beta testing in a store, one of the first people to try Storefront knew the old POS well. They went through a flow they knew from the old POS, and were surprised at how much easier it was in Storefront. "That was easy," they said.

I would bring in experts from every part of the back office sooner. I've facilitated many design sprints, including one for the company's vision of retail, but I didn't run one for Hub. A sprint with people who knew inventory, reconciliation and reporting would have re-imagined it from more angles than I could alone.