By William Hudson
November – December 2013, DOI: 10.1145/2517668
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 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 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.
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 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.
By Mikael Wiberg
March – April 2014, DOI: 10.1145/2566676
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 Virginia Tech.
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.
©2014 ACM 1072-5220/14/07 $15.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2014 ACM, Inc.