thats absurd.

and somewhat reminiscent of an Oatmeal post or two…

-spike

@Susan: Your instinct is right… The situation is rare in which I’d just listen to business goals, whip up a prototype, and then put in front of users. There is definitely a use for that process, but it’s an exception. During user research, I’m thinking more the traditional interview and observation that you mentioned, with a huge focus on observation. Concurrently, that’s when BAs would be gathering their high-level requirements. You bring those two things together with business goals to come up with a preliminary design & prototype, then use the prototype to drive out the details of what’s required. Regarding who drives the prototype, it’s probably slightly better if a user does if they’re given a *realistic* task to complete along with the data they need to do so. When you need to get mass feedback, though, a walkthrough is fine.

@Andrew Absolutely. Thanks man!

@Jen Yep. That’s the main focus of this article, eliciting requirements through design. And yes, a strong BA/UX partnership can go a LONG way to make that successful. If you’re interested in learning more about sketching sessions, I encourage you to check out Will Evans’ series on facilitating design studio sessions. You can find Part 1 here: http://blog.semanticfoundry.com/2011/04/30/introduction-to-design-studio-methodology/

@Stuart I’ve had the exact same experience. Hence this article. : )

@Scott Wow. Clearly you are deep, deep into software development process design. I’d love to see you turn that Powerpoint into a blog article and post a link to it here. On the surface, what you described seems very complex. Clearly I could be missing something, because this is a blog post comment and not a fully articulated argument, but I’ve seen complex processes like this really struggle with adoption. The people who are supposed to carry them out get confused and just fall back on the way things have always been done. Even when directives come from on high that the process must be used and there are process mentors and all that corporate infrastructure intended to enforce adoption. That said, you’ve named it “Behavior Driven Development” and it is “activity-centered” which to me is a good sign. To me, this indicates that the purpose of this process is to really understand the business and user goals in order to develop something that actually solves them. Anyway, I’d love to know more… please write that article and post a link here in the comments!

@Kathy Much earlier in my career, I had the same issues with prototyping as you described. But for the past almost 6 years now I’ve been using a prototyping tool called Axure. I can do my wireframes, richly-interactive prototypes, and documentation all in the same tool. It’s allowed us to really strongly integrate iterative design here at Evantage. Axure isn’t the only tool out there that lets you do this and it might not be right for every situation, but for us it allows us to do what we need to do. And Agile’s more than just a buzzword, so I’d recommend getting used to it. : ) Check out those articles I posted at the beginning of this comment. Anders is a *great* source for all things Agile & UX.

@Peter Valid criticisms all. Take a look at the white boxes in the flows. Those are collaborative and include technology. I should have made that more obvious. The entire team needs to understand the business problem and to have a voice in how these problems will be solved, hence the collaborative nature of determining/uncovering business goals and design concepting. Also, these flows are drastically simplified for the purposes of this article. You’ll notice I omitted visual design too. In the more detailed version of this flow, visual design-specific activities (ideation, mood boards, etc) can begin as soon as observations start flowing in from user research. Technology-specific activities (estimation, feasibility analysis, etc.) can begin once the concepts begin to take shape. In the full version, I’ve also got technology providing and taking input from iterative prototyping, as you recommend.

@Nick Absolutely. Although I do favor going interactive as soon as possible. That’s for two reasons. First, I happen to be good with a rapid prototyping tool called Axure. Second (and more important), interactive prototypes more clearly communicate how a system is really going to behave, allowing you to get more accurate feedback. But using paper prototypes to gather feedback and elicit more detailed requirements is DEFINITELY better than interminable requirements review meetings. And yes, developers need early involvement too. Check the collaborative activities indicated by the white boxes.

I also think we should get developers in as early as possible so that we don’t show ideas that can’t exist in nature. Plus it makes them feel good, which is helpful later.