Form design: does human expertise complement AI?

Will an AI model create an ideal form tailored to your business, or is the human touch still worth paying for?

AI tools are great at creating forms. If it were a race between a human software developer and AI, the latter would surely win. It works much faster, and the result can look really decent. I can describe a signup form to a model and have a working, validated, responsive, accessible-ish form back in about three minutes. Yes: it will be prettier than what I’d have hand-written in an afternoon. The spacing will be consistent, which it wouldn’t be if I’d done it. The dark mode will work. The Zod schema will be there without me asking.

So, you may ask: why do we still include developers and UX specialists in our proposals for form design? The question is fair, and you deserve a fair answer, which you’ll find in this article.

AI understands standard code, but does it understand your business?

An AI-generated form is technically good across the universal metrics it can evaluate: layout, contrast, standard required fields, and basic email validation. It does this brilliantly… as long as it is very generic. It’s because AI relies on statistics, and by that, can offer generic, statistically proven answers. But we, “obsolete human coders”, understand that no two businesses are alike. Thus, it’s not always a good thing to use standardised forms, based even on broad statistics. To put it simply: AI doesn’t have any specific knowledge about your unique business operations, your users, or your operational history.

That’s why our part begins exactly where the AI’s capabilities end. Everything expensive sits on that side of line. It looks like this.

One directory, thirty-one wrappers

To illustrate our charity fundraising platform, has a thirty-one form field wrappers, about 4500 lines in total. Why there are so many for something so simple as online form? Here’s what they’re for:

Loqate address combobox — 600 lines. Six hundred, just to let someone type an address? A standard text field, after pasting an address, would get us a result as a single string. Thanks to the use and customization of Loqaute, we have the option of entering the street, city, zip code, and this field underneath searches for the right address or gives a list of addresses to choose from, and we can choose exactly what we want. Why was that needed? Well, if our charity fundraising platform had relied on a standard address form, it would have encountered a serious issue during the fundraising stage. Free-text addresses would be sent to the payment provider and fail verification, which would silently prevent the completion of donations that the charity was counting on.”

Characters/words limit input — exists because a database column had a length limit and the truncation was silent. A charity wrote a careful appeal and the last sentence disappeared on save. Nobody told them. Nobody told us either, for a while.

Image upload with a cropper — exists because charities upload huge phone photos as logos, and that logo sits on the page where a donor decides whether these people are real.

SEO friendliness message — exists because a fundraising page that nobody finds is worth nothing, and the volunteer filling in the form does not know what a meta description is and never should.

Read those again and notice what they have in common. None of them is knowledge about forms. Every one is knowledge about something outside the form: a third-party API’s failure modes, a backend column, a payment provider’s matching rules, the camera in a volunteer’s pocket, how Google indexes a charity page.

A generator can’t see any of that. Not because it isn’t smart enough — because that information is not in the prompt, not in the repo, and in most cases nobody has written it down anywhere at all. It exists as an incident from eighteen months ago that three people remember.

The three minutes are not where the money went

Here’s something important: where does the money go? The honest answer: not in the code of the form itself.

When you look at the time needed to prepare a form, it looks easy and not very time-consuming, right? And partially, that’s true. Writing the first version: hours. Sometimes minutes. This is the part the AI model does, and it does it well.

Everything after: here lies the actual cost. The mentioned charity signup ended up as FormStep_0 through FormStep_4 — five steps, not one page. That decision didn’t come from design sense. It came from watching where users stopped. Then:

Staging it, so screen one asks for a name and an email and nothing else. The commitment curve matters more than the field count, and you can’t tell which curve you’re on until people are on it.
Killing silent failures — every error that only appeared on submit moved to where the user was already looking.
Deleting fields. Not redesigning them. Deleting. Each field is a question you’re asking a volunteer at 9 pm, and the argument about whether it’s needed is with your own colleagues, not with a model.
Autocompleting anything with a canonical answer, so the user recognises instead of recalls.

Try prompting for that. Not the components — the decisions. “Remove the fields that don’t earn their place” requires knowing which fields don’t earn their place, which requires a funnel, which requires shipping, which requires the six months the three-minute demo skipped.

Conversion is not on the list of axes a generator can see, and it never will be — because conversion isn’t a property of the form. It’s a property of the form plus the specific people filling it in, and the model has never met them.

The failure isn’t ugly, and that exactly is the problem

We call that the blurred problem. It’s not easy to spot it, and it’s not that obvious, yet it can be impactful. If AI-generated forms came out visibly broken this would be an easy article. They don’t. They come out clean, polished, they look really nice. And that makes it so damaging.

The failure mode is a form that looks completely correct and quietly does the wrong thing on the 5% of traffic nobody demoed. The address that doesn’t match. The sentence that got truncated. The upload that times out on a lousy mobile connection somewhere in the countryside. The validation that’s technically right and fires at the exact moment that makes people give up.

You cannot review your way to finding those. Nobody catches them in a design review, because there’s nothing to catch — the AI-made form looks great. But you would find them in low numbers of support tickets, in Sentry, in a funnel report, or from a charity ringing up to ask where their text went.

That’s the job the line item is paying for. Not the typing. Not the code. Perspective and thinking.

Even our AI-first products came back to this

One more data point, because it isn’t only about generated markup.

The mentioned above fundrising platform also uses AI Chat — a conversational assistant, the modern answer to “why is this a form at all”. Its component list includes a folder called ChatForm, plus DesktopProgressSteps and MobileProgressSteps: a progress indicator, built twice, responsively, on top of the thing that was supposed to abolish multi-step forms. It came back because chat throws away state visibility — in a form you know what you’ve answered and what’s left, in a chat that’s all scrollback — and users asked.

Another product, AI-native from day one, OpenAI in the dependencies and an app/api/ai-agent route, independently grew StepProgressDisplay and ResearchStepsDisplay. Two unrelated products, no shared code, same conclusion.

The interface got generated. The understanding of what users need to see didn’t, and had to be added later by people, from feedback.

So what do you actually pay for?

Not for the code itself. By all means, let’s allow artificial intelligence to generate those – I say that completely honestly. That technical layer is not where the true value lies. You are paying for something that, at least for now, AI cannot provide; something that requires years of practical experience and the constant testing of theoretical knowledge against reality. You are, therefore, paying for:

knowing which fields to delete, which is a fight with stakeholders and needs evidence
knowing which validation is real and which is theatre inherited from a 2019 backend
knowing this form’s specific failure modes — the third-party API, the column limit, the device your actual users hold
measuring after launch and being willing to change it, which is where every number in this piece came from
and, increasingly, reviewing what the generator produced against all of the above

To summarise, you are investing in experience gathered for years before popular LLMs were even created. Of course, the actual task of building a form takes less time today than it did three years ago. We are not going to pretend otherwise. However, the most valuable part of this process is knowledge. It always has been, and it is what ultimately remains essential.

If you ask, “does AI do it faster?”, the answer is yes. But if you ask, “does AI do it better?” – the answer is no. There are surprises that are best avoided. When a form goes into production, support tickets from users experiencing issues start pouring in, and ultimately someone has to write that aforementioned “wrapper number thirty-two” to salvage the situation – this is certainly not what you want to experience. AI alone cannot do this. A developer empowered by AI, however, absolutely can.

And this is precisely the true value and peace of mind that your final bill reflects.

If you want to be sure that your forms will work as planned (or any other part of your application) contact us. We’re here to help!