top of page
LOKE Online & Scheduled Order Management
Designing a flexible scheduling system for merchant operations
Senior Product Designer
Platform
Desktop
Product
SaaS
Project Timeframe
In Progress
Role
LOKE is a hospitality technology platform providing white-label loyalty, ordering, and operational tools to enterprise and multi-location brands. Alongside its customer-facing products, LOKE Office serves as the merchant administration platform for managing online ordering operations.
Scheduled ordering was historically controlled through legacy POS integrations rather than natively within Office, limiting merchant visibility and flexibility over availability and future orders.
The Challenge
The challenge was to bring scheduling natively into LOKE Office. The goal was to redesign the existing system to create a clearer, centralised method for managing order timing, availability rules, and operational overrides.
Project Summary
Before redesigning the system, I took time to understand how the existing scheduling setup actually worked. I mapped out how trading hours, deferred orders, overrides, and pause states interacted, and where things started to break down.
User Insights
I then spoke with merchants to understand how these limitations affected their day-to-day operations. The themes below highlight recurring friction around control, rule clarity, and confidence in managing online orders.
Discovery: Understanding the Scheduling System
On configuring availability windows
"I need more flexibility in how far in advance customers can order. The rules are too rigid"
Theme: Lack of flexible rule configuration
On blackout dates
"There's no simple way to block out busy dates without it affecting everything else"
Theme: High risk and unintuitve overrides
On online order management
"I want to be able to manage my online order settings in one place - not across different systems"
Theme: Lack of a single source of truth
On unstable configuration
"I'm hesitant to change settings because if I get it wrong, online ordering could break"
Theme: High risk of configuration errors
On rule conflicts
"I updated our trading hours but when I need to have an override rule, I'm never sure if it will work"
Theme: Ambiguous rule hierarchy
Key Friction Points
No direct Office configuration limited control for merchants
Confusing scheduling behaviour and outcomes
No simple merchant configuration for scheduled ordering
Outdated architecture and limited scalability of existing timeslots
Analysis & Planning: Designing Scheduling Architecture
Collaborative Workshops
Together, we sketched on a whiteboard then created digital diagrams from these using Gemini to better visualise:
• The relationship between standard and scheduled orders
• How availability rules were applied
• How overrides interracted with standard trading hours
To untangle the complexity of the existing scheduling system, I partnered with the Product Manager and two Engineers to run a series of collaborative workshops. Our goal was to map how scheduled ordering interacted with the broader online ordering ecosystem.
Visualising logic dependencies
Merchant setup settings
Standard + scheduling logic
When we mapped the system, we realised the real challenge wasn’t just individual rules - the complexity came from how they depended on each other.
• Scheduled orders were tied to standard online ordering hours
• Both required buffer times within operating hours so the kitchen wouldn't get overwhelmed.
This dependency made it hard to visualise how availability was calculated until the logic was laid out side by side.
Designing a configuration model that clearly supported both standard and scheduled ordering without conflict became the core challenge.
System Mapping
After visualising the logic side by side, I created a clear scheduling hierarchy. This defined how rules should be layered and evaluated.
How scheduling rules are decided
• Location operating hours are the foundation
• Standard online ordering hours are derived from operating hours
• Scheduled orders are layered within standard hours, with defined buffers and pause states
• Overrides exist outside regular hours
Defining the Merchant Configuration Flow
To make the merchant setup process clearer, I mapped out how merchants configure both standard and scheduled orders from start to finish. There were many moving parts - opening hours, buffers, pauses, date rules, and overrides. This meant it was easy for things to conflict.
While building the flow, I used ChatGPT to help define different scenarios and spot gaps in the logic. This helped me simplify the structure and make sure both order types followed a clear, predictable path.
Interaction Design
Rapid Wireframing using the Office Design System
To explore interface directions quickly, I again used ChatGPT to generate structured prompts for UX Pilot, referencing existing Office components and patterns.
This allowed me to:
• Rapidly produce low-fidelity wireframes aligned to the design system
• Test how the new scheduling model could be expressed clearly in the UI
• Refine how hierarchy, rule grouping, and override visibility are displayed
• Reduce cognitive load while reasoning through complex rule interactions
Step 1:
• I introduced new dedicated Ordering Hours architecture to the Office interface
Step 2:
A. Set online order hours within operating hours
B. Then determine online order overrides
Step 3:
A. Set Scheduled Order hours + buffers
B. Then determine Scheduled Order overrides
Prototyping & Validation
Using Figma Make, I developed an interactive prototype to validate scheduling logic, override precedence, and buffer behaviour to test my design. This allowed feedback from the engineers and stakeholders to test the interactions, align on expected system behaviour, and reduce ambiguity during the build. The final implementation aligns with the existing Office Design System to ensure consistency and scalability across the platform.
What this achieved:
• Clarified rule precedence between global hours and overrides
• Identified edge cases before development (buffer conflicts, availability gaps)
• Increased alignment between product, design and engineering
Visual Refinement & Clarity
• Introduced clearer and systematic hierarchy to separate global schedules from overrides
• Used visual grouping and spacing to reduce cognitive load
• Made it clear when overrides take priority over standard hours.
Impact & Outcomes
Established scalable framework
Created a framework capable of supporting additional order types and future constraints.
Clarified rule precendence
Made sure overrides and standard hours behave predictably across scenarios
Reduced implementation risk
Validated edge cases in development through prototyping
Removed legacy POS constraints
Replaced POS-inherited limitations with a clearer global and override model
Reflections
• Using AI tools for structured prototyping and ideation made complex configuration interfaces faster to explore and iterate on
• Automating repetitive layout work allowed greater focus on system logic and behavioural clarity
• In complex SaaS products, investing in architectural clarity early in the development process significantly reduces implementation friction down the track.
bottom of page