Euros and Sense at AIB: The Implementation Model versus the User Mental Model

Screenshot from AIB's transfer money screen showing an input field for cent, not euro

On the AIB internet banking screen to transfer money, instead of asking you for the Euro amount to transfer, they’re asking for the amount in cents. While they’re not imposing a huge cognitive load on me to convert from Euro to cents (they even give an example of how to do it), it should not be an excuse. Compare it to Bank of Ireland’s equivalent

Screenshot snippet of transferring money from with the Bank of Ireland site

The System or Implementation Model

The system model, also commonly referred to as the implementation model, is what we’re seeing here. AIB’s backend systems, like all other banks, deals in cents.

But here’s the thing, we don’t need to know how the engine works to be able to drive a car.

The user interface for transferring money on the AIB site reflects how the system is built internally, rather than reflecting the customer’s goals.

Alan Cooper on Interaction Design

In Chapter 2 of Alan Cooper’s About Face 2.0. The Essentials of Interaction Design (recently released as a third edition, About Face 3) the topic of the conflict between the implementation model and the user mental model is discussed in great detail. Some of the key statements and axioms he describes are at play with AIB:

  • Axiom: User interfaces should avoid implementation models in favour of user mental models
  • Software designed by engineers follows the implementation model

The User Interface IS the application

An overused saying and perhaps a little twee, but it’s true. It’s the only thing the customer cares about.

Taken from 37 Signal’s Basecamp Manifesto,

If something is confusing, slow, or a pain to use, it won’t get used. It’s that simple. That’s why we pour so much love into the design of the Basecamp user interface.

How to avoid the dreaded implementation model

My tips for avoiding the dreaded implementation model are:

  • Starting out, understand your users’ goals and design for them.
  • Design the interface first, then the backend, not the other way around
  • Aim for “Easy to use” over “Easy to code”
  • Design and test with real users, don’t present your ‘design’ to users for the first time when the application goes live

Categories Design, Spotted, Usability