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.