3 ms·

Fitting Big-Picture UX Into Agile Development

8 points by dilipray 14y ago

kevinconroy 14y ago
Helpful advice if your scrum process is run literally by the book. In my experience, though, I've found that it's very natural to integrate graphic and UX design into sprints along side programmers. As the Product Owner, my goal has been to keep a rough roadmap of issues and features. I often schedule design or graphic work a sprint or two ahead of when we want development to occur. In this way, the requirements become more fully baked in advance of coding. If design or UX uncovers issues that cannot be solved by the end of the month that's okay. Just reevaluate during sprint review and determine next steps. Usually giving them another sprint provides enough time to figure things out. Another trick is to have developers create a working "wireframe" version of features in the template language. (Think HTML with CSS turned off in your browser.) Then when it's working, hand it off to the designer to make it pretty in the next sprint. Doesn't work for every feature, but small to medium sized ones can benefit from this. This also provides a good way to handle scheduling contention so that the designer doesn't have to handle every issue before developers do. Your milage may vary, but I've have 95%+ success with this technique.
- colmvp 14y ago
  "Then when it's working, hand it off to the designer to make it pretty in the next sprint." I hate how some engineers think that's the role of a designer. It feels so condescending.
  - kevinconroy 14y ago
    I'm a designer and an engineer. There are some pages where the UX is clearly defined, is simple, and it just needs to be pretty. I agree that this is a larger problem in the industry, but I meant no offense.
durzagott 14y ago
While I appreciate the author has tried to take a good stab at the whole big-picture-design problem, this to me looks like a Scrum-but. "We do Scrum, but... every so often we stop doing Scrum and get our design hats on" Perhaps I've been fortunate in the projects I've worked on so far, but we always managed to get the UX designs done one sprint in advance. Sure, things need to be reworked as new discoveries are made. But isn't that the whole idea of iterative development?
mathewsanders 14y ago
I feel the heart of this article is here: For many designers, the process often feels like an effort to design an engine, wheel or windshield without really knowing in what kind of car these parts will need to be integrated. If people are designing in sprints without a clear idea of what they are building then something has gone horribly wrong. I think Agile works best when you have a clear understanding of what you're trying to do. If a design strategy hasn't discovered this in Sprint 0 then I think there will be ongoing problems. Maybe I'm wrong, but I feel that the whole nature of Agile is that at the end of a sprint you've got some self-contained feature working. I don't think their is anything in the agile philosophy saying that what you have in sprint n will continue to exist in spring n+10. Like code you may refactor as more information comes in. As designers we need to accept that when designing in Agile that what we do 2 weeks ago may not exist tomorrow. I think as designers that's a hard thing to do because we don't like 'waste', we want to avoid re-work and we also like to design the best solution with ALL the information we can get, but doing so requires a lot of upfront thinking and is just taking us back to waterfall.

8 points by dilipray 14y ago

Helpful advice if your scrum process is run literally by the book. In my experience, though, I've found that it's very natural to integrate graphic and UX design into sprints along side programmers. As the Product Owner, my goal has been to keep a rough roadmap of issues and features. I often schedule design or graphic work a sprint or two ahead of when we want development to occur. In this way, the requirements become more fully baked in advance of coding. If design or UX uncovers issues that cannot be solved by the end of the month that's okay. Just reevaluate during sprint review and determine next steps. Usually giving them another sprint provides enough time to figure things out. Another trick is to have developers create a working "wireframe" version of features in the template language. (Think HTML with CSS turned off in your browser.) Then when it's working, hand it off to the designer to make it pretty in the next sprint. Doesn't work for every feature, but small to medium sized ones can benefit from this. This also provides a good way to handle scheduling contention so that the designer doesn't have to handle every issue before developers do. Your milage may vary, but I've have 95%+ success with this technique.

colmvp 14y ago
"Then when it's working, hand it off to the designer to make it pretty in the next sprint." I hate how some engineers think that's the role of a designer. It feels so condescending.
- kevinconroy 14y ago
  I'm a designer and an engineer. There are some pages where the UX is clearly defined, is simple, and it just needs to be pretty. I agree that this is a larger problem in the industry, but I meant no offense.

durzagott 14y ago

While I appreciate the author has tried to take a good stab at the whole big-picture-design problem, this to me looks like a Scrum-but. "We do Scrum, but... every so often we stop doing Scrum and get our design hats on" Perhaps I've been fortunate in the projects I've worked on so far, but we always managed to get the UX designs done one sprint in advance. Sure, things need to be reworked as new discoveries are made. But isn't that the whole idea of iterative development?

mathewsanders 14y ago

I feel the heart of this article is here: For many designers, the process often feels like an effort to design an engine, wheel or windshield without really knowing in what kind of car these parts will need to be integrated. If people are designing in sprints without a clear idea of what they are building then something has gone horribly wrong. I think Agile works best when you have a clear understanding of what you're trying to do. If a design strategy hasn't discovered this in Sprint 0 then I think there will be ongoing problems. Maybe I'm wrong, but I feel that the whole nature of Agile is that at the end of a sprint you've got some self-contained feature working. I don't think their is anything in the agile philosophy saying that what you have in sprint n will continue to exist in spring n+10. Like code you may refactor as more information comes in. As designers we need to accept that when designing in Agile that what we do 2 weeks ago may not exist tomorrow. I think as designers that's a hard thing to do because we don't like 'waste', we want to avoid re-work and we also like to design the best solution with ALL the information we can get, but doing so requires a lot of upfront thinking and is just taking us back to waterfall.