Länsförsäkringar CRM

2018 – ✟2022

Redesign of a CRM system

In 2018, the Swedish insurance company Länsförsäkringar assigned me to help improve the usability and visual design of their CRM system. The system, internally called “Ett KUND,” is based on Siebel CRM (owned by Oracle).

The situation

This is just one of many, many pages that the user has to delve through.

The CRM system itself is capable of handling any chunk of data you might throw at it and can be integrated with most of the other old systems that any large corporation has. So, Siebel is (was) probably great for the work it was intended to do. However, since the initial implementation of the CRM system more than ten years ago, no one really paid any attention to how the system should work, look, and behave.

So, after those years of internal development, the UI now was overrun by 5-6 levels of Y-axis tabs (that the user had to scroll sideways to see), big buttons in strange colours mixed with tiny icons, erratic non standardised ways of saving data, confusing micro copy in alerts and modals, etc etc.

Oh, there is also more than 400 screen recordings giving aid on how to perform various tasks in the system. That gives a hint of the dire need for an overhaul of, well … pretty much everything.

Defining the problem a.k.a ’slicing the elephant’

Apart from being very hard for new users to master, the CRM system had other areas of improvement. For example, the visual appearance. Länsförsäkringar (LF) has its own definition of colours, typography, iconography, etc., that together set LF's visual appearance. The company also has set rules on "how interaction should be presented to the end user." Most of these rules and guidelines were overridden in the CRM system.

Another thing to consider when building a tool like this is how LF is structured. The company is divided into 28 local branches, each of which can run itself as they think is fit to comply with the needs of their respective customers. There is a term defined as a "common way of working" that all local companies want to be aligned with. Still, throughout the years, various special ways of handling customers, naming conventions, saving specific data, etc, have emerged. This means that the task of building one tool that would suit all 28 branches was even trickier.

Finally, LF does not only sell insurance but is also a bank. And if you're a bank, you have very certain rules about what information can be shared between different users with different access rights.

Prerequisites

The initial though to just redesign/style the Siebel application itself was soon scrapped. It simply wasn't possible to clean up weird UX patterns or inject CSS and HTML to get a reasonable look and feel according to what LF stands for. We also couldn't just start all over due to the magnitude of data inside Siebel, as well as a lot of dependencies on external (old) systems.

But was there perhaps a way to use just the information in Siebel and then present that information in a nice way in a modern front-end framework? We decided to jump down that rabbit hole and see what we could come up with.

The masterplan looked something like this:

1. Perform studies/interviews with different users to understand what they do & want to have done

2. Design and build a new UI that fetched data from Siebel and presented it so that the users get things done quicker, easier, and more intuitively. The new "UI layer" should comply with LF's visual identity and be built with modern web technology (and also be mobile-friendly)

4. Build, test, iterate & evolve

First steps in prototyping

After a series of interviews, I gathered the findings and made a few interactive mockups/prototypes. The idea was to test whether the direction was heading the right way and whether we in the project group understood the pain points and delivered on areas of improvement.

User interface design

After a bazillion iterations and trials with close contact with focus groups, we eventually settled for a balance between "old ways of viewing stuff" and an interface that followed LF's visual guidelines.

Watching the service come to life

After a very long time, we eventually had a working PoC that we could start to open to selected beta testers.

The initial trials went very well. The main question was, "When will I be able to do X or Y?". Almost nothing in the feedback was pointing to that we had misunderstood the workflow or that we had crippled functionality from the "old" Siebel product.

It really felt great to have reached the point where we had a basic functioning product that the user could use in his/her everyday work. Users also mentioned that "those +400 information videos really weren't needed anymore."

The design files started out as Sketch files, but eventually was moved over to Figma. Many, many .fig-designs were created.

But then …

Just before summer 2022, our team was alerted that "there were ongoing talks and discussions regarding the future of our project." At first, we thought these discussions must be related to increased engagement in the project, but soon, we realized that they were quite the opposite.

A few weeks later, we got the message that everything we had done should stop. No more development, UX, or UI work should be developed or taken further. Mhm … okay, but why?

Arguments like "it's technically complex" (yes, we know. And we solved it) and "no one is using the system" (yes, we know. We just added a tiny bit of beta testers) didn't make the reasoning behind axing our project clearer. Working as a consultant comes with a great responsibility to accept the client's decisions – regardless of what you think about things. But … in this case, it would have been nice to understand the real reason why the Siebel facelift was put six feet underground.

Oh well, on to the next project :)