Examples

Users love examples. Given a choice between examples and explanations, most users look at the examples first and try to find one that fits their actual problem.

Examples work like pictures: Examples are viewed, text is read.

Advice for great examples

  • One example is good, but offering a few examples is better.
    Three examples are often optimal; avoid more than five examples.
  • Use contrast if you provide a set of examples.
    Users notice even small differences: If you want people to listen — whisper.
  • Test your examples with representative users
  • Maintain your examples.
    Examples can start to look dated over time. Fifteen years ago, an example of a deposit interest rate might have been 8%. This example would just cause confusion today.
  • A set of examples does not have to show every possibility.
  • Keep examples as simple as possible.
    It is much easier to understand a loan example where a person borrows $10,000 at a 10% interest rate than to understand one where a person borrows $95,423 at an interest rate of 9.25%.

Contrast between examples

The contrast between examples in a set provides important information, even if the difference between the examples is small. This is illustrated by the following series of three examples, drawn from a Help function’s instructions on completing an amount field:

You can enter the amount in the following ways:
507.75
10,000.00
10000

The first example in this set (507.75) shows the norm. The other two examples illustrate the following rules:

  • You can use a comma as a thousands separator, but this is not required.
  • You can enter .00 if the amount is in full dollars, but this is optional.

Tests of the first set of examples showed that some users mistakenly concluded that they could only enter amounts that were in full dollars or that ended with .00, .25, .50, or .75. So we improved the set:
507.76
10,000.00
10000

Test your examples to ensure that they do not lead to critical misunderstandings.

The following set of examples illustrates how to properly complete a particular website’s Name, c/o, Address 1, Address 2, City, and Post code fields The examples show how the two address fields should be used:

Input fieldExample 1Example 2Example 3
NameMr. W.G. BrownAnne Caroline BrownMike Smith Jones
c/oc/o Jones
Address 149 High Street1, Upper Liddleton
Address 2WinfordAppleford
CityLondonBristolAbingdon
Post codeEC1Y 8SYBS18 8HFOX14 4PG

Explanations in examples

If you provide multiple examples, explanations may be helpful to point out the important differences between the examples.

The following set of examples is taken from the Street field in an address search. They illustrate the use of jokers or wild cards:

Westgate     (only finds Westgate)
*stgate         (also finds for example Eastgate, Mistgate)
*stg*            (also finds for example Postgram and Oastgrove)

Dynamic examples

When we tested the website of the Danish Inland Revenue, our test participants located the following information about mileage allowance:

Allowance per kilometer (km) per working day for 1998:
First 24 kms     No allowance
25100 kms     1.34 Danish kroner (kr.) per km
Over 100 kms   0.67 kr. per km

Example:A taxpayer drives 110 kilometers between work and home
(55 kms each way) and has worked 220 days in 1998.

There is no allowance for the first 24 kms.

Allowance for 25100 kms (total 76 kms): 76 x 1.34 =    101.84 kr.

Allowance for 101110 kms (total 10 kms): 10 x .67 =        6.70 kr.

Allowance per working day 101.84 + 6.70 =                  108.54 kr.

Total transport allowance: 220 days x 108.54 kr. = 23,878.80 kr.

The test participants were satisfied and understood the information. Then one of them added with a smile, “It would be even better if I could just enter the distance and it calculated the allowance for me!”

Indirect examples

If users are unsure about how to complete a field, they look for help on the Web page they are on. If available, they will use indirect examples — that is, information that is not intended as an example, but that functions as such. If users need to input a date and are unsure of the date format, they will look at the page for a date, such as Last updated 04-16-2020.

Always accept output and examples in your text as input

Because users use indirect examples, a key rule for websites is that they must always accept their own output data formats as input. If a website shows today’s date in the unusual format 15/December/2020, for example, it should also accept input data in this form.

Complex example in Help

The following window appears if the user requests help for “Discount points” in the mortgage calculator shown on page 100.

The example included here — one point on a loan of $150,000 is $1,500 — is hardly useful. The following Help text shows the tradeoff better:

A discount point is equal to one percent of the loan amount. You pay the discount points up front. In return, you get a lower interest rate.

See the following examples:

Example 1 — No discount points:
$100,000 loan — 30-year term
7.5% interest, no points = $699.21 monthly payment

Example 2 — With discount points
$101,010 loan — 30-year term
Buy one point for 1,010.
The amount you receive will be $101,010 – $1,010 = $100,000
(the same as in example 1).
Pay only 7.25% interest in return for the one point you bought.
The monthly payment will now be $689.07.

In example 2, you save $10.14 per month compared to example 1.

It will take more than eight years ($1,010 ÷ $10.14 = 100 months) before you have recovered the $1,010 you paid for the discount points. This simplified calculation assumes that $1 paid eight years from now is worth as much as $1 paid today.

Non-optimal example

The examples below are from a bank’s website. They are problematic, partly because the site tries to show all available options, and partly because the options are shown in a way that only computer-literate users would understand:

The date can be entered in one of the following ways: D, M.D, M/D, M-D, M.D.YY, M/D/YY, M-D-YY, MM.D, MM/D, M-DD, MM.D.YY, MM/D/YY, MM-D-YY, DD, MMDD, MMDDYY, MDD, M/DD, M-DD, M.DD.YY, M/DD/YY, M-DD-YY, MM.DD, MM-DD, MM.DD.YY, MM/DD/YY, MM-DD-YY.

It is not necessary to show all valid input formats in a series of examples. It would have been better to write:

Date examples:
03-15-06
3/15/06
0315         (implicit: the current year)