Last week, just after presenting our section on “UX” to the people in the “Agile Training” class, I received the Urban Dictionary Word of the Day . Groan! Yeah… I used the tired metaphor to explain what Mark and I do as the only two “UX” people here — each of us supporting a number of agile teams and projects.
Here is who I told them we are when we wear our different hats:
The User Researcher is the person who uncovers insights about users and their tasks. We observe, listen, and learn.
The Interaction Designer is the person who is the discipline of defining the behavior of products and systems that a user can interact with.
The “Usability” person is the person who makes sure the product is usable — a term used to denote the ease with which people can employ a particular tool or other human-made object in order to achieve a particular goal.
We went on to explain that there are multiple UX methods and deliverables that we use to help the team Understand, Solve and Evaluate components of the end user’s experience with a product.
In old-school agency days back in 1999, we had a long, drawn out water-fall process where User Research understood and communicated the user goals, their personas, what’s important to them, and how they do stuff. The IxD and/or Information Architects solved the problem of how that experience is manifested in the User Interface. Then hopefully someone would validate usability at the end of the project just before launch.
In the agile process, we do all of those things too — but at the story, iteration and release level with the software developers. We no longer go off into our caves and write a huge usability manifest that we hand off to designers and developers. Our tests don’t take a month to plan, execute, and report out on. We don’t draw coffee-table books of wireframes that are out of date by the time the project launches.
Chris Nodder and Jakob Neilsen provide a diagram in their paper: “Agile Usability: Best Practices for User Experience on Agile Development Projects” that shows how UX work can and should have impact thought the development cycle:
On our team, we interact with both the business (customer) representatives and the development team. As such, we think of ourselves as bridges. Early involvement in a project helps us to guide the team in thinking about the right users and their important tasks. In our case, we can clear up assumptions development makes about how the customers are currently doing their jobs with an existing product.
We do our up-front understanding work in iteration 0 or before. This consists of site visits, interviews, truck driver ride-alongs and such activities. Throughout all the iterations we help to solve problems from the user perspective and validate that the solutions are usable. Below is a sketch I drew with a few team members to explain what we do during our iterations.
As we get started in an iteration planning meeting, we help the the team better understand how stories link together into user goals. We might draw user flows that link several stories together during this time. UX also owns the wireframes. A low fidelity set of screen states that can be linked together as a prototype lets us walk through what we are building during the sprint. These along with the narratives become the specification for the developers.
During this time, UX is busy testing these prototypes via RITE sessions with folks who have agreed to be part of the “revolving door team.” These people are second tier support — so they are already aware of user issues.
Because I am working on the mobile device team, we have a set of technical hurdles to overcome to get to a prototype on the device. Testing click through screens on a desktop before integration lets us get at many of the problems with the interaction model before the solution is coded. This happens several times during an iteration. When we get results, we put on the IxD hat again and work with the BA and developers to tweak the interaction design..
When we have a build deployed on our device development environment, we can take it out to the field and test with users. This usually happens once during an iteration — just before QA.
Finally, before a release, we do more formal usability testing before deployment. Generally here we are focused on consistency and standards between features and functions. I will write more about these test sessions in the future — for now, I am off to an iteration planning session!