Stakeholder interviews
Understood how requesters, coordinators and service teams exchange information, make decisions and recover when information changes.
Enterprise service design case study
Captivate: turning a static visit request form into a shared coordination workspace.
Captivate is an internal enterprise platform used to plan client and leadership visits across office locations. I combined stakeholder walkthroughs, heuristic evaluation and workflow research to identify why users relied on calls, email and chat—and translated those findings into a progressive, multi-location planning and service-tracking experience.
RoleUX Researcher / Interaction Designer
MethodsStakeholder interviews, walkthrough, heuristic evaluation
ScopeRequester journey and shared visit coordination
DeliverableInformation architecture, user flows and prototype
01 · Challenge
The context
A visit looked like one request, but operationally behaved like a network of changing dependencies.
Client and leadership visits require several independent teams to coordinate spaces, technology, badging, food and refreshments, stationery and experience support. A visit may involve one office, multiple offices in the same city, or several cities. Each meeting can have different attendees, timings, rooms and service requirements.
The existing experience treated this complexity as a single, largely tabular form. Users were expected to provide information before it was available, while service providers continued coordinating through email, official chat channels and scoping calls.
The design challenge was to make an evolving visit understandable and actionable for everyone involved, while keeping the request light enough to start before every detail was known.
Business and user tension
- Requesters wanted to reserve support early, even when guest lists and agendas were incomplete.
- Service teams needed reliable details before confirming availability.
- Coordinators needed a complete view across locations and service owners.
- The organization wanted to reduce manual follow-up and avoid unnecessary scoping calls.
02 · Research process
Triangulating the problem
I studied the product from three complementary angles.
No single method could explain both the interface friction and the operational breakdown behind it. I combined behavioural evidence from stakeholders with an interface-level evaluation and an end-to-end walkthrough of the existing process.
Existing product walkthrough
Mapped the request lifecycle from initial entry to assignment, service monitoring, notifications and visit completion.
Heuristic evaluation
Assessed navigation, visibility of status, error prevention, content hierarchy, accessibility and consistency with brand standards.
Stakeholder walkthrough: how the work actually happened
The walkthrough exposed a gap between the system’s apparent linearity and the real operational lifecycle. The request was only the beginning; coordination continued across several people and channels.
Existing workflow
Account team enters all available visit details
Coordinator schedules a scoping call
Request is assigned to service owners
Teams update Captivate, email and chat
Requester manually tracks confirmation
Requests arrived anywhere from two months to two days before a visit.
The workflow needed to support both early planning and time-sensitive requests without pretending all information would be known at the start.
Service teams worked to a 48-hour review expectation.
The product did not clearly distinguish response time from the minimum lead time required to deliver an individual service.
Users entered dummy data to finish the form.
This pointed to premature data requirements rather than carelessness or lack of compliance.
Status updates lived across chat, email and the admin tool.
Captivate lacked action-driven status updates and a reliable shared summary.
Heuristic evaluation
The interface review showed that visual and interaction issues reinforced the workflow problems. Users could not clearly understand where they were, what was required now, what could wait, or what would happen after submission.
Heuristic
Observed issue
Consequence
Visibility of system status
No reliable request summary or service-level progress after submission.
Users returned to email and chat to ask whether support was confirmed.
Match with the real world
A multi-location, multi-meeting visit was represented as one flat form.
Services became difficult to associate with the correct office, date or audience.
User control and freedom
Editing time, venue, catering or attendee details was not sufficiently supported.
Changes generated manual follow-up and uncertainty about affected teams.
Error prevention
Errors appeared late and required information was not explained contextually.
Users supplied placeholders or discovered blockers close to submission.
Recognition over recall
Users could not see current booking information while configuring later steps.
They had to remember dates, locations and counts while selecting services.
Accessibility and consistency
Content hierarchy, contrast, imagery, icon use and brand patterns needed improvement.
The dense tabular presentation increased cognitive load and reduced scanability.
Synthesis: the recurring themes
I grouped the findings by underlying cause rather than by screen. This prevented the redesign from becoming a collection of isolated interface fixes.
Information arrives progressively
A visit contains locations and sessions
Services have independent owners and statuses
Changes are normal, not exceptional
03 · Problems identified
From observations to design challenges
The findings resolved into six connected product problems.
Each problem was written in operational terms so that the design response could improve both requester usability and service-team coordination.
1. Premature completeness
Users had to provide detailed guest and service information before it was known.
→
Progressive commitment
Separate a preliminary support request from later attendee and service details.
2. Flat information model
One form could not elegantly represent several cities, offices and meetings.
→
Visit hierarchy
Structure information as Visit → Location → Session → Service.
3. Generic service capture
All services were requested in one place despite requiring different details.
→
Conditional configuration
Show questions appropriate to rooms, technology, catering and access.
4. One headcount for everything
Meeting room, lunch and refreshments could involve different numbers of people.
→
Session-level attendance
Assign attendees and quantities to specific sessions and services.
5. Fragmented status
Overall progress depended on manual email and chat updates.
→
Service-level tracking
Expose owner, status, questions and confirmation for every service request.
6. Changes broke the process
Updates after submission were difficult to communicate and revalidate.
→
Targeted revalidation
Reopen only the services affected by a material change.
04 · Design strategy
Reframing the product
The redesign positioned Captivate as a shared role-based coordination platform.
The redesign needed to support the lifecycle before, during and after submission. Instead of splitting requester and admin work into separate tools, I framed Captivate as one shared visit record with role-specific workspaces for requesters, coordinators, service owners and admins.
Ask for the right detail at the right time.
Make early submission possible, then use clear deadlines and readiness indicators for information that can follow.
Organize the interface like the visit itself.
Keep locations, sessions, attendees and services connected so users can understand dependencies without a scoping call.
Make ownership and consequence visible.
Every action should explain what was sent, who is reviewing it and whether a change affects confirmation.
The new model separates information readiness, service confirmation and actual visit status, while giving each role the actions and visibility they need from the same source of truth.
Proposed operating model
Future-state service blueprint hypothesis
I used the research findings and proposed interaction model to show how the redesigned service could operate across requesters, Captivate, coordinators, service teams, admins and supporting systems.
How to interpret this blueprint
This is a research-informed hypothesis—not a validated description of future operations. The frontstage journey is grounded in the walkthrough and prototype; backstage processes, ownership, integrations and measures require further validation.
- Validate service-team responsibilities and escalation rules.
- Confirm integration and change-impact feasibility with engineering.
- Establish operational baselines before using the proposed measures.
Information architecture and omnichannel interaction model
The architecture connects the visible navigation to the underlying visit hierarchy and shows how actions move between requesters, coordinators, service teams, admins and supporting channels.
05 · Design solution
Research translated into interaction
Each major interface decision directly addressed a research finding.
1
A task-oriented “My visits” dashboard
The old experience did not give requesters a useful summary after submission. The new dashboard prioritizes visits requiring attention, services awaiting teams and confirmed visits.
Evidence
Status updates were fragmented across email and chat.
Design decision
Show attention required, confirmation progress and the next primary action.
Expected effect
Reduce “What is happening with my request?” follow-ups.
My visits
3 need attentionTwo due this week
4 awaiting teamsWithin response time
2 confirmedNext visit in 12 days
2
Preliminary request before detailed planning
Users can create a workspace with basic client, purpose, dates, locations, approximate attendance and broad support categories. The interface explicitly states that services are not yet confirmed.
Evidence
Users entered dummy data when details were unavailable.
Design decision
Distinguish “required now” from “can be completed later.”
Expected effect
Improve data quality without delaying early coordination.
3
A persistent visit workspace with clear navigation
A compact visit context remains visible above tabs for Overview, Attendees, Locations & sessions, Services, and Review & send. Each tab then presents its own header and action.
Dell Technologies leadership visitAction needed
OverviewAttendeesLocations & sessionsServicesReview & send
Attendees
Manage visitor, host and local attendee details in one place.
4
Locations and sessions as the planning backbone
The itinerary introduces the missing session layer beneath each office. Rooms, catering, attendees and technology can now belong to the meeting where they are actually needed.
Evidence
“Multiple touchpoints” meant leadership meetings across offices and cities.
Design decision
Represent every session with date, time, attendance, format and services.
Expected effect
Remove ambiguity that previously required a scoping call.
5
Conditional service configuration
Selected services reveal only their relevant details. Technology asks for conferencing platform and technician support. Catering asks for quantity and dietary requirements. Visitor access is generated from the guest list.
Evidence
Service teams needed different operational information.
Design decision
Explain why a question is required and recommend services from visit context.
Expected effect
Capture micro-details accurately while keeping the interface manageable.
6
Independent service statuses and focused questions
Service confirmation is separated from information completeness. Teams can confirm, review, request information or decline support at the service level.
Evidence
Different teams approved and updated their own services.
Design decision
Calculate overall progress from the status of individual services.
Expected effect
Create a reliable shared source of truth without hiding partial progress.
7
Service Library and contextual Help
The global Service Library explains availability, lead time and required information. Help is organized around user tasks and surfaces unresolved items from the active visit before offering escalation.
Evidence
Users needed inspiration and clarification without leaving the planning flow.
Design decision
Connect learning content directly to visit and session actions.
Expected effect
Reduce broad consultations while preserving support for genuinely complex visits.
8
Role-based workspaces inside the same Captivate platform
A role switcher in the prototype shows how requesters, coordinators, service owners and admins can use the same visit record while seeing different queues, actions and summaries.
Evidence
Coordinators and service owners needed a reliable summary instead of monitoring requests through disconnected updates.
Design decision
Keep admin work inside Captivate with role-specific dashboards for assignment, SLA risk, service queues, workload and improvement priorities.
Expected effect
Create one operational source of truth and reduce fragmentation between requester, admin and service-team workflows.
Research-to-design traceability
The table below captures the central logic of the redesign.
Research finding
Underlying need
Design response
Information becomes available gradually.
Start coordination without inventing details.
Preliminary support request, autosave and progressive completion.
Visits span offices and leadership meetings.
Understand where and when each requirement applies.
Visit → Location → Session → Service hierarchy.
Pax varies by room, meal and activity.
Capture the correct quantity for each service.
Session assignments and service-specific attendee counts.
Scoping calls compensate for missing structured detail.
Ask precise follow-up questions asynchronously.
Conditional forms, rationale text and visit conversations.
Updates occur outside the tool.
See one reliable, shared status.
Activity history, service owners, questions and independent statuses.
Admins and service owners lacked a shared operational summary.
Coordinate work without creating a disconnected admin experience.
Role-based Captivate workspaces for requester, coordinator, service owner and admin views.
Dates, venues and catering change after submission.
Edit without restarting the entire request.
Persistent workspace and targeted service revalidation.
06 · Prototype
Clickable experience
The prototype demonstrates a shared platform with role-based workspaces.
It includes the requester journey from discovery to service confirmation, plus a role switcher that reveals coordinator, service-owner and admin workspaces inside the same Captivate shell. These views show assignment, SLA risk, service queues, dependency checks, reporting and the six improvement priorities for the next iteration.
07 · Outcome & next steps
What changed
The redesign converted operational ambiguity into shared structure, role-specific ownership and next actions.
The current outcome is a detailed interaction model and clickable prototype. Because the product has not yet been measured in production, I frame impact as design improvements and testable hypotheses rather than claiming unverified business results.
Requesters can begin with known details and complete the visit plan as information becomes available.
The visit workspace brings service progress, responsibilities and next actions into one place across requester and admin roles.
Contextual questions and structured service details reduce the need for broad scoping conversations.