DigiButler
A premise-based guest-engagement ecosystem connecting hotel guests with services and the staff responsible for fulfilling them.
Context
DigiButler used the in-room television as a gateway to hotel information, entertainment, services, ordering, and communication. Each guest-facing action connected to hotel operations and the staff responsible for fulfilling it, supported by desktop, tablet, and mobile tools.
The system was premise-based and could operate without depending entirely on internet connectivity. For guests, the goal was easier access to hotel services from the room. For staff, it was a clearer way to receive requests, monitor activity, and manage interactions. For the hotel, the TV offered another surface for making facilities, menus, and services visible.
The Problem
How could a complex hotel-service ecosystem feel simple to a guest while still supporting the operational work behind every request? The existing experience combined a legacy Android application with manual staff processes, so improving the television interface alone would not solve the full product problem.
Users
Guests needed a low-friction way to discover and request services from the room. Staff needed the corresponding operational view to receive requests, handle orders, respond to inquiries, and track fulfillment.
Constraints
The guest experience had to work from a standard remote at a 10-foot viewing distance, run responsively on older TV hardware with limited processing power, and account for premise-based connectivity. We also had eight months to deliver within an existing technical environment.
Role & Approach
Owned
The guest-facing TV experience was my main responsibility. I shaped its interface direction, defined how it worked with a remote, and carried those decisions into the frontend build.
Contributed
On the staff side, I helped turn the same service and ordering concepts into practical workflows for desktop, tablet, and mobile.
Collaborated
This was a team effort with 4–5 designers and 12 developers. Working across design and frontend meant I could raise hardware constraints early, talk through tradeoffs with the team, and help keep the built experience close to what we intended.
Discovery
Conversations with stakeholders and walkthroughs of hotel operations changed how we framed the product. A guest request was only half the experience. The staff still needed a clear way to receive it, track it, and complete it.
Key Design Decisions
The Solution
The delivered product connected in-room discovery, entertainment, service requests, ordering, and communication with the operational tools staff used to respond. The TV kept guest tasks focused and remote-friendly; staff surfaces exposed the detail and status needed for fulfillment.
System & Engineering
The product shared terminology, service and order concepts, data models, and workflow rules across platforms. Implementation remained platform-specific: TV components handled focus navigation, remote input, viewing distance, and constrained hardware; operational surfaces supported dense status and monitoring work; tablet and mobile supported portable tasks. Working in both design and frontend helped me translate these product decisions into maintainable components without forcing one interface pattern everywhere.
Outcome & Reflection
Delivered
The full ecosystem shipped across four platforms: TV application, web dashboard, tablet, and mobile. The product launched and was used operationally for over two years.
Results
The product connected guest-facing actions with the operational workflows needed to fulfill them. Its intended value was easier service access for guests, clearer request handling for staff, and another surface for hotels to present facilities, menus, and offerings.
Biggest Win
The successful launch and sustained operational use for two years. The product became part of how the hotel ran its daily operations, which is the real measure of whether a product works.
Fell Short
Over time, the product changed without consistent design stewardship, and some interaction quality regressed. Several features were also cut to meet delivery constraints and were not revisited.
Learned
This project taught me that performance, operational reality, and implementation constraints are part of design quality. Remote interaction forced us to clarify navigation, while the staff workflows showed why a polished guest screen is incomplete without a coherent fulfillment system behind it.
Would Improve
Today I would establish shared product foundations and focus-navigation rules earlier, validate operational workflows more deeply, and preserve design stewardship after launch rather than treating design as finished at delivery.
How It Influenced My Work
DigiButler shaped how I approach multi-surface products: share the underlying concepts and workflows, then let each platform respect its users, input model, and operating conditions.
Credits
DigiButler was a team effort by IntegrityNet's Creative Team and Software Development Team.