Published on | Prototyping: From UX to Front End — Medium Max Cameron-Taylor

SearchLight: UX Case Study

How do you design an effective user experience to help users in critical, potentially life-threatening situations?

This is the question Track24 frequently ask when designing their products, and was the challenge presented to us for this UX design sprint.

Security technology company Track24 wanted help with developing the user experience for their new service SearchLight — helping to locate, account for, contact and assist individuals involved in a safety or security incident as they go about their job.

This project was undertaken as a client project as part of the User Experience Design Immersive course at General Assembly.
Along with two other team members, I completed a two and a half week design sprint making use of the entire UX process from thorough user research, through design ideation and iterations with regular user testing and also incorporating visual design that reflected the client’s branding.

We built an app that would help people to be more prepared and informed in the event of an incident, focusing on delivering relevant and contextual information, as well as actionable advice to help them stay safe.

Our designs were extremely well received by Track24 and they are currently in the process of incorporating our suggestions in the development of the product.

The following case study will detail the overall process we went through during the design sprint, however you can skip to the final, high-fidelity prototype by clicking here.

The Client

For the past 15 years, Track24 has been helping organisations to help keep their people safe when they are operating in at-risk areas, such as post-conflict environments in the Middle East.

These individuals are considered in ‘danger-by-default’ and are exposed to a high level of risk, with an increased chance of being involved in some kind of security incident.

Track24 are now looking to scale up their services to those individuals considered ‘safe-by-default’: people who would usually expect to be perfectly safe, but could potentially be involved in an incident as they move around and go about their job.

Living in a modern major city such as London is usually perfectly safe, however there is still the potential to be involved in dangerous incidents, as recent terror attacks across Europe have repeatedly shown.

The Product

SearchLight helps organisations to answer their first question in the event of an incident — “are any of our people affected?”

Currently, the method of achieving this is very slow, cumbersome and expensive — usually involving sending out mass communication over SMS messaging and/or email, then manually sifting through the replies and checking people off.

SearchLight offers a way to automatically account for individuals involved in an incident and allow them to be directly contacted, whilst highlighting their position within a defined area around the incident, without impacting on their location privacy.

This is great for the companies and organisations that use it, but what about the individuals?

What can SearchLight do to benefit the user?

The Brief

Together with two other UX designers, our task was to devise an app with a templated view in order to provide users with a contextually relevant experience that would help speed up their understanding of a developing situation.

Client: Track24 www.track24.com
Product: SearchLight
Sprint timeframe: 2.5 weeks

My Role

As team facilitator, my role was to take the lead on the team decisions and the process that we used, and guide the overall direction of the project.
My design experience and background also led me playing a main role in the visual design and direction for the high-fidelity prototype.

The was made up of myself, and two other UX designers: Hélène O’Brien and Alberto Martinez Lasanta.

User Testing the current app

Our first step was to conduct user testing on the app in its current state, in order to be able to understand specifically where it was not meeting user’s needs. We tested with people who had not seen the app before and asked them to explain what they are seeing and their expectations.

From this it was clear that the app was confusing for users and was not behaving in a way that they expected, offering up lots of opportunity for improvement. Specifically, the main point of confusion was that upon receiving a notification of a nearby incident, once the user opened the app there was no further information given and no clear action for the user to take.

Feedback from testing the current app

We also conducted competitive analysis on the main competitors in the security and safety app space, and found the experiences on offer to be lacking. The clarity of information provided by apps such as Everbridge, Vizmo and Life360 was often weak, and the apps did little to help the user understand what information was relevant to them and how they might be affected.

User Interviews

As the client specified that they were looking to roll the service out to multinational companies with a large employee footprint that could be in several locations at any given time, we set about identifying users who fit this demographic.

We were also interested in talking to people that had been in some way affected by a recent incident in order to gain insight into their thoughts and feelings around the topic.

We managed to gather a selection of users to interview, both from the security coordination team side as well as potential app users.

Our selected interviewees

We developed a series of questions that we felt would help us to understand users’ motivations, needs and frustrations around the issue of being involved in an incident, and after mapping out our received responses were able to come out with several key points to move forward with:

Affinity mapping the results of the user interviews

Problem Statement

Armed with intimate knowledge about the company and their services, along with a sizeable bank of insight into users needs, we were now able to clarify what the real problem we were working with was, and how we should focus on designing solutions to those problems, along with what we hoped to achieve:

Personas

We took the information we had gathered about our potential users from discussion with the client, and our results from the user interviews and put together three main personas:

From these we focused on Peter, the family man who works for a large consultancy firm and as a result of recent attacks in London and elsewhere over the past couple of years, he’d like to feel a little more prepared and reassured as he moves about the city.

Design Studio

We ran a design studio workshop with the client in order to make use of their their knowledge and expertise and help bring forward some initial approaches that would help with the development of the app.

Our design studio focused on the problem of what the user first sees when they are notified of an incident and open the app. From this we managed to settle on the overarching theme of showing contextual information in a chronological view.

Initial sketches from the design studio

Feature Prioritisation

We took the initial ideas from the design studio and together with the user research we had gathered we conducted a feature prioritisation exercise.

Deciding which features to prioritise

We identified the most valuable features for us to develop in this sprint as:

A ‘My Situation’ screen showing contextual information about the ongoing incident relevant to the user.
An incident ‘News Feed’ with live, updating information about the incident.
A messaging feature to allow communication with security coordinators who can provide assistance.
A map view to provide relevant location information relating to the incident and guided directions.

Design Iterations & User Testing

Paper Prototype

We put together a quick paper prototype so that we could gather some initial feedback on our ideas for the app.

Our first tests with a paper prototype focused around the scenario of a terrorist incident occurring nearby while on a business trip, and a car being sent to take the user away from the area.

Selected paper prototype screens

Users remarked that the ‘Mark yourself as safe’ button was confusing and contradictory, so this was removed in favour of a ‘Get Help’ button when moving into the next iteration. In this way, users could request assistance if they felt they needed it based on the situation they were in.

Sketching and Ideation

Throughout the process we were continually sketching and refining in order to produce and clarify ideas to take forward into digital prototypes, solving design problems through rapid ideation and iteration of designs

My Situation

The overall aim of the ‘My Situation’ screen was to quickly and clearly answer the user’s questions of “What is it?”, “Where is it” and “What should I do now?”.

The design of this screen was progressively revised in order to provide greater clarity and make the information more immediately digestible.

Initially, a short, form style flow was added for after the user pressed ‘Get Help’ to help the app deliver the best action for the user to take, however during testing users found this to be tedious and confusing, remarking that they would not want to have to go through this process when in a pressured situation.

This was replaced with a simpler, single piece of advice and two options to either follow that advice, or provide an alternative.

We were trying to build in some flexibility into the ‘advice’ element of the app, in order to make it relevant to as many situations as possible, however from testing it became clear that this was only causing confusion for users.

As a result, we decided to simply present users with a single ‘Recommended Action’ that they should take, based on their proximity to the incident.

The three information cards could be modified by the coordination team in order to provide the most recent and relevant advice to the user.

Map

Initially the map feature was designed to show the incident information together with the advice dialogue, however during testing users found this unnecessary as they were able to view the information on the ‘My Situation’ page and it only made the map more confusing and cluttered.

Including a marker on the incident location, along with the name of the location was sufficient for users to understand where the incident was occurring.

We added the user’s profile picture onto the map to help them understand their location quicker, however users told us that they felt it was overly large and that current visual devices for marking user location were more understandable.

This was therefore replaced with the convention of using a blue dot that also shows the user’s facing direction.

The visual design of the incident areas was also adjusted to make the distinction between the immediate incident area and the general warning area clearer.

Feed

The feed view provides live, updating information on the ongoing incident from relevant and trustworthy sources. The items in the feed are shown chronologically to allow the user to follow the developing situation as it happens, and look back on key events.

This feature was readily understood by users during testing and needed minimal iteration, however as users said that transparency within the app was important to them we incorporated a ‘My Feed’ feature to allow users to view the points at which their location was shared with their employer.

Messaging

The app’s messaging feature was continually revised in order to include current conventions to aid user user understanding — elements such as ‘online’ markers, read receipts and active typing animations.

Users also made it clear that it was important for them to be able to call or send a voice message if necessary, as typing may not be practical depending on the situation they are in.

Scenarios

The prototype was put together to provide an example of how the app might have been used had it been operational during the Oxford Circus false-alarm incident that occurred on 24th November 2017.

We arranged the two scenarios to show the functionality of the app as if the user was either nearby the incident, or within it.

Click here or on the image below to view the final, high fidelity prototype which runs through these two scenarios:

invis.io/TQEOKVFKE

Results

What we have explored:

Addressing users’ main concerns of why, what, where and when.
A templated approach that can adapt to companies’ own security protocol
Trustworthy and accurate updates from reliable sources
Relevant, timely and actionable advice.

User Feedback:

“It would have been great to have this in light of what happened in Oxford Circus last Friday”

“It’s very clear and obvious what’s happening and that it is important to me”

Client Feedback

Track24 were delighted with what we had produced for them and said that our work had greatly exceeded their expectations.

Following our presentation, Track24 have taken our design suggestions on board and plan to implement them when developing the next version of their app.

Next Steps

We managed to achieve what we had set out to deliver for the MVP within this limited sprint, however there is so much that could be explored with this interesting and important product.

There were many more things that came up during user interviews and testing, and given more time we would have liked to have implemented the following features:

Develop the on-boarding process

to help familiarise users with the app and its benefits

Incorporate communication with next of kin

to reduce the need for sending individual reassurance

Include more advanced travel updates

to help users understand the disruption to them

The UX Team: Alberto, me and Hélène

Thanks for reading!

If you’d like to get in touch or find out more about me, please use one of the links below:

Email // LinkedIn // Portfolio

How do you design for critical situations? was originally published in Prototypr on Medium, where people are continuing the conversation by highlighting and responding to this story.

How do you design for critical situations?

SearchLight: UX Case Study

Top Stories