How best can I indicate conditionally required fields?

Question

I often work on pages containing forms with complex requirements and subforms. The example below has these attributes:

• The default button -- that is, the button that will be "clicked" when the user hits Enter -- is indicated by white text / dark blue background button.
• Focus is indicated by a light blue halo.
• Required fields are indicated by an orange bar (their related label has an orange star).
• The General List Info fields and the data in the table are the data that is part of the main form and ends up getting saved when Submit is clicked.
• The requirements for the main form are Author and Update Date.
• The contents of the Find Cars for List groupbox is a subform that adds any rows from the database that match the filtering fields into the table. One of the fields must be filled to avoid an error (there's no indication of it before hitting the Add to List button).
• The fields and buttons above the table are another subform that allows the user to set the preferred color for rows or remove them from the list.
• The requirements for the Cars List subform vary based on intended use. To update rows, the first Rows to Affect field and Preferred Color are required. To remove rows, only the first Rows to Affect field is required.

Please ignore any silliness in the content or design other than the way conditionally required fields are shown.

---

The Core Question:

How do I best front-load the form requirements in cases like this? I want to help users avoid getting errors, but toggling requirements as they change introduces (IMO) confusing behavior. E.g., if the user is tabbing through the Cars List subform, it looks like Preferred Color is required even though the user's intent may be to use the Remove Rows button. Should I simply drop any attempt to show the requirements for complex forms, and just let users click buttons to get error messages?

Answer 1

The confusion of the design is that you have 4 different potential actions in a single form. Multiple actions, with different requirements, take action on the same form. It is best to provide clear direction to users.

Think of the form as a puzzle. I present you 4 different puzzles, for simplicity lets say that they are all 10 pieces each and all a single color. Not very exciting, but easy to know what piece belongs to what puzzle.

I'm not going to ask you to pick 1 puzzle and put it together. Despite it being easy to know what piece belongs to what puzzle, I offer you two choices:

1. Pick up a bag of 40 puzzle pieces, decide which puzzle you want to put together and then pick out the appropriate pieces out.
2. Ask you which puzzle you want to put together, then hand you a bag of 10 puzzle pieces for that particular puzzle.

Unless you are really bored, you'll pick option 2. Make each of those puzzles a 100 piece landscape and you'd be crazy to pick anything but option 2!

I'm unclear on how this form interacts with its destination, so this may be missing something...

^{download bmml source – Wireframes created with Balsamiq Mockups}

Each action is very clear now. I'm adding, or modifying, an existing list which has 3 major section: author, update date, list of cars. If I want to edit the list of cars I enter into that task flow.

An add button brings up a dialog, or adds a new row to the table that allows inline table editing. In either case the action is very clear and the resulting fields are clearly part of that action.

Removing a row is as simple as selecting the desired row and clicking the remove button. Still want the user to type in a row number? Bring up a dialog to ask them. Again, the action and the resulting fields are clearly related.

How do you edit? You could add another below the table and support editing the highlight row. You could also provide an inline edit button for each row that enters into an edit mode for that row. Again, the resulting fields that appear as a result of the action have clear purpose.

In the end, you're not presenting a bunch of actions with appropriate fields mixed in. You're asking the user a simple question first: "What do you want to do?" When they tell you what they're action is, you poll for the necessary information.