Story of bringing to life "CLaim it" Or "Eat it" (CLOE) – car accident assistant application
Launch in three months native iOS App focused on AI car damage detection technology that helps drivers evaluate the damage vs insurance over lifetime costs as a base for following product strategy
Building Minimum Lovable Product (MLP) in short period of time.
Methods used:
⚡How Might We (HMW)
⚡Rapid Prototyping
⚡Usability Testing
⚡Hi-Fi Prototyping
Dream Team
⚡ iOS Engineer
⚡ Product Manager
⚡ Full-stack Engineer
⚡ UX Designer (me✋)

My role
✨ Building user journeys and Hi-Fi interactive prototypes
✨ Plan, conduct, report a usability testing
✨ Usability and visual quality assurance
✨ Prepare required deliverables for a launch on the AppStore

Review initial App state
When I was assigned to work on the CLOE App project, basic user flow was already developed, and a promo video was describing how the app is functioning.
Understand the user flow, competitor analysis, define priorities
Used How might we (HMW) method to define what's missing in the flow. At first we defined short term problems to solve.

How Might We:
- help a user understand what is going to happen when one first open the app
- help a user to understand the estimated repair cost and insurance claim impact
- help user contact Insurer
- help user select repair shop

Post MLP scope defined with Product Manager:
- help the user remember that one has the app when accident happen
- decrease the amount of information needed from the user at the moment of the accident
Collaboration organisation
As a team, we started organising our work by setting up a Kanban board with a specific "Design task" issue type. After the design task was reviewed and moved to "done", Product Manager transformed it into engineer's tasks.
Twice a week, we had refinement sessions, where I shared all the work done to receive a review and discuss technical limitations.

The most common design task deliverables:
- Visual and interactive specifications
- Video or screens of expected flow and interaction
- Interactive prototype
- Link to Figma source file
User test: car & insurance definition
The problem of a car definition flow
Car definition question work in a way when every next question about the car is filtered out by the previous answers. We didn't know which detail about a car german drivers know better: production year, range of production years, or engine horsepower.

Insurance perception problem:
To evaluate claim insurance impact user needed to answer question "what is your Insurance company and Tariff name" by selecting an option from huge dropdown list. To increase reachability of information I offered to divide this question into two separate ones. Some insurers have only one tariff and I offered skipping the question if there is only one option. One of the team members raised concern that german drivers will find estimation not correct if we skip question of insurance product.

I set up a User test using the UsabilityHub platform, which helped us to define german drivers knowledge of their cars' details and define the perception of list of Insurance questions. See the results of UT in the pictures.

Increase trust with a labor illusion effect
We had ability to proceed to results of damage cost estimation without any delay, right after the legal message. Seems perfect, faster results, no more time to wait. Wha's the problem? – you may ask. Couple researches proves that people trust and value results more when they obtain them after a carefully crafted delay, even if the delay is not real. Source: Gartner (2005); Growth design (2020)

To communicate effort and bring more trust to the results of estimation we've decided to always show delay before showing the results with meningfull explanantion of the possible process behind.
Decision screen
The decision screen works perfectly on smaller screens such as iPhone 8. However, if the user opens the app on iPhone X and later versions page looks cut off and user hardly understands the information placed there.

Run a preference user test for three options selected by the team and implement the page based on the user test results.

Lack of engineer's time, so we needed a simple solution that tangibly improves the usability and convenience of the Decision screen.

Run quick Guerrilla Preference Test and implement version with the smallest effort but high impact.
Repair cost visualisation
Repair cost details weren't readable. It's hard to understand what is the cost evaluation of each damaged car part. It's not clear how much will it cost to repair a car fully. User doesn't understand how to find the total cost of parts, labour and materials.

Build a collapsable table with a total cost of each damaged part. Calculate and visualise subtotal cost estimation of parts, labour and materials.
Users don't understand what will happen after they open the app for the first time. What they will need through the process, and how much time approximately it would take.

Design onboarding screens to help the user cope with challenging circumstances and give an overview of the next steps.
AppStore deliverables
We needed to launch the CLOE App on the AppStore. For that, we needed logos and visuals of screens, which describe main features of the CLOE application.
The final state of Minimum Lovable Product CLOE App right before the AppStore launch
Final prototype for the application launch
Lates application build on TestFlight
⭐Ideal world Result ⭐
We launched the CLOE on App Store and got in first month 200 users to test the Application, which helped them save on insurance or repair costs over 330 000€ in total and got ⭐4,4/5 stars users' ratings and started building Android App.
⛔Real world Result⛔
One day before the product launch, it was announced that the company was shutting down due to operational reasons. We have never launched the CLOE App. ⛈ ☹
+49 176 3020 6355

Berlin, Germany
Made on