How the work
actually happened.

The operator sells charters that start around a few thousand dirhams. Every booking begins as an enquiry, so the entire business depends on a visitor being willing to start a conversation. The existing site described the boats accurately and still converted badly.

I interviewed the owner and the staff who answer enquiries, because they were the only people who could tell me where conversations actually died. That turned out to matter more than anything I could infer from the site itself.

Two things came out of it. Customers repeatedly asked the same questions before they were willing to enquire, and the answers were not on the page. And the owner could not change a price or a tour without paying someone — so the content was quietly going stale, which made the site less accurate the longer it stayed up.

I had framed this as a layout problem when I arrived. It was not. It was an information problem on the customer side and a maintenance problem on the business side, and the second one was slowly causing the first.

I designed the journey around the questions people actually asked rather than the structure of the old site, and made pricing transparent at the point of interest instead of on request — the single-price quote removed a round trip that the staff told me people rarely came back from.

I placed a knowledge-base chat assistant at the moment of hesitation rather than in a corner of every page, so it answers the specific question standing between someone and an enquiry.

The admin dashboard and content editor were designed so a non-technical owner can publish a price change without a developer. That was a design decision about who holds the keys, not a feature request.

Before launch I ran usability sessions on the booking flow with the client and with people using it for the first time. I watched where they slowed down rather than asking whether they liked it.

The hesitation clustered in the middle of the enquiry path, on steps I had considered necessary. I cut them. The flow shipped shorter than I designed it, which is the part of this project I am most pleased about.

I would test the admin side with the same rigour as the customer side. I designed the content editor carefully but validated it far less than the booking flow, and the owner is the person who has to live in it every week.

I watched people shop. The blocker showed up almost immediately and it was not what I expected: they knew the occasion and they knew the feeling they wanted to convey, but they did not know what to order. They were being asked to choose between roses and eucalyptus when the thing in their head was an apology.

I designed a second entry point rather than replacing the first. The customer describes the feeling in their own words and the interface composes the bouquet from it; the stem-by-stem manual path stays for people who would rather control every element. Removing choice from someone who wants it is as bad as demanding it from someone who does not.

Arabic right-to-left layout and dark mode were designed from the first screen rather than retrofitted. Retrofitting RTL means discovering every hard-coded assumption about direction at the worst possible moment, and it shows in the result.

For checkout I stayed deliberately conventional — cart, Stripe, sign-in, same-day delivery selection across the seven emirates. The novelty belongs in discovery, where the customer is undecided. At payment, familiarity is the feature.

I would test the described-feeling path against the catalogue path properly, with the same people on the same task, instead of trusting that the observation generalised. I believe it does. I did not prove it.

A malicious QR code is invisible by design. A lookalike domain, a punycode homograph, a mixed-script substitution — all of them are engineered to survive a glance. The detection is solvable in code. The design problem is telling someone with no technical vocabulary that the thing they are about to open is not what it claims to be, in the two seconds they will give you.

The strictest decision was what the product refuses to do: it never opens a link on the user's behalf. A safety tool that navigates for you has to be right every time, and nothing is right every time.

It runs entirely on the device. Nothing the user scans leaves their phone — which also means the product cannot quietly become a log of everywhere they have been.

The warning shows what the domain claims to be alongside what it actually is, because the gap between those two is the whole story and it is more persuasive than any severity label.

I tested the warning screens with non-technical users, and the question was narrow: without me explaining anything, do you know what this is telling you and what you should do?

The first wording failed that test. It was accurate and useless — it described the mechanism instead of the consequence. I rewrote it around what it means for the person holding the phone, and kept testing until the danger landed without explanation.

I would test the safe case harder than the dangerous one. A scanner that makes people anxious about legitimate codes has failed differently, but it has still failed, and I spent most of my attention on the warning state.