Deploy

Context

Deploy is an internal product to aid Aloompa team members in deploying bluetooth beacons at events. These beacons help event organizers, our clients, gather valuable insights about attendee behavior during the course of the event by measuring the amount of attendees in close proximity to each beacon at any given time. This technology not only allows our clients to identify which performances were the most attended, but it also provides operational information about where attendees tend to gather, and it can prove a return on investment for sponsorship activations.

Prior to the event, Aloompa’s team members work with event organizers to establish which areas on the event site should be measured for attendance levels. The product of these conversations is a paper map with notations of where the beacons should be placed. Typically, the most interesting areas to watch are ingress and egress points, stages, and sponsorship activations.

After the plan is set, the Aloompa team will begin entering detailed configurations, known as “triggers”, into a content management system. Triggers are named for their desired destination areas and can be configured to send messages, work in tandem with other triggers, or simply monitor nearby attendee locations. Once a trigger’s configuration has been completed in the content management system, it appears in the Deploy app and is ready to be paired with a beacon and given a geolocation. The Aloompa team then travels to the event and arrives on-site with a case full of beacons and the Deploy app installed on a phone. Team members use a notated map and the Deploy app to place beacons in the correct locations around the event site.

Research

Conducting research for the refinement of this app was a lot of fun because it gave me an opportunity to help solve problems for the people I work with every day. A previous iteration of the Deploy app was already successfully being used, so I began analyzing its use by setting up a test environment in our office, observing the tasks that several members of the Aloompa team were required to complete in order to successfully deploy a beacon using the first iteration of the app. I noted any complaints they had and watched for points of confusion, frustration or hesitation during the process.

Problems observed in the previous iteration of the app:

• The app did not have search functionality and team members were required to visually scan the list of triggers in order to find what they were looking for. This was cited as a major pain point during tests, and helped provide evidence supporting the necessity of search functionality for this app.
• There was no way to immediately tell which triggers which still needed deployment. All appeared in a list in the app together, whether they had been deployed or not, and the team member at the event had to check this list against a screen showing only deployed beacons to deduce which triggers still needed to be configured.
• After deploying a beacon, there was no way to edit its configurations, so team members had to reset the trigger through the content management system and re-deploy the beacon. This meant they had to carry a laptop and find an internet signal if any mistakes were made, which is very difficult at a music festival or sporting event.
• Upon deployment of a beacon, the team member’s geolocation is associated with the beacon. An accurate geolocation is required in order to report attendee data back to the event organizers on a map. Unfortunately, the geo-accuracy of a phone can vary wildly based on cellular signal, and deploying a beacon when geo-accuracy is bad can cause the beacon to deploy far away from the desired target, resulting in an unfavorable trigger reset and re-deployment process. We needed to find a way to make this situation less painful.
• If a beacon is damaged or runs out of battery life during the course of the event, the data reported to the event organizer becomes incomplete. Replacing the beacon requires the team member to reset the trigger and re-deploy the beacon. A pattern is emerging.
• Recovering beacons required the team member to enter the detail view for each beacon and tap a “recover” button, but typically the physical beacon recovery process is fast and multiple beacons are being picked up at a time, so the process of recovering through the app seemed sluggish by comparison.
• The recovery process is not always as methodical as the deployment process, and team members wanted a simple way to know which beacons were the most convenient to their location during this phase, but recovering beacons from the map view wasn't possible.

One of the initial concepts for beacon deployment initiated the deployment process by tapping a 'plus' button found in the tab bar of the app. Tapping this button began opened a pop-up dialogue with a sequence of steps.

After creating a prototype of this concept and asking test subjects to complete a deployment, it became clear that not everyone immediately knew to tap the plus button to begin the deployment process. Several subjects commented that they weren't sure what to do upon the first viewing of the UI. Reorganizing the flow to display the to-do list of triggers as the very first screen made the initial objective clearer. You can see the results of this change in the designs below.

The "deploy" screen gives the user an overview of what is left to be done. It shows progress graphs of the deployment process, as well as a to-do list of the triggers awaiting deployment. Since a deployment doesn’t have a defined start or end point, the first thing many team members do upon reaching this screen is type in their current location on the event site, which produces a refined list of triggers awaiting deployment for that area. As triggers are paired with beacons and deployed, they are removed from this screen so that the user will only see the tasks remaining.

Refinements:

• Added the ability to search remaining triggers.
• Implemented a task-oriented organization by removing triggers from the deploy view after they've been configured.

After selecting a trigger from the deployment screen, team members are presented with a beacon selection screen. At this point, they’ll reach into a case of beacons and select one at random, typing the identification number on the beacon into the search field, verifying that it has sufficient battery life. Additional configurations and notes may be added to the beacon, and once everything is in place the final step is choosing to deploy the beacon. The team member is able to watch their phone’s geo-accuracy (which updates in real-time) and verify that it is satisfactory before tapping the “deploy” button.

Once the beacon is deployed, it can be accessed and edited again at any time from the review screens. This allows team members to correct any errors they may have initially made without having to reset the trigger in the content management system. The presentation of a deployed beacon detail screen is slightly different from a new deployment, and includes the ability to update the geo-location or recover the beacon.

Refinements:

• Added the ability to search beacon IDs.
• Added battery life verification.
• Added geo-accuracy verification.

After beacons are deployed, they’ll appear on the “review” screen, which is segmented into list and map presentations, both containing the same information. During the course of the event, a team member might check these screens to verify configurations or replace broken beacons, but for the most part, the bulk of the work is done until the event ends.

Once the event is over, Aloompa team members are responsible for recovering as many of the beacons as possible. Typically they will head to an area and start packing them up, recovering them through the app after clearing the area. At this point it, it’s important to see the beacons relative to the team member’s position so that they can verify that they’ve collected the right number of beacons from the area. To help with this, we added a “nearby” heading to the review list view, which brings any beacons within around a one hundred foot radius to the top of the list. We also added the ability to recover a beacon from both the list and map views, eliminating the need to tap into the detail view to recover. Since recovering a beacon removes it from the app completely, there is a confirmation screen to protect against any accidental brief taps, but a long tap on the recover button will show intent from the team member and skip the confirmation screen, allowing the recovery process to move quickly.

Refinements:

• Enabled team members to recover beacons with fewer taps by adding a recover button to the list view.
• Provided the ability for team members to recover beacons in close proximity by adding a "nearby" section to the review list view and a recover button to beacons in the map view.

Conclusions

The refinements made in this iteration of the Deploy app save Aloompa team members time and frustration during the deployment process on a regular basis. Implementing a search function in several key areas of the app allows team members to tap a letter or two to get to the trigger or beacon they need, instead of scanning a list of text. Adding the ability to edit deployed beacons and verify their battery life, configuration and geo-location reduces the need to reset triggers in the content management system, and helps us continue to report accurate, complete data to our clients. A simpler recovery process allows our team members can leave the event faster and get back to their normal lives.

Future Iterations

While the refinements made in this iteration have made for a happier more efficient deployment team, I feel that there are a few more steps which could potentially help the product improve, even though they weren’t in-scope for this version.

• Implement a deployment plan map:
  The planning process still requires the team to reference a paper map to see where they need to place beacons. I recommend that we add the ability in the content management system to set map pins on suggested placements for beacons on the in-app event map. Upon arriving at suggested placement, you’d tap the pin to begin the deployment process, pairing the trigger with a beacon and overwriting the suggested location with a real one. This way the team member can see their deployment objectives relative to their current location, rather than looking at a paper map and searching the associated trigger in the app.
• Add a placement confirmation before finalizing a deployment:
  Even though we’ve implemented the ability to verify the deploying phone’s geo-accuracy before deploying the beacon, it would be helpful to see where the beacon is appearing on the event map before confirming the deployment. I feel this would help team members deploy and move on to the next objective confidently without feeling the need to navigate to the map and verify the beacon’s placement.