top of page

Tailoring Technology around Life and Death

"We are stuck with technology when what we really want is just stuff that works"
- Douglas Adams
Should ​Technology Accommodate our Lives or Should our Lives Accommodate Technology?

That was the question the creative team at VirtuSenes Technologies had to answer about their newly successful product, VSTAlert. VSTAlert is a revolutionary product that tracks potential patient falls in hospitals and senior living homes before they happen. It works by attaching a camera to the ceiling, constantly monitoring the patient's bed, and with over three million hours of AI training, it can spot when someone intends to leave their bed unattended. Once the camera detects intent to get out of bed, a message is sent to a nearby nurse while a speaker in the patient's room informs them that someone is on their way to help them get up. Patients falling from their beds often lead to dangerous surgeries or can be fatal on impact. VSTAlert has saved thousands of people from potentially fatal injuries. 

Identifying the Problem

Customers were not complaining about VSTAlert's effectiveness but rather about the lengthy and unintuitive training they had to undergo to learn the system and its companion app. The technology was great but needed to fit their busy environment, where time was a luxury at best. The steep learning curve and unintuitive user experience meant that the nursing staff often ignored the system to save time. Customers would cancel their contracts once nurses ignored the system for long enough. 

As the creative team lead, I knew the best place to start was identifying the root problems causing contact cancellations. Before designing any new mobile UI, we scheduled calls and site visits with nurses using our product. We needed to understand our users and their needs before designing.

 

Upon arriving at the senior living home, it became clear that our team did not fully understand how hectic these nurses' lives were. Nurses were making split-second decisions to serve the patients best, and they had no time to learn how to use yet another application. The few nurses who had received official training on using our system said that the mobile app needed to be more intuitive and that pausing the mounted sensors was counterintuitive to how they worked. Whenever a patient attempted to leave their bed and triggered an alert, the nurses were likelier to tend to the alert without using the mobile application, which would cause errors in the system. Additionally, there was no way to divide the alerts amongst the available nurses, which meant that if the nurse nearest the alert was busy, the alert might not be attended to in time. The nursing staff created workarounds to avoid using the unintuitive mobile app, and nobody felt they had time for official training on how to use it. The technology needed to fit how they worked.

After several senior living home tours, it was evident that the mobile application was the leading cause of the problem. As the app was beyond tweaking, overhauling it was faster. We had identified the main pain points, and accessibility was our guiding star. With minimal training, this app had to work out of the box and adapt to how the nurses were already working. The UI had to be clear and informative and let the nurses assign and communicate who was taking care of what alert. When a patient triggers an alert, there is no time to think, only time to act. 

Picture of design process from idea to product
Building From the Ground Up

Before starting with low-fidelity wireframes, we had to rethink the application's information architecture. Each screen had to serve a purpose, and nurses had to find the information they needed with minimal navigation. The home screen would contain the most needed information, with the rest less than three taps away. Alerts would be presented as pop-up modals, pushed to the forefront for attention, eliminating unnecessary pages. The app also had to indicate whether a patient was in bed or sitting in a chair before the nurses entered the room. 

Communication was the most important aspect that needed to be fluid for this application to gain wider adoption. The nurses needed to know who was available, who was covering what set of rooms, and how to communicate if they could not attend an assigned alert. Once a nurse got to the room, they knew what to do. Our job was to get the right nurse to the right room on time. 

Initial Design and Stakeholder Buy-in

Starting with low-fidelity wireframes, I outlined the newly proposed information architecture. The main screen would contain all rooms assigned to a specific nurse and the status of each room. Each room would indicate what patient was in it, whether the patient was in bed or sitting in a chair, and what important information a nurse needed to know about the patient to assist them better. Once a patient triggered an alert, a pop-up modal would appear on everyone's screen, regardless of who had the room assigned to them, with two options to select. Nurses could either tap that they were attending to the alert and were on the way or were busy and unable to attend. The pop-up modal would remain until someone selected that they could attend the alert so that no alert got missed. 

With the initial wireframes completed, I spent considerable time interviewing stakeholders to gain their alignment on the new user journeys. Leadership suggested that we add gamification to the app to increase engagement. We had yet to consider gamification in our initial wires, and it was a good idea to explore going forward. I committed to a two-week sprint cadence where, at the end of every sprint, the creative team would show leadership a working prototype of new ideas and present our research findings. Our rapid iteration cycle would aim to uncover new findings and incorporate them into the next version of our prototype as quickly as possible. We would fail fast so we could improve faster. 

Prototyping and Sign-off

At this point, I moved testing to mid-fidelity wireframes. Our design system started to take shape, and we could iterate rapidly due to our reusable design components. Since we knew our information architecture was solid, we could work out the visual UI to be as intuitive as possible. The prototypes became more sophisticated, and after another few rounds of stakeholder approval, the creative team could move into high-fidelity wireframes. We quickly updated our components to high fidelity, and after a couple of sprints of iterations, we had our final prototype to show to leadership and customers. The final prototype I built imitated real alerts sent to the device so leadership could get a sense of how nurses would have to respond. After receiving final approval, the application was ready for development. 

AlertNotification.png
SensorSettings.png
Room Settings.png
The Development Issue

Development would be another hurdle, as the onshore dev team lacked the capacity to build the VSTAlert mobile app. With pressure from leadership to complete the app, my manager and I decided to take on a significant portion of the code development ourselves. We spent two sprints learning React.js and implementing the Ionic framework to make our designs come to life. Leadership gave us a small offshore dev team to work with, and after five weeks, we had a working, native prototype on our phones. My manager handled the app's routing and back-end services while I tackled the responsive front-end portion and our code repositories on GitHub. After weeks of hard work learning a new front-end language and building our app from scratch, the creative team was able to field-test the new application with users. 

Initial Adoption

Initial testing went well, and the new information architecture and modern, intuitive design fit the nurses' lifestyles exceptionally well. The new app drastically reduced training time, and as a result, app adoption increased significantly. Nurses could better communicate who would attend each alert, and knowing who was covering what room became intuitive. The app displayed vital information regarding the resident in each room so that nurses could better assist them upon arrival. For the first time, the app did not get in the way of their workflow. 

Post Launch Success Tracking Card.png
Conclusion

In many aspects of our lives, we adapt to technology. We learn complex software to do our jobs, our phones constantly update in our pockets, forcing us to relearn how to use them, and whenever we get into a different car, we have to figure out how to drive it. Often, we have the luxury of dedicating time to learning new technology, but sometimes, we just need things to work right away. That was the case for the nurses who could not afford to spend time learning an unintuitive app when the health of their residents was on the line. We had to fit into their lives, not the other way around. At the end of the day, users simply want technology to work for them. It's our responsibility as designers to make sure it does.

© 2024 Jakob Andersson

bottom of page