Agile Prototyping - Part 2

In the first part of this series, I discussed the use of paper prototyping and other lightweight methods for fleshing out application user interfaces in Agile software projects.

The main issue as I see it is that user interfaces can be more difficult to change than business logic or other back-end development. The key to iterative techniques is to keep the cost of change low. Reworking an entire user interface can be a daunting task, even for the most agile of teams. This may not be politically correct to say, but it's been my experience over dozens of development projects.

So as I discussed in the first article, the use of lightweight, throwaway mockups or prototypes such as paper sketches or whiteboard drawings can be a useful way of figuring out how a design should work before investing a lot of time in it. You can explore lots of ideas without getting attached to them the way you would if there was a chunk of code involved.

However, one of the issues with these kinds of prototypes is that they are only useful when the customer is available onsite. It's hard to do a whiteboarding session and explain how a interface will flow over the telephone. And a FAXed paper sketch or even a carefully drawn Visio diagram often has left more questions than answers. I've been looking for a way to improve on this for quite some time.

As it happens, I think I've found it. My company, ExtremePlanner Software, has been looking at this problem for over a year, and we've come up with a product that's designed to solve it with a minimum of fuss. I can now take my sketches or whiteboard drawings, photograph or scan them into digital images, tag and link them together, and publish a quick HTML prototype in a matter of minutes. Sharing ideas with remote participants is now dirt simple, and just being able to interact with the designs has resulted in more useful feedback that static drawings ever produced.

The product is called EasyPrototype, and I'm really excited about it, both for my own use, and for the problems I know it can solve for others as well. You can read more about it, or try it out yourself here. It's been a long time since I had this much fun designing and using a product.


For more on agile tools and techniques: http://www.extremeplanner.com

(Tags: agile, design, prototyping)

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams

Is doing user research first wrong?

Don Norman recently posted an article titled "Why doing user research first is wrong". In it, he suggests that user research to discover the true needs for a software project shouldn't be done after the project has already started. Instead, he argues, this kind of work should be done in order to choose the right project in the first place. In other words, once the project is funded and kicked off, there are diminishing returns on user research.

Why is this controversial? Well, the user experience/usability community has been lobbying for more recognition and for time to do user research, ethnographic studies, etc. at the beginning of a project to better understand user goals. Norman's article suggests that unless a business truly values these things enough to do them before starting a project, that these activities can serve mainly to delay a project. And a delayed project that isn't really the right thing to do is just a very expensive, highly usable, failed project.

But isn't usability testing important? Yes, but Norman argues that usability testing is like beta-testing; important, but designed only to find bugs, not to redesign a work in progress.

I think this is a positive development, in that I belive user experience and interaction design work is immensely beneficial to a project, but I have never been comfortable with this work delaying customer feedback in an agile process.

To fit in with Agile development, interaction design needs to find ways to be more incremental instead of heavily front-loaded. Norman suggests that the most valuable time to do some of this work is during the project evaluation stage. But because many companies don't want to spend the money before approving the project, it is often only after a project is kicked off that interaction design work is initiated.

Perhaps the sweet spot for interaction design after the start of a project is to create and test prototypes and mockups in parallel with development efforts. Designers can provide a steady stream of input to the development team in a rapid feedback loop.

Or maybe all of this is heresy, and Don Norman will soon find himself facing a mob of angry usability professionals with torches and pitchforks.


For more on agile tools and techniques: http://www.extremeplanner.com

(Tags: agile, design, usability)

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams

ExtremePlanner 2.1 Released

My company, ExtremePlanner Software, has just completed version 2.1 of ExtremePlanner, our web-based agile project management product. The new version features email notifications, enhanced release planning views, and other goodies.

The testing was finalized last week, and we've been busily updating the website, file downloads, product tour, and other product information.

The initial release is for Windows, but depending on demand, we may be offering Linux and Mac versions of the product. Linux and Mac users, if you're listening, drop me an email (dave at extremeplanner.com) if you're interested in seeing ExtremePlanner on one of these platforms.

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams

What is Good Software Design?

James Shore writes about good and great software design in an article titled Quality with a Name.  From the article:

A good software design minimizes the time required to create, modify, and maintain the software while achieving acceptable run-time performance.

From this definition, he goes on to consider various design principles, but winds up in an interesting place that I’ve often found myself visiting:

Every design decision is made in the context of the whole design. The problem being solved; the other design decisions that have been made; the time schedule; the available pool of programming talent; etc., etc.

Context makes every piece of specific design advice suspect. I'm not saying that you shouldn't listen to it... you should! But at every moment, you should ask yourself: "When is this not true? What is the author assuming?"

I am constantly reminded of the role of context in almost every software “best practice” or “pattern”.  As engineers, we are driven to simplify, codify, and categorize eveything we do so that it can be reused, leveraged, or repeated with a near-guarantee of success.

Context works against us at evey turn.  It takes universal “truths” and makes them into horrible errors of judgement.  Or at least opportunities to blame someone else.

The message is clear: applying best practices and universal truths is no substitute for thinking.  An engaged and informed brain can run circles around a mindless implementation of what “they” say works.  Not that “they” don’t have something to offer, but it always comes in a wrapper of context.

For more on agile tools and techniques: http://www.extremeplanner.com

(Tags: agile, design)

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams