Users started turning to our client's support team at alarming rates. We reviewed recent feature releases and helped them solve a mobile-first mystery.

Addition By Subtraction

Challenge 

A product team in InsureTech was launching features left and right in a rush to meet release deadlines for their most recent innovation that was still in beta release. Real-time monitoring analytics told us that one-quarter of sessions included the user taking action to reverse a step in the process. 

Approach 

User Interviews 

Our client didn’t think there was time to do research— they just wanted us to change the UI to make the process easier, simpler and more straightforward. We gently pushed back until they gave us 48 hours to do research. Most people would be surprised by what research can help them learn in 48 hours. We scheduled six 15-minute meetings with generic consumer testers. We sent them test insurance packages using the client system— a task they should be able to complete with no assistance on the first try. We asked testers to think aloud while they used the system. 

Heatmapping 

Since the insurance underwriting process took multiple steps (and required signing multiple documents) we meticulously documented the every screen the user might see during this particular checkout workflow. Anytime there was an observable friction-point (i.e. the user had to backtrack, couldn’t complete a task, or otherwise made a mistake), we marked the visual location of the action. This type of visual understanding allowed us to better understand risky hot spots in the process.

Design Historicity 

We combed over all the documentation left by previous designers and learned that the prevailing wisdom at the start of the project was to design desktop first and degrade to mobile. A review of relveant user analytics also showed increasing frequency on mobile devices, which began at release dates corresponding with bolt-on feature releases that compounded an already crowded mobile UI. 

Results 

As a result of taking the time to re-trace historical design descisions on the project, we achieved the buy-in necessary to get the team to prioitize mobile-first design above all other feature releases. We uncovered an analytical story that showed a high frequency of process failures on mobile devices and were able to heatmap key areas to receive process attention including button styles, text and relative (responsive) screen location. On the mobile view, the user had to take action to close particular screen near the end of the process. If the user failed to take action on this screen, they would not have technically completed the process. We solved this problem by working with the development team to create an API hook that closes window within a few tenths of a second of completing the process, making it almost imperceptible to users. 

If we are being honest— most situations in which users (all of the sudden) have difficulty using a system they’ve previously not had difficulty using can be tracked back to a series of unfortunate design decisions. Sometimes research and strategy is more like an archeological dig than a construction project.

If your the design isn’t working, you can usually trace the decision back to a time when:

  • Nobody was is confident about the decision to change/add…
  • The idea came up at the end of a long meeting…
  • Team felt like they had to disagree and commit…
  • The product team do enough research…
  • An Executive wanted it…
  • A major client gave feedback tilted the scale too much…
  • Something similar seemed like it worked elsewhere…
  • The designer said it was best and everyone relied on their expertise…
  • The team voted and it was close…