Hi Nick, Thanks for jumping in with your thoughts.
I was reading the thread about prototypes and now reading this, and in both cases, the thing that jumps to mind is patterns. Patterns are a way to both learn and communicate good design. I won't debate the experience is highly valuable, particularly experience guided by a "master." At the same time, when masters are in short supply, we may need to look to other, more scalable options. I think that's where patterns can do a lot of good; they can help you avoid a lot of bad design in the first place and, in theory, help you pick the right one the first time. They also help you understand, rationalize, and communicate why certain designs are good in certain scenarios and others are good in others. So if we have these patterns, are under the guidance of a master, or are a master ourselves, we really shouldn't need to go through a lot of design iterations to get the right thing in most situations. What it comes down to, then, is getting it mostly right the first time, and the iterations serve to refine and tweak to really tailor the solution to the problem. So being agile is not about completely changing a design several times over but tweaking a mostly right design. The core problem with waterfall-like approaches is the wrong-headed assumption that we can figure out the right thing up front, document that right thing, and, via that documentation, sufficiently communicate that right thing to the folks who actually build it. Let's say you, as the UX pro, are able to figure out the right thing to build up front (which I find a dubious proposition), you still have to somehow communicate that to the folks who have to build it. Then they have to figure out how to make it happen (assuming it is technically feasible), understand your design from your documentation, and then execute upon it based on that. Granted, there is a higher chance of success with your help than if we skip the UX stuff and stick with the old-fashioned requirements gathering by the biz and bulid from that, but we're still left with this essentially flawed idea that the needs of the business can be sufficiently communicated through design artifacts. You're still in that boat where you're upset with the devs because you feel they didn't execute on your vision, when the problem likely lies more in the flawed process that assumes you can sufficiently communicate your vision through design artifacts. Even software architects who are (or were), generally speaking, master developers can make mistakes in their design or leave things out that leave developers hanging, having to work around them or come up with solutions on their own. We architects have an intimate, experiential knowledge of what it takes to build software, yet even we don't always make the right design choices up front, often leave out necessary details, and often fail to communicate our right ones. It's not fair to expect that UX pros should anticipate and address the difficulties in implementing their desired designs who lack (as a rule) the knowledge of how to make designs become reality with technology. Further, it's not fair to expect them to be able to sufficiently communicate their design through design artifacts, especially when they lack the common language and context that even devs and architects share. Similarly, it's not fair to expect developers to make the "right" decisions when they run into difficulties (or missing details) or always correctly interpret design artifacts and translate them into running code. That this is true is confirmed in my own experience, anecdotal evidence, and even the latent hostility there seems to be in the creative community towards developers (and to some extent vice-versa). In short, the addition (or expansion/specialization) of UX professions doesn't change the fundamental flaws of the waterfall process. You guys bring very important talents and skills that we *need *to make great software, but that doesn't mean we can go back to waterfall approaches. We need to incorporate you into agile processes. You need to be there to see your vision through to completion, and it is good for the business in that we can minimize the costly design artifacts that have limited practical value and focus on getting the right thing up and running. The value proposition of agile, as I see it, holds true even with--especially with--the incorporation of UX professionals. Architects and devs are not dumb people. We take pride in what we do just as much as UX folks do. We want to build great stuff. We've been doing software for many decades now, and we've figured out that waterfall doesn't work well to build great software (or even to build software that just works). Learn from what we've learned; don't go through the painful process to figure it out yourself. Some of us are also recognizing that we need more focus on UX in our software design. Businesses are also realizing that value, and thus these specializations are emerging to meet that need. I'd say we have a duty not to forget what we've learned, to learn from each other, and come up with new and better ways to build the best software possible. Let's put our collective brains and imagination together and do this thing. :) Cordially, --Ambrose On Thu, Feb 14, 2008 at 9:43 AM, Nick Iozzo <[EMAIL PROTECTED]> wrote: > Ambrose, glad to see someone with you background actively participating > in these discussions. This is what we need. > > From your description, what I see missing the time to explore the design > space. Bill Buxton had a great slide (and simple one) showing the design > process. In words: Design is about choice. > > You need to generate a lot of GOOD options so that you can then make a > GOOD choice. > > Hypothetically. Maybe one good interaction metaphor for your product is a > step-by-step process over several pages. Maybe another good interaction > metaphor is a simple form where the detail is reveal through progressive > disclosure. > > To want to build each one of these in a sprint in order to evaluate this > would be a waste of time. It is better to have a design exploration phase > prior to any development sprint. > > I have had experience in projects like this. Where you start out the > design exploration phase with a collaborative design workshop. You follow > this with a series of rapid iterations over the next ~2 weeks. I would > expect to be able to explore over 10 different good interaction metaphors in > that time. > > Ideally, I would then take 2 or 3 of the best interaction metaphors and do > some testing with end-users on them. I do not ask them to pick which one > they like, I use this to understand how well they can interact with each > one. > > I could use this information to then design the screens for the first > sprint. > > You could do this pre-work in time it takes to do 2-3 development sprints. > But, you have explored more designs then you ever would have been able to in > over a dozen development sprints. > > *Nick Iozzo > *Principal User Experience Architect > > tandemseven > > 847.452.7442 mobile > > [EMAIL PROTECTED] > http://www.tandemseven.com/ > > > ------------------------------ > ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... [EMAIL PROTECTED] Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help
