persistence of vision

I’m going to explore more mobile UI antipatterns, starting with what I call “hinting instead of acting”. This is when a UI hints at the proper action a user should have taken, rather than just doing what the user expects. 

I love the Google Maps app on iOS (huzzah for public transit directions!), but it employed this antipattern when it launched. When you touched a pin on the map, it caused the bottom of the screen to bounce, hinting that you should swipe upwards to get directions and other options. Why not just open the panel when a user touches the pin?

Read More

I’m currently reading Jonathon Haidt’s The Righteous Mind. It’s a book about morality and politics, but it is challenging some of my long-held conceptions about the design process, particularly critiques.

In the first segment of the book, Haidt makes a compelling argument that judgement and justification are two separate processes. Judgment is immediate and intuitive, and whether we choose to believe it, justification comes only after we’ve made our intuitive response to  something. As he states it succinctly Intuitions come first, strategic reasoning second.

This has some pretty profound implications for design critique. No matter how much we try to rationally analyze whether a design solves a given problem, we are actually going to judge it first on an intuitive level. When we analyze it’s effectiveness, we will inevitably come up with reasons that justify our our initial intuitive reaction.

I see a lot of this evident in the discourse surrounding flat vs. skeurmorphic design. I think a lot of designers are just tired of the detailed aesthetic that has dominated product and web design for so many years. They are eager to explore a new aesthetic and they justify the new trend as more honest to the medium, or more virtuous in its simplicity.

As I first grappled with this notion, I was a bit disheartened. After all, I greatly value the dialogue inherent in design critique. I’ve always believed that if you involve the right people in critique, you end up with better design. As the first designer at a several startups, I often lamented how hard it was to do my best design work in isolation. Does the fact that critique is justification of foregone conclusions make it worthless? In other words, is critical analysis of design just a load of BS to support personal biases? Maybe so, but maybe that’s ok.

Haidt points out that reasoning and justification serve an important purpose: 

“Intuitions come first and reasoning is usually produced after a judgment is made, in order to influence other people. But as a discussion progresses, the reasons given by other people sometimes change our intuitions and judgments.”

So, perhaps critical analysis is the mechanism by which good taste can spread between designers. Taste is ephemeral, subjective, and highly intuitive. It’s hard to teach or share an intuition, but through critique, we can use justification to influence others and maybe spread good taste.

Of course, there is a danger here. The intuitions that spread most successfully may come from the most effective arguers, rather than the designers with the best taste. But there really isn’t another mechanism for sharing intuition, and if designers are cognizant of the pitfalls, we can apply an appropriate filter when accepting feedback from more or less persuasive personalities.

I’d love to hear other designers thoughts and experiences with critique. Have you ever been caught without justification for your intuition? Has anyone ever changed your mind about one of your own designs?

I kicked off this series of posts without really delving into what qualifies as a UI antipattern. I was talking about my UI antipatterns posts with a couple of developer friends at Braintree, and one commented that “it’s fun to point out when people are doing it wrong online”. I wouldn’t disagree, but just because some site is doing it wrong, doesn’t mean it’s an antipattern. Sometimes it’s just crappy design, or total lack of design.

To qualify as an antipattern, it has to be a repeated pattern that appears to be beneficial at first, but turns out to create more unintended problems. Additionally, a better answer to the problem has to exist and be documentable and repeatable.

In all the posts I’m tackling as part of the UI antipatterns series, I’m trying to sympathize with the original intent of the design and offer a better alternative - not just point out the flaws.

I’m also choosing to deal with antipatterns mostly at the user interface (UI) level, rather than at the broader level of user experience (UX). There might be plenty of antipatterns to mine out of the user experience, but I’ll leave that to a later time.

What UI antipatterns do you see on the web or on your mobile device? If you have one that you think is worth exploring, please let me know and I’ll writ it up here.

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.

As I get to this next section, they’re asking for my birthdate again. They ask my age again too…except this time they don’t calculate it for me.

Finally, when I get to step three, they ask me one more time if I’m 16 years or older, even though I’ve answered this very question already, and have given them my age and birthdate…twice. Yep, I’m still over 16! 

This redundancy is particularly frustrating for those of us who make software. We know it’s possible for the software to map one answer into multiple fields. When you have to collect a lot of data from a user, it’s easy to get focused on where the data is eventually going to live (e.g. in a form or another system) but if you want people to complete your form, you have to focus on the user instead.

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.

Luckily, we are living in a grand age of Javascript wizardry. We can now format phone numbers on the fly with plugins like jQuery Format Phone or Masked Input Plugin. We can just let the user enter the number into the field naturally, including or not including special characters as they wish, and format the number for them as they type. The end result might look something like this.

This particular antipattern shows up in more situations than just phone number fields. Social Security Numbers and other places where sites collect numbers that include dashes or other formatting are prone to fall into the same trap.

A single field is more natural for a user, and utilizing Javascript to format the field as the user types will ensure that it is formatted as expected for both the user and the server.

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.

However, near the end of the deal negotiation process, lawyers, bosses, procurement departments and other gatekeepers get involved. You can think about these gatekeepers as a reflective box with a diffraction grate on both sides. The wave-like deal hits the first diffraction grating, and it appears as if it should emerge out of the other side at a predictable point in time. However, once the gatekeepers get involved everything goes quantum. The deal takes on a particle nature, and those particles bounce around inside the box for an indeterminate duration, until one of them happens pop out of the slit on the other side. This is effectively random and can’t be predicted by any of the parties involved, much to the chagrin of everyone whose livelihood depends on the deal.

What is to be done about this? Not much. Most sales and business development people know enough to try to skip the lawyers, or to at least get contracts in front of them as as early in the process as possible. For development teams, it’s best to realize that completing a deal is a lot like fixing a pernicious bug - it’s almost impossible to predict how long it will take. Embrace the truth that the deal is done when that particle randomly pops out the other side of the box and both sides put ink on paper.

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.

Make it easy to install

A lot of designers can hack CSS and HTML, and even work with layouts in various frameworks like Rails. However, to start working with those parts of your app, they have to get the entire thing to boot up locally. Make it easy, and offer step-by-step instructions. When I started working on Brainiac, I asked a developer “How do I get this running?”, to which he replied “oh, it’s a Leiningen app”. That didn’t mean anything to me, and left me feeling embarrassed about asking further questions. What I really needed was for him to lay out the handful of steps necessary to get the server running locally. I did get these for Brainiac, and then I added them to the project’s readme.

Read More

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.

I’m not trying to pick on the folks who contributed to Jukebox 2, as I’ve seen this same anti-pattern pop up on almost every project I’ve worked on that features tables with actions. The consequences for the user can be pretty drastic - in one instance when this anti-pattern was used for setting access permissions on a site with sensitive personal information, a user freaked out and locked everyone out of the site.

So what’s the better way to handle this? Much of the time, the action is a binary flag, so an On/Off switch is a natural metaphor. It can convey current state explicitly without the need to even display the action, since its implied by the very nature of the switch. The above example might look something like this:

That’s better, but we could help the viewer to better understand which users are enabled at a glance. In order to avoid confusion, we’ll use some styling on the row to signify a disabled user with gray text and a desaturated avatar photo.

That’s a big improvement in usability, without a lot of development work. The next time you find yourself adding and “Actions” column to a table, do your users a favor and give this a try.

Know of other UI anti-patterns? Share them below or drop me a line.

As I was out running the other day, I saw a sandwich board propped up in the middle of the road that read “Car Wash for Food Pantry”. The message was written in large, outlined, bubble letters, and I squinted to read it from just a couple of car-lengths away.

My design instinct immediately kicked in, as I determined that none of the cars on the road could read this sign in time to make a decision about whether to stop at the car wash. It was obvious that they should fill in the bubble letters, and make them much darker. I next realized that this bad design decision was probably impacting how much money they would raise, and given the cause, it might mean that some family would go hungry.

Design is not about making something look good. Design drives behavior - it can secure an advantage for your business or put food in the mouth of a hungry child. The design of the world around us shapes the events of our lives, and can even make the difference between life or death.

This site is a public forum for me to contemplate design, analyze product management, and drink delicious startup Kool Aid. This first post is mostly a stand-in, while I get familiar with Tumblr’s design tools. At least it’s a bit more engaging than lorem ipsum (if only a bit).