NineSmart Booking System

Challenge

The original booking system was built specifically for room reservations, using a tree structure for categorization: Building (Location) → Multi-functional Room (Room Category) → Speech Hall (Room Name). That hierarchy locked the module into room bookings only; it couldn’t flex to handle events, classes, or membership products without a structural rebuild.

Approach

Making Sense of an Undocumented Legacy System

The system had evolved over time with many functions and data flows left unclear or undocumented. I started by reviewing what legacy documentation existed and tracing how each feature connected to the underlying reservation, availability, and scheduling logic, to build a foundational understanding before touching anything.

From there, I reverse-engineered a detailed service flow diagram — mapping every step from login to booking confirmation — to surface unclear decision points, redundant logic, and opportunities to simplify the user journey. That diagram became the shared reference for design, PM, and engineering.

Mapping the Real User Journey

I built a user journey map covering the full booking process — from initial search through order checkout to post-booking review — structured into three phases: Searching, Ordering, and Post-Booking Review. Mapping it end to end surfaced three recurring pain points: inconsistent approval logic, unclear error feedback, and confusing booking types.

I also defined two user scenarios to design against:

• Goal-oriented users know exactly what they need — booking a specific meeting room with specific time, location, and features. They succeed when labeling is clear, availability is visible at a glance, and search/filter actually narrows things down.
• Exploratory users don’t have a fixed target — browsing for an event or class without specific preferences. For them, the old hierarchical structure was actively hostile: they’d repeatedly backtrack between groups just to compare options, which became genuinely frustrating once the catalog scaled past 50+ items.

Scoping the Redesign

I created a color-coded, functional site map spanning both user-facing features and backend admin tools, to align PMs and developers on exactly what would change.

Solution

The redesign needed to flex across office spaces, hotel rooms, events, and classes — not just rooms. I replaced the rigid hierarchy with two mechanisms designed to work together, so a user can quickly narrow down options to the one they actually want.

• Dual-layer filter. A first layer of time-based filtering — Location, Date/Date Range, Time/Time Range — applicable to any time-sensitive item, from venue bookings to course reservations to seasonal ticket purchases. A second layer of tag-based refinement sits on top of it (text tags, numerical data, and both item-level and global configurations), which clients manage themselves through the backend without needing engineering involved.
• Tag-based grouping. Items can now carry multiple tags instead of sitting in one fixed category — a meeting room can be tagged as both a multi-functional room and a lecture room simultaneously. This bought three things at once: items can be categorized multiple ways instead of forced into one hierarchy branch, users can combine tags to search more precisely, and admins can add, remove, or edit tags without any structural changes to the system.

Outcome

The redesign handled room bookings, membership redemptions, and class registrations in one flexible system, exceeding sales targets and broadening the client base. The booking module was adapted into a venue booking platform for an NGO and a luxury clubhouse in Hong Kong, and a membership redemption system for a Web3.0 game project. It was later combined with other modules and deployed across websites, mobile apps, tablets, and kiosks, ultimately selling to a large real estate developer in Hong Kong — successfully attracting three new clients to purchase the product.

Rethinking a fundamental structure — replacing a fixed hierarchy with a flexible filter-and-tag system — turned out to remove a business constraint, not just a UX one.