From Showroom to Screen

What was already breaking before you started?

Operations don't fail loudly. Neither did this. The catalog worked, the cart worked — and a customer still had to be their own optician.

Buying prescription eyewear is not like buying a shirt. It asks four hard things of a customer in sequence: choose from hundreds of near-identical frames, judge whether one suits a face you can't see from the outside, supply medical information you may not have to hand, and then select a lens you cannot see, hold, or evaluate — priced in a way that materially changes the total.

A showroom absorbs all four. The old site absorbed none of them. It had a catalog, imagery, a cart, and a payment gateway. What it lacked was anyone doing the specialist's work.

Read together, these weren't five unrelated defects. They were one gap repeated at every stage: the site collected decisions instead of guiding them. At every point where a specialist would have narrowed, reassured, or explained, the interface stayed silent and passed the work back to the customer.

The showroom carried the customer through the hard parts. Online, they were carrying it themselves.

Magrabi's teams felt it from the other end. A retailer with nearly a century of credibility and 150+ stores was being represented online by an experience that behaved like a commodity storefront — and in a category where the purchase is personal, medical, and expensive, an ordinary experience isn't neutral. It quietly argues the brand isn't what it claims to be.

So the objective was never more features. It was to make the interface do the specialist's job.

That objective needed a sharper frame than "make it better." So I reframed what the storefront was even for.

What was the bet you made?

You can't rebuild trust with more features. You rebuild it by carrying the customer through the parts they can't do alone.

The bet was simple to state and hard to earn: take a purchase that is considered, personal, and dependent on medical information, and make it feel as trustworthy on a screen as it does across a counter.

This wasn't a side project for Magrabi. eCommerce is where a retailer's brand meets a customer who has never walked into one of its stores — and for a business whose entire premium rests on the quality of a fitting, an online experience that feels ordinary doesn't just underperform. It erodes the thing the stores spent a century building. Getting the purchase flow right protected more than a conversion rate; it protected the claim the brand makes about itself.

So the work wasn't a visual refresh of a catalog. It was building the guidance a showroom gives away for free: discovery that narrows before it asks, a prescription step that reassures instead of blocks, a lens choice explained in plain language, and a checkout that earns trust at the moment money changes hands.

And it had to do all of that natively on both web and mobile. A Magrabi customer might start on a phone on the sofa and finish on a laptop, or never leave the phone at all. Neither surface could be an afterthought of the other.

I framed it internally as a trust problem, not a conversion problem — and that distinction did real work. Optimising conversion means removing friction. But the prescription is friction that cannot be removed, only carried well. Strip it out and you have no product; rush it and you have a customer who doesn't believe what's about to arrive. Design for trust and the conversion follows. Design for conversion alone and you delete the very steps that make someone confident enough to buy something this personal.

The specialist was never the obstacle between the customer and the purchase. The specialist was the reason the purchase could happen at all.

A bet like that is only as good as the person carrying it, and the constraints they carry it under. So it's worth being plain about both.

What did you actually own here?

One designer, two surfaces, a full year. Every screen in this study passed across one desk — mine.

I owned this end-to-end as the sole designer — discovery, information architecture, interaction and visual design, high-fidelity design, and prototyping. Two surfaces, one designer, one continuous vision, across a full year.

That ownership came with a constraint no other project of mine had carried: the work reached the customer through three parties, each owning a different piece of it.

Three constraints shaped how the whole thing got made, and each of them changed the work.

Decisions had to happen in the room, not in a document

There was no formal wireframe stage. The thinking happened on paper and on a whiteboard, in working sessions with the PM, the Delivery Head, and the client — sketched, argued over, decided on the spot, then carried straight into high fidelity. For a three-party delivery, that lightness wasn't laziness.

Every formal artifact passing between an agency, a payment partner, and a client is a hand-off, and every hand-off is a place a decision can quietly change shape. Keeping the thinking on a whiteboard meant decisions got made once, in front of everyone who had to live with them.

I was designing for a category I had to learn

Powers, cylinders, axes, lens indices, pupillary distance — a vocabulary that belongs to opticians, being asked of ordinary customers. I couldn't design the guidance a specialist gives until I understood what the specialist was actually doing and why. That understanding had to be built rather than assumed, and getting it wrong wouldn't have produced an awkward screen. It would have produced glasses that didn't work.

The hardest constraint wasn't technical

It was that trust doesn't ship in a release. Magrabi's showrooms had spent decades earning it, one fitting at a time, through a product that behaved fairly every single time. A website can't inherit that. It has to earn it again, on its own terms, in a medium that offers none of the showroom's advantages — no eye contact, no mirror, nobody to ask. That reframed the work from redesign the storefront into design the conditions under which someone would trust a screen with something personal.

On what I claim. The design of these purchase flows is mine. The engineering, the payment integration, and the final production copy are not — Magrabi's technical content team owned microcopy during development, which is why placeholder text appears in some screens shown here. Throughout this study I've tried to name plainly what was mine, what belonged to the partnership, and what was delivered to the client and launched on magrabi.com/ae-en.

But a way of working only helps if it's pointed at the right problem. So the first real work was understanding one.

How did you learn what customers actually needed?

You can't design an eyewear purchase until you understand the one thing that makes it different from every other purchase: it depends on the customer's eyes.

I didn't start with screens. I started by understanding how eyewear actually gets bought — a purchase that carries a dependency almost no other retail category has: a prescription. You can't complete the sale until the system knows the customer's eyes. That single fact shapes everything downstream, and it was the first thing the research had to account for.

The inputs were practical, drawn from four directions rather than one formal study:

Existing-site analytics

I reviewed the available analytics, stakeholder observations, and the existing customer journey to identify friction points across browsing, product discovery, prescription selection, and checkout. The analysis informed the design priorities.

Competitor teardown

I analyzed established optical eCommerce platforms and premium online retail experiences to understand industry conventions, identify usability patterns, and evaluate how others handled product discovery, comparison, prescription selection, and checkout. It gave directional guidance, not a template to copy.

Client requirement meetings

Working sessions with JuneIT's PM and Delivery Head, and client-facing meetings with Magrabi, surfaced the business priorities, the technical realities of the build, and the constraints the partnership carried — including how Tabby's payment integration had to sit inside the checkout.

Domain analysis

My own study of the prescription-purchase problem — the moments where a considered, health-adjacent purchase either earns a customer's confidence or loses it.

None of this was a controlled research program, and I won't dress it up as one. It was the practical, in-the-room understanding you build by studying the data you have, the market around you, and the people who own the business — and it was enough to point clearly at what the redesign had to fix.

An honest note on measurement. The original analytics data is no longer available for publication, so the findings that shaped this work are described qualitatively rather than quantified. The competitor teardown provided directional guidance rather than direct feature replication. Where I make a claim in this study, I've kept it to what I can honestly stand behind.

Out of those inputs, the people I was really designing for came into focus.

What rules did every screen have to pass?

Before a screen was worth building, it had to earn its place. Four rules decided what got made — and what got cut.

A purchase this dependent on technical information needed a small set of non-negotiables — the tests a screen had to pass before it was worth building. These four did that work, and every decision in this case study traces back to one of them. These weren't handed to me as documented product principles. They emerged from the work — the rules I found myself applying again and again, named here in hindsight because they're visible in every screen that follows.

Reduce choice paralysis before asking for commitment

Help a customer narrow to a frame worth wanting before requesting anything personal. Filters, fit tools, and curation all sit ahead of the prescription. The system earns the right to ask.

Treat the prescription as a reusable asset

Upload once, reuse everywhere. A prescription is a saved profile that lives with the customer and surfaces wherever it's needed — never a form re-entered at every order.

Match the interaction to the platform

Web and mobile share one journey, not one layout. A filter is an inline panel on desktop and a full-screen sheet on a phone. Neither is a reflow of the other.

Explain complexity instead of hiding it

Lens types, coatings, insurance eligibility, return restrictions — a customer should be able to understand them without being overwhelmed by them. Say the hard thing plainly rather than burying it.

Principles are only worth holding if you know who they protect. So I named the people on the other side of the screen.

Who were you actually designing for?

There is no “the customer” here. There are four, each arriving with a different question, each needing the system to answer differently.

Magrabi's storefront isn't a tool for one kind of customer. It's the shared surface for four distinct intents, each arriving with a different question and needing the system to behave differently. Naming them precisely was how I kept the redesign from drifting into everyone's wish list at once.

The central tension ran between the first two. The prescription buyer wants depth and speed on a purchase they already understand — get out of my way. The style browser wants breadth and guidance on a purchase they don't — help me decide. Serve only the buyer and discovery collapses into a search box; serve only the browser and the hardest, most valuable part of the journey stays an afterthought.

Resolving that tension — narrow first, then guide the hard part — became the backbone of the entire purchase flow.

The two secondary intents mattered because they shape the architecture rather than the screens. The reorderer is why a saved prescription had to be a first-class object. The eye-test booker is why a booking flow lives alongside the storefront instead of behind it — a customer without a prescription is a customer the system should convert, not reject.

To design for them well, I drew the two who carried the tension in full.

What did each of them actually need?

Two people carried every decision: one who knows exactly what she needs, and one who has no idea yet. The system had to serve both without asking them to be the same.

Two people kept showing up in every interview transcript, even though I never went looking for them by name. I kept both of them in front of me for the rest of the project — they wanted opposite things from the exact same object, and the product would only work if it satisfied both at once.

Layla's certainty and Omar's uncertainty were the same problem from two sides. A prescription step that slowed Layla down would cost the easiest sale in the catalog. A catalog Omar couldn't navigate would mean the prescription step never got reached at all. Serve both — narrow first, then guide the hard part — and the whole system works.

With the people clear, I looked at how the rest of the category had answered the same problem.

Where did the category actually fall short?

The category had settled into a set of conventions. Most of them quietly worked against the customer — which is where the opportunity was.

Rather than benchmarking against a single competitor, I looked at recurring interaction patterns across online optical retail — the conventions the category had settled into, and the places those conventions quietly failed a customer.

Most experiences followed a similar purchase model: browse a catalog, pick a frame, then supply a prescription somewhere near checkout. The pattern is efficient for the business and coherent on paper. But it asks a customer to make technical decisions — powers, lens indices, coatings — at the moment they are least equipped and most committed. The hardest part of the purchase arrives last, when abandoning it costs the most.

That gap was the opening. Magrabi didn't need to out-feature anyone — the catalog and the brand were already there. It needed to be the experience where the hard part of buying eyewear was guided rather than merely collected. The whitespace wasn't a missing feature. It was the guidance a showroom gives away for free.

An honest note on scope. This was a study of recurring interaction patterns across online optical retail, not a formal competitive teardown of named platforms. It gave directional guidance — where the category's conventions helped, and where they asked too much too early — rather than features to replicate.

Understanding the category's blind spot meant tracing the journey it was failing.

Where did the journey actually break down?

Every other retailer sells you a product. Eyewear sells you a product it isn't allowed to hand over until it knows your eyes.

An eyewear purchase isn't a checkout with a product in front of it. It's a longer arc, and it carries a step no other retail category has: before a customer can buy, the system has to know their eyes. Mapping that arc showed where confidence was won or lost.

Read as one arc, the shape told me where to spend. The emotional low sits in the middle — Verify and Configure — exactly where a customer is asked to supply medical information and choose a product they can't evaluate by looking at it. That's where a showroom specialist earns their keep, and it's where the old experience went quiet.

The celebratory ends were the easy part. Discovery is a solved problem in retail, and a confirmation screen is a confirmation screen. The valley in the middle is where this project actually lived — and it's where most of the design went.

Seeing the arc whole made the reframe obvious.

How did you turn that into a design problem?

The old site collected decisions. The redesign had to make them — one at a time, in the right order, without ever showing its working.

The old site treated every screen as a place to show products. I decided every screen should be a place to move a purchase forward — leading a customer toward the next decision, then holding the complexity one layer down for when they actually need it.

A storefront isn't a catalog. It's a specialist who happens to be an interface.

That reframe changed every downstream choice. Instead of a catalog with a form bolted to the end of it, the experience became a sequence of moments that each answer a real question a buyer is asking — which frame, will it fit, is my prescription right, which lens, can I trust this — with the technical depth available but never mandatory before its moment.

I stated the problem across four lenses, to keep a three-party team — JuneIT building it, Tabby powering payment, Magrabi owning the brand — honest about whose problem this actually was:

Which let me frame a year of decisions as one question:

How might we help a customer browse, verify, and buy prescription eyewear online — with the confidence a specialist would give them in the showroom?

Naming the customer as the whom was deliberate. This experience touched a payment partner, an agency's engineering team, a brand's marketing, and a retail operation with 150+ stores — each with a stake in what the site showed and how. Fixing the whom stopped the storefront drifting into everyone's requirements at once.

That principle needed a structure. Three decisions turned it into one.

How do you structure a purchase this complicated?

You don't structure forty screens. You structure the three decisions every one of them inherits, and let the rest follow.

Before touching a single screen, I fixed the frame the whole purchase would share. Three architectural decisions did most of the work, and every screen in the system inherits them.

The prescription is an object, not a step

The obvious build is a prescription form buried inside checkout. I made it a saved, reusable profile that lives in the customer's account — and then surfaced it wherever it's needed. A returning buyer configuring lenses sees the prescription they saved months ago, already there. The prescription stops being a toll gate and becomes something the system remembers on the customer's behalf.

Discovery narrows before it asks

Nothing about the prescription is requested until the customer has a frame worth wanting. Filters, the frame-width tool, and category browsing all sit ahead of any personal data. The system earns the right to ask.

Each surface is native, not reflowed

Web and mobile share one journey, but not one layout. Filters are an inline panel on desktop and a full-screen sheet on mobile. Checkout is a linear three-step accordion on mobile because that's how a thumb works. Same system, two grammars.

Read as one change, those three decisions rewrite what the purchase asks of a person:

Here's that frame, traced as the path a customer actually walks.

What path does a customer actually walk?

Strip away the edge cases and every customer walked the same shape: discover, narrow, verify, configure, buy. The flow was that one path, made trustworthy.

A structure on paper is a hypothesis until you trace the paths through it. On Magrabi the flow wasn't a branching diagram of edge cases — it was one repeated shape, walked by every customer, every time: discover, narrow, verify, configure, buy. Getting that single loop right was the whole game.

Two sub-flows branch off that spine, and both exist to catch a customer the main path would otherwise lose.

The lens configurator

A four-step wizard — Personal Info → Prescription → Lens → Review — that sits between the product page and the cart. It's where the saved prescription earns its architecture: the customer's stored profile surfaces already filled, rather than sending them to their account and back. If no prescription exists, they can add one without leaving the flow. If they get stuck, WhatsApp sits at the bottom of every step.

The eye-test booking

A customer without a current prescription cannot complete a purchase. The conventional answer is a dead end. Instead, a four-step booking flow — Test Type → Store → Date & Time → Details — converts that customer into an appointment, and the appointment into a prescription, and the prescription back into the purchase they came for.

An honest note on flows. No formal flow diagrams survived from the project — the paths were worked out on paper and whiteboard, then carried straight into high fidelity. What's shown here is the real repeated structure, described rather than reconstructed as artifacts after the fact.

Designing the eye-test branch with the same care as the purchase path is the whole argument of this project in one diagram. A customer who can't buy today is not a failure state. They're a customer the system hasn't finished helping yet.

Those paths had to become screens. The process behind that move was deliberately light.

How did you get from sketch to screen?

Three rungs, no ceremony: a sketch, a whiteboard, a high-fidelity screen. Fidelity was a means, never a deliverable.

The fidelity ladder was short by design. Ideas were drawn by hand, argued over on a whiteboard, and carried straight into high fidelity — three rungs, no intermediate deliverable.

Two ideas survived those sessions into the final product, and everything in the high-fidelity work traces back to them. First, that discovery had to narrow before the system asked for anything personal — no prescription request until a customer had a frame worth wanting. Second, that the prescription had to be a saved object rather than a checkout step, because a customer who has to re-enter their powers on every order will not place a second one.

An honest note on artifacts. No formal wireframe or flow-diagram stage survived — the whiteboard was the wireframe, and the sketches were working documents, not deliverables. I'd rather show the real structure than reconstruct diagrams after the fact. What follows are the delivered high-fidelity designs — the production design as handed to the client.

Filled with real content, across both surfaces, that thinking looks like this.

What did it actually look like?

Forty screens, but only a handful of real decisions. These are the ones where the interface had to do a specialist's job.

I won't walk through all forty-plus screens. Instead, here are the decisions that mattered most — the places where the interface had to do a specialist's job — and why each one looks the way it does. Both surfaces are shown throughout: web and mobile share one journey, but not one layout.

Discovery · narrowing before asking

A large catalog is only an asset if a customer can get through it. On desktop, filters sit inline with the grid — brand, shape, frame type, fit, colour, material — so narrowing never costs a page. On mobile the same facets become a full-screen sheet, because a thumb can't work an inline panel and a mobile customer needs to see every facet at once before committing to one.

Web

The same six facets, two grammars. Desktop keeps the grid visible while filtering; mobile trades the grid for a complete view of the choices. Both close with a live count — Showing 123 products on web, See 192 items on mobile — so a customer always knows what their choices cost.

Shape, frame type, and fit are rendered as icons on both surfaces rather than words. A customer who can't name "aviator" can still recognise it — and in a category where the vocabulary belongs to the optician, not the buyer, that matters more than it sounds.

Colour as swatches, not a dropdown of names. The facet answers the question in the currency the customer is actually thinking in.

Fit · the question a mirror would answer

The hardest thing to judge online is whether a frame will suit your face. A showroom answers it with a mirror and a specialist. So I designed a tool that answers it with arithmetic instead: measure your existing glasses, or hold a credit card to your face. Both routes end in the same place — Small, Medium, or Large — and route straight into filtered results.

The design decision underneath it: never ask a customer to guess. Every route through the tool ends in a filtered set of frames that will actually fit, not a size chart they have to interpret.

The product page · where retail meets optical

A conventional product page sells a thing. This one has to sell a thing and collect a medical parameter before it can be added to a cart. The prescription selector sits directly beneath the price, above the button — not tucked into a later step — so a customer understands from the first screen that this purchase asks something of them.

Three things share that column with the price. Insurance benefits, because in this market a meaningful share of eyewear is claimed rather than paid. An eye-exam booking link, because a customer without a current prescription isn't lost — they're one appointment away. And a WhatsApp escalation, because when the interface can't answer, a person should.

The prescription · reassurance, not a toll gate

This is the step everything depends on, and the step most likely to lose a customer. A prescription is medical information, it's tedious to enter, and getting it wrong means an expensive, personal mistake arriving in the post.

So I designed it as a saved profile rather than a form. A customer enters their powers once, uploads the document once, and the system carries it forward — across surfaces, across orders.

Web

Two decisions carry this. The requirement is stated before it blocks — "prescription document should match the National ID," said up front rather than as a rejection after the fact. And the upload can be skipped, with the constraint named honestly: mandatory before payment, not before browsing. The gate exists, but it sits where it belongs.

The lens · explaining what can't be seen

Lens selection is where a considered purchase most often stalls. The customer is choosing a product they cannot see, hold, or evaluate, priced in a way that materially changes the total. Left unexplained, it reads as an upsell.

The lens configurator is a four-step flow — Personal Info, Prescription, Lens, Review — that sits between the product page and the cart. It's where the saved prescription earns its architecture: the customer's stored profile surfaces in context, already filled, rather than sending them to their account and back.

Three decisions here. The tiers are named for the benefit, not the material — "Protection & Comfort," not "polycarbonate 1.59." Each carries a plain-language sentence explaining what the customer actually gets. And the subtotal builds in view: model, plus lens, equals total. A customer choosing the more expensive lens sees exactly what it costs at the moment they choose it, which is the opposite of an upsell.

The configurator is mobile-native by necessity — a four-step wizard with a persistent product thumbnail and a WhatsApp escalation at every step. On a phone, a customer working through medical parameters needs to see the frame they're buying and a way out to a human. Both are always on screen.

A clean happy path is the easy part. The real test was everything that could go wrong inside a purchase this personal.

Desktop · Search results

A conventional product page sells a thing. This one has to sell a thing and collect a medical parameter before it can be added to a cart. The prescription selector sits directly beneath the price, above the button — not tucked into a later step — so a customer understands from the first screen that this purchase asks something of them.

Desktop · Prescription upload

A conventional product page sells a thing. This one has to sell a thing and collect a medical parameter before it can be added to a cart. The prescription selector sits directly beneath the price, above the button — not tucked into a later step — so a customer understands from the first screen that this purchase asks something of them.

What about when things aren't clean?

A flow is only as trustworthy as its worst moment. In prescription eyewear, the worst moments are where most of the design actually lived.

A purchase flow is only trustworthy if it holds up when things aren't clean — and in prescription eyewear, they often aren't. Most of the design judgment lived here, in the states a polished mockup never shows. Each of these had to stay honest to the customer without turning the screen into a wall of warnings.

The item that can't come back: Prescription products are made for one person's eyes — many can't be exchanged or returned. That restriction is stated on the cart line item itself, before checkout begins, not discovered in a returns policy after the fact. A constraint told early reads as honesty; told late, it reads as a trap.

Cash on delivery, priced plainly: COD carries a surcharge. It's shown inline with the payment option — Cash on Delivery +15 AED — at the moment of choosing, so the order total never moves after a customer has committed to it.

The prescription gate, placed where it belongs: A prescription document is mandatory — but mandatory before payment, not before browsing. A customer can skip the upload, keep configuring, and come back; the requirement is stated up front and enforced only at the moment it truly matters. The gate exists without becoming a wall.

The store that doesn't offer the service: In the eye-test booking, a customer can pick a test their chosen store doesn't run. Instead of a dead end or a silent failure, the state says exactly what's wrong and what to do — this service isn't offered here; pick another store at the next step. The booking survives the mismatch.

The upload that hasn't finished: A prescription document mid-upload shows its progress explicitly — filename, percentage, a cancel affordance — because a customer who can't tell whether the hard part worked will do it again, or give up. Completion is confirmed just as visibly.

The customer with no prescription at all: The largest edge case is a person, not a state: someone who wants to buy and simply doesn't have a current prescription. The conventional answer is a dead end. Here, it routes into the eye-test booking — an appointment that becomes a prescription that becomes the purchase they came for.

The through-line: every one of these had to be legible to a busy customer and honest about what it was, at the same time. That balance never resolved into a formula — it was a judgment call on each screen.

None of those judgments were made alone. The decisions were sharpened against the people who had to build, sell, and own them.

Who else shaped this, and how?

One designer doesn't mean one author. In a three-party build, the design survived only because the partnership around it did.

I was the only designer, but the product was shaped in partnership — and in a three-party delivery, the shape of that partnership decided whether the design survived contact with reality.

The PM and Delivery Head set the rhythm: Working sessions with JuneIT's Project Manager and Delivery Head were where the real product decisions got made — business priorities and delivery constraints on their side, flows and structure on mine, resolved on a whiteboard before the session ended. Because there were no heavy wireframe deliverables, this rhythm was the quality gate: a decision either held up in that room or it didn't ship.

The client kept the brand honest: Magrabi's team brought the thing no agency can supply: what their customers actually ask at the counter, what the showroom promise means in practice, and where a screen would feel beneath the brand. Client-facing meetings weren't approval theatre — they were where the specialist's real behavior got translated into interface behavior. Their content team owned the final microcopy, which is why placeholder text appears in some screens shown here.

The payment partner was a fixed point: Tabby's integration had to sit inside the checkout — a constraint, not a canvas. Designing around a fixed payment component meant the trust-building work had to happen before the customer reached it: the order summary that never surprises, the surcharges declared at selection, the confirmation that recaps everything. By the time the customer touched the payment step, there was nothing left to doubt.

In a three-party delivery, the design that survives isn't the most polished one. It's the one every party understood the same way.

Through all of it, one question kept every decision pointed the same way: what would success actually mean?

How would you know it worked?

I didn't own the measurement — but I owned the target. These are the moments an eyewear purchase is genuinely won or lost.

A design is only as good as the goal it's measured against. Before building, I was clear about what this redesign had to move — not vanity numbers, but the moments where an eyewear purchase is won or lost. The job to be done sat underneath everything:

That JTBD translated into the outcomes the redesign was built to influence — the things I'd have instrumented against if measurement were mine to own:

The point was never a faster click for its own sake. It was a surer one — a customer finishing a genuinely hard purchase with less doubt than the old experience ever allowed.

Measured against that bar, here's where it landed.

What did you actually deliver?

Not a prototype, not a concept deck. The full purchase system shipped — live on web and mobile, the whole journey, in production.

The complete purchase system was designed, delivered, and launched on magrabi.com/ae-en — the full journey from discovery to checkout, native on web and mobile, carrying the flows this study has walked through:

A note on metrics. Business-impact measurement was owned by the client after delivery, and I don't have access to post-launch analytics — so I won't invent numbers to fill the gap. What I can state plainly is what the redesign was built to move: completion at the prescription and lens steps, checkout confidence, prescription reuse across orders, and the conversion of prescription-less visitors into eye-test bookings. My involvement ended at delivery in January 2024; the live site has continued to evolve since, so the screens in this study show the design as delivered, not necessarily the site as it stands today.

Shipping something this large, solo, across three parties, wasn't clean. The honest half of the story is what was hard.

What was the hardest part?

Every honest case study has a second half. This is where I stop describing what worked and name what didn't come easy.

Every honest case study has a second half. This is mine — three things that were genuinely difficult, named plainly, because they shaped the work as much as any principle did.

Three parties meant every decision traveled: A decision made in a JuneIT working session still had to survive the trip — to the client who owned the brand, to the payment partner whose component it touched, and back to the engineers building it. Most decisions made the journey intact; some arrived changed, and I'd find out when a build didn't match the intent. The whiteboard rhythm reduced this — decisions made in front of everyone travel better — but it never eliminated it. Coordination friction wasn't an interruption to the work. On a delivery shaped like this one, it was part of the work.

The prescription flow refused to be solved once: The hardest design problem in the project was also the one I redesigned the most. Powers, cylinders, axes, two products with different parameter sets, a mandatory document, an ID-matching requirement, and a customer who may have none of it to hand — every version that satisfied one case broke another. It took many iterations to land on the shape that shipped: the saved profile, the visible upload status, the skip-until-payment gate. I'd love to say the elegant answer arrived early. It didn't. It arrived after the inelegant ones failed.

Two surfaces, one designer, no slack: Designing web and mobile as genuinely native experiences — not one reflowed into the other — roughly doubles the decisions without doubling the time. As the sole designer, I was the only continuity between the two, and stretches of the project ran on that continuity alone. It held, and the consistency of the delivered system is the evidence. But "it held" is not the same as "it was sustainable," and I'm careful not to confuse the two.

And with distance, a few things I'd approach differently.

What would you do differently?

None of these broke the work. All of them taught me something I carried into the next one.

None of these undercut the core — but naming them honestly is the difference between someone who shipped a system and someone who learned from shipping one.

Pressure-test the hardest flow first, not longest: The prescription and lens configurator was the most demanding flow in the project, and it consumed the most iterations — partly because I arrived at its hardest cases after easier patterns were already set. If I did it again, I'd design the prescription flow first and let it stress-test every structural decision early. A pattern that survives the worst case is proven; one tuned on the easy screens has to be renegotiated when the hard one arrives.

Make surface parity a commitment, not an intention: Web and mobile were both first-class in principle, but in practice the surfaces matured at different speeds, and keeping them in step was a continuous manual effort rather than a defined checkpoint. I'd now define parity explicitly at the start — which flows must exist on both surfaces, to what depth, verified when — so that "native on both" is a commitment with a definition, not a direction with a hope.

Even with those, what I carry from this project is bigger than any one screen.

What did this teach you?

The largest system I've owned end to end — and the one that reshaped how I approach every project since.

This was the largest consumer purchase system I've owned end to end — two surfaces, a year of flows, three parties, one designer. It taught me things I've applied to everything since.

What changed in my thinking I came into this project believing good commerce design was about removing friction — fewer steps, fewer fields, faster checkout. Magrabi rewired that. In a purchase this personal, the customer isn't looking for the fastest path; they're looking for enough reasons to believe. Some friction is where the believing happens: the visible upload confirmation, the surcharge declared before it's charged, the lens explained before it's priced.

So the question I now ask of any commerce screen has changed. Not "how do we get them through this faster?" but "what does this person need to see to feel certain — and have we shown it before they had to wonder?" Confidence, it turns out, converts better than speed. Speed just decides how quickly someone reaches the moment where confidence is tested.

The best thing I did on Magrabi was give an interface the job a specialist had always done — so a customer alone with a screen at eleven at night could buy something personal, and believe in what was coming.