SmartClaims

Lead UI designer in an international product team in SwissRe

Project Brief

Create a solution to help automotive insurances digitize their claim processing activites. This should reduce their costs and improve their policyholder's experience.

Duration

8 months (April - December 2021)

Tools

Team

Scrum setup with 10 - 18 team members: PO, BE + FE develpers, QA, scrum master, 1 designer (me)

UX on sand?

To succesfully solve problems as a UX designer we need to work in a team and with a process which puts the user first. If the team culture, process and product strategy do not do this, catering for the user’s experience is like trying to build a house on sand.

No matter how beautifully the UX principles are adhered to, the house won’t be usable.

Below is a casestudy on how we were building on sand and its affects on UX.

Methodology

Agile/Scrum

What

  • It was decided that we use agile principles to develop this product. Agile principles emphasize the need for companies to respond to market demands quickly
  • Scrum is a methodology used to implement agile principles. Scrum is usually conducted in 2 week sprints and is made up of events such as daily standups, planning, backlog refinement, review and retro.

Problem(s)

  • While we followed scrum events, we didn’t follow Agile principles. We tried to fit the Waterfall method into a scrum outfit eg. n sprints for design, 1 sprint for development, 1 sprint for QA. At this time I didnt realise that most companies end up doing this: a “Scrumfall”.
  • Due to the nature of Scrumfall. The PO and I created designs without consulting the developers. After we agreed on designs and handed it over to the developers, there were always further changes needed to be made due to technical contraints.

Why this is bad for UX/UI

Once a step has been completed in Waterfall, it’s difficult to go back and make changes. Waterfall demands very clear product requirements from the beginning. Due to the chain of teams and processess the customer is far removed from the development team. This means the end result may not match user needs. In contrast, Agile builds a working version of the whole project (a MVP) so the changing customer can shape what is built.

Furthermore, by not including the developers from the start of the design process it will take longer to get features developed. This is bad for UX as end users will have to wait longer for improved product experiences. By this time their needs may have changed.

Solution

  • If you have committed to an agile product strategy, consider developing using lean ux methodology where design, development and testing is done in 1 sprint
  • There are many cases in which the lean ux may not work, at the least it will be important to include different stakeholders during the design process and not to have siloed teams

Tool

Azure DevOps

What

  • Azure DevOps is a software which helps the product team develop digital products
  • It uses a system of Epics -> Features -> Stories to organizse product requirements
  • It enables scrum teams to work in iterations, do planning, create a backlog of requirements etc.

Problem(s)

We lost focus of the product vision because we used DevOps as a project management tool for scrumfall instead of a product development tool.

Why this is bad for UX/UI

DevOps and Scrum were created to make sure the user is in the center of the development process. Therefore, the
"Features" represent functionalities for users and "Stories" represent user stories eg. As a... I want.. so that...

By using Features and Stories as a task list, its unclear what value the task provides to the user.

Everything done in a sprint should always be linked to a value it provides to the end customer. Features and Stories (used correctly) helps us accomplish that.

Solution

  • Use Features to describe functionalities for the user
  • Create Stories around a user eg. “As a user, I would like.... so that....”

Product Strategy

Lack of customer feedback

What

  • The SmartClaims team worked to create 2 end-solutions. 1. A mobile web-view for policyholders to submit claims. 2. A dashboard for insurance companies to analyze the claims
  • These 2 products were made simultaneously with a long list of feature requirements (waterfall)
  • These requirements were based on assumptions. There was no user research, no problem definitions, no personas, no customer journeys, no ideation process
  • These assumptions were also not tested with clients after every sprint

Problem(s)

  • We did not get regular client feedback throughout the development process

Why this is bad for UX/UI

By not getting regular client feedback throughout the design process we invested into an experience which the market, client and users did not value.

Solution

The product should be built in iterations as a MVP. Clients should have been shown something small that works and the product should have been developed according to their feedback.

Key Learnings

Current Status: Open for UX collaborations
Impressum
Find me on