Hi Jonathan. Whatever way you break it down, here are some keys to building design into product development:
a) Making user research an upfront part of your process - don't let someone else do the research and then have designers work from other people's insights and premises. Designers must be connected with the user on a human level to spark their intuition. You have to *be* with users to do that. This is especially relevant in the medical environment where there are vocal personalities such as chief administrators, who usually don't represent your target persona. To sum up: don't let users out of your sight :) b) Making sure requirements are created in concert with the design - you can't have someone do the design and another person be responsible for what the product must do from a "requirement perspective." Push for a single set of technical requirements with the design linked in. To sum up: marry the design and the textual requirements. c) Making sure requirements are allowed to change through the process. The only reason textual requirements don't change is because they are high level - so high level that *sometimes they claim to represent the "what" not the "how"*...a statement which should be soundly refuted but which has not been. Every requirement I have ever seen embeds pivotal design decisions. Design is a "what & how" - it's key that the process represent that. Try to keep the requirements and design "live" and visibly changing through the dev effort. This motivates development that you're working with them and will accommodate development ideas and trade offs. To sum up: build a process that represents change throughout - I've heard the term managed chaos, that's really what it is like. As for Agile, the effects of Agile on a project are best observed from its philosophy. Its philosophy is pro-scientific - we don't have knowledge unless we have a systematic method to get knowledge and data to prove we have it. The effects on a project of this scientism include statements like: a) we don't want to do too much upfront work, because we can't know what's good or bad or true apriori - leaving little place for revelation/intuition. b) we don't want to go too far without feedback, because feedback tells us what's important - leaving little place for discernment and judgement Despite being pro-scientific, advocates of the agile philosophy don't appreciate some back of the envelope logic. Namely, that there are an infinite number of paths to go down at every step of product development and you aren't going to cover even some of them with Agile. From figuring out "why" some problems are worth solving for a user and others not, to figuring out "what" problems are worth building solutions for and others not, to figuring out "how" to construct a solution that fits the problem or not* the space is huge*. Nobody truly believes you're going to be able to build, test and iterate at all of these (why, what, how) levels or even one, or even on one small branch of one. There are a gazillion ways to create and place just two buttons on a screen and each arrangement affects what the user experiences. So the question of "what should this product *be like*" can't hope to get timely answers from applying the scientific method, a huge amount of bias, intuition, judgement and skill must be used to navigate the huge space. For a product that is going in front of users and have interactive behavior (i.e. the interface), an interaction designer has the skills to navigate the space. For a product that is going to operate on CPUs (i.e. the code), an engineer has the skills to navigate the space. To practically work in an Agile environment you must counteract its pro-scientific philosophy with what??...you guessed it...scientific evidence. You must present upstream user research as data points and present downstream validation of design prototypes as data points. You must evidence through practice that design doesn't have to take sooo long to counteract the "wasting time while we could be iterating" mentality. You must show design ideas that "come from nowhere" lead to unexpected positive outcomes. You must frame negative outcomes from a lack of design on certain projects as evidence of the need for more design. Through time, this evidence will give confidence to development that design and a designer have a place in the process since there is evidence it is working well and leads to better outcomes. Intelligent design will win in the end. Navid Sadikali On Fri, Apr 4, 2008 at 3:39 PM, Abbett, Jonathan < [EMAIL PROTECTED]> wrote: > The materials I've found about "process" have been very heavy, seemingly > from corporate environments, so I'm curious if anyone out there, > particularly those in small/medium-sized groups or teams using Agile > methodology, can share their design lifecycles. > > Thanks, > Jonathan > > ________________________________________________________________ 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
