Usabilidad de los formularios web

El artículo An Extensive Guide To Web Form Usability es una excelente guía para mejorar la usabilidad de los formularios web.

En este artículo se indica que los componentes de un formulario son:

  1. Labels: These tell users what the corresponding input fields mean.
  2. Input Fields: Input fields enable users to provide feedback. They include text fields, password fields, check boxes, radio buttons, sliders and more.
  3. Actions: These are links or buttons that, when pressed by the user, perform an action, such as submitting the form.
  4. Help: This provides assistance on how to fill out the form.
  5. Messages: Messages give feedback to the user based on their input. They can be positive (such as indicating that the form was submitted successfully) or negative (“The user name you have selected is already taken”).
  6. Validation: These measures ensure that the data submitted by the user conforms to acceptable parameters.

Hoy es la conferencia virtual ¿Usabilidad, Accesibilidad? Objetivos, diferencias y semejanzas de cada disciplina

Hoy, a las a las 11:30 horas en Ecuador (las 18:30 en España), impartiré la conferencia virtual ¿Usabilidad, Accesibilidad? Objetivos, diferencias y semejanzas de cada disciplina en el CIESPAL que anuncié hace unos días (Conferencia virtual sobre “uso fácil” de páginas web).

Supongo que en el sitio web de CIESPAL indicarán la URL para la visualización de la conferencia. Quizás también lo anuncien en su cuenta en Twitter @ciespal.

Durante la conferencia virtual se podrá realizar preguntas a través de Twitter (con el hashtag #DiseñoWeb), Facebook y a través de la propia página de retransmisión mediante un chat online.

Citas sobre la usabilidad

En la página  web The ROI of Usability hay numerosas citas de casos reales que demuestran la importancia de la usabilidad. Algunas de estas citas son:

“The rule of thumb in many usability-aware organizations is that the cost-benefit ratio for usability is $1:$10-$100. Once a system is in development, correcting a problem costs 10 times as much as fixing the same problem in design. If the system has been released, it costs 100 times as much relative to fixing in design.” (Gilb, 1988)

 

“You can increase sales on your site as much as 225% by providing sufficient product information to your customers at the right time. In our recent research, we found that the design of product lists directly affected sales. On sites that did not require shoppers to bounce back-and-forth between the list and individual product pages, visitors added more products to their shopping cart and had a more positive opinion of the site. By understanding your customer expectations and needs, and designing your product lists accordingly, you can significantly increase your sales.” (UI Engineering, 2001)

 

“More than 83 percent of Internet users are likely to leave a Web site if they feel they have to make too many clicks to find what they’re looking for, according to Andersen’s latest Internet survey.” (Arthur Andersen, 2001)

 

“A bad design can cost a Web site 40 percent of repeat traffic. A good design can keep them coming back. A few tests can make the difference.”(Kalin, 1999)

Cómo un dato extra puede suponer pérdidas millonarias

En el artículo Expedia on how one extra data field can cost $12m cuentan el caso curioso del sitio web Expedia que logró aumentar sus beneficios anuales en 12 millones de dólares al eliminar un campo de su formulario.

En el formulario para realizar una compra, justo debajo del campo “Nombre” existía un campo llamado “Compañía”, en el que muchos usuarios escribían el nombre de su banco. Y justo debajo de ese existía otro campo llamado “Dirección”, en el que muchos de esos usuarios escribían la dirección del banco en vez de su propia dirección.

El problema surgía al realizar una comprobación para evitar fraude en el uso de la tarjeta de crédito: al comparar la dirección que indicaba el usuario con la dirección en la que estaba registrada la tarjeta de crédito, cuando no coincidía la dirección se anulaba la transacción. Y claro, no coincidía cuando el usuario escribía la dirección de su banco en vez de la suya propia.

El botón de los 300 millones de dólares

En The $300 Million Button se cuenta la historia de una tienda online que logró aumentar sus ventas al simplificar el proceso de finalización de una compra.

Inicialmente, el usuario tenía que estar registrado para finalizar una compra. Muchos usuarios llenaban su carrito de la compra con productos, pero al llegar al proceso de finalización, no lo terminaban. En un estudio se descubrió la razón: muchos usuarios no querían registrarse y muchos usuarios no recordaban si se habían registrado, por lo que perdían mucho tiempo intentando recuperar su contraseña y al final desistía. Al añadir una opción para comprar sin registrarse, las ventas aumentaron considerablemente.

En The Back Story for the $300 Million Button se explican más cosas sobre esta historia.

Entrevista a Steve Krug

Steve Krug es uno de los gurús de la usabilidad, pero se diferencia de Jakob Nielsen en que tiene los pies en la tierra. En Interview with UX Expert Steve Krug podemos leer la siguiente entrevista que le hicieron hace poco:

Rosenfeld Media: You’ve always been a big proponent of DIY Usability, i.e. the fact that it’s not rocket science so anyone should be able to do it. We understand anyone can do it, but does that mean they can do it well? 

Steve Krug: Actually, my trademarked slogan is “It’s not rocket surgery,”™ but why quibble? You’re right: it does mean I believe that most people—with a little instruction—can do much of what I do as a usability consultant. They can’t do it as well as I can—hopefully—because I’ve been doing it for 25 years, but a lot of it is just applying common sense.

And that’s particularly true for running some basic usability tests. Someone with experience–especially a professional–can probably do a better job than an amateur. But can an amateur do it well? In my experience, almost anyone can do at least a halfway decent job right away. After all, it mostly consists of just giving someone a task (or tasks) to do using whatever you’re building, and then watching them while keeping them thinking aloud. In fact, the hardest part for beginners is biting their tongue and resisting the impulse to help, to comment, and to ask leading questions.

RM: But does this mean they can do it well enough to make it worthwhile? 

SK: I think so, for a few reasons.

First, someone beginning to do DIY testing probably hasn’t been doing any testing before, and some testing is infinitely better than none.

Second, if they haven’t been doing any testing, then there are probably huge usability problems just waiting to be found. So even if the facilitation is less than perfect, the participant is still going to run into the worst problems and the observers are going to see them.

And finally, I’ve been asking people for years to send me examples of cases where testing by amateurs made a product worse. And after all this time, I haven’t had anyone send me a convincing example. In fact, most of the examples I’ve received have been where supposed professionals did a shoddy job. It makes sense that these are the ones I get, because professionals are—correctly—held to a higher standard. So I guess my answer is that amateurs may not do a perfect job, but they almost always do it more than well enough.

RM: If anyone can do it themselves, when would you need an expert or consultant to come in and help?

SK: I’ve always said that if you can afford to hire a professional, by all means do it. It’s just that the vast majority of the people out there developing “stuff”—sites, apps, etc.—can’t afford to hire someone. That’s why I’m always trying to teach people how to do it themselves.

But if you have any money for it, I’d highly recommend at least hiring a professional to do two things:

1. An expert review. Having a pro look at your stuff and apply their years of experience is enormously valuable. In particular, they’re likely to have a lot of knowledge about what’s worth fixing, and what kinds o fixes will actually work. It’s a great investment.

2. Coaching. Even if you’re doing DIY testing, it’s great to have someone with experience looking over your shoulder and mentoring while you get started. They can help you formulate task scenarios, show you ways to recruit participants, observe your sessions and critique your facilitation skills, and decide what to fix and how to fix it.

Like I said, professionals are going to be better at it than you are. But if you can’t afford to have one around all the time, get them to teach you.

RM: Thanks, Steve!