Skip to content

The same form, twice

One internal form as it usually ships, and the same one designed. Both work. Use both and the difference stops being a matter of taste.

Back to Demos

“It needs to look like proper software, not an internal tool” is a real requirement that sounds like a vague one. Here is the same form twice, so you can decide whether the difference is taste or not.

The first one is not a strawman

This matters, so it is worth being clear. The first version has real labels, a sensible field order, native controls, and validation that is completely correct. It is keyboard operable. A screen reader can read it. Nothing about it is broken, and nobody was careless.

It is what a form looks like when the interface was never anybody’s job. That is the normal case, not a failure, and it describes an enormous amount of the internal software people use every day.

Submit them both empty

Both run exactly the same rules against exactly the same fields. The first tells you “invalid input”. It knows precisely which field is wrong, and it does not say. You now check four fields to find one mistake, and you do that every time.

The second names the field, says what a valid answer looks like, and puts that sentence next to the box you got wrong. Nothing turns red while you are still typing, because being corrected mid-word is hostile.

Then submit a valid one

The first version does nothing visible between the press and the result. The second shows the press, says it is saving, then confirms what happened and what to expect next.

This is the one people underestimate. A large part of what gets reported as “the system is slow” is not slowness at all. It is silence: no acknowledgement, so the user presses again, and now there are two records.

Why it is worth paying for

Not because it is prettier. Because a form staff use forty times a day, that makes them hunt for their own mistake each time, costs real hours and produces real bad data. The second version is not decoration on the first; it is the same software being honest about what it is doing.

If you have an internal tool people quietly avoid using, that is usually the symptom. Describe what it does and who has to use it and you will get a straight read on whether it needs rebuilding or just finishing.

Have a problem you think technology could solve?

Describe it below. No project is too small or too undefined to start the conversation.

Prefer to talk? Book a call directly →

A sentence or two is plenty. No jargon needed.