The retirement and retail investment apps I worked on at Principal Thailand inherited a familiar shape: long web forms that behaved much like the paper forms behind them.
There were reasons for the questions. That did not establish that every question belonged at the beginning.
Our team worked with Compliance on a different sequence. Let someone create an app account quickly, then collect the information required for the next step when it was needed, including closer to financial account opening.
Creating that app account was not the same as opening or funding a financial account. The distinction was essential to the work.
Find the requirement behind the field
Counting fields alone makes a form review harder than it needs to be. Someone responsible for compliance hears a proposal to collect less information; someone responsible for the experience sees a long form people struggle to finish.
The more useful discussion was about timing. Which information did we need to let a person begin using the app? Which information was required before a later action could proceed?
We negotiated that sequence with Compliance. Legally required information still had to be collected at the required steps. Moving a question later did not remove the obligation, and an app registration did not satisfy the requirements for a financial account.
The product work depended on reaching that agreement. A shorter screen without an agreed process behind it would simply move the disagreement somewhere less visible.
An app account is not an investment account
Progressive collection creates its own design problem. Someone who has already registered can reasonably wonder why the app is asking for more information.
The interface needs to make the distinction understandable: what they have completed, what they can do now, and what is still required for the action they want to take. “You have an account” is too imprecise if the person hears “You are ready to invest” and the system means only “You can sign in.”
That is how I think about sequencing now. Each step needs a reason that makes sense at that point in the onboarding flow. Moving a question later can help because the person has more context. Moving it later without guidance can make the same question feel like an unexpected obstacle.
There is a tradeoff here. Collecting everything at once can be easier to describe internally. Collecting it progressively asks more of the product: it must keep track of what is complete and guide the person through what remains. The shorter first form is only one part of that responsibility.
Listen, compare, and be precise about the evidence
Voice-of-customer work helped us understand the experience. We also compared the onboarding flow before and after the changes.
That was not a randomized A/B test. A before-and-after comparison can tell you something useful about what happened, but it does not isolate the effect of a particular change from everything else that may have changed. I would not describe it as experimental proof that moving a field caused a result.
For me, the useful lesson was a way to work across functions. Compliance was part of designing the sequence, not just a final checkpoint for a flow we had already decided to build. The team needed a process that customers could understand and the business could operate within its obligations.
For a similar review, I would put each field beside the action that requires it, who can confirm that requirement, and the explanation the customer will see. A field without those answers needs a conversation before it needs a redesign. Sometimes the first step really does need it. Sometimes the requirement is real and the timing is simply inherited.