Using Calculators for User Engagement
Yun Zhou and Cliff Anderson
Cliff Anderson and Yun Zhou are Usability Engineers at Wachovia, the fourth largest bank in the US.
Calculators can play important roles on websites. They are especially popular for financial sites, where they can help users calculate mortgage payments, retirement needs, interest earned, and so on. They also appear on other sites, where users can calculate things as varied as their BMI (body mass index), carbon footprint, life expectancy, or gas mileage.
On any site, calculators can engage users by providing interactivity and by tailoring information to users’ own situations. In this regard, calculators are very similar to quizzes, but with a definite bias toward numbers.
Calculators are very popular at Wachovia, a large US bank. Over the years, the usability team at Wachovia has tested eight calculators in some detail. This article summarizes some of our findings from these tests.
Calculators cannot be simply sprinkled in a site willy-nilly. For calculators to be accessed, and for users to get something out of them, calculators must be positioned at the right level of the site.
For example, on wachovia.com, we currently include calculators on the pages that list our various accounts. These calculators typically help the user figure out how much money they will save or earn over a period of time.
We discovered, however, that users aren’t interested in these calculators at this point. Instead, they typically want to gather more high-level information and to narrow down their account choices. Only after they have done that are they interested in using calculators.
At the same time, a calculator may be very appropriate for your homepage. In fact, the right calculator can be very effective in engaging the user immediately. To do so, however, it must reflect a basic, common task; appeal to a wide audience; and – above all – be simple. Some companies have even had success with calculators in banner ads, like this one for creditcards.com:
It is tempting for marketing and business teams to want to make their calculators particularly detailed and powerful. The thought is that this can help differentiate their calculators from those of their competitors.
Users, however, are simply looking for something that will support their task. Nine times out of ten, this will involve a calculator with fewer bells and whistles than what is envisioned by the business. In fact, a user’s initial interest in calculators can be quickly squelched when they click on a link only to be presented with a lengthy, hard-to-interpret example of the genre.
When doing comparative testing across several financial sites, we noticed that users looking for certificates of deposits (CDs) focused almost solely on rates, ignoring calculators that would allow them to plug in specific amounts, terms, and more variables. In this case, the principle of simplicity would seem to argue for not using calculators at all, and simply listing the rates instead.
In most cases, however, calculators are valuable tools, and simply need to be streamlined. For example, the following calculator tried to combine users’ calculating their earnings on one CD with comparing that number to what they would receive on a second one:
This was simply too much for the average user to handle. Our suggestion was to either separate out the two steps or to eliminate the comparison altogether.
Related to the issue of simplicity is that of clarity. When asking users for information, the calculator must be very clear about what is wanted. If users are unclear, they will not hesitate to abandon the calculator. Though a calculator can be very engaging, it is typically not essential to a user’s tasks. Thus, users will not struggle with it, and any benefit it may bring to the user experience may quickly turn into frustration and abandonment.
Some of these issues can be taken care of by field-level online help. However, clear labels and an emphasis on simplicity can eliminate the need for help in the first place.
A related issue is when the calculator does not allow users to enter their own information. Make sure to include a wide range of values, or – once again – users may simply abandon the calculator when they can’t use their own age, income, height, or weight.
One of the great strengths of calculators is their interactivity. That interactivity must, however, be signaled and the user guided through it.
First, the user must be able to understand what the calculator is for. There is a temptation to handle this need with text. We have found, though, that users ignore instructions as a matter of course. Though a short, informative title can help, the calculator must speak for itself. (At the same time, instructions can be useful for search engine optimization. Just don’t count on users reading them.)
Calculators can do this in several ways. Most important is affordance. Your design must signal what is manipulable and what is not, what happens first and what happens next, what is input and what is output.
None of these should be taken lightly. What may be obvious to the designer may not be to the user. Testing the calculators – if only informally with employees – is the only way to get at these possible issues.
Take, for example, the issue of defaults. By showing a representative value, defaults can serve as just-in-time instructions to help users complete a field. Surprisingly, however, we have found that users often think that the defaults are fixed, and cannot be changed. Based on this, we typically recommend not using defaults.
Another issue with defaults is where they come from. Though users may know their own situation well, they may be less confident when asked to predict things like inflation rates, rates of return, and so on. Users may not even know their own information – for example, their diastolic blood pressure or their HDL cholesterol level. In these circumstances, we do recommend defaults, even fixed values. Cases like these also speak strongly for the necessity of including field-level online help. The EPA’s carbon emission calculator does a good job of helping users out with a figure they may not have at their fingertips:
There are a number of controls that allow users to enter and work with their data. The traditional way has been simply to use a data entry field, and allow users to type in their numbers. Other options include drop-down lists, spin boxes, and sliders.
Sliders are particularly valuable, as we have found that they signal their function well, can show results dynamically (i.e., without waiting to hit a submit button), and are also “fun.” At the same time, though, sliders can be difficult to manipulate, especially for users with poor eyesight, arthritis, etc. We recommend using a combination of the two. That way, the user can type in the value and then have it reflected on the slider, or vice versa.
Input Vs. Output
In the past, output was typically not shown until the user “threw the switch,” explicitly clicking a calculate button or submit button after they had entered all their data. This linear model was familiar, straightforward, and expected.
With new technologies such as Ajax and Flash, however, calculators now have the option of showing results dynamically. This makes the user experience more immediate, with the calculator responding in real time to each and every move the user makes. It also allows the user to interact even more with the calculator, changing values to generate what-if scenarios.
While this approach definitely has its benefits, it also introduces some new issues. First, it is simply not a model that the average user is familiar with. To some degree, users need to become trained to use it. A well-designed UI, however, can encourage use and facilitate understanding.
A second problem involves the possible blending of what is input and what is output. For example, on the following calculator, users repeatedly tried to type in the “Estimated value of property” field, which actually was used to display their result:
To the user, the fields all looked the same. For someone with a strict, linear input/output model, this result is not all that surprising. A calculator that used graphic design to explicitly separate input from output would have been much more effective.
A related issue involves how results are displayed. In the same sense that sliders are more “fun” than simple data entry fields, results that are graphical, visually-appealing, and involve animation tend to generate more user interest. Creditcards.com does a good job of this (the bars grow dynamically as you watch):
Calculators can be very useful in engaging users. Unfortunately, that interest is often dissipated when there is no clear next step after the user is done with their calculations.
To continue the user’s engagement, the calculator might, for example, point to information that would be particularly relevant to someone with those specific results. For example: Does a BMI (body mass index) calculator give you a reading of 27? Then here are some tips on reducing your weight. Won't be able to save enough to cover your college costs? Well then, how about some links to financial aid sites?
Here is an example of some next steps from www.finaid.com, a website for information on financial aid for college:
Clear next steps are especially important to commercial websites, where the goal is to get the user to do something concrete – sign up for a service, apply for an account, or at least share their contact information – that can possible add to the company’s bottom line.
Calculators are not for everyone. They can, however, be useful in engaging users with your site and in personalizing their experience on it. To be effective, however, calculators need to follow some basic rules. In particular, they need to:
|Contact the Voice|