Insis, an insurance software was not easy to use and the interface looked dated. A complete redesign of the user experience and the front end was required.
Because the system was really complex as it covered almost all insurance business processes, the project scope involved only the claims processing part of the system.
Role and process
We were 2 UX full-time designers and 2 temporary UX contractors in the begging to help us get to track faster. We were using a 1-week scrum development process.
Understanding insurance business processes
As the product we were designing was very complex we spent a lot of time talking with client representatives and business analysts. We needed a very good understanding of the system so we could make it simpler.
Enterprise applications have different UX priorities than websites. Typically, users interact with the interface 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 different sites. Therefore, on websites, usually, most of the users are novices and sites are adapted more towards new users. In enterprise systems, the opposite is the case. The majority of users are expert and interfaces should be adapted more toward them. Of course, this doesn’t mean we should not optimize for new users.
Business analyst showing us how the different actors participate during different stages of the claim registration process
As we wanted to make the best insurance software in the world, we researched our competitors and the results were published in the project’s wiki. It was very helpful as we got ideas for some neat interaction patterns and features. Basically, only 2 competitors were identified as having good user experience, Guidewire and Accenture. It seemed that they were the only ones doing proper user research. Broadly, the insurance sector was lagging behind banking and other financial sectors in terms of technological advancement. I was excited because the competition was not great, and, in my opinion, we were able to design a much better product than our competitors.
User research difficulties
Claim processing user types
Since we now understood more about the business and our competitors it was time for 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 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 we are UX specialists, and we should design it based on our past experience. No time for user research, the client don’t know what they want, etc. However, 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 and then stressed that Jacob Nielsen suggests field studies are the most valuable method before major redesigns. If we miss something important at the beginning, it will cost us much more to change it later.
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. A lot of valuable information was collected there.
Furthermore, 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. Also, we did a survey trying to elucidate user preferences and opinions from various client employees.
Defining the information architecture
Later, we did lots of workshops to decide what features to develop and what information architecture we should use. The more experienced senior UX contractor proposed a task-centric interface, meaning that the interface is focused around 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 get the information.
We started producing many variants of the navigation, layouts, and informational pages. Lots of interaction patterns were produced; for example, selection of a claim object, which is 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, we created a terminology excel spreadsheet. There we grouped similar terms like, “create” and “new” and defined which of them should be used.
After we cleared our picture about the IA it was time to produce a high-fidelity prototype. It was necessary 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 stressed 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. Only my UX colleague and I 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 progress of the prototype to the whole team. Each screen was validated with business analysts and the development team. We needed to make sure that the designs we were proposing were feasible. For example, we had a proposition to use 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 is a lot of work because there are hundreds of them. Another area that needs progress is keyboard shortcuts to support our expert users.