loop+ iOS
Application (Beta)


Wheelchair users are prone to suffering physical injury if they don’t build healthy seating behaviours. As these users are either unable to feel or communicate feeling, they often miss the tell-tale signs of a developing injury. loop+ aims to provide visibility all day everyday into their seating behaviours using sensor pad technology that continuously records data based on pressure and movement.

This also provides a huge benefit to their dedicated support team. Allied health professionals can easily document, quantify and record seating behaviours of their clients outside of the clinic, resulting in better care and evidence based data which can help speed up insurer assessments for needed equipment.


 

The loop+ device being fitted into a wheelchair. The chair on the left shows how un-intrusive the pad is when fitted.

Rectangle 22 (2).png
 

Role

I was brought in to work across the iOS application. As the only designer in the team my role spanned the full end to end design process. This would allow me to influence product decisions based on research captured, drive a visual direction for the brand and help install a design framework which would scale with the organisation.

The Approach

Having gathered field data from a basic prototype, the business had a clear vision of where to take the base app. Emphasis was put on two key views: 

Pad view - Provides a real time visual interpretation of users seated pressure and position.
Events view - Allows users to log daily activities and view pressure and position over the duration of the event.

Overlaying the two data sets would allow users and their support team to identify patterns in pressure across differing events helping to highlight areas of potential risk.

 

Early concepts for the event screen - figuring out the types of content we may need to display in the app.

 

Rectangle 22 (2).png
 

Creating Engagement

As the design began to take shape, one concern we had was around engagement. How were we going to create the necessary engagement that would see users picking up the app on a daily basis? As users were new to the concept they couldn’t truly say how the app would fit into their current lifestyle. Therefore getting the basic functionality out to a range of users as soon as possible was vital to start understanding this.

Process

Our aim was to follow a build measure, learn methodology and produce a working prototype (Beta) to get in the hands of users as quickly as possible.  

Deliverables were formed around key user needs which drove a staged release plan. Our sprint cycle ran every 3 weeks and it took roughly 6 sprints to get us to our first releasable prototype. Embedding design into the development sprints worked smoothly, allowing for clear visibility and increased collaboration across the team.

 

Events and Pad views

 

What Were Users Saying?

Our first beta release (0.2.0) allowed a group of pre-selected users to get their hands on the app. We asked them to use the product over a 2 week period, interacting with the app as much as they could so we could test the quality of their overall experience across both hardware and software. 

  • Users slowly decreased their usage over the testing period, alluding to the engagement issue we had prior concerns around.

  • Users suggested that although intuitive, it took too long to add an event on the go. This led to multiple users logging retrospectively making the data captured less accurate. 

  • Some of the less tech savvy users struggled to understand what the app was showing them and how they were expected to use it. They were looking to loop+ to educate them or provide the information to set them up properly.

  • Users felt that they were not seeing enough output from the app in terms of actionable feedback, as per the users quote below.

 
Rectangle 22 (4).png

 “It's the data that shows me what times of day I’m typically most at risk which is important to me. Maybe seeing this in graphs, where the risk may increase until I do a pressure relief, Or how many times throughout the day I’m over a threshold.”

loop+ Tester

 

Next Steps 

We felt that providing users more actionable feedback could in turn solve the engagement concern. 

The solution was a summary page that would provide a daily snapshot of information. This would ideally update in realtime, initially providing basic statistical data such as idle vs active times and periods where users were out of their ideal position. Over subsequent releases we would flesh this out to build in user defined goals which could be set by either the user or their support team, and focus on areas of immediate risk through pressure management.

We continued to build out 2 additional releases closely following the build measure learn process and addressing issues captured through our UAT which followed each release. This got us to a point where we could confidently release the product to market.

 
 

Replay event screen and the first cut of the summary screen ready for release.

 
 

Building A Design System

Throughout each release, my intention was to put in place the required tools, processes and resources that could scale with the business. It was key to build out a design system that would provide consistency across app and efficiencies through design. This housed all styles, components and patterns with in-depth guidelines on how each should be applied meaning any designer coming into the team could easily get up and run.


 

Figma design system

 

Capturing Post Release User Feedback

As sales picked up and our user base increased, we wanted to make sure the feedback being captured through the customer experience team was not lost to the product team. We set up a system (Fibery) which would pull information from multiple streams and house all user feedback in one location. This integrated our CRM, in product messaging service and allowed the CX team to input any conversations they were having in the field. Monthly it would be my responsibility to synthesis the data and build hunches / insights around what we were hearing. This provided us a true reflection of what users were saying and how often they were saying it which formed user needs used to influence product planning.

 

One “Hunch” created in Fibery off the back of 10 seperate references. This was used to drive product planning for future releases.