Agile and UI design
Join the DZone community and get the full member experience.
Join For FreeA
few days ago, one of my Twitter buddies asked me to explain how the UI
designers fit in on an agile team. I have some experience working with
dedicated design teams and user experience folks so I thought I'd take
a stab at his question and share my perspective. Once I finished my
note it seemed like it might make a good blog post. I'd be interested
to hear what you guys think about my answer.
Here goes...
Just
to set a little context... my friend asked me to explain the role of
the UI designer on an agile team. He explained that they were creating
user stories but were not sure how to incorporate the UI designers into
the process.
The unfortunate thing about explaining agile is
that there is no one right way of doing things. There are principles
that I like to see teams apply. Agile is all about creating
situationally specific strategies. You just take the principles of
agile and apply them the best you can given your constraints.
That
said.. my friend seemed to be on the right track. They were creating
stories with using a typical agile patterns... "As a user, I want to be
able to create a new account, so that I can do X". The principle that I
encouraged him to apply is that the story is small enough to be done in
a single sprint, all disciplines are involved in implementing the
feature (including the UI guys) and at the end of the sprint, it is
potentially shippable... in other words, done.
What would that
ideal look like in real life? During the sprint planning meeting, the
team would collaborate around a whiteboard on what it means to be able
to create a new account. The developer might talk about what methods
might need to be created. The QA engineer would discuss how it would be
tested. The UI designer would be involved helping the team understand
what the screen would look like. The product owner would weigh in on
the business value and keep the implementation discussions in check.
At
the end of the discussion everyone is on the same page about how the
feature will be built. Since everyone is on the same page, the UI
person can go off and start iteratively working on a mockup (if
necessary), the developer goes off and does code, maybe the QA person
goes off and starts test planning. If the team is pushing new code up
every day, continuous integration in other words, everyone gets to see
the evolving product and respond to it.
Just like the code evolves, the doc evolves, the plan evolves, the product evolves.
The
typical response from dedicated designers and QA people is that they
want to be able to do the work once and for all. Operating in this way
feels like waste. I encouraged my friend to keep in mind agile
principles like barely sufficient documentation, simplicity of design,
deferring decisions to the last responsible moment, and constant
refactoring... The key is to keep the focus on working product and off
comprehensive documentation.
Just like the dev team will refactor often, the supporting team members may have to refactor as well.
But
what if everyone is not in the same room, on the same team, maybe not
even in the same company (external customer)? You apply the same
principles and adapt them to your environment. I have seen teams do
just enough UI design in the previous sprint to keep the dev team
moving in the subsequent sprint.... This makes things more complicated
and creates more dependencies than an pure agile approach.
When
teams take this approach, I liken it to the product owner grooming the
backlog and specifying requirements in advance. The UI mockup becomes
like a requirement to the dev team.
As a team you just have to
decide how much time and energy you want to invest in up front design.
You can do agile practices with an up front design, it just causes you
to do even more rework if you want to change anything. It really
depends on the uncertainty of your market. If things are prone to
change, invest less up front. If things are stable, you can invest more.
Originally posted on Leading Agile
Opinions expressed by DZone contributors are their own.
Comments