0

I'm designing a complex form interface for building custom reports. The user can specify a lot of different kinds of information -- far more than will comfortably fit on screen. We will have approximately five separate screens of controls.

We're going with a tab-based layout, where each of the ~five screens is a separate tab. We find that the fields divide naturally into simple categories that our users will understand. The tab navigation and form controls (submit, cancel, revert, etc) will be fixed.

When creating a new report, the user will probably fill out the screens in a certain known order, although they don't necessarily have to. When editing an existing report, they may make changes in any order. A user may need to edit an existing report that they haven't seen or used in months, or at all.

The state of the form may be very complex, and it is subject to interdependent validation rules -- selecting one option may change validation rules for another option on a different screen. This is a consequence of the back-end system, which in turn is designed to follow complex business rules. It is even possible that rarely, changes in business rules or the underlying data could cause a report that was once valid to become invalid (requiring editing by a human).

Because of these factors I feel that it is very important to have some sort of summary view so that the user can see the complete state of the form.

Early prototypes of the form put the tab navigation on the side of the tab content. Each tab label had the name of the tab and a one-line summary of that tab's state. The downsides of this approach quickly became apparent. Most tabs required more summary information, so the tab labels became large, variable-sized, and full of information other than the name of the tab. Some information needed to compute the summary loaded late, so the tab labels moved around. It's also possible that the tab labels could overflow the available space, resulting in a vertical scrollbar for the primary tab navigation.

Left tabs

My preferred approach would be to have the tab navigation above the tab content (with no summary information), and have a separate summary panel on the side. The panel could include as much information as needed without trying to double as navigation, including verbose validation messages (“Because you chose option X, you must make a selection for Y.”). The error messages could even by “hyperlinked” to reveal and highlight specific fields.

Top tabs

However, some managers saw the first one and liked it, so it looks like we may be stuck with it. I'm trying to figure out how to salvage the summary information within those constraints. I definitely feel that I shouldn't put any interactive elements inside the tab labels, because that would conflict confusingly with the navigation function. I'm also leery of putting in colorful text or icons, because I don't want to drown out the tab name. The same goes for stuffing the summary text itself in the labels; full summary information might distract from the navigation and could even push the last labels off the visible area. On the other hand, partial summary information could be confusing, because a user might not understand that some important fields on another tab are excluded.

How can I salvage this? Is it okay to just stuff a bunch of summary text in between the navigation labels? If not, is there some reasonable limit? Am I overreacting by keeping other interactive content out of the navigation labels? And is there some other solution I'm missing?

  • Why do you need a summary? Do you have a more realist example of Summaries (rather than the generic placeholder text you are using)? – SteveD Jul 6 '16 at 10:08
1

Tabs have their pros and cons.

The user flows for creating reports do not have to be the same as the user flows for editing an existing report.

For example, when you create a new report, maybe consider using a multi-step wizard (no tabs) to guide the user though the task, but when you edit an existing report you can now use a tab view.

Are you able to do any usability testing before deciding on which direction the design should head in?

  • I would like to do usability testing, but I don't think that I will have the support to do anything rigorous (such as A/B testing on a task with a few users for each). We have shown prototypes to some current users, who expressed a weak preference for the second version (tabs on top, separate summary). The decision to disregard that input does not give me confidence that more thorough user testing will happen. – Thom Smith Jul 6 '16 at 18:50
  • I do like the idea of a slightly different interface for a new report; however, the process may not be entirely linear because of the complex validation rules. In addition, product management would almost certainly disapprove. – Thom Smith Jul 6 '16 at 18:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.