No shared availability view
Requesters could not confidently see whether a camera, microphone or studio slot was already committed.
Nestlé · Service design · Enterprise UX · Development
From informal studio requests to a traceable asset lifecycle.
A booking and return service designed to replace mostly offline coordination with visible availability, structured approvals, active-loan tracking, return checks and automated communication.
01
Context
The real problem was coordination hidden inside conversations.
Studio assets were largely requested through informal offline channels. Availability lived in people’s heads, chats and follow-ups. Staff had to confirm what was free, coordinate hand-over, remember return dates and resolve asset-condition questions without one shared lifecycle.
Every request created coordination work
Studio staff became the human integration layer between requests, calendars, asset status and follow-up messages.
Hand-back was weakly documented
Condition checks, damage notes and evidence were difficult to keep consistent when the process was informal.
How might we make booking and returning studio assets self-service enough for employees, while giving studio administrators a reliable operational record?
02
Before state
A simple request could span several disconnected touchpoints.
1Ask informally
Message or speak to the studio team.
2Check manually
Admin confirms dates and gear availability.
3Coordinate
Clarify purpose, timing and accessories.
4Hand over
Equipment is loaned with limited status visibility.
5Chase and inspect
Returns and condition issues are handled separately.
03
Research
Four rounds of testing shaped the booking and administrator flows.
Testing started with manual Power Apps prototypes. Feedback exposed gaps in calendar clarity, asset selection, time-slot visibility and administrator control. Each round informed the next design revision.
Calendar and asset selection
Users needed clearer availability, categories and a simpler way to understand what equipment belonged together.
Summary and time slots
The design needed to show whether a room was free before submission and make the booking summary easier to review.
Administrator controls
Studio staff needed a dedicated view for bookings, active loans, returns and changes without relying on hidden app logic.
Prototype before automation
The team validated the interaction and operational states before connecting the full data and automation layer.
04
Service model
The redesign turns a request into a visible lifecycle.
Availability before asking
Requesters start with dates and asset availability rather than a chat with an administrator.
Approval as a state
Requests move through pending, approved, active, return and complete states.
Returns are part of booking
Condition checks and evidence belong to the same service rather than a separate informal process.
Communication follows the data
Power Automate sends confirmations, decisions, reminders and calendar invitations from shared status data.
05
Architecture
The operational design fits the existing Microsoft 365 environment.
Experience
Power Apps requester flow
→
Power Apps admin views
→
Return and inspection flow
Operational data
Microsoft Lists
→
Booking and asset states
→
SharePoint evidence and files
Automation
Power Automate
→
Confirmations and decisions
→
Reminders and status notifications
Prototype versus production design
The live React and Vercel build tests interactions. The intended operational implementation uses Power Apps, Microsoft Lists, SharePoint and Power Automate.
Development contribution
App screens and navigation
Developed requester, administrator and return paths in Power Apps, including state-dependent screens and navigation across the end-to-end service.
Lists and evidence
Defined booking, asset, bundle, return-issue and administrator structures, including evidence stored in SharePoint.
Triggers and conditions
Mapped request, approval, decline, cancellation, calendar and return-photo branches in Power Automate.
Power Platform build evidence
The detailed build behind the service.
The screenshots below come from the project presentation and document the testing, redesign, Microsoft Lists structure and Power Automate workflows.
Download the full presentationUser testing
Manual prototypes tested booking availability, summaries and administrator controls before the service logic was automated.
Redesign after testing
The revised experience separated booking types, clarified dates and declarations, exposed Outlook availability, improved browsing and created a dedicated administrator view.
Operational data
Microsoft Lists and SharePoint hold the booking record, asset catalogue, recommended bundles, return issues, evidence and administrator access.
Automation flows
Power Automate responds to booking and return states, sends the right communication and stores evidence against the operational record.
The service in screens
Requester and admin views share one lifecycle.
These screengrabs come from the deployed interaction prototype. The live prototype remains available for the full interaction.
Screen 1
Choose the type of booking
The first decision separates studio and equipment from equipment-only requests so the rest of the form stays relevant.
Screen 2
Give requesters visibility into their bookings
My Bookings makes request status, dates and progress visible without another follow-up message.
Screen 3
Give admins an operational overview
The dashboard surfaces pending approvals, active bookings, return work and completed activity so the team can manage exceptions instead of rebuilding the queue.
Screen 4
Manage the approval queue
Booking management centralises approval decisions, request details and status changes in one operational view.
Screens 5–6 · Edit booking
Administrative edits are deliberate and traceable.
Selecting Edit Details first surfaces an override warning. The administrator can then update the user, date, selected assets and inspection notes without changing the booking silently.
Screen 7
Track what is currently out
Active-booking views reduce ambiguity around who has which equipment and when it is due back.
Screen 8
Bring returns and quality checks into the same service
Returns become a formal stage with condition checking rather than an informal hand-back with no consistent record.
08
Outcome
The service replaces invisible coordination with explicit states and shared evidence.
Requester clarity
Employees can see the booking path and status instead of relying on informal follow-ups.
Admin control
Approvals, active loans and returns become visible operational queues.
Traceability
Structured data, SharePoint evidence and automated communication create a clearer record of the asset lifecycle.
Impact still to validate
The next useful measures are booking turnaround, manual follow-ups, conflicting requests, overdue returns and condition issues. The case study does not claim unvalidated productivity percentages.
Reflection
The interface mattered, but the larger design problem was operational visibility.
As the Power Apps Developer, Business Analyst and UX/Service Designer, I combined interaction design with app development, data architecture and automation. The solution used tools the organisation already supports while keeping a separate live prototype for testing the experience.
Open live prototype