My work with this client required a broad array of UX skills. After a few months of onboarding, I worked with minimal oversight as acting UX Lead for multiple project teams while working with a Visual Designer.

When this initiative first kicked off, the insurance company requesting work had multiple aging, disconnected insurance tracking systems which were operated by a manual, internal workforce. The company requested a solution to not only modernize, streamline, and unify the legacy systems, but required little to no training for a downsized workforce. Initially, a UX team spearheaded the start of the project with extensive user research, design, testing, and reiteration. The solution agreed upon was a semi-automated intranet application that would utilize human oversight to correct tracking errors. The application has been in multiple project cycles since 2015.

This project has presented many challenges since my onboarding in Spring 2018. The needs of this insurance company are unique and present opportunities to cultivate a company culture of design thinking and research investment. With this in mind, I have had a constant goal of UX education and application through work. Over the last 2 years, spearheaded by me, a collection of project teams worked towards user interface standardization, a UI code upgrade that supports future reskinning, and user research initiatives for high impact features.

​

As the scope of the project is far too broad to explain here, please view a few details regarding my work on this application below.

​In Summer 2019, the insurance company requested usability enhancements regarding a location within the application called the “Activity Feed”. This area of the UI documents all changes to a single insurance profile, organized by time. The company’s user tracking reports displayed that they were spending enough time navigating through the Activity Feed that the overall work velocity of the user was measurably impacted beyond what the business found reasonable. User research was gathered by way of survey. Project teams provided enhancements based off of the resulting data, but required further research to confirm the efficacy of the changes around 6 months later, in Spring 2020.

It was established in the prior user research I had collected that users do not know where the information they are looking for is located. As a result, they are required to scan through all logged information within the UI. Certain events were known to “spam” multiple entries spanning across multiple pages within the feed. Furthermore, half of the users required data from only a few logged events while the other half required all data from all logged events; customer service representatives versus auditors. Loading the data into each activity feed page took upwards of 30 seconds, which lead to multiple clicks for reloads within the UI driven by user frustration. These additional clicks would, in turn, further slowed down the data load. Backend enhancements were what I recommended in order to alleviate the loading-based user pain points. Technical exploration of said enhancements found the updates were cumbersome and needed further technical data analysis before they could continue.

With these complexities in mind, more research was proposed in order to refine work flow bottlenecks and prioritizations. The company approved use of surveys to collect user data.

Leveraging the previous research mentioned above, I crafted a survey with similarly formatted questions, adjusted for the new enhancements while reducing answer bias based off of what was observed previously. Additional optional long answer fields were added, as well. The intent of these was to improve the chances of finding trends outside of what was assumed based off of the previous survey. Results were surprising, as the new survey received 214 individual responses compared to the initial survey’s 67, which had lacked the optional long answer fields.

Utilizing Excel, I created a keyword search counter to track key concepts within the long answers. Only one count per answer was allowed to prevent over representation of key concepts. Once multiple choice and open answer concepts were automatically evaluated and categorized, I conducted a manual review to avoid further data bias resulting from the automation. Finally, results were compared to previous data collected. Pain points mentioned most often were ranked highest in order to provide clarity to future prioritization.

Results indicated that while enhancements in the last 6 months had improved the experience of using the activity feed, the pre-existing pain points remained at the forefront of user feedback. Removal of “spam” events was not welcome for auditors, but was not seen as enough for customer care representatives, who only needed to see a few items. For both, “work item” events were still difficult to track and presented disjointed information between steps in the process in certain situations. Filters were not being utilized as they would trigger another data load, and were thus avoided. Due to this, data load times had been perceived as worse than before. This can be attributed to a new, extra-large batch of data being loaded into the system a few months prior, as that would require more data to search through before pulling it into the UI. Such an observation was corroborated by the project teams.

With all this in mind, the intent of my following recommendations was to continue to push for the backend enhancements while also allowing for users to find info as quickly as possible in the meantime. In order to display to the auditors and the customer service representatives the data relevant to their jobs, and to prevent the data views for one job from affecting the other, I proposed utilizing the existing job roles system to customize the activity feed data that was viewable for each job. Upon further discussion with the teams, it was discovered that this approach was dependent on the backend work. As a result, I recommended splitting out a separate view for auditing that displayed all events. The Activity Feed would, meanwhile, be further cleaned up to reduce data unnecessary to customer care representatives in completing their work. I also recommended all activity feed tabs have a date filter added to allow users to jump multiple pages with fewer clicks. While splitting this data into separate sections would not alleviate the loading issues, the intent was to allow the users to find what they needed within as few loads, or clicks, as possible.

With respect to the individual “work item” events, I proposed a few enhancements. As the Activity Feed is meant to show a timeline of events, multi-step processes working adjacent to other processes sometimes made viewing work items into a strange mixture of all said processes, rather than a streamlined series of events. As a result, in order to view “work item” events in a more easily understood manner, I recommended a new UI display of this data. There were two broad approaches, one which utilizes the filters in the Activity Feed and one which split out the work items into their own view, much like the audit info. The filter approach would utilize already existing functionalities of the UI, but would require the user to load data upon selection. Meanwhile, the separate work item view would provide duplicate information within the UI, as the work item data would also exist within the audit and activity feed views. Furthermore, having work items in a separate view is reminiscent of the legacy programs many current users were already comfortable with, which could cause familiarity bias. However, the separate view would provide more freedom in how data was grouped.

After discussion with the project teams and using a remote concept test with users with regards to the two approaches, the separate work item view was approved, along with all previous recommendations. The teams also agreed to another round of testing after another 6 months to confirm whether the changes had the intended effect. Scan-ability and discoverability of information required more data to further streamline the work processes for users.

In Spring 2020, requests came in to alleviate a pain point experienced when users attempted to fill out forms within the insurance tracking application. The bulk of the forms within the application took up multiple pages, and required extreme detail with multiple required fields. This was often cumbersome for the users’ cognitive load as they had to either memorize these fine details or find ways outside of the application to document the data they needed to input, such as a text file. When required data was not documented or recalled, the user would then need to back out of the form to find the relevant data. This would undo all previous work within the form pages, requiring users to re-enter all information.

I created a set of four prototypes based off of wireframes a previous UX resource provided before their departure from the program. The concepts were viewed favorably by the domain team. I researched Google Material, Apple, and Microsoft standards in order to provide affordances which indicated the correct intent for the prototypes. One concept included moving the form, which was displayed within a modal, around the screen while allowing the user to interact with the rest of the application behind. Another proposed moving the data in the modal into a side or bottom panel. Finally, options also included moving the modal info into a separate tab, a data reference kept open within the application that allowed the user to switch back when needed, or open it in a separate browser window. The intent of these was to allow the large form its own area of the UI, rather than as an overlay modal that blocked the user from utilizing the rest of the application. With this, the user would be able to view the data and form side by side, reducing the need to use screenshots, external text documents, or sticky notes.

I proposed a test that focused on collecting qualitative data using a moderated, remote concept test utilizing the prototypes I created. I then wrote a script, with questions ranked most to least important.

Data was recorded and broken up into positive, negative, and neutral responses to each prototype version. I tested affordances with users to determine if the icons/textures for dragging, pinning, and/or opening the form in a new window were intuitive. As users utilized dual monitors, it was assumed at the start of the initiative that users would prefer to have the forms open in a new browser window so that they could have the main system and the form side by side, without overlapping screen areas. However, I discovered users preferred to move the modal around the screen within the web application. Those interviewed expressed concerns with losing track of the other window should it become hidden behind other applications.

Following my findings analysis, I created new versions of the original wireframes that performed the highest with various interaction options and UI layouts for review. My recommendations were to allow users to move the modal around within the browser. They would then be allowed to interact with the rest of the web system behind the modal, rather than having the modal block access. Finally, the modal would not be allowed to be pulled so far that it disappeared beyond the boundaries of the window. Additionally, my proposals included updating the interaction icon to increase intuition of the intended affordance for users, and a double click included for the modal header in order to return the modal to starting position.

​

It was determined that the functionality for moving modals would be rolled out in a single area of the web app, the area where the majority of users experienced the pain point, and would be used to track usability data and receive feedback before further areas were addressed. As having only one area with the new functionality could negatively impact discoverability of the new feature, I encouraged the team to provide release notes in order to increase user awareness.