Car insurance

As opposed to Project Atomium, we started with a functional user flow that had previously shown promising results. However, as we entered the dynamic landscape of 2023, we realized the need for a significant transformation. The user flow, though once successful, no longer met the elevated standards expected in the present era. Moreover, it had yet to embrace the latest version of the cutting-edge design system developed by ING.

Besides the obvious, technical issues – like not utilising ING Flow – there were some glaring issues.

• The flow is running in a modal window.
• Accessibility issues
• Illogical information architecture
  • ordering of the questions
  • overall screens order
• Weird, apparently out of place questions
• Business centric instead of user centric
• Low conversion rate
• High abandonment rate
• No measuring plan is implemented (ie. proper analytics)
  • We know the abandonment rate between screens but we don’t know why
  • No event tracking tied to buttons
  • Improper Adobe Analytics dashboard
  • High probability of analytics errors (ie. Improper implementation)
• Lack of consistency between ING Insurance flows

A competitive benchmark was done to evaluate and compare the user experience of the car insurance products with our direct competitors. It involved conducting a systematic analysis and assessment of various UX aspects:

• UX/UI
• Behavioural design
• The type and order of questions asked
• The layout of the login screen
• Promotions/X-sell

Therefore, the following companies and their services were analysed

• Yuzzu
• Corona Direct
• Ethias
• BNPPF
• KBC
• Belfius
• Argenta
• Yago
• Progessive
• ANWB
• Inshared

From a UX perspective, a stakeholder map is a powerful tool that helps identify and categorize the different groups of people who have a vested interest in the success of a particular product or project. This map is used to visualize the relationships between stakeholders, their level of influence, and their interests.

The stakeholder map for UX includes both internal and external stakeholders such as users, designers, developers, managers, customers, investors, and regulators. Each stakeholder is assigned a specific category, such as primary, secondary, or tertiary, based on their level of influence and importance to the project.

The primary goal of creating a stakeholder map in UX is to design and develop products that meet the needs and expectations of all stakeholders involved. By understanding the interests, motivations, and goals of each stakeholder, designers can create user experiences that align with the business goals and objectives of the project.

Moreover, a stakeholder map in UX can help identify potential conflicts or issues that may arise during the project’s lifecycle. This allows UX professionals to proactively address these challenges and ensure that the final product meets the needs of all stakeholders involved.

In conclusion, a stakeholder map is an essential tool for UX professionals, providing a clear understanding of the stakeholder landscape, helping to identify potential issues, and creating products that meet the needs of all stakeholders.

In the course of a few meetings with the tribes, the mapping was done.

To my surprise, there wasn’t any comprehensive user flow map. From both the user’s perspective or the intricate processes involved, it became evident that mapping the current flow was an essential task we couldn’t overlook. It was clear that by creating a detailed map, we could gain a deeper understanding of the user journey and uncover potential areas for enhancement.

With a collaborative spirit, ING and NN joined forces, actively involving all stakeholders. This shared effort allowed us to have diverse perspectives and tap into a wealth of collective expertise, ensuring a holistic and comprehensive approach to mapping the user flow.

For those unfamiliar, a design sprint is a structured process that brings together cross-functional teams to solve complex problems and create innovative solutions in a short amount of time. It involves rapid prototyping, user testing, and iteration, all within a compressed timeframe.

By organizing a design sprint, we were able to bring together the right people and resources to tackle the challenge at hand, while also fostering a collaborative and creative environment. It was an exciting and exhilarating process, one that allowed us to explore new ideas and test them quickly.

Ultimately, the design sprint was the perfect solution for our needs, allowing us to create an innovative solution that was grounded in user needs and backed by rigorous testing.

Over the course of multiple days, our team dedicated focused efforts to shape the desired user flow, with a specific emphasis on the “happy version” – an ideal scenario where everything goes smoothly for the user.
By implementing the user flow I proposed, we were able to refine the overall user experience and fostered an active and productive dialogue between the ING (UX) and NN (Technical) teams. During this collaborative process, we identified a couple of sections within the flow that required improvement:

1. Determining car age: One area of concern was the inability to ascertain whether a car is more or less than two years old when the registration number is known. This limitation prompted us to explore potential solutions in order to minify the friction of the flow.
2. The information we are able to extract from the VIN number (registration number). This side of the flow is covered by an API called INFORMEX. This API is able to pull only some information, that doesn’t break the EU GDPR rules. The first registration of the car is sadly, not an information we had access to.

Over the course of multiple days, our team dedicated focused efforts to shape the desired user flow, with a specific emphasis on the “happy version” – an ideal scenario where everything goes smoothly for the user.

By implementing the user flow I proposed, we were able to refine the overall user experience and fostered an active and productive dialogue between the ING (UX) and NN (Technical) teams. During this collaborative process, we identified a couple of sections within the flow that required improvement:

1. Determining car age: One area of concern was the inability to ascertain whether a car is more or less than two years old when the registration number is known. This limitation prompted us to explore potential solutions in order to minify the friction of the flow.
2. The information we are able to extract from the VIN number (registration number). This side of the flow is covered by an API called INFORMEX. This API is able to pull only some information, that doesn’t break the EU GDPR rules. The first registration of the car is sadly, not an information we had access to.
3. Home ownership inquiry: Another section in the flow involved asking the user about their status as a home owner, as this factor contributes to the overall “rating” of the user. However, we recognized the absurdity of this question and we initiated a sub-track with NN to see if this question can be removed.

Explainer: In this context, the age of the car plays a pivotal role, shaping the unique treatment and considerations provided to users. The distinction lies in whether the car is within the range of approximately 2 years old or older. A car exceeding the 2-year mark is deemed a “second-hand car,” which entails distinct premium rates and specific information requirements compared to those associated with owning a car less than 2 years old.