Generally, no matter how beautiful our form design, it’s unlikely that it will ever rise to the level of delighting users. There is no designers’ holy grail that can make people enthu-siastic about filling out a form. However, form aesthetics do matter: clear information and visual design can mitigate users’ boredom by clearly guiding their eyes and encouraging them to make it to the end, rather than abandoning the task halfway through. Good form design doesn’t draw attention to itself and should be nearly invisible, always honoring its primary purpose, which is to collect accurate information from people. While form design needs to be both pleasing and professional in tone, in most cases, proper visual treatment will seem reserved and utilitarian in comparison to most other kinds of web pages. Form visual design can only be judged by how effectively it enables users to complete the task.
For this project, the areas where we focused our design efforts were in the typography, page layout, and interaction design.
T H E B E A U T I F U L P E O P L E 23
Web form typography and accessibility
In general, older readers have difficulty seeing small type. And survey participants are not so generous that they’re willing to strain their eyes to read a form. Because the target audience for our survey project was older (55–75 years of age), we knew that overall legi-bility would be an issue.
We chose the sans serif typeface Arial (a close cousin via Microsoft of the modern work-horse Helvetica), which is standard-issue on nearly 100% of web browsers, and we set headers and body copy large at 20 pixels and 14 pixels, respectively. Although larger type caused the page to be slightly longer, the improvements in legibility were well worth it.
Line spacing was not too tight, and was left-justified with a rag right. Line length was roughly 85 characters. And we set the majority of the text with the high contrast combi-nation of black type on a white background, also for legibility considerations. While we did use color strategically to brighten the page and emphasize the main headers, we did not rely on it to provide any additional information to the user. We did this because, for the male audience, roughly 7–8% has some type of color blindness.
Giving them some space
A densely designed form with no breathing room is guaranteed to intimidate the user. So, leaving some open whitespace in a layout is key.
In our survey, the first section included a text description of the luxury product, which we asked participants to read and evaluate. Web readers are notorious for their short atten-tion spans and tendency to skim text rather than read it all the way through. So, following web writing best practices, we separated the 250-word product description into subsec-tions with headers, pulling out key bullet points and dividing it into easily digestible chunks (see Figure 2-2).
24 C H A P T E R T W O
Accommodating different browsers and testing for compatibility
To make sure the form was usable by our audience, we designed the form page so it could be viewed easily in a variety of screen sizes, from an 800-pixel width on up. To accomplish this, we centered the form in the browser, using a neutral gray background on the right and left margins to fill the remaining space of widescreen monitors and ensure that the form wouldn’t appear to be disembodied and floating. We also tested in all major web browsers, including the legacy IE6, to ensure that the dynamic form looked good and functioned well.
Interaction design considerations: Dynamic form length
Dynamic forms can “soften the blow” of having many questions to answer. Using Java-Script or other methods can create a soft reveal that allows the form to be subtly altered—
or lengthened—based on user input (see Figures 2-3 and 2-4). These techniques allowed us to balance not scaring users off with a form that is too long on the one hand, and not infuriating them because they had been “deceived” about the form length on the other.
F I G U R E 2 - 3.The survey starts with only three questions. (See Color Plate 6.)
T H E B E A U T I F U L P E O P L E 25 For our project, the readers, in effect, built the survey as they answered each question. We
used a very simple piece of JavaScript code to make sure each new question was condi-tional upon an answer to previous questions. The idea for this solution came from another website we were working on at the time. In that project—a portfolio site for a designer—
we used JavaScript to hide and reveal details about different projects, making it possible to take in all of the designer’s work at a glance and then dive deeper into areas of interest, all F I G U R E 2 - 4.The survey may expand to up to six questions depending on user input. (See Color Plate 7.)
26 C H A P T E R T W O
without leaving the home page. This idea—not overwhelming the user with too much information, yet making that information quickly accessible at the same time—was on our minds when we approached the survey design. Here is the code we used:
<script language="JavaScript">
//This finds the word "Yes" in an input value and displays the designated hiddenElement (or hides it if "Yes" is not found)
function switchem(switchElement,hiddenElement) { if (switchElement.value.search("Yes") > -1)
document.getElementById(hiddenElement).style.display = '';
else
document.getElementById(hiddenElement).style.display = 'none';
}
</script>
<script language="JavaScript">
//This finds the word "No" in an input value and displays the designated hiddenElement (or hides it if "No" is not found)
function switchem2(switchElement,hiddenElement) { if (switchElement.value.search("No") > -1)
document.getElementById(hiddenElement).style.display = '';
else
document.getElementById(hiddenElement).style.display = 'none';
}
</script>
...
<li id="survey1" class="surveynum">How interested would you be to purchase this kind of product?
<p><b>Would you say that you:</b></p>
<ul class="nobullet"> might not purchase"> Might or might not purchase</li>
<li><input Probably would not purchase"> Probably would not purchase</li>
T H E B E A U T I F U L P E O P L E 27 Definitely would not purchase"> Definitely would not purchase</li>
</ul>
</li>
<li id="survey2" style="display:none" class="surveynum">Which of the following are extremely important to you?
<p>(Check up to 3 responses)</p>
<ul class="nobullet">
<li><input type="checkbox" name="q2" id="q2a" value="The price of the product">
The price of the product </li>
<li><input type="checkbox" name="q2" id="q2b" value="The product's lifetime guarantee"> The product's lifetime guarantee</li>
<li><input type="checkbox" name="q2" id="q2c" value="The quality of the craftsmanship"> The quality of the craftsmanship </li>
<li><input type="checkbox" name="q2" id="q2d" value="The fact that it can be customized to my taste"> The fact that it can be customized to my taste </li>
<li><input type="checkbox" name="q2" id="q2e" value="The prestige of owning the product"> The prestige of owning the product </li>
<li><input type="checkbox" name="q2" id="q2f" value="The safety features"> The safety features </li>
<li><input type="checkbox" name="q2" id="q2g" value="The on-call customer service guarantee"> The on-call customer service guarantee</li>
</ul>
</li>
<li id="survey3" style="display:none" class="surveynum">Why are you not interested in this product?
<ul class="nobullet">
<li><textarea id="surveytextarea" name="q3"></textarea></li>
</ul>
</li>
The result is that selecting any of the three positive responses on the 5-point scale in Ques-tion 1 revealed a checklist that helped further identify what the respondent liked about the product (Figure 2-5). Selecting either of the two negative responses revealed a text area in which the respondent could explain, precisely, what he disliked about the product (Figure 2-6).
As programming goes, this is child’s play and hardly worth mentioning. But the impact from the user’s standpoint is subtle and powerful. It meant that we could “listen” and
“respond” to the user’s input in a very conversational manner. It also meant that the psychological impact of the form length is much lower, as users are facing only a three-question survey at the start. The survey potentially could expand to six three-questions, but all of this happens without the user ever leaving the survey landing page, and without forc-ing the user to actively click some sort of “Next page” button.
28 C H A P T E R T W O
Designing trust
We did some concrete things to try to establish trust with the respondents and indicate that this was a legitimate survey, not a phishing expedition. First, we prominently dis-played the client’s company logo at the top of the web survey page. The logo itself linked back to the “About Us” area on Urban Wallace Associates’ main website, so survey partici-pants could see who they were communicating with. Additionally, we hosted the survey page on a subdomain of our client’s main site, not on some third-party host.
As previously mentioned, our client’s research needed the U.S. state of residence of each respondent. But, since we told respondents, “we do not collect any personally identifiable information about you,” it would have been awkward to then start asking questions about where the person lived. Our solution was to record the visitor’s IP address automatically, which would satisfy the U.S. state location requirement but not violate the respondent’s privacy. After all, a user’s IP data is logged anytime he or she visits any website, and, at F I G U R E 2 - 5.Detail of survey when the user answers “Yes” to Question 1. (See Color Plate 8.)
F I G U R E 2 - 6.Detail of survey when the user answers “No” to Question 1. (See Color Plate 9.)
T H E B E A U T I F U L P E O P L E 29 most, it can only be used to determine the city of that otherwise anonymous user’s
Inter-net Service Provider.
We then purchased an inexpensive data set of IP-to-State information. With it, we were able to match each IP address collected with the U.S. state in which it resided. Although we could have scripted our pages to access this database and match the numbers at the time of data collection, we chose to do the matching semi-automatically after the fact. For starters, the project budget and timeframe did not warrant purchasing the additional server power to handle the task. But more important, from a user perspective, was the delay this matching would have inevitably built into the survey completion process.
Although it might have been more convenient for us to receive finalized data at once, it would have created an additional inconvenience for our user. When designing a data col-lection experience, it’s important to think about what server tasks must take place during the survey in order for the user’s needs to be met, and what tasks can be delayed until after data collection. Don’t ask the user to do what you can do—or discover—on your own.
All of this leads us back to the central point of this chapter, which is also the final, and core, aspect of building trust: treat the respondent with respect. By demonstrating that you value the respondent and her time and intelligence, by interacting with her in a con-versational manner (despite the fact that all survey questions are being delivered by a pre-programmed machine), and showing her that you’ve been “listening” to her answers (don’t, for example, ask slight variations of the same question over and over again, which makes it seem as though you didn’t pay attention to her original response), you’ll increase trust, encourage real answers, and keep the respondent from disengaging.
Designing for accurate data collection
This sort of talk can seem a little touchy-feely at times, especially to people who only work with the hard numbers retrieved from data collection, and not the human beings who generated that data. But all of this user-centered focus is not just a matter of politeness—
it’s also crucial for the reliability of the data that we actually get. “For a survey like this,”
says Roger Urban, whose firm specializes in measuring market interest and customer satis-faction through face-to-face, mailed, telephone, and email surveys just like this, “you’re dealing with extremely thin data sets, so the quality of that data is really important.” In other words, when important decisions are being based on the answers given by only a few hundred people, those answers had better be great.
But great answers do not mean positive answers. After all, this is research, and just like sci-entists, we want to measure reality (Do customers care about price that much when it comes to this product? Is safety really their top concern, or not? Are they, in fact, happy with our service?), to see where our assumptions are wrong. “Techniques of persuasion are a disaster when it comes to research,” says Roger Urban. People will, subconsciously, try to please researchers by answering in the way that they feel they are supposed to answer.
Introducing persuasive techniques, whether implicit or explicit, will skew your research data.
“If you want an artificially high positive,” says Urban, “I can get it for you every time.” But if you’re making real business or policy decisions, what good is such data?
30 C H A P T E R T W O
Motivation
You can’t use persuasive techniques during the act of data collection, but you do need to persuade your respondents to participate in the first place. With no money involved, what is their motivation?
“There should always be some benefit,” says Roger Urban, “even if that benefit is just
’voicing your opinion.’” Human beings are interesting creatures; where cold, hard cash may not be able to compel us, far more nebulous benefits may do the trick—for example, some well-placed flattery. We all like to be thought of as experts; validation that our opin-ion is important may be enough to convince us to spend time talking to a stranger. So, too, can the allure that we may be receiving “inside information” by participating, that we are glimpsing what the future holds. For example, what techie wouldn’t be interested in par-ticipating in a survey that allowed us to glimpse the design of Apple’s next i-gadget?
In our project’s case, we knew that we were dealing with an older audience. The language in the initial email was important in terms of engaging the recipient, and our team went with an appeal to the respondent’s expertise. In our first mailing, we tested two different headlines on equal-sized groups of recipients:
“You can shape the face of [product information removed] for future generations.”
“We’re seeking the voice of experience.”
As it turned out, the first headline, though offering the respondent the power to steer the very direction of the future, apparently proved slightly more ephemeral and altruistic (after all, it implies that the benefit may be solely for future generations, not necessarily for the respondent) than the ego-stroking one that turns their age into a positive (“experi-ence”). For the first headline, 12.90% of those who opened the email clicked through, and 16.22% of those completed the survey. For the second headline, 14.04% of those who opened the email clicked through, with 29.5% of those people completing the survey.
When the second mailing was conducted two weeks later, with the “voice of experience”
headline on all messages, it generated a click-through rate of 27.68% and a completion rate of 33.16%. This second email went to people on the list who did not open the first mailing. (One of the secrets of email surveys is that the second mailing to the same list generally receives just as many responses as the first.)
This is another aspect of UX philosophy that’s worth remembering: test everything. In this case, test even your testing methods! When you have the time and resources, test different copy, test different layouts, and test different types of interaction design—all with actual users.
Reporting the live data results
In our project, one special consideration was that the recipient of the final data, the client, would also be a user of the system—with drastically different needs from those of the sur-vey participants.
T H E B E A U T I F U L P E O P L E 31 Because the project was time sensitive, the client needed to see the survey results quickly
to determine whether the product was generally well received. For this use case scenario, our solution was an HTML page, accessible to the client, which displayed the data, crudely sorted with minimal formatting. The live, raw survey results were sorted first by mailing (two mailings of each headline were sent to two age segments—55 to 64 and 65 to 75) and then by people’s Yes/No answers to the first question about their interest in the product.
Unlike the survey participants, who needed to be convinced to participate and encouraged to complete the form, the client was motivated by a desire to see the data as quickly as it was generated. For the client, speed and immediate access to the live results as they came in were more important than any other factors. Thus, his user experience reflected those priorities (see Figure 2-7).
The raw data display was not, of course, the final deliverable. Upon the project conclusion we presented the client with fully sortable Excel spreadsheets of all the data we had col-lected (from eight total mailings, sent in two batches), including the U.S. state data that had not yet been generated at the time of the survey.