Re: [agile-usability] Interaction designer Scrum Team and planning poker
- Nick Gassman wrote:
On Fri, 04 Jul 2008 09:08:23 -0700, William Pietri wrote:
http://www.jjg.net/elements/pdf/elements.pdf [...] In situations were you've got somebody that really can handle the whole stack, from thinking about the user needs and the guiding philosophy of the project down to writing the CSS, then they're fully involved in both sets of activities. If they're more inclined to specialize, then you'll see them end up more on one side than the other.
William, I work across the whole stack, but I don't do CSS. I might specify/approve/advise on any element there - in detail - but don't actually produce the materials. I see the model as one that talks about user requirements and design, and not about how they get produced. Are you suggesting differently?
For the purposes of my point above, I don't think it matters. I wrote it that way because some project teams I work with really have one person that does all that, including the CSS.
More broadly, and comparing with my experience producing physical things, I believe that all "production" of software should be automated. The human role is pure design. I see Jesse James Garrett's model as about finer and finer expressions of a design. For many of the designers I work with, the CSS is just the most detailed expression of their design intentions. Production happens when a browser takes their HTML and CSS design specs and produces a screen for the user to interact with.
But practically, not everybody works that way, and for the purposes of Jean Claude's question, I think it my answer would be the same.
Agile approaches normally involve a just-in-time resolution of detail. To the extent that a given designer sees their role as involving the abstract end of things, they will be involved in what in my world we generally call product management. When they work at the concrete end, then they will be closely involved in the minute-to-minute activity of the team, and also involved in providing estimates. Some do both, and are involved in both.
- My assessment is the same -- the best fit for an
Interaction Designer is as part of a SCRUM's Product Owner role. In
that role the designer is better able to direct the project's vision,
both from a business perspective and a user experience perspective.
This also has the advantage of moving much of the designer's work
outside of sprint tasks. Estimating a design's completion can be
quite difficult if testing and validation are to be part of that
design's "done" criteria.
Senior UX Designer
--- In firstname.lastname@example.org, "jcgrosjean" <jcgrosjean@...>
> According to you, what is the best place for the Interaction designer /
> user experience specialist in SCRUM projects?:
> - belonging to the Product Owner team (as Jeff Patton suggests it in a
> recent article :
> - belonging to the Team (as developpers, testers ...)
> I tried the firt and the second solution : advantages and drawbacks in
> both cases. It also impacts the way we do estimation and planning, the
> velocity of the team... A simple example, if he belongs to the team, he
> intervenes and is playing the planning poker; if you consider him as a
> Product owner, he doesn't have to give an estimation during
> the "planning poker" (but provides the team with useful information to
> estimate the UI design).
> Finally are wireframing and storyboarding activities estimated as tasks
> for the team ? and user testing ?
> I tend to believe that the most confortable place for him is with the
> Product Owner.
> If the team clearly adopts agile principles and values, there is no
> And you, how do you organize it in your projects ?
> Jean Claude
> My assessment is the same -- the best fit for anvision,
> Interaction Designer is as part of a SCRUM's Product Owner role. In
> that role the designer is better able to direct the project's
> both from a business perspective and a user experience perspective.I agree with that... to the extent that the designer just doesn't
> This also has the advantage of moving much of the designer's work
> outside of sprint tasks. Estimating a design's completion can be
> quite difficult if testing and validation are to be part of that
> design's "done" criteria.
stay in its ivory tower and keeps a close contact with the ones doing
the dirty coding. This all sounds natural on this group, but surely
needs to be stressed again to lots of Interaction Design folks...
Hence he should really focus on hi-level lo-fi prototypes (to ensure
a balance between design and technical capability and avoid potential
One more pro for the designer being part of the PO team is that he
then is at the core of the value/priorisation process and can focus
on questions such as : What are essential features ? How can we
incrementally build this one feature ? What is the relative
importance of these features ? And most importantly : how does that
translate across Garrett's planes ?