Jakob Nielsen on the use of Agile methods:
Agile’s biggest threat to system quality stems from the fact that it’s a method proposed by programmers and mainly addresses the implementation side of system development. As a result, it often overlooks interaction design and usability, which are left to happen as a side effect of the coding.
In my experience, mostly as a developer, it is really easy to dismiss interaction and usability design for two reasons.
The first comes from the developers themselves, trading prettiness and consistency of user experience for cleaner and sounder domain models whenever they go in opposite directions. Signs this is happening are developers crying YAGNI when the stakeholders ask for a zoomable chart or DTSTTCPW when a sortable, paginated data table is required.
Next time you see a system where there are enormous listings of items with no search, pagination or sorting, ask the developers if they have ever watched a typical user at work; chances are they have only thought about the system as they see it: since the testing dataset is usually small, a loop spitting out a bit of HTML for each element isn’t such a big deal. They might even say there’s a story to implement all that lovely stuff later on, but they just get moved over and over to the bottom of the backlog barrel… until everyone watches a person struggle to find needles in a tabular haystack all day. This is a simple example – almost too trivial actually, but one I’ve seen happen way too many times.
Changing the perception that usability is just the icing on the cake draws attention to all that wasted time to the stakeholders, and should enable a much better dialogue: developers get to write an application users will love, stakeholders spend their money wisely on something that will actually increase return on investment (as productivity gains), users feel empowered and less likely to make mistakes. Everybody wins.
The second reason UI design and usability get overlooked, and this is the one Frank alludes to in his latest post, is that some agile teams rely a bit too heavily on the stakeholder’s descriptions of what is wanted. It instantly reminded me of one my favourite quotes from Cars:
Lightning McQueen: All right, Luigi, give me the best set of black walls you’ve got.
Luigi: No, no, no! You don’t know what you want! Luigi know what you want. Black-wall tires, they blend into the pavement, but these white-wall tires, they say look at me, here I am, love me.
Lightning McQueen: All right, you’re the expert.
I find it rare for the stakeholders to know exactly what they want, down to what the end-user experience should be like. Thinking about a reasonably-sized application at this level of detail can only be done as a series of small, incremental steps and having someone on the team who is really obsessed about making every single pixel on the screen be in the right place. And if you read the last sentence and thought “well, that’s not exactly the role of my stakeholder!” you get the point: the stakeholders should not have the final word as to what the usability and experience details should be, in the same way they simply delegate to and rely on the expertise of the development team to flesh out the details of a persistence layer.
Have look and feel expertise in your team, and trust it, in the same way you would trust the database or network connectivity expertise.
scot | 28-Nov-08 at 5:03 am | Permalink
“They might even say there’s a story to implement all that lovely stuff later on, but they just get moved over and over to the bottom of the backlog barrel”
Customer decides priority of stories. If the marvelous features like pagination “just get moved over and over to the bottom” you should be asking why the customer didn’t prioritize it, not why the developers didn’t develop it … in order words YAGNI.
What goes into the iteration is the customer’s choice. If customer wants advanced usability they are free to schedule the all the super-cool usability stories they like. If they don’t devote the time (i.e. budget) to it, that’s not the developer’s fault (necessarily). They don’t have to have all the details at hand, just enough to fill in two or three sentences on a story card. Putting that story card to the top of the stack is not the responsibility of the developers.
And if they don’t budget for a usability expert, they are not gonna get a fantastic interface … just the one the developers can deliver them. Again, that’s all down to the customer’s priorities.
Stop blaming agile for something that’s not even remotely agile’s (or any other methology, RUP, scrum, waterfall, whatever) problem.
bo | 28-Nov-08 at 5:47 am | Permalink
Interestingly, in the same article that you quote here, Nielsen goes on to say that Agile works great with a usability perspective, as long as design and UX is incorporated into the iterative process rather than left on the outside.
If you’re doing a project where you have some occasional external usability experts who come by to complain about priorities your stakeholders set (probably for very good reasons), then you’re not doing agile.
Carlos Villela | 28-Nov-08 at 10:07 am | Permalink
@scot, that’s exactly what I meant by “changing the perception that usability is just the icing on the cake (…) and drawing attention to all that wasted time to the stakeholders”. I don’t believe there’s someone to blame (as you put it, “not the developer’s fault”), but it’s clear that there are conversations between stakeholders and developers not happening when usability problems go unnoticed, and that is the issue I am focusing on, and not whether this is a problem with agile methodologies or with the customers themselves.
@bo, I don’t disagree with the article, I think Jakob has some very valid points. The idea was to clarify why “it (agile) often overlooks interaction design and usability, which are left to happen as a side effect of the coding”, with the two points I made earlier.
Josh E. | 06-Dec-08 at 6:49 pm | Permalink
Hear hear! The truth is, there is a difference between domain expertise and user experience expertise. Business stakeholders generally have a whole lot of one, and very little of the other. Prioritization should be based on business, user, *and* technical needs, and there should be opinions on the team to guide that prioritization process. Employing a user experience professional is a surefire way of getting the users’ voices into your prioritization. Oh, and you’ll also get a well designed app that the users (and therefore the business) will love all that much more.
I think the thing that is really hard for people to understand is that there is a difference between pure domain expertise and on-the-factory-floor real-world expertise. An Interaction Designer will use methods to understand both of these perspectives and then design the software based on them. Note that Nielsen says, “It’s perfectly feasible for developers to do interaction design and usability.” The important thing is that time and resources are dedicated to the cause.
I wholeheartedly agree with Nielsen on this one. Since there has been software, user experience has been de-emphasized as a “soft art,” “black magic,” or as quite simply unneeded. This mindset is misguided, and is still prevalent even in forward-thinking Agile communities. We must emphasize to our clients the importance of user experience, even beyond look-and-feel, and in many cases it will be up to the development team to do so.