Don't Ever Submit

Submit       sub·mit             səbˈmit         Verb Accept or yield to a superior force or to the authority or will of another person Synonyms: give in, give way, yield, back down, cave in, capitulate, surrender

When a web application or mobile application is ready to postback data to the server, the button that software engineers have trained us to use is the submit button.  We may as well be the dogs in Pavlov’s lab.  The bell rings and we are ready and willing to press the submit button while we salivate over what will come next.  This terminology makes perfect sense to the software engineer because from their point of view the user is submitting or transmitting the page data for processing.  From their point of view it doesn’t matter if its banking data or your review of your favorite Italian restaurant.  It’s all data and it needs to be submitted.  But software is not created to live in a world from their point of view.  If the eight billion people on the planet were all software engineers, the concept of submitting data would make perfect sense.

The emotionless diatoms that write software have even convinced us that submit makes perfect sense.  “Yeah.  That’s the button you push when you are ready to do something.”  Think for a moment about the other 7.9 billion people who are not software engineers.  Think what they might have on their minds when they want to transfer money from their checking to their savings account.  What might they think the button should be labeled?  How about when they place or order for pizza to be delivered after a long day at they office?  What about when your are exiting your Lyft car and you want to give your driver his fee plus the gratuity he earned?  If you said “submit” to any of these questions you have been training by the superior forces who design software interfaces that “submit” makes perfect sense in these cases.  

Resist living in their world.

Stop the madness.  

Don’t surrender the world’s interfaces to the writers of algorithms and database queries.  When you want to complete the transfer from checking to savings, it should be perfectly clear to the other 7.9 billion humans on the planet that the button should be labeled “transfer”.  When you finish your order on the pizza delivery site, the button should say “Complete My Order”.  When you get out of your Lyft car and you want to pay your driver, the button should say “Pay Your Driver”.  Unless you are on some alien world where left is right and down is up, these simple decisions should be completely obvious.  If they are so obvious to the humans inhabiting this planet, why can’t they be obvious to software engineers?

The answer is: Software engineers have forgotten what it is to be human.  Maybe they never knew.  If they could just get out their electronic bubble and live in the shoes of a human for one afternoon – they would see the world the rest of us see.  This world is driven by emotions.  The student ordering their text books on Amazon does not want to “submit” their order.  They likely feel deeply engaged in the process of getting their books.  They may not like how much they cost, they may not want to be taking this class and they may not want to read the books they are ordering, but they do feel something when the order is ready to be placed.  Maybe they would like to “Complete Book Purchase”?

When the software industry cannot get the easy stuff right, how do we ever hope to get the hard stuff right?  Next time you are placing an order, reserving a table or choosing your next class at University, think about what it is your are really trying to do.  What motivates you to be doing this task online right now?  You are likely feeling a sense of completion and a yearning to receive your product.  Don’t give in to the software engineers, don’t back down or cave in.  And above all, don’t ever submit to the emotionless world the software community occupies in our lives.  There has to be a better way.

Neil Alan is Software Engineer with a B.S. in Computer Science and soon to be a graduate of the Master’s program in Human Factors at Bentley University in Boston, MA.  Emotional giants in the user interface industry have heavily influenced Neil.  Neil first met Alan Kaye in 1987 at Talcott Mountain Science Center in Avon, CT.  On that day he knew there was a better way to interact with consumers of software. Since then, Franciene Lehmann, Alan Cooper, Nancy Dickenson, Bill Gribbons, Meena Kothandaraman, Jakob Nielson and Chauncey Wilson have been helping Neil fix the world’s software engineers one line of code at a time.

The Inmates Are Running the Asylum

In Alan Cooper’s seminal work “The Inmates are Running the Asylum”, Cooper discusses systemic problems in the software development life cycle.  Too often the software development cycle is adversely effected by the technical team charged with implementing the proposed solution.  The technical team is generally not educated or trained in craft of experience design and they generally lack the empathy needed to understand the emotions of their users.  The technical team is passionate about the software they write and they are deeply invested in the design they have created.  Their personal investment in the software design is a large part of the problem.  By their nature engineers are analytical and generally lack the empathy needed to design delightful experiences.  It’s not that they don’t want to design delightful experiences; they need better training and insight into the emotional motivations of their users.

In so many ways, the inmates are running the software development asylum.  Through their action and inaction the software development teams are driving development schedules and release features.  Those aspects of the software that are not sexy enough or are too emotional for the engineers are often labeled difficult to achieve or are given estimated development times that are so long that product owners are reluctant to invest the time to bring them to market.  It is through this quiet resource dance that the software development team has hijacked the software design process.  Now that the software engineers have hijacked the process, the user’s emotions are cut out of the design process.  The software wont crash and it might be reliable, but it’s unlikely to be delightful.

Thankfully Cooper does not stop after clearly describing the problem.  The product owners need to recapture control of the design process in order to create software that is not just usable, but potentially delightful.  Cooper introduces the concept of the Persona to readers and subsequently to the software development team.  Through the persona, Cooper introduces the concept of designing for people to replace the concept of designing for users. By clearly defining the user in terms of name, photograph and emotional motivations the product owners can humanize the user to the software development team.  It may be easy for the developers to dismiss the needs and wants of the users, but it becomes much more difficult to deny the needs of Susie the Stylist who is trying to bring harmony to the world.

Software design is a team undertaking.  Engineers are very talented and well educated in the area of algorithms and database design.  Unfortunately, software users don’t generally care about algorithms or database design.  Software users care about issues that effect their jobs and the tools they use to make their job easier.  It is likely that the tools needed to make the software user’s job easier requires algorithms and databases, but if the software is hard to learn, hard to remember and difficult to run – it doesn’t really make the user’s job easier.  The software development team must include members that are trained in the design craft.  These professional designers need to carry the emotional needs and wants of the customer to the software development team.  With the right mix of algorithm designers, database designers and experience designers – the software product has a chance at being a delightful experience.

This article was originally posted on UXMatters. http://www.uxmatters.com/mt/archives/2006/07/label-placement-in-forms.php

Label Placement in Forms

By Matteo Penzo

Published: July 12, 2006

“We were able to subject Luke’s theories to usability testing and enrich them through the power of numeric data.”

In using eyetracking to evaluate the usability of search forms for my previous article for UXmatters, “Evaluating the Usability of Search Forms Using Eyetracking: A Practical Approach,” we discovered much interesting data. I’ll provide an in-depth analysis of that data here.

Please note that our ad-hoc test setup didn’t resemble real-world conditions. Since I had to properly measure saccadic activity and saccades times, I had to eliminate all elements that would force users to visually browse through the pages we used during testing.

We based our test setup on Luke Wroblewski’s article “Web Application Form Design.” Luke provided valuable insights and feedback during both our test preparation and results analysis. Thank you, Luke! Thus, we were able to subject Luke’s theories to usability testing and enrich them through the power of numeric data.

During the process of building the forms that we would test, we tried to respect Luke’s suggestions regarding the relationship between label placement and formatting and the type of form content—well-known data versus unfamiliar data that requires thought. Thus, you’ll find both types of data on each of the pages that we tested. To add some real-world flavor, we paired inputs fields for well-known data with other slightly more difficult form elements such as drop-down list boxes. Moreover, doing so helped us to confirm our previous findings about forms.

Our test subjects comprised both expert users—primarily designers and programmers, but also some usability experts—and novice users. We requested users to complete all of the forms that we presented to them. Our gaze-path recordings were complete once a user clicked the submit button.

Test 1: Left-Aligned Labels to the Left of Input Fields

“Excessive distances between some labels and their input fields forced users unnecessarily to take more time to interact visually with the form.”

This was the first case we tested, because it’s the most popular format in use on the Web. Not surprisingly, both classes of users performed very well in associating the label with the proper input field.

For all users, we found that there was a single saccade between the label and the input field, which means that users easily perceived the connection between them. However, a medium saccade duration of 500ms (milliseconds) was typical, which is quite long, showing that users were experiencing heavy cognitive loading.

The whitespace between labels and their input fields worked well in visually guiding the users’ gaze path toward the input fields. In fact, there were no fixations over whitespace. However, excessive distances between some labels and their input fields forced users unnecessarily to take more time to interact visually with the form. Figure 1 shows the eyetracking data for this test.

Figure 1—Testing left-aligned labels to the left of input fields

Since we included a drop-down list box in the form, we also had the opportunity to confirm our previous findings about them: that they are the most eye-catching form elements. When facing a simple form on a white page, the first fixation of all users was on the drop-down list box. This form element clearly conveys its meaning and how a user must interact with it, giving it a higher importance in the user’s mind. Moreover, in our first test form, the item selected in the drop-down list showed just a number, with no reiteration of the meaning the label communicated. We found that most test subjects, including the expert users, were forced to recheck the label to remind themselves of the value of the numbers the drop-down list contained.

Test 2: Right-Aligned Labels to the Left of Input Fields

“The right alignment of the labels reduced the overall number of fixations by nearly half, showing that this layout greatly reduced the cognitive load required for users to complete the task.”

While the meaning of the labels and their placement to the left of the input fields was exactly as in the previous test, the right alignment of the labels reduced the overall number of fixations by nearly half, showing that this layout greatly reduced the cognitive load required for users to complete the task. Also, the form completion times were cut nearly in half.

There was almost no saccadic activity between the labels and their corresponding input fields, both because users very quickly understood the meaning of the input fields and because of the ease of the lateral eye movement.

While we had 500ms saccades with the left-aligned labels, with right-aligned labels, the saccade times between the labels and the input fields were only about 170ms for expert users and 240ms for novice users.

My initial concern with this particular form design was that it would be difficult for users to make the transition between typing their data into an input field and moving their eyes to the beginning of the next label, because its position was unpredictable. Well, I couldn’t have been more wrong. Their diagonal eye movements were very quick, and there was no need for them to reposition the fovea over the initial word, as the eyetracking data in Figure 2 shows.

Figure 2—Testing right-aligned labels to the left of input fields

Most users—both expert and novice—needed to recheck the input field’s corresponding label in this case, too—though the relative brevity of the saccades made this task slightly simpler than in the previous test.

Test 3: Left-Aligned Labels Above Input Fields

“Placing a label right over its input field permitted users to capture both elements with a single eye movement.”

From the results of our second test, we knew that the nearer a label is to its input field, the more quickly users could move from the label to the input field. So, we were not surprised when we noticed that most of the fixations were right on the input fields rather than on the labels, as the eyetracking data in Figure 3 shows.

Figure 3—Testing left-aligned labels above input fields

Placing a label right over its input field permitted users to capture both elements with a single eye movement. Also, if a label indicated data that was very familiar to users—for example, their first name or family name—users did not fixate on the label separately to read it. They were able to view both the label and the input field in the same foveal area; thus eliminating the need for additional fixations and saccades.

Note—For a brief introduction to how human eyes work, take a look at my article “Introduction to Eyetracking.”

Moreover, we measured shorter saccade times of just 50ms in cases where users did move from a label to its input field. Recall that, in the case of left-justified labels, the saccade times were nearly ten times as long. So, users were able to complete the form very quickly and with a reduced cognitive load.

After two test cases in which the drop-down list box proved to be the most prominent form element, I wanted to check whether its position would influence the results. Not at all. Independent of its position, it continued to attract users’ attention. In all cases, we found it to be, indeed, the most eye-catching form element. It’s more prominent than even the submit button.

I’d also like to point out that, in this case, none of the expert users needed to recheck the corresponding label; though some novice users did need to recheck the label.

Test 4: Bold Labels Above Input Fields

I thought this would be more a sub-case than a full-fledged test case, but the differences in the results we obtained led me to see this as a separate case. I had in mind what Luke had said in his article “Visible Narratives: Understanding Visual Organization.”

“In this layout [with labels above the input fields], it’s advisable to use bold fonts for input field labels. This increases their visual weight and brings them to the foreground of the layout.”—Luke Wroblewski

“Bold labels resulted in an almost sixty-percent increasein saccade time to move from the label to the input field.”

However, bold labels resulted in an almost sixty-percent increase in saccade time to move from the label to the input field—from 50ms without bold labels to 80ms with bold labels—with no apparent advantage from the more prominent labeling. Bold labels were more difficult for users to read and perceive—probably because there was more visual confusion between the bold text and the heavy adjacent borders of the input fields. Figure 4 shows the eyetracking data for this test.

Figure 4—Testing bold labels above input fields

I’ve reviewed these results with Luke, and we’ve agreed that the absence of any visual design on our test pages might have modified the impact of the bold labels. However, as I said at the beginning of this article, what we tested was performance in terms of time, or speed, which required the absence of any other visual noise, and the times we recorded for bold labels were fairly poor.

Conclusions

Some interesting guidelines arose from this brief analysis of our test results. Coupling the following guidelines with Luke Wroblewski’s form design guidelines will help you to build the best form possible in each different situation.

• Label position—Placing a label above an input field works better in most cases, because users aren’t forced to look separately at the labeland the input field. Be careful to visually separate the label for the next input field from the previous input field.
• Alignment of labels—In most cases, when placing labels to the left of input fields, using left-aligned labels imposes a heavy cognitive workload on users. Placing labels above input fields is preferable, but if you choose to place them to the left of input fields, at least make them right aligned.
• Bold labels—Reading bold labels is a little bit more difficult for users, so it’s preferable to use plain text labels. However, when using bold labels, you might want to style the input fields not to have heavy borders.
• Drop-down list boxes—Use them with care, because they’re so eye-catching. Either use them for important data or, when using them for less important data, place them well below more important input fields.
• Label placement for drop-down list boxes—To ensure users are immediately aware of what you’re asking for, instead of using a separate label, make the default value for a drop-down list box the label. This will work for very long lists of items, because a user already has the purpose of the input field in mind before the default value disappears.

Acknowledgement—I would like to thank Magda Giacintucci, of Consultechnology IMR, for her help, both in preparing the lab setup and conducting the tests.

Topic: Information Design

- See more at: http://www.uxmatters.com/mt/archives/2006/07/label-placement-in-forms.php#sthash.SeHK1V1J.dpuf