I am designing a web-based application where you can add entries, and each of them have some 20 fields.

For the most part, after adding an entry, it won't have to be edited afterwards. But the option to edit any field still has to be present. Also, there should be a way to perform a search on any of the fields and pull matching records.

How can I design these forms so they don't end up looking like the third one here?

Take a look at the older questions in the tag Forms.
–
dnbrvMar 8 '12 at 5:05

If you're doing an application that registers customer information for example, you have to enter the information "somewhere"... The system's not going to guess it. I think the true problem with the "Your company's app" screenshot above is not the number of fields per se, but that it's too cluttered and the buttons are all over the place which is bad UI design. Let's keep in mind that sometimes you DO need a lot of fields and that doesn't necessarily make it bad UI design, you just have to organize them in an ergonomic fashion, on separate pages if need be, in an easy way to work with.
–
Wadih M.Mar 8 '12 at 14:18

6 Answers
6

The reason that Apple's and Google's products look the way they do is because they took design decisions. Instead of looking for features to add, they are looking for features to remove.

As this is a very general question, all I can offer is a very general answer.

Do your users need so many fields? - I can't imagine a case in which one single information unit requires 20 different data fields. Start with eliminating and combining fields. If you're redesigning an already working app, ask to see 10 random forms from the past few weeks. If you see fields left empty (or filled with rubbish because they cannot be skipped), maybe you can leave them out.

Are there fields that only advanced users use are that all users use rarely? - Out of 20 fields, you can probably find a few. Defer those to secondary screen, where they don't clutter and interfere with the main user workflow. Like in the previous tip, if you have access to real data, take advantage of it to see if there are fields that are rarely used.

Follow form design best practices - Read Luke Wroblewski's article that Mr. Angeltveit linked to, and also take a look at this article about web forms' traps and tricks.

Like with everything else - sketch, test and iterate until you find the best form combination.
Good luck!

When your designing your form think of it as how am I going to get the user from A to B in the easiest and most pleasant way possible.

I would consider breaking the form up into steps via javascript so the form does not look lengthy and daunting on the user.

Try and keep them focused on the fields by moving any labels inline and the descriptions to the right hand side of the form and to the side of the forms elements and only show when the user focuses on a paricular form element or even consider using a pop over on an info icon.

Try and fill out the form for them on things you can gather like their location eg. Suburb, postcode and or suggest with 'Autofill with somesuburb' link.

Use auto suggest to help them type less.

try and keep it compact so the user does not have to scroll up and down the page.

Be direct and keep your words minimal in any error messages without sounding harsh, rude or condesending and especially without sounding like a robot on repeat. eg. Required...Required...Required...

Avoid using the word required on the label, rather use (optional) on any fields that are not required.

Don't try and be unique or re-invent the wheel like your trying so hard to be cool with new fancy names for your labels, be straight to the point and use what people already know these fields as and that speaks to everybody at every level (eg. children, parents, grandparents).

Use labels rather than placeholder text only if your considering this method. It always annoys to have to focus out to see what you need to type in an input field and use placeholder text as a way to hint what to write to the user.

Try and keep checkboxes and radios on one line.

Rather than thinking of all the grand stuff you can put in your form, think what can I take out to make it or does the user actually need to specify that.

My recommendation, and where I believe all data entry and interaction is headed is in the intelligent, dynamic presentation of fields based on context. Here is the simplest possible example...

EXAMPLE
A registration form, presents itself as quick and easy, with three fields (improving enagement) Then adds fields as the user completes the task.

RELEVANCE AND CONTEXTUAL LEARNING
Contextual forms are designed in the same way, so that if you ask someone Do they own their own home, then the next question "how many years have you owned your home" is not presented if the answer is negative. If they responded that they do not have children, you do not have fields for their ages. etc.

HELP MENUS could be so easily managed with contextual relevance. If a user is known to be using a drawing tool, for example, the relevant help would be about that tool set... Someone should help Adobe and Apple with this.

Like many others have said, think about grouping. Also, principles of hierarchy come into play a lot with those groupings. Clear headings for information groups are key when you're asking for a lot of information on a form.

I recently had a very data-heavy form that was part of a large, complex approval process that forces the completed form to move through a variety of queues as it gets marked by various people for approval. To solve the organization, the form was broken into "tabs" on the left that move with the user as they complete areas, letting them know what kind of information they're to be entering at that time. There's no scrolling, but rather "next" buttons to move from topic to topic.

All field labels are on top of the fields right aligned with the input field for easy scanability.

Google and Apple also took the approach that users wanted to do 1 thing with their product, and made that 1 entry and 1 control to do it.

So, as per Yosef ( and Krug, of course ) take stuff away until it becomes a problem, then get round the problem, and keep taking stuff away, until you cannot get round the problem. And start with a focus of "what do people want to do with this", not "what can we get from people".

IME, focussing on the end user is both rare and highly productive. Google and Apple do, and they are not doing too badly for it - not only in terms of revenue, but in terms of user love. MS, OTOH, do not do this very well, and are losing market share, and have never had user love like Apple.

You can make some money, short term, with a crappy product. You can only make money long term ( these days ) with a good product.