Case Study: SkyNet Reach Duress

Get it on Google Play
picture of hand holding and using the phone in an outdoor setting

Intro

Australia has a dire need for worker safety due to some cities in remote areas and vast distances with dead cellular coverage zones in between them. This is my role in making SkyNet Reach Duress to meet this demand.

My Roles

I led the UX part of the team to identify how, where, what and why workers use the app and to identify and take care of customer pain-points. I also led the UI and front end development effort in making the app.

User Research about Aussies

Since I am based in the States and not in Australia, I asked UX interview questions to my Australian colleagues who were then able to ask our Australian customers to provide their first-hand insights and expectations.

We did not have the time to get feedback from a MVP (minimum viable product) so I especially wanted to find out their thoughts about this product. I also wanted to learn about the Australian Emergency Call Service as it's slightly different than 911 here in the States.

Prototyping and Testing on a Distributed Team

I made paper printouts and emailed the file to my colleagues so we could do paper prototyping separately on large conference room tables and then watch them use the prototypes over Skype.

Design Execution and More Testing

I designed and did front end development for Android. I executed wireframes, user flows, site maps and design specs.

Sitemap and rough sketch of the app

Leadership

I managed up by presenting prototypes and mockups to executives and other stakeholders. I managed beside me by working with back-end developers to test my UI designs, understand how the software architecture worked and make sure they passed Android Core App Quality standards.

Picture of the the app displayed in 3 different android phones

The Challenge

Someone who is in duress needs help ASAP.

There were two parts for our challenge.

  • Design an UI layout that would make it easy to perform a single action of sending a duress signal while visible in the harsh sunlight of the outback. No not the car, the real outback.
  • Design an UI layout that is informational for the worker to relay information back to the command center or tech support.

The Work Flow

UI design and development were broken into parallel workflows using a kanban board. I led the design for all aspects related to the UI .

We focused on the fact that our B2B mobile app can save a life.

Customer Insights

These are the key insights that formed the launch version of the product:

Educating the user to remember our app

The concept of getting help is simple. Dial 112 or 000 (Australia’s version of 911). We had to make sure that users knew to use our app, which has more stable satellite connectivity, when cellular reception is dropped.

Educating the user about their smartphones

Unlike most of the B2C apps in Google Play with users who are already tech-savvy, our customers have different levels of technical expertise and are different ages so we had to make sure that users also understood their smartphones.

No time to think when an emergency happens

The main purpose is to get help. We focused on the fact that our B2B app can save a life; Every pixel, line of code, byte of data serves this one singular purpose.

How We Created SkyNet Reach Duress

Content First

My first design challenge was to propose how we would display content.

The Send Duress Button

This most important part of the design was the send duress button.

The two areas that were most debated and tested were:

  • What size to make the button?
  • What level of device and signal detail do we provide?

I initially drew the duress button a certain size in paper prototypes. After observing several users interactions, I thought the size was large enough to tap on accurately. However, after field testing and usability testing, I received feedback of people missing the button so I enlarged it.

Initially, everybody on the team, including myself, predicted that the user wanted to see all the diagnostic (device and signal details) full 100% width in the app so users can see everything one line at a time. However, after field testing and customer discussions, we added a toggle switch display format to let users see everything in one view while retaining the option of viewing one line at a time.

sketches of different layouts with different size buttons

Help Guide as User Onboarding

As a B2B software company, we had the luxury of having a dedicated customer service team for our software products. However, to solve the problem of the same type of query being asked over and over again, I used explanatory slides as help content in the action overflow menu in the action bar.

animated gif of the slideshow explaining the different features of the app.

Animated gif of each of the help slides as user onboarding. The user can tap on previous and next controls to view content. The goal of the slideshow was to reduce the volume of tech support queries.

Detailed Specs

I created five rounds of detailed photoshop mockups during this project to communicate requirements to the engineering team.

For the interactive Sending a Duress Signal process, I also tested different animations.

We didn't have specific details about customers devices so I designed all graphics to support multiple screens and follow Material Design for devices and displays.

Interaction Flows

I mapped out how each button state and view would flow to communicate process logic to the engineering team.

Picture of the the app displayed in 3 different android phones

Technical Challenges

In beta testing, we encountered several size and clarity issues with using using standard web graphics. We corrected these after research and further testing.

Post Launch Lessons

Sending a duress was too easy

We made it as easy as possible to send a duress by being able to trigger a duress signal by taking advantage of all a smartphone has to offer.

Sending a duress costs money

Each time a duress is sent, the command center is called triggering a bill. Therefore, we had to reduce the sensitivity (i.e. number of false alarms) by adding a long press of 3 seconds.

This was a hotfix quickly corrected.

The Impact

It’s still in its infancy so it’s too early to tell. Since the launch of the redesign of SkyNet Reach Duress on Android (April 2015), the median number of active customers has increased by 50%

What I Learned

Don’t Get Too Fancy

A smartphone has standard set of options and buttons that everybody around the world is used to using. We tried to customize some of these thus changing normal and expected behavior.

Don’t fix something that’s not broken.

Launching Is Only The Beginning

Despite SkyNet reach duress being a B2B app, launching in Google Play exposes it to the world.

We have received invaluable feedback from customers that have enhanced the app.

To me, designing this app was fun but I more value the impact it has on customers and their business goals. This isn’t a $0.99 game that entertains; SkyNet Reach Duress truly helps workers in their time of need and their employers who monitor them.

Get it on Google Play

Revisiting the Project (With hindsight)

Don't localize the design

We chose the remote road background as we thought it best symbolized the outback. Using this specific image instead of a generic graphic design pattern or background could narrow or turn away potential customers. After all, not all field workers are in the outback.

I would've preferred to test different backgrounds to see what type of impact it had on users.