UX writing / UX Design / Terminology

©Quandoo Gmbh 2020
Based in Berlin, Quandoo is a restaurant reservation platform whose products support an end to end network of web-based services ranging from diner reservations online, to restaurant service and online reservation management for restaurateurs.
As the main UX Writer, it’s been my task to take ownership of the voice and tone required for Quandoo’s nascent entry-level online reservation service, Book.
One of my more memorable quests was finding the right terms to simplify scheduling parameters and articulate the core function of empowering restaurants to automate reservation acceptance based on their needs.
A bit of context: at the time, Book had recently been developed as MVP for a new generation of B2B products with updated designs meant to phase out legacy products and steer the company from sales/request-driven products to scalable, value-driven products.
There had never been a content strategist involved until I came along.
Given the complexity of the hybrid architecture behind Book’s reservation system, some investigation into the app’s future relationship with Quandoo’s higher tier apps was required.
Once it was established what services were to be used and how, next it was up to the team and I to define the identity of the feature.
Although the feature actually required configuring two parameters (time availability and capacity) to work, the core idea was to provide restaurants with control of their online reservation
capacity — which spawned the internal working title “Live inventory”.
Needless to say, “inventory” was nowhere near representative of what a restaurant worker would attribute to “how to regulate my online reservations”.
After a few twists and turns from the product front, the initial, logical name for the feature was “Reservation settings” as this area would regulate when, and to what capacity a restaurant would receive incoming reservations online.

The problem here turned out to be an inherent ambiguity in the word “reservation” that I validated through an in-person 5 second test.
During that particular on-site testing session at a partner restaurant, 2 out of 3 restaurant workers weren’t clear on whether this section dictated default settings for individual reservations or settings for the overall reservation stream, as intended.
This is because in the restaurant industry, “reservation” is attributed to both the act of itemizing access to a space at a future time, and the duration of the event while it takes place. Think of it like using the same word for “ticket” and “concert”.

The setting for one of our lunch 'n' learn site testing sessions.
Also, while the “capacity” tab was clear to testers even without reading the description, the “hours” tab seemed to over-simplify, (considering these hours are set apart from their actual opening hours) leaving users globally confused about what the feature did.
Then there was the relationship to other existing products. Which also required alignment with the overall business strategy.
With the necessary insight gathered, deciding on the terminology was firstly, a matter of weighing these factors in order of importance:
Then it was possible to settle on terms that were the simplest, least ambiguous, and best suited to facilitate:

©Quandoo GmbH 2020
Settling on “Availability settings”, this encompasses the goal of identifying where the restaurant can regulate their volume of reservations taken online. Being a reservation platform, context was strong enough to waive the need to be explicit here.
On the other hand, it was necessary to articulate the difference in time settings so here “hours” becomes “Reservation hours” and in the account settings, their regular opening hours are named “Business hours”.

©Quandoo GmbH 2020
The reason behind using “Business hours” instead of “Opening hours” has to do with an existing parameter in that older, more complex product who’s time to change had not come yet.
But that’s another story.