Agile vs. Usability?

Thre’s been a recent discussion around how agile methods face usability, mainly following Jakob Nielsen’s post about how agile, if poorly executed (that’s my opinion), can be a threat to usable software.

I don’t want to say again what was already said, and I believe that agile and usability can be a good match, as long as you know what you’re doing, but what sometimes bothers me is the common thinking around agile methodologies, that usability = what the client wants. I’ll explain.

In most of the agile projects I’ve been (not to say all of them : ) ), whenever there is some issue around how to make some feature in terms of usability, like “how should be the user experience around this operation”, the common answer is: “let’s ask the client..”.

Well guess what? The client never thought about usability in his life. Of course he used computers already, but he probably doesn’t know how to better develop an application to make it more usable. And this situation gets even worst when the client is just a proxy to the real user, who will probably not even work in the application being developed.

To give a pratical example,  if you asked a bunch of people how they would like to search for web pages in the pre-Google era, how many do you think would answer a “blank page with a text field on it”?

If this ask-the-client behaviour comes from pure lazyness or some cover-your-behind strategy, that’s another discussion, but what I think most agile teams should change in the way they work is to stop pretending that the client has all the answers, and trust a little bit more in themselves to create solutions.

And my guess is that the clients would also like it, because I don’t believe they want to spend their time answering questions like “which is the best solution for this problem: a select field or radio buttons?”.

And if you really want to trust the client to tell you how to build software, do it in a real HCI fashion, observing real users using your application and getting your answers from there.

Cheers,

Francisco.

Advertisements
7 comments
  1. marc said:

    “let’s ask the client..”.

    Excellent stuff. The truth is that it is rare for the client to know what they really want. Their perception of the UI is clouded by either their current application or website, or their competitors products and a need to maintain functional parity. Ask the client how it should look and behave and the chances are you’ll build another mediocre product with mediocre usability.

  2. Rafael said:

    Very good point!
    It’s all about the old way people find to protect themselfs from their clients. How crazy!

  3. I think this article is true of waterfall as well. It is more about the people doing the work than the process surrounding. In an agile methodology you would finish the iteration and present to the customer for testing/comment.
    Wether waterfall or agile, running to the customer for clarification on any little thing is down to the individuals and probably a ‘cover your backside’ approach.

    Regards,
    David
    I think this article is true of waterfall as well. It is more about the people doing the work than the process surrounding. In an agile methodology you would finish the iteration and present to the customer for testing/comment.
    Wether waterfall or agile, running to the customer for clarification on any little thing is down to the individuals and probably a ‘cover your backside’ approach.

    Regards,
    David

%d bloggers like this: