Helping to improve response times for workplace incidents
We helped Ramtech improve their existing REACT App. Using a 5 day Design Sprint, we helped improve the response experience for the product and make it easier for users to raise alerts on site.
Defining the key problems
Ramtech were already clear on which parts of the app their users were struggling with based on the feedback they'd received. With this, we outlined a series of questions to help us prioritise which areas of the prototype to work on, and understand what feedback and responses to look for to make sure we were solving the right problems.
- Can we reduce the delay in dealing with alerts?
- Can we make the UX simple and less confusing?
- How do we make sure users know what they need to do with alerts?
- What would make the alerts more understandable and clear?
- What would make the app look and feel like a better product?
Once we'd agreed on the main goals for the sprint, we now had a collective understanding of what 'success' would like for the prototype. These goals also acted as the guiding light for the rest of the week, helping us keep sight of the key issues so that we were focussing on the right ideas and solutions at all times.
Refining instead of reinventing
With an existing version of the product already live and in use across multiple workplaces, our approach to coming up with solutions was based more around improving the existing flow rather than reinventing the wheel.
We looked at the overall user journey of the product, and put pen to paper to create a handful of rough ideas on how we could improve the flow and interaction at various stages. We also identified the key touch-points that users would encounter when using the app, and organised them into three top-level steps: Raising an Alert; Accepting an Alert; and Ending an Alert.
Understanding pain points
During the initial workshop, we delved deeper into what issues were occurring in the product so that we could try and understand more about why they might be happening.
Users may implicitly complain about common UX issues, which in one of our cases was that the current app felt too fiddly. As this tends to mean small or complicated, we started looking into potential problems around the main call-to-actions not being big enough, as well as seeing if there was scope to reduce the amount of content or options on screen at any one time.
Other issues that had also been reported were: The alerts and actions weren't always clear and could be easily missed; Users weren't always sure how to respond to an alert; There was a lack of accountability around who was dealing with the alerts.
By uncovering the common user pain points, we sketched out a handful of potential solutions and mapped them to a storyboard that would later form the foundation of our prototype.
Putting our assumptions to the test
After 2-days of discovery and idea generation, we put together a clickable prototype ready to test with people and gather valuable feedback and insights.
We then sat down with 5 current users of the REACT App to test our new prototype with, finding out more about how long they've used the app along with their goals and frustrations when using it. This initial feedback then set the benchmark to test our new prototype against.
The prototype was split into three scenarios based on a real-life action the product would be used in. As the users completed each scenario, we observed how they used the prototype and asked for their thoughts and opinions on the flow, the options presented, and the overall usability of the product as a whole.
One big idea that we were keen to test was the ability to upload a floor plan of a building, and select the room/s from the map to pinpoint where the alert was being raised from (e.g. A fire in the kitchen). We also wanted to see whether the ability to upload attachments such as a video or image would be useful in providing more context for the alert.
Gathering real feedback and insights
As a whole, the general impressions of the UX were positive. Every participant commented that the alerts were easier to read, and the UI was clearer and better to interact with.
People were able to raise and accept an alert much more easily, and the added feature of choosing from a site map was well received. We also gained more of an understanding about the context of how and when the attachments such as adding a video would be used.
There were also many useful suggestions and feedback that we hadn't initially considered. One recurring piece of feedback we had was around raising an alert, and making sure as many steps of the process such as adding an attachment were optional. During high-stress situations, most people stated that they wouldn't even have time to think about adding a video for example.
Many users also mentioned that they'd like to be able to explain why they'd ended an alert, which tied in nicely with one our goals of improving accountability in the app.
Creating actionable next steps
Overall, we can say we were successful in answering our initial Sprint Questions.
Users felt the improved flow and larger, clearer UI was much better and easier to interact with, and the additional features such as selecting a room from a site map and being able accept and end an alert in just a few steps was definitely a winner.
With all of the useful feedback and insights we've gathered from this, we feel we've given the team at Ramtech the confidence to move forward and see where they can make the most impactful changes for their users.
Like this? You'll love some of our other projects too
Helping to improve response times for workplace incidents
We helped Ramtech improve their existing REACT App. Using a 5 day Design Sprint, we helped improve the response experience for the product and make it easier for users to raise alerts on site.
Defining the key problems
Ramtech were already clear on which parts of the app their users were struggling with based on the feedback they'd received. With this, we outlined a series of questions to help us prioritise which areas of the prototype to work on, and understand what feedback and responses to look for to make sure we were solving the right problems.
- Can we reduce the delay in dealing with alerts?
- Can we make the UX simple and less confusing?
- How do we make sure users know what they need to do with alerts?
- What would make the alerts more understandable and clear?
- What would make the app look and feel like a better product?
Once we'd agreed on the main goals for the sprint, we now had a collective understanding of what 'success' would like for the prototype. These goals also acted as the guiding light for the rest of the week, helping us keep sight of the key issues so that we were focussing on the right ideas and solutions at all times.
Refining instead of reinventing
With an existing version of the product already live and in use across multiple workplaces, our approach to coming up with solutions was based more around improving the existing flow rather than reinventing the wheel.
We looked at the overall user journey of the product, and put pen to paper to create a handful of rough ideas on how we could improve the flow and interaction at various stages. We also identified the key touch-points that users would encounter when using the app, and organised them into three top-level steps: Raising an Alert; Accepting an Alert; and Ending an Alert.
Understanding pain points
During the initial workshop, we delved deeper into what issues were occurring in the product so that we could try and understand more about why they might be happening.
Users may implicitly complain about common UX issues, which in one of our cases was that the current app felt too fiddly. As this tends to mean small or complicated, we started looking into potential problems around the main call-to-actions not being big enough, as well as seeing if there was scope to reduce the amount of content or options on screen at any one time.
Other issues that had also been reported were: The alerts and actions weren't always clear and could be easily missed; Users weren't always sure how to respond to an alert; There was a lack of accountability around who was dealing with the alerts.
By uncovering the common user pain points, we sketched out a handful of potential solutions and mapped them to a storyboard that would later form the foundation of our prototype.
Putting our assumptions to the test
After 2-days of discovery and idea generation, we put together a clickable prototype ready to test with people and gather valuable feedback and insights.
We then sat down with 5 current users of the REACT App to test our new prototype with, finding out more about how long they've used the app along with their goals and frustrations when using it. This initial feedback then set the benchmark to test our new prototype against.
The prototype was split into three scenarios based on a real-life action the product would be used in. As the users completed each scenario, we observed how they used the prototype and asked for their thoughts and opinions on the flow, the options presented, and the overall usability of the product as a whole.
One big idea that we were keen to test was the ability to upload a floor plan of a building, and select the room/s from the map to pinpoint where the alert was being raised from (e.g. A fire in the kitchen). We also wanted to see whether the ability to upload attachments such as a video or image would be useful in providing more context for the alert.
Gathering real feedback and insights
As a whole, the general impressions of the UX were positive. Every participant commented that the alerts were easier to read, and the UI was clearer and better to interact with.
People were able to raise and accept an alert much more easily, and the added feature of choosing from a site map was well received. We also gained more of an understanding about the context of how and when the attachments such as adding a video would be used.
There were also many useful suggestions and feedback that we hadn't initially considered. One recurring piece of feedback we had was around raising an alert, and making sure as many steps of the process such as adding an attachment were optional. During high-stress situations, most people stated that they wouldn't even have time to think about adding a video for example.
Many users also mentioned that they'd like to be able to explain why they'd ended an alert, which tied in nicely with one our goals of improving accountability in the app.
Creating actionable next steps
Overall, we can say we were successful in answering our initial Sprint Questions.
Users felt the improved flow and larger, clearer UI was much better and easier to interact with, and the additional features such as selecting a room from a site map and being able accept and end an alert in just a few steps was definitely a winner.
With all of the useful feedback and insights we've gathered from this, we feel we've given the team at Ramtech the confidence to move forward and see where they can make the most impactful changes for their users.
