AMEX GBT Travel Risk Management Software for Security Officers

Problem and Background

Amex GBT engaged our team at Pivotal to develop their travel risk management software. Security officers for large enterprises (5,000+ employees) must know where their employees are and keep their employees safe when a risk occurs. An example of a risk could be anything from travel health risks, civil unrest, acts of violence and terrorism. Our goal was to develop an MVP for a web based application for security officers, travel managers, and travel counselors.

Team Breakdown and Timeline

Team Breakdown: Pivotal: 2 Designers, 1  Product Manager, 8 Developers, 1 Client Director, 1 Client PM, 4 Developers.

Timeline: 4-6 weeks Discovery and Problem Framing Phase, and 4 months deliver MVP, 2 months Beta.

Greenfield Product Discovery

Project Kickoff: We arrived at a shared understanding of goals (business, product and engagement), customers / users and risks to begin prioritizing our work. We spent the first few weeks of the project in a discovery phase deeply understanding the users, the business and the problem space. We decided to solve problems for our first user group, security officers, within the scope of our MVP.

facilitation

Persona Workshop Facilitation

I facilitated a Proto-Persona workshop with our stakeholders. Personas surface when multiple domain experts externalize their assumptions about a user group. As a group they rank what is most important so that gets us quickly to the most reliable persona given the minds in the room. We developed our persona Tom (security officer), and highlighted what we thought our riskiest assumptions were about Tom so that we can develop a script for our security officer user group.

Generative Interviews:  We needed to evaluate our assumptions from the workshop, so we gained access to Security Officers and conducted several rounds of generative interviews to gain a deep understanding of their context by identifying their needs, goals, and pain points. This was done through 1 hour long remote phone interviews. We synthesized these learnings through affinity mapping.

Key Insights from Generative Interviews

  •  Security officers are usually former intelligence or military.
  • They wear many hats, for example, they detail VIPs, monitor travelers and assets, develop and enforce security policies.
  • Their primary concern “Is everyone Safe?”.
  • Major pain point is that locating travelers and finding contact information is slow.
  • This could be a matter of life and death, so they need to pinpoint and triage who is in the location of risks and who will arrive there.

Ideation

At this point our team was ready to start framing the problem through sketching, we developed scenarios based on our findings from Tom, our persona. Scenarios are not prescriptive as to help us defer judgement and come up with creative solutions. We converged on our sketches by dot voting various concepts and features we thought would be valuable in solving the user's problem.

1
2
3

Round 1 Low Fidelity Iteration & User Testing

Tools: Balsamic, Photoshop, inVision

amexvid1

Learning Goals:   We wanted to test if security officers wanted to search a location or view a map first. We tested a quick search feature and a basic kanban style of workflow. We also wanted to know if a graphical visualization of traveler status is useful.

Round 1 Findings: A search bar was not enough, they needed a world map to ground themselves into the traveler’s context. They found the kanban style workflow helpful for prioritization. Off to our next round of testing!

othername

Pair Designing at it's finest. At Pivotal, we pair design. Pairing promotes learning, knowledge-transfer, and productivity. Pairing helps us to make creative decisions through collaboration, help us to externalize ideas, articulate our thinking and have a shared ownership of our designs.

Round 2 Low Fidelity Iteration & User Testing

Tools: Balsamic, Photoshop, inVision

View Prototype

static1.squarespace

Learning Goals: How might we prioritize Tom's workflow? Auto-prioritization of travelers: helpful or dangerous? What itinerary data is the most important. What information do they need in the map view?

Round 2 Findings: SOs are happily surprised at how easy it is to get to an auto-prioritized list of travelers from an alert, and trusted the itinerary data that prioritized the travelers. SOs wanted the i from a map bubble. 

After a few rounds of user testing with low fidelity clickable prototypes we learned the following about Tom's workflow:

  • Alerts are prioritized on severity and relevance
  • In a given risk, Security Officers alert all travelers in an area in one email blast
  • Security Officers need a way to communicate to all travelers and get responses
  • Alerts need to tell the travelers what to do
  • Security Officers need to view a live world map to ground themselves into the traveler’s context.
  • Those using the current risk tool must refresh often to keep alerts coming in
  • Security Officers will send a follow up report with traveler communication logs to their leadership throughout the risk and until the risk is resolved.

Now that we had our workflow validated, we focused on deepening our interaction models and drilling down into each feature. Concurrently, our development team ramped up and we collaborated very closely to bring these validated features to life.

Round 3 Higher Fidelity Iteration & User Testing

Tools: Sketch, Photoshop, inVision

hifi1

Learning Goals:   What do risks looks like? How best to handle inbound and SMS messaging, explore messaging threads with travelers, dig into auto-prioritization–what factors prioritize travelers? 

Round 3 Findings: SOs found risk alerts extremely valuable as it helps them quickly access the risk and travelers quickly. SOs wanted SMS responses to automatically change prioritization– Type 1: I'm okay to turn green, and Type 2: "I need help" to stay or turn red. They found the iconography helpful in quickly determining traveler's location status. 

Production & Delivery

Development Inception: We spent the day with exercises designed to bring a common understanding of the process, project, and product goals to the team, both Pivots and client team.
 

production

We synthesized the learnings from our 3 Lo-Fi prototype sessions, and pulled some key takeaways. Very few seem to have relied on the map in the past. But when we took it away, they became unsettled. We wanted to speak with more Toms to better understand the real role the map plays for them, and to better understand their behavior around messaging and alerts. 2 out of 3 of our Toms get alerts elsewhere. All of them message travelers outside of the current tool, and two of the Toms want to make sure the travelers will read the email, and one because he can more easily tell if the traveler has replied.

Below are a few screens from our MVP:

Scenario: Security Officers work in a command center with several TV monitors with multiple news sources on. They see breaking news and they log into the software. They see where travelers are based on data from airline reservation record locator codes and hotel reservation confirmation numbers. They also see a bullseye to quickly pinpoint where there are risks. 

Viewing Travelers and Risks

Tools: Sketch, Photoshop, inVision

View Prototype

1

 

Messaging Travelers from Impacted to soon to be impacted

Tools: Sketch, Photoshop, inVision

View Prototype

2

Object Click Interactions: The SO will click into a risk alert, risk bullseye or a traveler bubble to see who may be impacted. Because this data comes from airline record locators, we ordered the travelers from their arrival time. Travelers who are about to land are an amber striped card. Red striped cards indicate travelers who have just landed or are still at that location. Employees in the location are also located and have a house icon instead of an airplane icon. 

Card Selection Interactions: Selecting a card will release a traveler's full itinerary including return flight, hotel, and rental car information as well as a messaging drawer that has their employee phone number and email address and messaging history.

Security officers can use this system to track their employees, send and receive safety information quickly, and provide  

Reflection: This project spanned over 7 months. We conducted over 30 rounds of testing with multiple Security officers and various user groups to develop a robust travel risk management solution for Security Officers. We also began beta testing with a few select users.

3

If you'd like to see a more detailed prototype walkthru, please schedule some time for a portfolio walk through!