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.
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.
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.
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.
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
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.
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 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.
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.
I mapped out how each button state and view would flow to communicate process logic to the engineering team.
In beta testing, we encountered several size and clarity issues with using using standard web graphics. We corrected these after research and further testing.