‘We are not good at designing’ (or why users are black swans)

This is one of the conclusions of the author of “The Black Swan” that may be also applied to the design of interfaces.

Listen Nassim Taleb in this interview (minute 4) claiming that humans are bad designers:

In his most popular book, “The Black Swan” (nothing to do with the movie), Taleb explains that many disciplines allegedly scientific like sociology, meteorology, politics and especially economics, are so complex and are so hugely affected by single events impossible to foresee (“black swans”), that making valid predictions is useless in most cases. Worse still, we are unaware of how bad we are making predictions.

Obviously, Taleb is not talking specifically about interface design, but it’s inevitable to come to the same conclusion because it’s also true that we are not good at designing interfaces. That’s why every approach to User-Centered Design is iterative: we know we are not going to find a suitable solution at first, so we keep trying and refining until we reach a valid design (because “we are good at discovering things”).

And what are our black swans? Users: it’s impossible to foresee how users are going to react in front of an interface (anyone who has performed or watched a usability user test has realized).



Software testing and usability: so close, so far

Software testing and usability are usually seen as independent fields, but they seem to have many common aspects. Why not trying to integrate both of them?

In my previous job as an expert in usability and accessibility, I was a member of the Software Quality Area inside my company. There I realized that, although they are closely related, usability and software testing are, in practice, developed as totally independent disciplines, with:Usability and software testing, working together

  • different experts and teams
  • different methodologies and techniques
  • different tools

Couldn’t they be more integrated?


UX thoughts visiting a NASA exhibition

A user-centered design vision of a visit to a NASA exhibition.

Last week I was visiting a NASA exhibition in Madrid. As a usability/UX specialist, I was prepared to see complex interfaces and panels full of buttons; and they were there. But two other things related to UX were called to my attention.

First, prototypes. One of the items at the exhibition was a sequence of prototypes of the lunar module that landed on the moon during the Apollo missions.

Second, checklists. Several old-fashioned paper checklists used during space missions were shown.

 Checklist used during a NASA space mission

I don’t know whether checklists are generally considered as a usability or user-centered design technique; anyway, I think they should. For more considerations about that technique, read the surprising and interesting book The Checklist Manifesto.

So two conclusions came to my mind:

  • When we talk about usability methods, it may seem that they are some kind of magic trick or very advanced technique; but most of them are simple and based upon common sense. And they have been performed during many years.
  • Since those kind of techniques have been performed during many years, and (most of) the missions were successful… hey, they somehow work!

RIA (Rich Internet Applications) usability heuristics

This time, the proposal is for a set of usability heuristics specifically compiled for rich internet applications (RIA), whose interfaces currently lack a standard set of principles or best practices.

RIA (Rich Internet Applications) technologiesRich Internet applications (RIA) (or ‘web applications’ as opposed to ‘web pages’) are very common nowadays; they may come from a standard web page that has been improved with extra functionalities, or from a desktop application that has been migrated towards a web platform. In any case, there are very few well-established standards for that kind of interfaces.

That’s why I have compiled a list of RIA-specific usability heuristics (or best practices) that may help when it comes time to develop or to evaluate a rich web application. They are not intended to fully cover all the aspects of the application, but to address issues specific of rich web interfaces; these heuristics should be a complement of more general ones.

As with the psychological usability heuristics, they are in the form of a Google Docs spreadsheet to make it easy to download or clone it for your own work.

RIA Usability Heuristics spreadsheet (Google Docs)

These are some of the sources I have used to compile the heuristics (thanks to them!):

What do you think of those heuristics? Do you know any other?

Give me back my text labels, GMail!

The new GMail interface includes icons in action buttons instead of old text labels; not a good decision from a usability point of view.

A lot has been written about the new GMail interface; most of it is a matter of opinion, but I’m afraid Google has committed an obvious mistake: using icons (in buttons) that don’t have a clear single meaning.

Let’s take a look at two of the buttons; isn’t this your first guess when you see them?

Guess for two of the buttons in new Gmail interface: download? important? 

Wrong. The real functions of those buttons are:

Real meaning of the icons: archive and spam. 

Using fancy original self-designed icons is a common mistake made by novice interface designers; icons are hard to memorize, and users usually recognize just a few of the most common. Many times, the best way to describe a function is simply a text label.

I’m surprised Google has fallen into that error; maybe they have been paying too much attention to people complaining about their ugly interfaces. Anyway, Google, please, give me back my text labels for actions!

‘UX interpretations’ as a UCD technique

UX Interpretations could be a useful technique to translate common poorly-specified requirements into a more UX friendly format.

User Centered Design techniques during the requirements phase (source: UsabilityNet)Some User-Centered Design techniques are supposed to be conducted during the requirements phase of the software development life-cycle, but in most real-world projects the usability/UX team cannot perform them, usually for reasons like these:

  • Requirements are defined by another team (business analysts) and the UX team is not involved in this phase; they usually don’t take part until the design phase.
  • The UX team is involved when the project is almost finished (and the interface problems are already pretty severe).

Yes, we know that the UX team should participate since the early stages of the development, but… what can we do when we are faced to given requirements, which are usually incomplete, long lists of technical features, and which have nothing to do with UCD techniques like use cases or user stories?

UX Interpretations

Last June, Greg Lauger explained in his article ‘Matching Requirements with User Experience‘ on Johnny Holland Magazine some techniques used in that kind of situations, and I think that the ‘UX Interpretation‘ approach (he calls it a “collaborative clarification”) is a great idea and could be used as a UCD technique on its own.