GATORE

Designing for Two Distinct Users

The hardest design challenge on GATORE was serving two very different audiences within a single product. A customer discovering a new café thinks nothing like an owner managing a Saturday night rush.

That meant two separate design contexts — different information architecture, different interaction patterns, and different definitions of success for each side.

One Front Door: Sign In & Get Started

Customers and café owners both need to sign in, but a single generic login form wasn't going to cut it for either of them. Before landing on tabs, I played with a couple other options — separate sign-in buttons in different parts of the site, or just putting the business portal on its own site entirely. Neither felt right; both could leave someone stuck on the wrong side with no quick way back.

So I went with one shared page and put tabs at the top to switch between Customer and Business, defaulting to Customer since that's most of the traffic. Get Started (creating an account) uses a dropdown instead, since that's a bigger commitment — but even if someone picks Customer there, they can still hop over to the business portal with the tab on that same page.

Tabs also just made the page easier to build and host, but that's not the real reason I picked them. What sold me was the recoverability — land on the wrong side, and you're one click from fixing it instead of hitting a dead end. It's also one URL to remember, which matters for people who wear both hats, like a café owner who's also a customer somewhere else. And honestly, it just fits GATORE better: one platform for both sides.

Making Signup Feel Less Like a Form

Account creation had to ask for a lot — profile info, game preferences, group size — and cramming all of it onto one page felt like the fastest way to lose people. I split it into a five-step wizard with a progress bar up top, so it's always clear how much is left instead of one long, dread-inducing scroll.

For game preferences specifically, I skipped the standard checkbox list and used colorful icon tiles instead — Strategy, Party, Card Games, Co-op, and so on, each with its own color and icon. That was mostly about making the step feel more playful than a form, though it doubles as a faster visual scan than reading a list of labels.

This step is also marked Optional. Preferences feed the recommendation engine, but I didn't want them gatekeeping account creation — someone can skip straight through and add preferences later instead of stalling out on step 5 of 5.

Not Every Reservation Needs an Account

Competitive research on other booking tools made this one pretty clear: almost none of them make you create an account just to book a single table. So on the "Your details" step of a reservation, I gave people a choice — sign in, or continue as a guest with just a name and email.

An account still has real upside. It's the only way to see your booking history, set game preferences, get recommendations, and track what you've actually played. But someone booking a table for the first time shouldn't have to buy into all of that just to sit down and play.

Guest checkout keeps the reservation flow itself lightweight, while the account benefits are pitched right there in the "Sign in" option — so people can see what they'd be getting without it being a requirement.