Menu Search
Jump to the content X X
Smashing Conf Barcelona

You know, we use ad-blockers as well. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

Essential Design Patterns For Mobile Banking

Despite a great deal of mobile innovation, many creators of financial apps still copy their interface patterns from the desktop Web, even though these patterns are not as well suited to the mobile space. Small screens, custom controls, divided attention and fat fingers demand different thinking when designing for mobile.

I previously covered mobile wallet UX considerations in my article “Ultimate Guide to Designing NFC Mobile Apps You Won’t be Ashamed Of101.” In this article, we will look specifically at simple mobile transfers of funds from checking to savings accounts, taking what works on the Web and converting it into authentically mobile flows using simple, effective design patterns. Similar analyses and design strategies can be applied to many other areas that involve complex forms, such as mobile e-commerce checkout and social network registration.

Further Reading on SmashingMag:

We will not name any companies in this article. That is deliberate. If you are looking for company bashing, you won’t find it here. But if you want to know how to make mobile banking work, read on.

Let’s begin with the basic building block: selecting an account. It can be accomplished in two primary ways: via a “picker” (called “spinner” in Android) and via a dedicated selection page (also called “table view”).

Picker/Spinner Link

For system interactions, many app and mobile website designers start by looking at the desktop Web interface pattern: a form with drop-down menus. Here is a common pattern for me-to-me transfers (i.e. transfers between two of your own accounts, such as checking and savings):

Typical Web Form
Typical me-to-me transfer via Web form.

The drop-down menu works reasonably well on the desktop Web, assuming the customer has between 1 and about 20 or 30 accounts. Each account can be listed in the drop-down menu by its full name, along with the account balance:

Web Form Options
Selecting an account via the Web form’s select control.

How does this translate to mobile? Not very well. Blindly copying the desktop Web is a knee-jerk reaction, and it turns out that it’s mostly unsuccessful, resulting in a subpar experience. Here is why. Instead of the 20 or 30 selections that can be displayed in the drop-down menu, the iPhone’s standard picker control shows only 3 full and 2 partial choices:

ios Picker
Selecting an account via iOS’ picker control.

In Android 4.0 (the latest public Android version, named Ice Cream Sandwich), the situation is slightly better. Instead of the picker, the Android OS uses the spinner overlay, which shows 8 options. Unfortunately, the formatting options are quite limited, and the text area in the overlay is about 20% narrower than the main screen because the spinner is not using the full width of the device. This leads to confusing double and triple wrapping of text and numbers:

Andorid Wheel
Selecting an account via Android’s spinner control.

Interestingly, some online banks use this pattern to display a list of accounts. However, by necessity (and to avoid the confusion of wrapping and truncation on older and smaller low-end devices), they use short codes for account names, such as CHK, SAV and CC1. These abbreviations work reasonably well for text banking, where the short-and-sweet mental model (“C U L8R”) reigns supreme. However, code abbreviations are far from the slick world-class UI elements that consumers have come to expect from their smartphones. Rather, they smack of “dim phones,” BlackBerrys, DOS and enterprise software. Having to remember codes to do mobile banking is a far cry from the experience of playing Angry Birds or shopping on Amazon or Gilt. To create a better experience on mobile, we need another design pattern: a dedicated selection page.

Dedicated Selection Page Link

A slicker and more usable mobile design pattern for listing accounts than pickers and spinners would be a dedicated selection page (also called “table view”) in which 10 or more account options could be listed comfortably. As Apple’s iOS developer guidelines6 state, “Consider using a table view, instead of a picker, if you need to display a very large number of values. This is because the greater height of a table view makes scrolling faster.”

This is how it looks wireframed using the agile, lightweight, sticky-note methodology (see the “References” at the end of this article):

Dedicated Page
Selecting an account via a dedicated selection page (wireframe).

The advantages of using a dedicated selection page over a picker or spinner include the following:

  • Any font and branding you like;
  • A platform-independent experience;
  • Use the entire width of the page;
  • Text wraps as needed, so multiple device profiles can use the page comfortably;
  • Display 10 or more options at a time, with comfortable scrolling.

The bottom line is that, with a dedicated selection page, you can easily display the account’s full name and balance.

How could this pattern be used with a form? One popular pattern is a form with dedicated selection pages. Unfortunately, this often creates very long flows.

Form With Dedicated Selection Pages Link

The idea behind this pattern is simple: copy the standard desktop Web form but use dedicated selection pages instead of pickers or spinners.

Using this mobile design pattern, our me-to-me transfer flow would look like this:

  1. Blank form;
  2. Dedicated page to select the “From” account;
  3. Back to the form (with the “From” field now filled in);
  4. Dedicated page to select the “To” account;
  5. Back to the form (with both the “To” and “From” fields now filled in);
  6. Fill in the amount, etc., and hit “Continue”;
  7. Verification page.

Here is the flow wireframed using the agile lightweight sticky-note methodology:

Dedicated Pages Form
Me-to-me transfer via a form with dedicated selection pages (wireframe).

While this pattern works, it makes the flow quite long: seven pages. Could it be shortened? Absolutely. One excellent mobile-first pattern is the dedicated wizard flow.

Dedicated Wizard Flow Link

This is an extreme adaptation of the desktop Web form. This pattern works extremely well for short forms because it dispenses with desktop forms entirely, using a dedicated page for each attribute of the form.

Using this pattern, our me-to-me transfer flow would look like this:

  1. Dedicated page to select the “From” account;
  2. Dedicated page to select the “To” account;
  3. Dedicated page to enter the amount, with a numeric keyboard;
  4. Verification page.

And here is the flow using the agile methodology:

Dedicated Wizard Flow Mobile
Me-to-me transfer via a dedicated wizard flow (wireframe).

This pattern works very well for short forms, and it is a great example of Luke Wroblewski’s mobile-first7 design thinking. The entire flow is accomplished in only four steps. Note that a verification page (allowing the customer to review the entire transaction before tapping the final “Transfer” button) is recommended with this pattern. Note also the use of the breadcrumb pattern, which shows the customer which step of the workflow they are on and how many steps remain. The breadcrumb enhances this design pattern nicely.

Are we done? Should you create a dedicated wizard for every flow on your mobile banking website? Not so fast.

In mobile, nothing comes for free. That includes the dedicated wizard flow, which completely breaks down in longer forms. The basic idea is to have a dedicated page for each element of the form. But if the form has five or more elements, then the flow starts to get too long. Another issue is the inability of this pattern to distinguish between optional elements (such as “Memo”) and required elements (such as “Amount”). With this pattern, each element gets its own entry page with the appropriate keyboard and is likely to be treated as “required”. Even if the customer understands that they don’t need to enter anything, each element requires the customer to at least look at the page and click “Continue.”

So, is there another pattern for a page with five or more elements and many optional fields? I’m glad you asked. One of the most versatile yet underused patterns is the wizard flow with form. And as a bonus, this pattern dispenses with the need for a separate verification page.

Wizard Flow With Form Link

The idea here is very simple. Start with a dedicated page to select each account, and then show the rest of the fields in a form.

Using this pattern, our me-to-me flow would look like this:

  1. Dedicated page to select the “From” account;
  2. Dedicated page to select the “To” account;
  3. Continue to the form (with both the “To” and “From” fields now filled in);
  4. Fill in the amount, etc., and hit “Continue”.

Here is the wireframe using the agile methodology:

Wizard Flow Form
Me-to-me transfer via the wizard flow with form.

This mobile design pattern combines the best features of Web forms, such as the flexibility of having optional fields and multiple input fields, with the vastly improved usability of dedicated, mobile-optimized selection pages. Another boon is the option to dispense completely with the verification page, because the form page itself acts as an editable verification page. Of course, you could always append a separate verification page if you really must.

Editing is also much easier than with most other patterns. Instead of having to go through the entire flow again, the customer only has to edit the fields that need correction. For example, to edit the “To” account, the customer would tap the corresponding field in the form and be taken to the dedicated “To” account page, and then immediately back to the form, without having to go through the entire “From” account → “To” account → Amount flow again.

Mobile: Thinking Differently Link

As we’ve seen now, mobile design itself is usually not complicated. In fact, because people will be using your app with fat meaty pointers (commonly called “fingers”) in a stressful multitasking environment (commonly called “life”), a less complicated design is virtually guaranteed to perform better. However, designing for mobile is one of the most sophisticated exercises any of us is likely to encounter. Simply copying successful desktop patterns is usually the worst choice, yet it is the one many designers naturally gravitate to.

Designing for mobile requires thinking differently. Remember that in mobile, each form field requires at least an extra tap to bring up the keyboard, picker, dedicated page or other element to enter data. Instead of a vertical flow to guide the person to the next field, consider using a horizontal flow instead. Look for options and inputs to eliminate. Whenever possible, minimize the number of pages the person has to go through in order to complete the workflow; this will reduce input errors and increase customer satisfaction. Last but not least, make user testing the core of your mobile design process, and be sure to user test everything you design as early as possible.

References Link

(al) (da) (il) (jc)

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11

↑ Back to top Tweet itShare on Facebook

Greg is a UX strategist for Fortune 500 firms. His 4th book, The $1 Prototype and the new Lean Mobile UX blog can be found at

  1. 1

    Jelmer Borst

    July 5, 2012 6:53 am

    Welk, luckily we in The Netherlands we got some brilliant mobile apps for online banking: good design, great usability and does everything you want. Take a look at the iPhone / Android app by ABN Amro.

  2. 2

    Great! this article going to help me out… thanks Greg!

  3. 3

    Really usefull, inspiring article!

  4. 4

    Does the average mobile user really have 20-30 accounts to transfer between? I would guess it’s closer to 4-5, but if you have data to prove me wrong, I’d love to see it.

    Also, apple picker is an established ‘design pattern’, equally valid to the sliding screen pattern, which they also mainstreamed. I don’t really see a strong case being made here for the ‘picker’ option being in any way “subpar.”

    • 5

      Greg Nudelman

      July 6, 2012 4:05 pm

      Thanks for kudos everyone!

      Hi Shmeets,
      You make good points. However, I found in my workshops that many people are not aware of the choices between the picker and “sliding screen” as you called it (Apple calls this Table View, I called it a “Dedicated Selection Page”), nor are they aware of the differences between Android and iOS select controls. I wanted to call this out.

      And to answer your first question, yes, it’s pretty common to collect more accounts when you get older ;-) Also, small businesses that include traveling sales people and even silly examples like local boys and girls camping clubs often have a bunch of accounts. I am not a poster child in any way but I have about 20 different accounts (although with several different banks). The point is it is dangerous to make too many assumptions, esp. those that limit the interface in some way. You got to go out there and test things with your customers, as I show in my “How to make Agile RITE work for your Mobile Design project” webinar.

      • 6

        it would be great to have some real data here not anecdotal evidence,
        as much as l like the thinking here I would love to see the bigger picture and early analysis,
        what is the context?
        does the multiple account problem apply to 12%, 2%, 0.002% of users?
        we face issues like that on regular basis,
        in industrial design it is a common practice to design for 95% of the users

  5. 7

    Phull Phil Blappooosa Glupp

    July 6, 2012 2:11 am

    Nice one. This is really useful..
    Thanx.. :-)

  6. 8

    Apps are what is needed to make your smartphone smart and unique.Im fond of app creating and find it really helpful to use site like Snappii where i can build apps in minutes.

  7. 9

    David Karle

    July 6, 2012 7:46 am

    I think our design team here at USAA Bank did pretty well with this. We rethought transfer funds as if it were an actual machine. To, From, Amount, and Date are all displayed using an accordion pattern, maximizing the real estate for each item and minimizing the number of separate screens to traverse through. We’ve had a lot of success with it. Check us out in the app store. USAA is a member only financial institution that believes in the quality of our customer service. However, most people may be eligible for our banking products. Find out on

    • 10

      Greg Nudelman

      July 9, 2012 11:46 am

      David, Thanks — very familiar with USAA interface and met one of the guys on your team when I presented at Design4Mobile in Chicago. It’s a very nice design and I did not include it here. Good to keep it in mind as another option.


  8. 11

    This has less to do with uninformed designers, and more to do with the way that large companies go about finding 3rd party vendors. The business folks get a great presentation promising the world. Then the contract is signed without a word about actual capability or the code used, or benchmarks for performance, or best practices. So the 3rd party hires cheap developers overseas who can’t do anything in the vendor’s proprietary system that doesn’t support anything. The model is totally messed up.

    I appreciate the design in the post (not sure why you keep mentioning agile to show some hand-drawn wires), but I don’t think the issue is design. Until large companies change the way they think about design and more practically, how they engage with 3rd parties, then the designer’s hands are tied.

    • 12

      Greg Nudelman

      July 9, 2012 11:56 am

      Good point, Nate. However, many financials *are* rolling their own solutions. Perhaps exactly for reasons you mentioned. As for Agile, you have to watch the video I provided in the references to get the full picture of how this methodology fits in. It was just outside the scope of the article. I’ll be teaching a full workshop on mobile agile design at the UXWeek in San Francisco, and I’m trying to organize something for MobX in Berlin so I hope to see you there —


  9. 13

    You should take a look at NatWest’s iPhone app. They have really nailed their interface. Transfering between accounts and sending money is brilliant. has some screenshots.

  10. 14

    Colin Wiseman

    July 9, 2012 4:42 am

    HSBC in the UK have a fantastic mobile app. Totally stripped back feature set and large chunky options to click. Rarely need to open my “standard” online view of the account these days.

  11. 16

    Nice work! Must say was a really good read! It’s so important that we remember that designing for mobile is a whole new world to what most of use are used to. But also remember a lot of it is common sense :)

    Also couldn’t see this in the references.
    “lightweight, sticky-note methodology (see the “References” at the end of this article):”

    • 17

      Greg Nudelman

      July 10, 2012 4:31 pm

      Thank you! “How to Make Agile Work for Your Mobile Design Project,” (registration required) Greg Nudelman, video from the Mobile Design Essentials Virtual Seminar, DesignCaffeine is the one —


  12. 18

    Pritesh Desai

    July 9, 2012 2:57 pm

    Here in India, I use SBI’s mobile app. Instead of using on screen buttons, it uses a drop down ribbon menus which are un-intuitive and cumbersome.
    On the home screen, there’s a text field to input username, but the button to login is hidden inside the options menu.
    It is designed for older ‘non touch’ smartphones and doesn’t take into consideration touch screens.

  13. 19

    Marjan Lemmens

    July 11, 2012 5:16 am

    Very cool you talk about these specific issues and possible solutions. Have you also considered that the normal account overview screen looks very similar to the ‘From account’ selector screen? How to differentiate these 2 from one another? is just a different header enough?

    What do you think about introducing a swipe option to switch to another account? (like a carrousel)

    have a look at this app for iPhone:

  14. 20

    Nice idea, but… Healthcare and Banking are so heavily regulated that seemingly simple things like rendering an account list requires inordinate amounts of engineering, because the data needed to complete a transaction comes from a myriad of sources.

    The result is usually a simple decision of: ok if we build the required infrastructure to support this solution, how much will that cost? Is this cost justified by the consumer benefit?

    And the answer is usually no.

    Why? Because the consumer doesn’t have a choice. If you have your 401k and mortgage and car loan and checking and credit cards and money market and savings account all at Bank X, you’re going to accept whatever mechanism is provided for you.

    So while the exercise is interesting, I wonder how you would sell the solution as worth spending, oh, say, $640,000 on?

  15. 21

    That’s also my question – the dedicated page with account info looks very much like the account summary page, albeit with a different call to action. With this design there would be at least 3 (potentially more if the FI allows external transfers) similarly looking, content-rich pages, which may cause user confusion. How would you solve this?

  16. 22

    James Dellow

    July 23, 2012 3:21 am

    CBA in Australia have a well thought out app, called Kaching. It fits the entire from, to, amount and description into a single screen using two vertical pickers. The pickers include an image to help identify the type of account, to make selection quicker. I also like the fact they are attempting to use other smartphone features, such as the ability to ‘bump’ two phones together to transfer cash to another person.

  17. 23

    Shinji Akhirah

    October 13, 2012 5:46 pm

    Great, informative and well written article.
    Clear, concise and insightful.
    Thank you.

  18. 24

    web design company

    November 27, 2012 2:53 am

    To use full for your idea’s in my site designing work,thank you for ur idea’s

  19. 25

    Very interesting article…
    I have actually been making my own financial app so I came across this dilemma myself.

    The solution I came to myself was to have a page to set the value, date, time etc and then make a separate screen as a dedicated account selection screen.
    The way I did it was to have two lists side by side, so that you can select both the ‘From’ and ‘To’ accounts at the same time.

    If it interests you check out the “Add transaction” screens on my free app. Forgive me because it is just a minimum viable product at the moment, it urgently needs some design work…

  20. 26

    Yay. I just came up with the very same pattern.
    Boo. Wish I’d read this first.

    Nicely written article, will be helpful in explaining and justifying the pattern.


↑ Back to top