Sure, Those Colors Look Nice - But Can You Prove They’ll Work?
For the past several months, I've been working with a client who is based in North America but who operates regional offices in various parts of the world where their (tourism industry) product is offered. Over the past year, we've collaborated with this client one country at a time, through their North American central office, updating some of their country-specific web properties. It's been a cool opportunity for the team to experiment with tweaking web designs to work in cultures that we haven't designed for in the past. One of the best lessons learned (well, more confirmed than learned), is that good web design (as any other form of art) transcends regional boundaries. A good web design in America is also a good web design in Norway, France, or Australia because, at the end of the day, the best web design gets out of the way and lets the content and features pull users in and through the conversion process. So far, we've found that user intuition about how to get from Point A to Point B in the purchase process doesn't vary by location - everybody is looking for the same information.
However, we also found that aesthetic preferences, as you might suspect, vary a great deal between nations. The preference in one country might be for ultra-sleek, clean design with little imagery and a neutral color palette. In other places, users seem to prefer a richer, bolder palette full of evocative imagery and depth. Given those widely varied and utterly subjective preferences, we faced a new challenge with our current design project in this space: How do we define a design that not only works but also looks "good" in Germany, in Australia, in France, in the UK, and many other distinctly different parts of the world?
Our first attempt was to employ our standard process of presenting three mood board options and finding the most preferred of the three. In this case, we had the opportunity to ask our users (during usability testing for the same product) what they thought about the mood boards. For this exercise, we came up with three distinct directions. One that was sort of business-y, one that was fun and lively, and one that was neutral. We asked users how they would describe them and which they preferred. After weeks of interviews, we were able to finally discover that the mood board results were totally inconclusive. Each country had a preference, but with 4 countries responding to 3 mood boards, we couldn't possibly have come up with a less definitive answer. Germany preferred one, France preferred another, the UK preferred the third, and in Australia there was no clear winner. Obviously, none of these design concepts was the "right" answer.
Beyond that, even within the countries that preferred a particular design direction, the feedback was contradictory. For example, we presented a mood board similar to the one below.
Continue reading "Sure, Those Colors Look Nice - But Can You Prove They’ll Work?"
Confirming Passwords Is Annoying: Is There a Better Way?
The defining characteristic of a password field is that it abstracts text as dots. While the intention of this behavior is understandable (it makes users feel secure and protects from prying eyes), the unintended effect is that it creates a usability problem. Users can't tell if they've entered a password incorrectly until after the site's validation informs them. It's like typing with your eyes closed.
The most common solution for the password field problem on registration pages is to require people to confirm their password in a second field. Again, the intention is understandable (it cuts down on mistakes), but the reality is that sites are requiring people to deal with two password fields. Here's an example of the common solution with some JavaScript validation:
Demo
While this isn't a terrible experience, I think there are a few other ways to handle this problem worth exploring. With some inspiration from a post on IxDA.org, I've created three below. Of note, all of these proposed solutions load a password field when the page is generated, so the browser will initially treat them as regular password fields.
Solution #1: Users click a checkbox to show characters
Demo
Pros: The decision to show or not show characters is fully at the discretion of the user. Passwords can be edited while characters are displayed.
Cons: It doesn't automatically switch back to a password field. People could accidentally keep it checked while they're filling out the rest of the form, leaving the password susceptible to prying eyes.
Solution #2: Users hold down a button to temporarily show characters
Demo
Pros: Users are able to see their password characters if they'd like and cannot accidentally leave the field in the show character state. This solution potentially feels more secure to users than solution #1.
Cons: The downside is that users cannot leave the field in "Show characters" mode while they're editing the field. They can only see what they've entered when the button is pressed down.
Solution #3: The password field automatically changes to show characters
Demo
Pros: As a user, this approach would be my personal favorite because it's the easiest option, and you always see your password as you're typing it in. I don't really care about other people seeing what I type, since I rarely find myself in situations where I notice or would expect people to leer at my screen.
Cons: When users first select the field and start typing, it will look and behave like a regular text field -- which may be startling to some. Users will not see that it switches to a password field until after they've entered something and clicked off of it.
Conclusion
None of the solutions presented here are the silver bullet for how to handle password fields in all situations. Depending on your users, your goals for the form, and your willingness to try something a little extraordinary, one of these options may make sense for your site. If anyone has any other ideas for how to handle password fields, I'd love to hear about it in the comments.
Update! April 16, 2009
In response to this post, Stephen Lewis from Experience Internet put together a writeup and demo for another alternative to password confirmation. His works very similarly to the iPhone password input field where the last character is momentarily a character before automatically switching to password "bullet".
Embracing the Curve
As web application designers, we often work to design interfaces to be as simple as possible, focusing on the new, uninitiated user who wouldn’t necessarily be interested in using a sophisticated interface. On the other hand, developers, enterprise, and other experienced users appreciate those sophisticated interfaces for the power they can give to the user.
It’s a common situation to outgrow a web application. You sign up for a tool that appears to be easy to use, and it is. You adopt it as part of your toolkit or workflow, and continue to invest your time and interest into it. Over time, though, you begin to feel the limitations of the simple tool. Maybe you were using Basecamp and are finding that it’s not the best way to task other people on a project. Perhaps you’re getting frustrated by Twitter’s lack of privacy or group options.
As a designer, what’s the right way to go? Do you design the simple interface for the new user, or the sophisticated interface to offer power to the more advanced user? In creating simple web interfaces, we are often designing at the expense of power, and that power can be the key that makes software truly invaluable for users in the long term.
It's a false dichotomy. You do both.