4

Suppose, in a multistep flow, where citizens can apply for subsidies from the government, we have some financial calculations (e.g. a collection of what-if's) presented in a table. Each row is a post in the calculation, e.g.

Standard amount:     $645.00
Extra grants:         $72.00
Fee:                -$124.00

TOTAL AMOUNT:        $593.00

All rather standard.

My question is:

  • How to make very clear in the UI, that calculations are preliminary/simulated, and thus not (yet) binding/committing?

My first ideas:

  • The use of dashed lines in the table to indicate "unfinishedness".
  • "Next" button text with something like "Commit to this calculation"
  • A progress indicator showing the next step
  • ??
  • is this a financial modeling tool? If it is, there is a number of patterns that could be used but will depend on how flexible your input controls are. – Okavango Jan 4 '15 at 16:00
  • 2
    Estimated standard amount: ... ESTIMATED TOTAL AMOUNT: – paparazzo Jan 4 '15 at 16:29
  • Okavango, no, it's a government tool for citizens. I have updated the question accordingly. – agib Jan 4 '15 at 18:53
6

Disambiguation & Labeling :

Preliminary vs simulated : you should try to be specific about the process in which this calculation is taking place; using "preliminary" suggests it is part of staged process. "simulated" on the other hand suggests a modeling activity where users could play around with the figures before committing. These considerations need to be taken into account when labeling which (in my opinion) is a substantial part of the solution in this case.

CTA: Commit to this calculation

This is another labelling issue : Poorly devised labels usually end up suffering from being ambiguous, overlong, complex, superfluous, so try to use labels that are descriptive but short. The button text "Commit to this calculation" suggest that you need to provide the user with more explanation about the process before guiding them to take action.

Progress bar and Endowed Progress Effect:

A progress bar is definitely a good idea, besides providing the user with information about the number of steps within the application process it has the advantage of making users feel they have made progress towards a a final goal (Endowed Progress Effect). This article from Smashing Magazine has great examples of progress bars adaptable for different contexts.

Facilitating the process:

Also consider revealing more information about the next step (if required)* (Information about step 2 in step 1, information about step 3 in step 2) This is particularly useful if users need to input details from official documents such as national insurance numbers, passports etc.This could potentially help you indicate the process is not yet finished!

*A simple tagline that will fit-in easily within a staged disclosure process.

Indicating "unfinishedness":

This concept is simply to complex to encapsulate into iconic form "dashed lines" and if the the application process has multiple steps than there is no need to futher emphasis that the figures provided are binding. Users will expect the process to be finalised when they reach the last step in the process, at that point provide the user with clear and concise information about the implications of completing the process (next steps).

Also adapt your CTA labeling by using real world terminology: Apply, submit, signup, or any other term/verb that users would have used if they made the application offline.

Below is an excerpt from Windows User Experience Interaction Guidelines that i think is useful.

When users are committing to a task, use a commit button that is a specific response to the main instruction (for example, Print, Connect, or Start). Don't use generic labels like Next (which doesn't imply commitment) or Finish (which isn't specific) for committing a task. The labels on these commit buttons should make sense on their own. Always start commit button labels with a verb.

  • Thank you for the thorough answer. I'll take your points into consideration. – agib Jan 6 '15 at 12:22
  • NP, I have also added an excerpt from windows interaction guidelines. – Okavango Jan 6 '15 at 12:47
1

An estimate heading would help, but maybe something as simple as an * next to the total field might get people to pay attention that there is an exception or something they need to understand about that number.

Or something as explicit as:

TOTAL ESTIMATE:     $593.00
0

There are various ways you can do this, but I will keep it simple.

You can:

  1. Make a label above/on the step and label it something like 'proposed changes' or 'simulation'. This ensures the user knows that they are in fact looking at a simulation, rather than the real modifications.

  2. Make a small, non-intrusive popup saying that this is the simulated result/this is a simulation, before the user enters that section of the program. This ensures their knowledge of the data being a simulation.

  3. Make the data more grayed out than the rest of the interface, or simply restrict it's color scheme to gray/black/white, which will naturally give the user the impression that this is different from the rest of the data on the program.

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.