During the worker's compensation claims process, adjusters are in charge of managing one to several injured workers as they recover. Our product allows adjusters to communicate and manage injured workers in one.

However, many key details like documents and specific injured worker information are hidden a layer beneath the main page (Currently split into 2 screens).

Gain Life's adjuster platform currently places most of the important information a page beneath the main claims content. However, this information happens to be most important to adjusters. There also exists duplicate information from the main page on this page.

Three concepts were created in the form of wireframes. I worked in low to mid-fidelity and checked in with stakeholders and my design manager early and often to determine the best course of action.

After meeting with the development team and stakeholders, we eliminated the two column designs present in Version 1 and 3. However, we wanted to the modularity of those versions, which resulted in a completely hi-fi new version.

The team created two split remote user tests for with five key scenarios for the two high-fidelity versions for 60 participants. Our adjusters were of older age.

The results were quite surprising as the designs were not usable. Below are the results for expected completion time and percentage across both versions.

Users got lost when looking for information because both pages had poor hierarchy to highlight important information. A majority of users didn't even know how to switch between claims, find and send documents, and message.

The hardest problems were handling the business scaling and edge cases. As we were expanding to new lines of business, many new requirements came into play, which gradually added more design elements.

The UI changing based on the customer environment made it hard to balance customer requests into one clean UI. Edge case handling was easily the most difficult part of the entire design process for me.

In the future, I would try to make a log of possible edge cases first, and work directly with engineering to see how they would be handled before designing.

• Focus on more use cases and user needs (new clients were coming in with many requirements) which forced us to make a couple last minute changes to universally conform to their needs (some aspects of the final version could've easily been considered)

• Check in with development early on to make sure certain things are implementable (Adjusting to the current app margins, adding in new buttons and stuff based on new / incoming clients etc)