On my first project at KFintech, a KYC form with 66 fields, I argued for one long scrolling form. Markers in the margin would show the mistakes, and nobody would have to click sections open again and again.
My teammates pushed back. Paperwork arrives in pieces: an identity proof today, the bank or tax papers later. Short sections let a person finish one part, save it and come back for the rest. The stepper shipped.
That wasn’t the only time. Design reviews with operations staff, demos with IR heads and beta testers’ feedback changed my mind. Since then, I let the layout follow the shape of the work, not my wish for fewer clicks. These are the shapes I look for now.
When answers arrive at different times, use steps
Say a loan application has 60 fields. The applicant’s ID is ready today; salary slips and bank statements come next week. One long form makes them either wait or fill in half and hope it saves.
Steps fit this work. Each step is a chunk someone can finish, save, skip and come back to. Show which steps are done and which are waiting, and let the final submit wait until everything is in.
Jakob Nielsen calls this staged disclosure. His rule of thumb fits: steps work when the parts don’t depend on each other, and fail when people have to keep jumping back to compare. NN/g’s four principles for lighter forms start with the same idea: a structure people can see their way through.
A long form is still right when everything is at hand in one sitting and the fields depend on each other, like a short checkout.
When people ask the same question every week, give it a tab
Say a support team starts every Monday with the same questions: what’s unassigned, what’s overdue, and what’s waiting on the customer. With one table and a row of filters, they rebuild the same filters every week.
A saved view for each question, shown as a tab, turns that into one click. Put the dates the tab compares in its header, so nobody wonders what “this week” means. The cost is a longer tab bar, so keep it to the questions people really repeat.
When different people need different questions, branch early
Say a tax-filing app asks everyone the same 13 questions. A salaried person scrolls past questions about invoices; a freelancer scrolls past questions about an employer. One early question, “How do you earn?”, can send each person down a shorter path.
The common mistake runs the other way, asking everything up front before anyone sees what the product does. Ask the questions that change the path up front, and ask the rest later, inside the product. I learned that one on a nutrition app. Its onboarding grew from 14 screens, which beta testers already called long, to 21, because the AI asked for more data up front.
Judge a new style on the busiest screen
One more lesson, about tables. In the IR portal, a dark theme looked great in its first review. In demos, IR users told us they struggled to read the dense tables. When I measured it later, the body text passed, but a small Buy status chip came out at 3.58:1, under the 4.5:1 that small text needs. Now I try a new visual style on the most crowded table before the hero screen.
How to choose
The work looks like | Try | Watch out for |
|---|---|---|
Everything at hand in one sitting; fields depend on each other | One page | Length: group it under clear headings |
Parts arrive at different times, or each part needs checking | Steps that save and can be skipped | People who need to compare across steps |
The same questions, asked on a schedule | A tab per question | A tab bar that keeps growing |
Different people need different questions | One early branch | Questions added before anyone sees value |
A growing set of tools in a sidebar | Labelled groups that collapse | Width: the sidebar in my design system library is 240 px open and 68 px collapsed |
Related case studies: the KYC form in the KYC registry, the tables in the IR portal and the onboarding in Burpy.