Pitching a POC for a help button during live events

CLIENT: A leader in audiovisual experiences in hotels, conferences, and resorts in North America

OBJECTIVE: Pitch the client's steering committee on an initiative to utilize an IoT button for event attendees to request help from AV staff.

MOTIVATION: Whenever an issue arose, attendees had to call a phone number, look for help within the hotel, or try to fix the issue themselves, which is very disruptive to their experience. 

MY ROLE: Lead UX/UI Designer

MY ACTIVITIES: Storyboard, UX/UI

IMPACT: Generated enough excitement for client to implement their own proof of concept by deploying 6 buttons to 2 hotels to test guest reaction to the buttons before making a larger investment into management portal.

1 - Creating a Shared Understanding

Imagine you are about to present in front of 100 people and the projector cuts out behind you. You have never been to the that hotel before and are unfamiliar with A/V cords and equipment. You might feel embarrassed, anxious, and a little off your game. 

What do you do?

Do you run into the halls looking for someone on the hotel staff? Do you call the front desk? Do you look out helplessly into the crowd?

These are the moments that our client was trying to reduce. The moments where things don't go as planned.

2 - Empathizing for all Parties Involved

It isn't just the speaker that is affected at this point. The meeting planner who coordinates the entire event needs to get it back on track and may be feeling pressured, irritated, and disappointed.  The technicians feel a need to resolve the issue as quickly as possible. Sometimes technicians don't have all the information that they need to fix the problem, so they may have to leave for additional supplies or equipment.  

primary user

• Speaker / Client

secondary users

• Technician
• Meeting Planner

3 - Defining the Physical & Digital Touchpoints of the Service

That being said, our project team did not want an inconsistent experience for clients in different locations that pay for their A/V services. Thus, the idea of implementing an "easy button" was born, just like you have probably seen with Staples. There were many different ideas for the actual button such as ones from GSM, bttn, and Amazon. The AWS IoT button was selected based on ease of set up, price, and lifespan. 

After we discussed the users and physical solution,  I drew a storyboard to help illustrate the physical and digital touchpoints.  

There were a lot of considerations that I brought to their attention in this process as it would affect whether or not this venture was successful. Since we only had a few weeks to create designs to support this pitch, we weren't able to address them all. Here is a subset:

We also had to define success metrics that the steering committee would use to determine whether or not to fund a larger implementation. 

4 - Designing an Interface to Support the Amazon Button

In order for this pitch and solution to be successful, I needed to integrate data from our client's core system.  I designed a dashboard to help administrators and managers keep track of the effectiveness of both the buttons and the technicians. Additional data such as the technician contact information would be pulled from the core system as well as the venues / rooms that the button would be assigned to. 

5 - Limitations of the Solution

There is a lot of dependency on technicians to provide details about the issue, which may require increased training to make this a habit. In addition, many of the technicians did not have their personal phone numbers within the core system. Due to union regulations and personal preferences, there would need to be further discussions about SMS charges due to a notification from the system. Email was another possible way of informing technicians about an AV issue, but it's incredibly easy to miss if you aren't receiving a notification on your lock screen or only check a computer during certain times of the day. 

Clients also may struggle with this solution. The button does not have an interface in which a client could provide details about the issue or receive notice that a technician has been dispatched. If time allowed, I would have loved to perform user research to better understand the needs of the primary and secondary users impacted by this problem and to review the current state business processes that would need to support the new solution.