Period: June 2016 – October 2017
Insis, an insurance software was not easy to use and the interface was outdated. It required a complete redesign of the front-end and the whole user experience.
Due to the high complexity of the system, which covered almost all types of insurance business lines, the project scope involved only the claims processing part of the system.
Role and process
2 UX full-time designers and 2 temporary UX contractors were employed in the beginning to help us get to track faster. We were using a 1-week scrum development process.
Understanding insurance business processes
Considering the complexity of Insis, we spent a lot of time talking with client representatives and business analysts. We needed a solid understanding of the system in order to make it simpler.
Enterprise applications have different UX priorities than websites. Typically, enterprise users interact with their software approximately 6-8 hours a day. They also go through initial 1-week training before the first real use of the system.
Given that much interaction and training time, employees quickly adapt and become expert users of the system. On the other hand, online users occasionally interact with many sites. Therefore, websites are adapted more towards new users.
In enterprise systems, the opposite case is true. The majority of users are experts and interfaces should be adapted toward them. Of course, this doesn’t mean we should not optimize for new users. But, the primary focus should be the experts that use the system for 8 hours a day.
Business analyst showing us how the different actors participate during different stages of the claim registration process
Given the fact the aim was to make the best insurance software in the world, we researched our competitors, and the results were published in the project’s wiki. This proved to be very helpful as we got ideas for some neat interaction patterns and features.
Basically, only two of our competitors were identified as providing a good user experience, Guidewire and Accenture. It seemed that they were the only ones doing proper user research. Overall, the insurance sector was lagging behind banking and other financial sectors in terms of technological advancement.
I was excited about the inferior competition since it allowed us to design a much better product.
User research difficulties
Claim processing user types
Since we now understood more about the business and our competitors, it was time to focus on user research.
We actually never saw a user in person and don’t know what they look like.
- Are they young or old?
- What is their computer literacy?
- What supporting tools do they use while working?
- What computer peripherals do they have?
- Do they talk on the phone while interacting with the system?
A field study would answer all of the above questions and give us a great starting point.
However, the management had their business concerns and denied visiting any client offices. Their stance was that as UX specialists, we should design based on our experience. They claim there was no time for user research; the clients don’t know what they want, etc. Regardless, we appointed a meeting, which included all of the 4 UX designers and the management, to convince them of the opposite.
I used a research paper by Axel van Lamsweerde showing that one-third of companies don’t finish their projects because of inadequate requirements. Furthermore, I stressed that Jacob Nielsen suggests field studies are the most valuable method before major redesigns. If we initially miss something important, it will cost us much more to change it later on.
It wasn’t easy, but, eventually, they agreed with us. Finally, we started searching for a suitable client for a field study. So, we visited one client from Russia. It was interesting to find out that our users are quite computer literate. They were using MS Excel very competently, typing really fast, and using keyboard shortcuts. So, a lot of valuable information was collected.
Moreover, we did focus groups and interviews with other clients from the Nordics. They were working with more than 10 systems and had a lot of valuable experience to share. Additionally, a survey was conducted to elucidate user preferences and opinions from various client employees.
Defining the information architecture
Following, we did many workshops to decide what features to develop and what information architecture to use. The more experienced senior UX contractor proposed a task-centric interface, which is focused on a task list. It should allow users to complete task after task without the need to organize or remember them. In theory, this paradigm should save a lot of cognitive load for our users.
Furthermore, we proposed “profiles” for each business object, like a claim, person, policy, etc. It is a way of grouping entity information in one place, so users are not required to search in different parts of the system to attain information.
We started producing many variants of the navigation, layouts, and informational pages. Lots of interaction patterns were created; for example, selection of a claim object used during First Notice of Loss registration or initial claim registration. It was designed to reduce the interaction cost of selecting an object.
To be consistent with our terminology across the whole application, a terminology excel spreadsheet was created. Here, we grouped similar terms like “create” and “new” and defined which of them should be used.
After we had cleared our picture about the IA, it was time to produce a high-fidelity prototype. This stage is essential for testing concepts with users and also as a reference for the front-end developers. We chose Axure as a tool because it is quite flexible and, once set up, easy to use.
We conducted a focus group interview with users who work as claim clerks, claim adjusters, and supervisors. They had experience working with multiple claim administration systems. During the discussions, our clients emphasized how important note-taking is during claim processing because multiple actors interact with it.
The information from the focus interview was very beneficial; based on it, we made notes functionality more prominent and added other functionalities.
After that, our UX contractors left the project. From here on, myself and my UX colleague were left as defendants of the UX. Next, we had to create a high-fidelity prototype and continuously iterate on it.
Furthermore, at the end of each sprint, we presented the prototype progress to the whole team. Each screen was validated with business analysts and the development team. It was necessary to ensure the designs we were proposing were feasible. For example, we proposed the use of a “search everything field” or Omni search. It would’ve been convenient for our users to have a single search field where they could find anything in the system. However, our developers quickly disapproved of it because it requires enormous developmental effort.
The system is still in development. A high-fidelity prototype is available, so regular user testing/interview sessions need to be conducted to optimize all remaining business processes and user journeys. It requires a lot of work because there are hundreds of them. Besides, another area that needs progress is keyboard shortcuts to support our expert users.