The five-field form sank the startup. How to design forms correctly

The startup was selling B2B analytics. The product worked, the demo was delighted, there were more than two hundred leads per month in the pipeline. Six months later, the company closed. A simple fact was found: the registration form of five fields ate about 70% of incoming traffic. Email, name, company, position, team size – and the Start button. People would come in, look at the uniform and leave.

This is not a story about “remove the fields.” This is the story that form is not a data container. This is a negotiation interface: the user decides whether they are willing to give something in exchange for what you promise. And in these negotiations, most designers play for the opposite side without noticing it.

The shapes look like the most boring part of the product. Therefore, they are designed last, on the remnants of attention, according to a pattern from the design system. That’s why they kill conversions—no one treats them like a product.

---

## Why Form Is Not “Just Fields”

When a user sees a form, they simultaneously answer three questions:

• How long will it take?
• What will they do to me with this data?
• Is the result of these efforts worth it?

If even one answer sounds like “incomprehensible” or “too much,” it closes the tab. And the decision is almost always instantaneous and unconscious. Nobody sits and counts the fields. The person glides their eyes, assesses the “weight” of the form, and either begins to fill in or not.

This leads to an unpleasant conclusion: the visual volume of a form is more important than its real content. Four fields spread out into four screens with a progress bar convert better than the same four fields in one block with signatures in three lines.

### What the user’s brain actually thinks

• Number of visible fields (not total)
• Length of signatures and helpers
• The presence of stars "required"
• Difficulty with the expected response ("the company" is just, "how do you plan to use the product" is not)
• Legal references and check boxes of consents

Any of these factors can make the shape heavier than adding a whole field. The caption “We use your data in accordance with the privacy policy and do not share it with third parties” under the button makes the form heavier than the additional “phone” field.

---

## The big question before every field is why is it here

Let's go back to the start-up. When the team sat down to review the shape, a typical picture emerged:

• **Name - "so that letters are personalized"
• *Company – “So that salespeople understand the context”
• Office - "to segment into CRM"
• *Team size – “To let marketing know ICP”

None of these fields are needed by the user at the time of registration. All of them are needed by internal teams – and almost everything can be obtained later: from the signature in the letter, from the email domain, from enrichment by Clearbit, from the first sales call.

This is the basic anti-pattern: form as a convenient way to collect data for internal processes at the expense of an external user.

### Field-need test

For each field, ask three questions in a row:

1. What will break in the product if this field is not available right now?
2. Can this data be retrieved later, automatically or in the course of use?
3. Am I willing to personally fill out this box to try out an unfamiliar product?

If the answer to the first question is “nothing,” the second question is “yes,” and the third question is “well, probably,” the field should be removed. Don't make it unnecessary. Remove.

### Anti-patterns that occur almost everywhere

• The "phone" field in the form, after which there will be no call
• The “position” field in a product that does not segment by position
• The “How You Learned About Us” field is the attribution that a designer pays with a conversion
• Confirmation of password if there is a button "show password"
• The field of patronymic when it is not used in any letter or interface
• Capcha on a form where there is no problem with spam

### Questions for Form Review with Team

• What fields exist for internal processes and not for the user?
• Which of these can be transferred to follow-up email or onboarding within the product?
• What fields can be filled in automatically – by domain, geolocation, past sessions?
• If you paid 5% for each field, which would you keep?

The last question is the most honest. Because you pay for them already, you just don't see the price explicitly.

## Workflow: from layout to release

Forms don’t come from Figma; they come from a meeting where someone says, “We still need a field about the industry.” If the designer meets this line in silence, the form has already lost. Next is the technique of keeping the shape under control at each stage.

### Stage 1. Remove real requirements

Before the layout is opened, talk. Not what fields are needed, but what decisions you make based on that data.

Questions to ask about product, sales and marketing:

• What exactly will you do with this field in the first 24 hours after registration?
• If the field is empty for 30% of users, will your process break down?
• Is this field elsewhere (CRM, analytics, enrichment)?
• Is it possible to obtain this data after the first valuable action in the product?

Half the fields fall off at this stage - it turns out that no one uses them in their current form, they are there "historically".

### Stage 2. Design a Minimum Version

Collect the form as if you were paying money for each field. Next, add only what will survive the review.

The basic principle of consistency:

• What the user already knows by heart (email, name)
• Then something that requires a short thought (company name)
• In the end – something that requires selection and comparison (tariff, team size)
• Legal and consents – next to the button, not a separate block on top

### Stage 3. Run the shape on yourself

Fill it yourself - from your phone, in a browser without autocomplete, in an uncomfortable position. It sounds corny, but 80% of the problems are here, not on tests.

What to pay attention to:

• Where finger misses past field
• Where the keyboard closes the "Next" button
• Where autofills are wrong
• Where Validation Curses on Correct Data
• Where you have to translate a password after an error

## Diagnostics: How to understand that the form breaks

Shape rarely falls entirely. There are usually one or two steps that most people take. The challenge is to find them quickly.

### Where to look in the metrics

• Drop-off for each field separately, not in form as a whole
• Fill time – an abnormally long field is almost always either unclear or questionable
• Frequency of corrections of the same field - an indicator of poor validation or wording
• Percentage of users who opened the form from mobile and switched to desktop

### Behavioral Signs of a Problem Field

• The user several times clicks in the field and leaves without entering anything - the field is incomprehensible
• Wash and rewrite - format is not obvious
• Stops in front of the field longer than in front of others - the field raises doubts "why do they need it"
• Throws a form on the same field every time – this is the point of failure

If the product does not have analytics at the level of individual fields, this is the first task, not a redesign of the form. Without it, you treat blindly.

### Quick usability test for five people

No lab setup. It is enough to catch five friends who do not work in IT, and ask to fill out the form out loud. In an hour, you'll hear more than three analytics reports.

What to fix:

• On what field does the pause occur
• What words in the captions cause questioning
• Where a person guesses a format rather than following a hint
• At what point does the phrase “why is that?”

The last one is the most valuable. Each “why” is a field that either needs to be removed or explained directly in the interface.

## Typical errors in the layout

Most designers know about “don’t make a placeholder instead of a label.” But in live models, the same rakes pop up again and again.

### Signatures and helpers

• Label inside the field as a placeholder - disappears at focus, the user forgets that enters
• Halper only under the field - the mobile keyboard closes it
• A star is “necessary” without explaining what a field without a star means
• Enter the correct email instead of “For example, anna@company.com”

### Validation

• It works for every keystroke, swears at the still unwritten email
• It only works by submit, and the user sees five red fields
• The error message appears at the top of the form and the error appears in the third field at the bottom
• After an error, the form resets already filled fields (especially the password)

### Buttons and finals

• Disabled button until full, without explaining what is wrong
• Two equivalent "Send" and "Cancel" buttons next to each other
• After submit, there is no boot state and the user clicks a second time
• Successful sending without confirmation – the person doesn’t know if it worked

### Checklist before giving form to development

• Each field passed the "what will break without it" test
• Labels outside the field, helpers visible with the keyboard open
• Validation works by blur, not by every character
• Error reports are specific and near the problem field
• Submit button has loading and disabled state with understandable reason
• The form is filled in with browser autocomplete (correct autocomplete attributes)
• Legal text is no heavier than the form itself
• Form filled in person, from the phone, in real conditions

## Segment summary

Good form is the result of three disciplines: strict selection of fields at the entrance, accurate diagnosis at the output and attention to the details in the layout. A designer who knows how to say “no” in a meeting and “show me the drop-off” on a review saves a product more conversion than any redesign session.

## Advanced Scenarios: When the form is more complicated than "name and email"

Simple form is a warm-up. The real pain begins when there are objectively many fields: KYC from fintech, application for a mortgage, registration of a legal entity, medical questionnaire. Here you can not “throw away the extra” – the data is really needed. But giving the user a sheet of thirty fields means losing it on the seventh.

### Long Forms: Rules of Survival

• Divide into steps by meaning, not by an equal number of fields. “Contacts”, “company”, “payment” are clear blocks. "Step 1 of 4" without a title, no.
• Show progress. Not as a decoration, but as a promise: "Two short steps left.".
• Keep the state between steps and between sessions. If the user has closed the tab, he should not start again.
• The easiest fields are at the beginning. This is the effect of an investment: the more a person has already invested, the less chance he will give up.
• Heavy fields (uploading documents, long texts) - near the end, but before the final submit, so as not to scare at the start.

### Conditional fields and dependent logic

Any field that appears depending on the answer in another is a risk. The user sees the form grow and loses the sense of end.

• Hide only what a particular segment doesn’t really need. Don’t hide the phone field just because you feel cleaner.
• If the field appears, animate gently and keep the focus close so the person doesn’t look for what has changed.
• Never reset data when switching the radio button. Users return more often than they think.

### Forms with files and complex input

• Downloading a document should show the preview and file name, not “successfully.” People don't believe in silent success.
• For numbers (card, TIN, passport) – a mask, but such that it can be inserted from the clipboard. A paste-breaking mask is a classic way to lose a user.
• Auto-address fields (address, company) save minutes, but a silently falling API turns form into a mystery. Always leave manual input like a foulback.

## AI and forms: where it helps, where it interferes

The temptation to “let’s put AI instead of form and let the user speak with words” is growing. Sometimes it works. More often than not.

### Where AI Really Relieves Pain

• Free input parsing in structured fields: single line address, details from inserted piece of text, date in any format.
• Tips and autocomplete based on previous answers within the same form.
• Explanation of why you need a field, on request - instead of a long helper in the layout.
• Quality check: The model “passes” the form before the release and fixes ambiguous signatures.

### Where AI is hurting

• Replace the form with a chat where the user has a clear task. Fill in five fields faster than a conversation.
• Hidden fields that the model “thinks up” for the user. Any model error = an error in the data that no one noticed.
• Real-time LLM validation without deterministic foulback. The user does not have to wait for the response of the model to understand that the email is invalid.

The rule is simple: AI is good as a layer on top of a shape, not instead of it. The structure of the fields remains, the input becomes more tolerant.

## How to explain the decision to the team

Half of the bad shapes are not born of ignorance, but because the designer has failed to stand up for shrinking fields. In a meeting, it is not rightness that wins, but argument.

### Arguments that work

• “Every extra field is a minus to conversion.” If you have a drop-off, show me. If not, refer to the data from the analytics of the product as a whole.
• This field is not used in any downstream process. The strongest argument is that we collect data, but nobody reads it.
• “Marketing can do that after activation, not before.” It often works: the business gets the data, the product gets the conversion.
• “The lawyer confirmed that without this field release is possible.” Without this verification, the dispute is endless.

### Anti-Patterns of Communication

• Bet your taste. "I think it's superfluous" loses any business logic.
• Bring the finished layout without discussing the fields. The decision on fields is made before Figma, not in it.
• Agree to "let's add, then remove." You can't.

### Questions for team form review

• What is the most expensive drop-off field and why is it there?
• What happens to the user if he or she fails in the third field below?
• Does this form work with browser autocomplete and password manager?
• Did someone fill it out in person, from a phone, on a bad Internet?
• What is the next step after a successful shipment and is it visible immediately?

## Segment summary

Complex forms benefit from structure, state preservation, and honesty about mandatory fields. AI helps at the entrance and in the hints, but does not cancel the design. And the best way to protect a good form is to come to a meeting not with a layout, but with numbers and the question “why do we need this field?”.

## Final checklist: form before release

No theory saves if before rolling out, no one passed the shape with his hands. This checklist is something that should be closed before you show it to the living.

### Contents and fields

• Each field has an answer to the question "why is it here and who is reading it?"
• All fields that can be collected after activation are transferred after activation
• Mandatory fields are marked explicitly, optional - not masquerading as mandatory
• Field signatures describe what to enter, not what it is called in the database
• The hint under the field is shorter than the signature or not at all

### Conduct and input

• Form friendly with browser autocomplete and password manager
• Masks don't break the buffer insert
• Number fields on mobile open the numerical keyboard
• When switching radio buttons and tabs, the entered data is stored
• Long form remembers state when a page is accidentally updated

### Errors and feedback

• Validation works after leaving the field, not on every tap
• Error text tells you what to do, not just the "wrong format"
• When submite, the focus jumps to the first field with an error
• Success shows what happened next and where to look
• Network failures do not erase input

### Context and device

• The form is checked on a small screen and on the slow Internet
• The keyboard does not cover the active field
• Touch targets at least 44 pixels
• The form works from the keyboard, without the mouse, taboo
• Screenreader reads captions, not "edit text"

## Anti-patterns that occur more often than others

If you see at least one of these items in your product, it's not a taste brew, it's a known hole.

• **Commentary field required to be completed. No one knows what to write, everyone writes “-”.
• Kapcha on every login attempt. Comfort is lost faster than bots - motivation.
• Combined phone input without country code and geolocation. Half of international users leave.
• Double typing email "to confirm." Solves a non-existent problem through real conversion.
• **Resetting a password that requires you to enter an old password. If a person remembered him, he would not press "forget".
• Clear the form button next to send. Only exists to be pressed by mistake.
• How did you find out about us? as a must. Marketing metric at the cost of conversion.
• **Hide the password without being able to show. **This is a guaranteed typo on mobile.
• Message "something went wrong" without specifying which field is to blame. Game guessing for the user.

## Review questions of any form

Run this list before the form goes into the sprint.

• Who is the customer of each field and what happens if the field is removed?
• What is the minimum data set required for a user to gain value?
• What would a person see if they filled it out correctly, but the server answered 500?
• If the form is long, where are the reasonable points of progress?
• Can I walk with one hand while holding my phone on the subway?
• What happens if the user returns in an hour, a day, a week?
• What fields are currently being collected, but are not used in any report or feature?
• If we need to add another field tomorrow, which one will we remove?

## Practical outcome

A good shape is not one in which the fields are beautiful. A good form is one after which the user did what he came for and did not remember the form itself. This means fewer fields than the business wants; more respect for input than it seems necessary; and the habit of checking each field with the question “why.”.

The header startup didn't sink because it had five pitches. He drowned because no one on the team asked any of them that question. The form is always a mirror of how the team thinks about the user. And you can fix it just as much as the team is willing to hear that it's too early to collect some of the data.