Alarm Manager, a STANLEY Security mobile web application was created for the purpose of reducing the amount of wasted operator calls and to give users the ability to cancel and confirm alarms for locations they manage, alongside those who work with them. We were tasked with redesigning the experience.
Original design we were tasked with redesigning
During our initial research, we found the most common complaint was that the existing experience was confusing and made users feel frustrated.
"The buttons are hard for me to reach and there are a lot of glitches I experience. I want to not worry about pressing the wrong thing."
By doing a deep dive on what users want and identifying where they’re getting confused led us to a solution that addressed pain points and greatly reduced wasted call time.
We created a mobile web application which eliminates the need to users to download a new app and only exist for helping them complete their desired actions as easily as possible.
Our team decided to use the double diamond design process in our approach for our projects, including this one. Empathy is the core of user experience, and by using a human-centered approach to all stages of thinking, we deliver the best experience possible for people.
Before diving straight into the redesign process, we decided to take a big step back and start by understanding problems to be solved, opportunities, and identify user needs and wants. We wanted to understand, rather than assume the context of the problem.
Reduce unwanted false alarm dispatches?
Create a more usable group chat interface for users to make a decision?
Make users feel confident they know relevant alarm information and actions?
To redefine the architecture and design of the app, as well as understand our users better, we asked our users to define what are some of the most important questions that come to mind about managing their alarms. Those were shortlisted to top 3:
Since a constraint we were given at the beginning from stakeholders involved creating a quick iOS style Alarm Manager redesign, the team (UX director and me, UX designer) held a fun crazy 8 session in which we each sketched out our 8 different ideas for redesign based on key functionality and our hypothesized optimizations. These mockups gained us approval to take a step back, conduct research, and then redesign based on findings.
Before conducting user interviews, we wanted to understand what questions to ask as well as who are users even are. We held a 3 hour long Figjam collaborative session on mood boarding, identifying needed features, text message copy, and creation of user flows.
We also conducted competitor research and analysis to better understand the competitive space. We identified what our competitors are doing that we aren’t, what they were doing well, and what could be improved. These included ADT Alarm Messenger, Rapid, Alarm.com, and COPS Monitoring.
One of the best ways to learn more about our users is conducting user interviews, so we decided to create key questions and a script. After recruiting four different users, we held remote user interviews discovering more about them and their frustrations and ideas for optimization, taking turns being the interviewer and notetaker/observer.
During this phase we synthesized our observations about our users, developed our clear problem statement, and pulled out key insights to focus on through mood boarding sessions and creation of customer journeys and personas. The below are our main insights, with three highlighted as most key.
Uknown sender, lack of trust, may think fraud if they haven’t seen before - RSA token?
Needs onboarding, copy improvement, clearer actions
Ability to hide, see who's chatting, way to see who's actioning alarm
Almost all wanted the ability to put their systems on test
More description of alarm info, type, and in-depth history wanted
Almost all mentioned long loading times, sometimes up to 30 seconds
Notifications of actions taken, new messages, and reminders to get call list to respond
Larger customers may want to brand UI, in Canada people deal with dealers, not STANLEY
Expired links should still show information, actions taken, follow up text messages possibly
Personas were created based on our understanding of major user types as well as their user stories to reflect the target user, their practice, and final goal.
Once we had an understanding of our target users, we decided to do a deep dive of the current information architecture and map out the “golden path” for a desired outcome and create user flows for the different key actions that could be taken in Alarm Manager.
One of the main areas of improvement identified was around the copy, more specifically being the key terms used around major actions users could take such as cancel and confirm alarm. We identified potentially confusing copy and major actions we wanted to be clear, and ideated on alternatives with stakeholders.
Before the next phase, we wanted to break down key insights, challenges, and identify what each interview had in common and what was unique, what we thought would be most important to include and optimize, and mood board potential designs and practices to fit those insights and on the same page.
Taking our insights and research, moodboards, and action items, we moved into the develop phase where we moved from sketches to low fidelity wireframes and made iterations based on stakeholder feedback.
Before jumping into low fidelity wireframes, we held a session where we each roughly sketched ideas based on our mood boarding session and collaboratively worked together to prepare what to wireframe in our next step.
After we decided on what screens to tackle first, we held wireframing sessions in Whimsical to not get caught up on details and created different wireframe iterations for major screens.
After honing down on our top screens for each major state, we took the low fidelity wireframes and created a wireflow with three major iterations to correspond with identified major user paths and actions that could be taken.
After creating the low fidelity wireframes and wireflow, we then held stakeholder presentations and presented the work thus far along with a low fidelity clickable prototype, and made iterations based on feedback in preparation for the next design phase.
After iterating and gaining stakeholder approval, we designed the high fidelity prototype, brainstormed usability hub testing questions, gained insights, iterated, created a live usability test, recruited users, and then outlined the screens and design system in Zeplin for better developer handshake.
The high fidelity prototype was created collaboratively with frequent stakeholder meetings to gain feedback and make slight optimizations, and to prepare for testing.
Once the prototype was finalized for testing, we held sessions to brainstorm key questions to ask and set up a usability test with 200 users with different demographics and went through the feedback together to pull key insights.
Once optimizations were made based on usability hub feedback, we created a live usability test in Maze and sent out recruitment emails to our customers who were interested and held live usability testing. Feedback was used to further back up design decisions.
To aid in developer handshake, we used Zeplin which caught small changes that needed to be made for consistency and then outlined the design system and screens. Once we sent the Zeplin and Figma to developers, ongoing communication and stakeholder meetings remained.
Alarm Manager allows users to gain control of their alarms and manage in a streamlined, efficient way; mitigating the hassle of previous procedures.
Based entirely around the user, the redesign of alarm manager resulted in a much more user friendly and centric mobile web application that also aids in less operator calls, wasted resources, and accomplishment in company goals.
.gif)
This project taught me a lot about the importance of user centered design, testing, recognizing potential biases, and stakeholder involvement. It was also a great opportunity to get more experience with different methods of testing and pulling key insights.
I would consider different approaches to testing and recruitment, and try to involve the larger team more in gaining different perspectives when ideating.
I would experiment with different solutions that would aid users, such as wanting to include different live feeds of videos that show activity, and possibly including a map, which we were experimenting with but had to drop due to constraints.
