
Fitting Big-Picture UX Into Agile Development - dilipray
http://uxdesign.smashingmagazine.com/2012/11/06/design-spikes-fit-big-picture-ux-agile-development/
======
kevinconroy
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
"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
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.

------
mathewsanders
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.

------
durzagott
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?

