Plan A/B Test for the Onboarding Flow

This is a very good starting point and the overall direction is solid. That said, I don’t think the core of the task is fully captured yet, especially when it comes to the experimentation logic and the impact of Version B.

Right now, Version B does not feel sufficiently enhanced compared to Version A. As a reader, it’s hard to clearly understand what has changed in the user flow and why those changes are expected to improve profile completion. The difference between the two versions should be immediately obvious, both at a flow level and at a behavioral level.

To strengthen the project, I would suggest restructuring it around a clearer experiment narrative. It would help to start by explicitly describing the current onboarding flow step by step, so the existing experience and its limitations are easy to grasp. From there, the goal of the project should be clearly stated, for example, increasing profile or bio completion during onboarding and explaining why this goal matters for match quality and early engagement.

Once the goal is clear, the problems in the current flow should be called out directly. This could include issues such as front-loaded effort before users see value, high cognitive load when writing a bio, or a lack of motivation to complete the profile at that stage. These problems should naturally lead into a clear and testable hypothesis that explains how the proposed changes in Version B address those issues and why they should lead to better outcomes than the current flow.

The most important improvement would be in the presentation of Version B. The new flow and designs should make it very clear what has changed compared to the current experience. It should be easy to understand which steps are new, which ones have been delayed or simplified, and how the overall experience differs from Version A from a user perspective. Without this clarity, it’s difficult to evaluate the effectiveness of the proposed solution.

Finally, once the flows and designs are well defined, the test setup should be described in concrete terms. This includes clarifying who the target users are, how many users are expected in each variant, how long the test will run, which devices or platforms are included, and which metrics will be used to determine success. Adding these details will make the experiment feel complete and grounded in real product constraints.

Overall, the foundation is strong, but improving the clarity of the flow changes and the experimental structure would significantly strengthen the project and make the intent and impact of Version B much easier to understand.

great work!

The project shows a solid foundation, but it's missing key elements that the brief explicitly required. I don't see a formulated test hypothesis, concrete success metrics, or a clear testing plan. The brief asked you to create version B with specific changes compared to A, and here I get the impression I'm only seeing documentation of the existing flow without a clear indication of what exactly you're testing and why.

The user journey is described, but I'm missing an analysis of problematic areas in the current onboarding and concrete change proposals. What exactly would you simplify in version B? Why do you think these particular changes will improve profile completion rate? Without this, it's hard to assess the effectiveness of the proposed test.

It's good that you showed the app flow, but the task required something more – strategic thinking about how to test specific changes. You need to go back to the brief and fill in the missing elements: hypothesis, metrics, description of variant A vs B, and implementation plan.

I appreciate that you tackled the topic and presented the flow – it shows you know the tools and can document user journeys. Now it's time to add the strategic layer that will demonstrate your product thinking. ✌️😊

You’ve done a solid job mapping the Ploy Love experience and using real product screens. It’s clear you understand the journey end-to-end, not just individual screens. The numbered steps and screenshots make the flow easy to follow, and it already feels abovethe “junior wireframe only” level.

That said, the core problem and goal aren’t stated explicitly. I would clearly call out what “profile completion” means for this app, where onboarding starts and ends, and what success looks like. Shorter, more user-centric copy (for example, “After login, the app imports your basic info so you don’t fill long forms”) would also make the board easier and faster to scan.

You captured the current flow (A) well, but the improved flow (B) isn’t visually separated or clearly labelled. As a result, the project reads more like a product walkthrough than a focused A/B test. For B, it would be good to highlight specific changes that reduce friction before the first match-fewer mandatory steps, clearer progress, and a quicker “first value” moment for the user.

The brief also asks for measurable goals and metrics, but those aren’t very visible in the artefact. I’d add a small panel with the primary metric (profile completion rate during onboarding), supporting metrics (step-by-step drop-off, time to complete, % of users who reach their first match), and a clear hypothesis such as: “If we reduce mandatory photo steps and add a progress indicator, completion will increase from X% to Y%.”

Finally, a short note on the test plan (traffic split, rough duration, who is included) and what you’d do if B wins or loses would make the work feel complete and actionable.

Overall, the foundations are strong: clear journey, good understanding of the product, and thoughtful use of real UI. Making A vs B explicit and bringing metrics, hypothesis, and test plan into the same board would push this closer to a real, ready-to-run experiment.