Agile Usability

If I had time, I would re-read Tom DeMarco’s book Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency, because I have precious little slack in my own life, these days.  So it is that I just now got around to reading Jakob Nielsen’s article, Agile Development Projects and Usability, which William Pietri noted on the Agile Usability list on November 17.

The statement

“For a project to take interaction design and usability seriously, it must assign them ‘story points’ (i.e., resources) on an equal footing with the coding”

jumped out at me.  Alistair Cockburn wrote a thoughtful reply where he noted the same statement.  I agree with Alistair’s comments, but I’d like to comment on this statement from a slightly different perspective.

First of all, story points do not represent resources applied.  They’re an estimate of the work required to accomplish a small but measurable increment of functionality.  This work has never been just “coding.”  At the very least it includes testing and acceptance by the Customer.  If the functionality includes a change to the UI, then figuring out what that UI change should be is also part of it.

Many shops don’t have UI experts, so figuring out that UI change falls to the developer and the Customer having a discussion and making a decision.  Yes, this sometimes results in a terrible UI from a usability point of view.  The good news is that, if you’re working in small increments in an iterative fashion, you can always revisit this and change it.  If it’s bad enough, this usually happens.

When there is a UX/UI designer, their work is too-often treated as an up-front requirements definition phase, handed to the development process as a fait accompli to be developed without any further discussion.  The problem with this is not that it’s not “Agile,” it’s that it sabotages the benefits that people seek when they adopt Agile.  The Customer might have made some subtle adjustments to the functionality of the story, and the pre-designed UI might no longer be so appropriate.  The precisely-defined UI might be really expensive to develop, and a much cheaper approach might be approximately as good.  And, if the story is never scheduled for development, this up-front design is completely wasted.

It appears to me that the only way to get the Agile benefits of balancing needs and costs to get the best bang for the buck, is to move this UX/UI design work into the incremental, iterative development cycle.  That doesn’t mean to create a separate story card for UI design, and then another for implementation.  The completion of the story includes the UI design, the implementation, the testing, and the acceptance by the Customer.

“But,” some designers protest, “we need to do usability testing with mockups to know which is the best design.”  Well, perhaps.  On the one hand, with enough experience you might be able to design a “good enough” UI without this step, particularly if you know it can be changed in the future.  Doing the usability testing with live code, rather than a mockup, might provide better feedback because it tests the concept as-implemented, rather than as-conceived.

Sometimes, of course, we just won’t know enough to jump right to code.  This happens with coders, too, and we have a tool to deal with this situation.  That tool is a “spike.”  This is a time-boxed exploration to learn what we know we don’t know.  For a coder, it may be coding up an alternative implementation to see if it will work, or if it will provide advantages.  For a UI/UX designer, it may be creating and testing a low-fidelity prototype.   It’s time-boxed because it’s not directly producing value–it’s producing knowledge that we must then leverage to produce value.  Our goal is to answer some questions, not produce the best possible prototype.

When Nielsen recommends,

Most successful teams have adopted a parallel track approach, where the user experience work is continuously done one step ahead of the implementation work. So, by the time such teams start to develop a feature, the initial user experience work on it has just completed.

I think that he’s offering a half-step toward a more agile, effective approach.  While doing the UX work “one step ahead” is better than six month’s ahead, it’s treading on the same slippery slope as doing acceptance testing “one step after” implementation.  Splitting these concerns into a three-iteration waterfall makes the presumption that the work done in one iteration will not be affected by the associated work done in another.  This is rarely the case.  Even William Royce’s classic paper, Managing the Development of Large Software Systems, which described the approach now called “waterfall,” shows feedback from one phase to the previous.  The work done in implementation may inform the UI design and the work done in testing may inform both the UI design and the implementation.  Either the story is not done-done or it drags on for more iterations, being handed back for re-work.

Most successful Agile teams have learned to incorporate testing in the same iteration as development.  Sure, it’s less convenient that way.  They always struggle to keep these aligned without resorting to a mini-QA phase at the end of the iteration.  The developers and the testers have to take the bigger picture into account, and not focus solely on their own tasks.  It’s more difficult, particularly at first, but it’s more effective.

In the same way, Agile teams with UX/UI experts can incorporate UI design into the same iteration as development.  Those UX/UI experts will have to look at a bigger picture than just their area of expertise.  They’ll find this more difficult, especially at first.  But it will be more effective.  There will be times when they need to answer some questions before a story is ready for development.  In those cases, they should do a low-fidelity prototype spike to answer the questions they have.  It may be that the knowledge gained from that spike will mean the story itself is scrapped.  Or it should give them enough information to proceed with the more detailed design with the developers who are implementing it.  They might even consider measuring the actual implementation with usability testing in the same iteration, along with the functional testing that is part and parcel of calling the story done.

So, usability experts, are you up for the challenge?  Are you willing to stick your neck out and take responsibility for the usability of the delivered software?  Or are you going to take the easy route and say, “I did my task; the developers just didn’t follow my directions properly.”   I’ve heard that for years from people who fancy themselves as architects.  I don’t buy it from them, either.  Those who would be experts in design have a responsibility to see that design through to successful deployment.  Anything less doesn’t count.

5 Replies to “Agile Usability”

  1. Hi. I’m a UX practitioner who has worked almost exclusively on web-based applications managed using waterfall methods. I have, however, worked in Agile teams a couple of times.

    I think your final point, “Those who would be experts in design have a responsibility to see that design through to successful deployment” hits the nail on the head. However, I get the impression you don’t realise how hard it is to accept that responsibility in practice.

    Rather than try to explain what I mean by that, permit me to ask you a question through which you may discover more: why is it that designers are lazy? Why do you think they wish to pass the buck to developers for what the designer sees as failure?

    You may also like to try for a bonus question: in an Agile world, why can’t developers be designers?

  2. Hi, Jonathan. Thanks for your response.

    I don’t think that designers, in general, are lazy. I do think that many have a narrow view of their role, and are not yet comfortable stepping beyond those boundaries. By the same token, many developers take the same view in reverse, and don’t step beyond their self-imposed boundaries to help with the design.

    And I don’t want designers to take the rap for failure. Instead, I want them to work more closely with the developers (and the developers more closely with them) so that both succeed. It does no one any good to say “the design phase was a success but the implementation phase failed.” That’s a major reason to eliminate phases. Instead, think of these as /aspects/ of deploying a successful application.

    I understand that the way things are is not due to personal inadequacies on the part of designers. It more that the organizations and systems and processes we’ve set up to handle more complex UIs tend to get in the way of collaboration. The specialization between design and development both increases the skill brought to bear on each, and reduces the ability to make trade-offs between the two. It also seems to engender an “us” and “them” attitude that further confounds effective creation of applications.

    It’s time that we recognize this and come up with strategies to break down these barriers. And while the “fault” may not be a personal one, the solution surely depends on individual people working thoughtfully and hard to do things differently.

  3. I think I see what you mean in the abstract. However, I’m not sure what you consider to be the perceived boundaries that designers need to cross.

    Re-reading your post, I can see nothing that is particularly problematic (from a designer’s perspective) or even very new about what you suggest in terms of a remedy for the problems. Believe me, good designers are all about collaboration. Some, in fact, liken their roles to film directors (so-called practitioners of “Big IA”). They would like nothing better than to work in an environment that puts collaboration in the centre. So perhaps you have simply had bad luck in dealing with some very narrowly-focussed UI designers.

    But even in accepting your proposed remedies, I am still worried that incorporating iterative UI development into the Agile process will effectively kill off “the vision thing.”

    Vision, like it or not, is what UI designers are paid to provide. Wireframes, prototypes and user testing are mere means to an end. So, are you are willing to take the concept of re-factoring right into the heart of the business itself? I doubt many Agile operations would have the ability to allow vision to be manipulated in an iterative way.

    But this is interesting. In my wilder moments, I sometimes muse about “design as business strategy” – but I soon put that idea back in its box. You, however, seem to want to run with just that.

    So for that indeed, I salute you!

  4. Hi Jonathan and George,

    My company is planning to embrace Agile soon. Call me an utopist, but I am excited about the opportunities that Agile will bring to us designers. One of them is to better our relationship with developers. I believe we all have some who want us to provide the final designs and are happy to implement them. But there are also some who will reject our designs no matter how good they are. Being forced to work faster in the Agile world will hopefully force us all to join forces and work together as a team. I believe this in itself will solve a lot of issues described in this blog. And that is why I am so excited about going Agile.


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.