What I learned from writing payment interfaces (Part V)

[Note: Each post in this series will have a sidebar with questions intended to encourage you to think.]

In Part I and Part II we looked at elements, both foundational and code-related, that affect speed. In Part III we started our exploration of velocity by looking at mitigating risk and in Part IV we looked at expanding our app to other locales. In this entry, we'll look at non-specific cognitive overhead.

Cognitive Overhead

• What can you do that is not checking out while checking out?
• Which of the following affect reaction time?
  • Time spent waiting
  • Day of the week
  • Chronological age of the user
  • Time of day
  • Month of the year
  • Complexity of the interaction
• Which is likely to affect conversion more?
  • Adding a message that notifies you to add your address to a prepaid card
  • Using a tabbed design that separates card types
  • Having concise text labels
  • Forced acquisition

Cognitive overhead is the number of logical connections or 'jumps' your brain has to make in order to understand or contextualize the thing you’re looking at, or to put it another way, it’s what your brain has to go through to assign meaning and purpose to what you see - is a significant risk in developing a risk-aware, global app, and is especially significant for a payment interface.

Paying for something can be a very complex – and therefore slow^[1] – interaction, especially for young or older users^[2]. Non-member users often have to ask themselves "do I apply for credit", "which card should I use", "should I use my bank account", "how do I ship this purchase to my sister for her birthday", and "should I create an account". Member users have even more questions than non-members, questions like "why can’t I just make all this information the default so it doesn’t take as long next time".

There are a number of things that can increase cognitive overhead, like handling risk and globalization, especially when those topics are not fully developed or integrated well. On the other hand, there are things we can do to reduce cognitive overhead – things that a payment interface naturally does, like reducing automation and increasing user input by putting the user in the middle of the process, and things that a payment interface may not naturally do, like giving the user real-time feedback – such as a message to let you know you need to add your address to the card profile when using a prepaid card.

To some, suggesting that reducing automation and increasing user input as a way to maintain or increase velocity may sound counter-intuitive; however, for a number of users, especially those who are unfamiliar with your app - the group with the lowest original velocity, the time it takes to make choices is lessened when clear, concise information is present and the users are allowed to make their choices.

Consider, if you will, the case in which automation routes a user to a feature they didn't intend to use - in that case the user must then backtrack to a point where they understand the context before they move forward. This situation becomes even more vexing if automation repeatedly moves them forward in the same direction. In a payment interface, this type of behavior is typically seen in forced acquisition^[3] - a situation in which the user's frustration becomes palpable and is reflected in lower conversion.

Of course it's not only impossible to remove all automation, it's not advisable either. We must determine how to reduce cognitive overhead through other means. One of the simplest ways to reduce cognitive overhead is to simplify not only the process but the design as well. As da Vinci said, "simplicity is the ultimate sophistication".

How we may simplify the design is often relatively clear. Simplifying the process, on the other hand, is seldom clear. How can you easily accomplish this? Think of your process in terms of a story. Is your story simple, with a single plot-line like The Very Hungry Caterpillar, or is it complex, with multiple plots and sub-plots like Game of Thrones? If users see your process as not only simple but with a clear path, they’ll complete it faster and it will feel more convenient. Another  advantage to this approach is that with a simplified process returning guests are more likely to have greater velocity on each iteration.

Of course there are other benefits to reducing cognitive overhead - benefits the engineers and support personnel will enjoy. Benefits we gain because we know that it is always easier to destroy a complex system than to selectively alter it and that complex systems fail in complex ways. The less complex a system is, the better habitable (form) it is for the engineers who have to modify it and support it, the better we are able to ensure its function, and the better its fitness is likely to be.

Notes:

1. Hick’s Law - an individual's reaction time increases by a constant amount as a function of available choices
2. Age affects the processing speed of the brain (Salthouse, T. A. (2000). "Aging and measures of processing speed". Biological Psychology 54 (1–3): 35–54.
3. Acquisition occurs when a guest user becomes a member - your app has 'acquired' a member. Forced acquisition, then, is when the user is forced to upgrade from a guest to a member account.