- Four, I held on to your post here to give some thought. Would you mind providing some tangible examples of what you d recommend as an effective way to developMessage 1 of 7 , Apr 17, 2008View SourceFour,
I held on to your post here to give some thought. Would you mind providing some tangible examples of what you'd recommend as an effective way to develop designs in discovery? Are you suggesting to invest effort towards comping several refined iterations? During a phase as malleable as Discovery, what else could possibly afford the ease of updating, adjusting, and flexibility? I'd consider wires much less deterministic and more suggestive until final round, no?
Lastly, are we comparing apples to apples here? My assumption is that we're discussing large sized applications and content/interaction intensive sites.
Four Hewes, Caspian Design wrote:
I would consider dropping wireframes as an effective way to develop
designs. I see many designers get hung up in Agile when they bring
their legacy of design development products (wireframes, flow charts,
etc.) to iterative/increment al development.
Wireframe documents initially developed in a slow-paced design
process as a defining and refining step from concept to
implementation. As you know Agile/XP/Scrum defines and refines
in-the-doing, utilizing feedback instead of the determinism inherent
in wireframes ("I drew this after we thought up this and now we will
code what I drew") .
While wireframes and similar artifacts have legitimate, inherent
value in some design discovery processes, their nature (slow to make
and abstracted) is at odds with Agile's build-to-evolve- for-fitness
fundamentals. I have concluded that wireframes and their ilk are too
tightly tied to linear development to be worth the cost of
retrofitting them for agile - with one significant exception: as
quickly made and quickly used artifacts of conversational design
exploration, typically as hand-drawn sketches.
I hope these comments help you to find an approach to evolutionary
design that fully integrates with the rest of your team's work.
Four Hewes, Principal
Caspian Design | A Hybrid Consultancy for changing marketplace,
technology and business
Strategic Guidance | New Product Development | Design Services
== brett.christenson wrote:
I have read that other UX teams try to keep one cycle ahead of
development but I still do not understand how this fits into the
Scrum process. When are wireframes and other cycle 0 design
deliverables done when the backlog can change from sprint to sprint?
At 10:38 AM -0700 3/28/08, William Pietri wrote:
I'm more of an XP guy than a Scrum guy, but let me tell you what my
best teams do.
There's a longer answer, which I'd be glad to give when I have a
little more time. But the short answer is that I see a progressive
refinement of the plan with just-in-time delivery of required
information. Working backwards and totally making up the iteration
numbers, here's an idealized history of a feature over one-week
iteration 7: we build X
end of iteration 6: we commit to building X
iteration 6: we make a detailed estimate for X
iteration 4: we select X as something we'll do soon
iteration 3: we make a rough estimate of X
iteration 3: in prioritizing, we notice that X might fill a business need
iteration 2: someone has an idea for X
Now it's important to note that all of this could happen in a week or
two. If somebody has an idea that everybody agrees is more important
than whatever we had been planning, then something can go in right
away. But typically what I see is a gradual, collaborative refinement
of an idea, from vague notion to detailed implementation.
It's also vital to realize that although every completed story starts
with an idea that gets jotted down on a card, the reverse isn't true.
A detailed plan for a feature is an expense only worth paying if
we're sure we're going to do it. And even a rough plan is only worth
doing if it helps us decide whether to do the detailed work. Many
very good ideas stay only as cards in the backlog that we never quite
get to. My good teams focus on making decisions at the last
responsible moment and doing the smallest responsible amount of work
compatible with good results.
Typically, I will see a designer spend a fair bit of time working
with (and often pairing with) developers to implement their stories.
Another chunk of their time is with the product managers to help
flesh out what an upcoming story might mean in practice. And
designers, developers, and product mangers all will participate in
estimation sessions, iteration planning meetings, and retrospectives.
Those estimation and planning meetings will drive a lot of the