This post originated from an RSS feed registered with Agile Buzz
by Dave Churchville.
Original Post: Goal Driven User Interface Design
Feed Title: Agile Project Planning
Feed URL: http://feeds2.feedburner.com/AgileProjectPlanning
Feed Description: Thoughts on agile project planning, Extreme programming, and other software development topics
Can an agile development team build a usable, non-trivial user interface in 2 weeks? Or do complex user interfaces and interactions require some upfront design to get right?
User interfaces defy the "just build it and get feedback" approach in that once they are deployed and learned, major changes can be very disruptive to end users. Assuming for a minute that the customer doesn't have expert UI designers on staff, and is expecting you to provide a reasonably effective UI, how do you proceed?
Some options to consider:
Stagger the design and implementation cycles so that the team analyzes the user's goals and does sketches and mockups of the UI in Iteration 1, to be coded in Iteration 2. This probably requires at least one person dedicated to this role.
Perform upfront analysis that tries to capture user roles, agendas, and goals before any development begins. Interaction design advocates this approach, and its supporters say that this initial analysis does not change much over time, and so is worth doing early.
I believe that understanding user goals is critical, and a great time saver before the major coding begins on a project. This doesn't have to be a huge effort that takes months of field study, but it probably does mean talking to users of the software in their various roles. It might take anywhere from a few days to a few weeks depending on any travel that's necessary, and on how many user roles you're exploring. But again, even a little bit of goal analysis is better than nothing.
A common objection to this sort of early analysis is something like "But I have an onsite customer, I'll just ask her when I run into something." This can be very effective for domain-specific questions, but less so for something outside of the onsite customer's goals. If your system has a function that only shipping clerks will use, asking the inventory manager what the screens should look like may not be the best way to go.
If you absolutely can't get access to real users, you can use "personas" or user role analysis to figure out what they *might* need. This isn't ideal, but it's a lot better than nothing.
The process might look something like this:
Brainstorm all the possible users (real people) of a system. For a sales management system, that might be: Salesperson, Regional Sales Manager, VP of Sales, CEO, CFO, and probably most importantly, Sales Assistant.
For each role, try to identify the goals they have in their job, and how the system might support those. The Sales Assistant may have a goal of keeping her 4 Salespeople happy. This might translate into being able to access their information quickly, switching between customers for different salespeople, etc.
From the goals, you can start designing possible UIs to support them using paper, whiteboards, or drawing software.
Test the prototype drawings against the user goals and scenarios to validate them.
Start developing software based on the validated prototypes.
In my experience, you can definitely build software without going through any of this (and I have). But time and time again, the most customer-satisfying user interfaces I've developed have come from doing some initial goal analysis.
As a strong proponent and longtime practitioner of agile methods, I don't much like the idea of spending a lot of time on upfront analysis. But goal analysis, especially when the user interface is sensitive (repetitive use applications, those that need to be very easy to learn, etc.) can be time well spent.
Previous Topic
