2 of 3
This is an antipattern I’ve come across many times while working on financial software. It often occurs when a website is trying to present one form that will map to multiple systems, or will be used to replicate a physical form (e.g. a credit application). Few things are more frustrating to a user than having to fill out the same data multiple times. It adds no value, increases the likelihood of error, and causes people to tear their hair out.
For example, let’s take a look at the Active.com signup for the Shamrock Shuffle (a great springtime running race in Chicago). It starts off with just a few questions about my age. Thankfully, it calculates my age for me, based on my birthdate, but it won’t infer that I’m older than 16.
When collecting a US phone number on a web form, it has become convention to collect it with three separate fields. This is meant to help the user successfully input the number in the format the server will accept. Since the user may think of the phone number as one piece of data, rather than three distinct items, many sites employ a feature that jumps the cursor to the next field as soon as it is filled with the expected numbers of characters.
This will totally screw up a user like me, who is used to powering through web forms by hammering the tab key as soon as I complete a field. Which leads to the unfortunate situation illustrated below.
The good folks at Southwest Airlines have tried to help me by moving my cursor to the second field in the phone number, but I’ve already hit the tab key. So I’ve skipped the second field entirely and gone straight to the third. Doh. Hence, an antipattern.
When we were first starting up Backstop, we would watch eagerly as each new customer advanced through the sales pipeline, and tear our hair out as deals seemed to drag on forever. Years later, I still hear the development teams I work with at Braintree asking ”when will deal X be done?” So, I thought it might be useful to write down this explanation I came up with for that early Backstop dev team.
The best way for a geek to understand the situation is to think about the deal as an entity with a dual quantum nature, similar to light. It possess both the linear characteristics of a wave and some decidedly non-linear characteristics that suggest a particle nature.
In the early or middle phases of deal negotiation, things progress along a fairly linear and predictable path. All parties involved agree that they are headed for completion at a reasonably forseeable date.
Like many designers, I use open source software, believe in the open source ethos, and would love to help make open source software look better and be easier to use. A lot of open-source projects are focused on the back-end, and don’t require a ton of UI/UX design, but it seems that there are more web apps popping up these days.
I had the good fortune to get involved with the Brainiac project recently, and wanted to share some of the hurdles I faced as a designer getting involved in the project. If you can address these things on your open source project, you stand a much better chance of getting designers and front-end developers to contribute.
One of the things I’d like to explore on this blog are some of the common UI anti-patterns I see while designing software.
For example take a look at this picture from the very cool Jukebox 2 open source project. At a glance, it looks like most of the accounts are disabled.
Surprise! The reverse is actually true. The problem is that the UI control for disabling an account seems to be displaying its state. This is totally confusing for the viewer, because it’s actually showing the state the account will be in once the users clicks the button.
2 of 3