From brief to first draft: Designing & Prototyping

Creating the design brief

To start the design phase, I used a Claude Skill I'd built, fed with all our existing customer research (personas, surveys, interviews, competitive research, A/B test results). I already had my own idea for solving the problem, so I described it and "discussed" it with Claude, which I treat as a virtual design assistant. That back and forth surfaced initial caveats and refined the idea into a design brief.

Example of brainstorming session with Claude

To avoid hallucinations, I instructed the Skill to cite its sources so I could manually check the data if needed.

Wireframing

I passed the brief to Claude Design, already fed with our design system, which visualised the idea. The wireframes had inconsistencies and usability issues, but were a solid starting point, and already included interactions, which helped illustrate the flow to engineers.

Initial wireframe of the Photo upload step designed by Claude

First mockups

I moved the designs into Figma and documented all my thinking and comments there.
The proposed onboarding flow had 4 steps, and each of them needed its own round of input from stakeholders around the company:

• Step 1: Accepting contract documents and opting into marketing emails
• Step 2: Question about why the customer signed up → UX Research on likely sign-up motivations
• Step 3: Uploading a pet profile photo → Legal on the right permissions and service language
• Step 4: Onboarding checklist for the dashboard → Operations on which treatments to promote so claims stay fast and cheap to process.

I then integrated input from across the team into a complete flow of screens, with interactions and dependencies described.

Example of a change made after a consultation with the Legal team

Getting feedback

I brought the refined designes to our engineering team and the PM, who gave me feedback of the complete flow. It did not only includ technical feasibility, but also touched an important usability question.

One engineer caught a gap in the logic: step 3 of the checklist (uploading a claim) was designed as something the user checks off manually, but the system already recognises automatically when a claim is made, so users shouldn't be able to check it themselves.

Refinement & Final result

I reworked the onboarding checklist's third item based on that feedback: instead of a checkbox, it's now an icon for document upload with a button that leads directly into the claims flow. I also replaced the design elements Claude Design had generated that didn't match our design system.

Before team feedback:

After team feedback:

Final result

The final onboarding flow has 4 steps, which lead to the ultimate customer activation: uploading their first claim.

Step 1:

The mandatory legal step: accept the contract documents.

This step existed already but needed an adjusted copy to be more welcoming and reflect what would proceed after it.

The skippable question "Why did you sign up for petolo?"

The answer options were refined by our UX Research team based on their observations on what reasons customers had been mentioning throughout various research.

Step 2:

Step 3:

The skippable nudge to upload a pet profile photo.

Here I wanted to use the endowment effect, the principle that people value something more highly once they consider it theirs. Placing the pet's photo on the dashboard alsobuilds an emotional connection to an otherwise dry, formal product.

A foldable onboarding checklist that disappears once the first claim is uploaded, or after 3 months.

It includes 3 items:

• Pet profile photo uploaded, marked complete by default. Pre-completing part of the checklist uses the goal gradient effect and the Zeigarnik effect together: people are more motivated to finish a list once it's already in progress, and an unfinished task keeps occupying their attention until it's done.
• Book a prevention appointment with your vet, checked by the customer themselves.
• Request a refund, the logical next step after the appointment. This links directly to the claims flow, and completing it makes the checklist disappear from the dashboard.

Step 4:

Next steps

The flow is currently in development, so it isn't possible to determine its final impact yet. We'll measure success by rolling it out to a subset of customers first and tracking the cancellation and withdrawal rate within the first 3 months, along with the rate of prevention claims.

What I learned

This project taught me how keeping asking questions helps discover the real underlying problem. "Too expensive" could easily be misidentified as pricing issue until we asked what was underneath it. That way, we discovered that customers hadn't experienced enough of the product to know it was worth paying for. It is possible that this problem could be solved without changing the product itself, but by changing the way it is presented.