be blamed for following a waterfall
model (Oh, the shame!), we’re moving
toward doing lots of the UX design
up front. Our “Sprint 0” is going to be
at least six weeks so we can do some
research, overall UI framework for the
application, development of personas
and stories (we’ll be writing Epics
with the team), task modeling (our
application has many complex and fairly
long task flows), and creating assets for
the Dev team.
I think this is what you mean by
“rough design.” We just call it “getting
ready for the build” by getting all our
ducks in a row. To reference another
industrial process, I liken it to the
work that an architect does before a
house is built.
One last observation from my
experience is simply that UX work
often takes longer than Dev work. That
is to say that if we were to decide how
many stories to build in a given sprint
by the “UX points” count, our sprints
would contain far fewer stories. Again,
this may be a question of resources and
could be specific to my experiences.
Maybe that question of how many
UX folks you need to keep up with X
points of Dev work during a sprint is
one that deserves investigation. Thanks
again for your insightful article.
This is a very well-written article.
Thank you for citing the research!
My current team is preparing to
build an enterprise set of personas
to guide widespread development
that you specifically warn against
in your “collaboration” section. My
last project purposefully included
developers in persona development, as
you recommend. We won’t have that
luxury with my current project. We are
targeting Agile teams as the primary
users of these personas.
Does anyone have experience
developing enterprise personas and can
you specifically address how to mitigate
the “collaboration” risks identified
in this article?
I really like this thinking, but I’m
struggling to get my head around the
practical differences between “user
Don’t Help Users:
By William Hudson
November – December 2013,
Your article offers lots of food for
thought in this short piece. The biggest
problem I see with much of this “UX
practices squeezed into Lean/Agile
build methodologies” is simply that they
don’t have the same purposes or goals.
User stories are just one example and a
good one to call out. I really appreciate
your focus on minimal personas. Those
multi-page fawning biographical
sketches often contain little that is
useful for guiding development but lots
of evidence that your UX team is made
of frustrated novelists.
The personas and the user stories
(or persona stories, a construct I agree
with) are relatively easy for our team to
fix. More challenging is the integration
with the Agile process. I’ve worked
on a number of Agile projects and
tried a number of different integration
methods. Trying to stay one or two
sprints ahead of the Dev team always
seems to turn into a frantic race to keep
up. I’m thinking lack of resources has
been the reason for this. Perhaps we
could do it with a larger UX team.
Despite the Agile constraint of
“no big design” and the fact you will
stories” and “persona stories.” Some
more examples of implementation
would be really useful, contrasting the
user and persona versions.
However, if we do nothing other than
revise a user story using a persona name
and simplify the language by using
the third person, I think that’s a real
improvement, integrating personas into
the process and promoting empathy
with the purpose of the story.
and the Future
By Mikael Wiberg
March – April 2014
The 3D text used in the article is
pretty ugly—not up to the usual new
standards of design in Interactions.
And while we are on the topic, take
a look at the upper left corner of the
website for my university, www.vt.edu.
Thanks for implicit plug—”Invent the
Future” is a registered U. S. trademark
of Virginia Polytechnic Institute &
State University, otherwise known as
Positivism in Design
→ http://interactions.acm.org/ blog/view/
There is always something positive in an
idea or a design. Sometimes something
might be way off brief but even then it
will still have some sort of merit.
I have found it’s dangerous to stomp
on creativity. Creatives and designers
will pull their head in and learn what an
organization likes and stay within those
confines to avoid being stomped on.
I really appreciate
your focus on
contain little that
is useful for
but lots of evidence
that your UX team
is made of frustrated
JULY–AUGUST 2014 INTERACTIONS 7 INTERACTIONS.ACM.ORG