UX and Agile

There has recently been a lot of discussion in the UX field about Agile and how we can integrate our work into the process.

Here are some interesting discussions:
Agile & UX on IxDA List
Leah Buley’s post on Burndowns and Flareups in Agile

In my experience working in an Agile environment at THE_GROOP, I feel like Agile can work, but it ultimately depends on your constraints – clients, time, and resources.

What Works:

• Having a Sprint 0 for UX strategy/research before design and development. This is the time for ideation, sketching, and research. This strategy phase is vital to providing the ground work for the rest of the project.
• Writing out the tasks that need to be completed per sprint, and including iteration as one of the tasks. This allows the designer to get both a broad view and detailed view of the project. It is incredibly helpful to lay out all the tasks that need to be done in a concrete way. By going through this activity (however painful and tedious), it forces you to see what you *don’t know* upfront and then plan accordingly. This is also a good time to talk to other stakeholders and figure out how much documentation is necessary. If the developers don’t want an annotated wireframe, then don’t build it into the schedule.
• If you do the Sprint scheduling with other stakeholders like visual designers and developers, it is really easy to coordinate activities, find out where we can all work in parallel, and also surface the dependencies.
• Burning down at the end of each day feels great (for UX as well!) You also quickly learn how long it actually takes you to do things, so that you can estimate better on the next sprint.

What Doesn’t Work:

• Clients often want to see progress each day/week. Once they see initial design ideas, they have a difficult time letting go (no matter how rough the sketch). This makes it VERY difficult to iterate, or “throw away” designs.
• Aside from clients, time constraints often also restrict design iteration. Unlike code, which could potentially be thrown away and written in any number of ways to do the same thing (with most clients non-the- wiser), design is much more “sticky” because it is so visual. Once you start on a path, you are pretty much forced to continue going down that road. It is almost impossible to completely throw out a design that “just didn’t work” and start from scratch. This is especially true since developers and designers are dependent on the UX work to move forward, so once the ball is rolling, its hard to stop.
• There is practically no time for user research/testing after Sprint 0. You basically have to fit it in guerrilla style (after work or during lunch utilizing fellow co-workers), which doesn’t give you great results or confidence

In general, the visibility of UX work makes it very difficult to generate new ideas, conduct proper testing, and iterate on designs. However, it does force the designer to plan ahead, and get to know themselves a bit better. I do believe agile can work for UX, but perhaps a modified version that takes some of the problems into account.

I am still going to be thinking and developing my ideas about this topic as time goes on, but these are my initial impressions. Will be interesting to see how things change over time!

Filed under: Design, UX , agile, UX

Experience Matters: An Airline Example

I just came back from a trip to Atlanta, and I flew Delta because they are the cheapest to that destination given that Atlanta is their hub. I thought it was really apropos when I read this blog post by Peter Merholz today that specifically talked about the airline industry, where he stated that “Customer experience refers to the totality of experience a customer has with a business, across all channels and touchpoints.”

I chose to fly Delta because of cost, but I looked at the routes that Soutwest, JetBlue, and Virgin flew before looking on Delta because I was willing to pay more for the better customer experience. Unfortunately, none of those airlines went to my destination, so I was forced to pay $15 for one bag, $8 for a sandwich, and $2 for headphones for the pleasure of watching a tiny screen in the middle of the aisle which kind of hurt my neck to look at after a while. I was REALLY unhappy about having to pay for my one bag given that I can’t get threw security with a little bag anymore because of all the liquid restrictions. I hate being nickle and dimed, and I don’t believe the price is even justified anymore given that gas prices have dropped significantly. I guess I would sum up by saying that my experience at all the touchpoints as horrible, and I hope that someone over there reads Peters article.

Filed under: Thoughts, UX , airline, experience

Thinking About Sketching and Personas

I recently attended a UX book club in Los Angeles. As part of the worldwide UX book club movement, we read Bill Buxton’s “Sketching User Experiences”. About 20 people showed up for the discussion, which made it really interactive and great. There was certainly discussion about the book itself, with the main insight (for me) coming from the understanding that sketching is like having a conversation, the conversation is the most important part, not the final product. Sketching is a way to think through a problem by utilizing different mental processes, so the final sketch does not matter, rather the insights that you gained from the *act* of sketching does. This makes a lot of sense to my academic side, because discussions were always a big way to surface the questions and inconsistencies I didn’t know existed. I have certainly participated in a lot of class discussions where the act of talking about something truly helped me “get it”, whereas reading the same thing in textbook would never have given me that “ah ha!” moment.

Aside from the sketching takeaway, something that really struck me in our book club conversation revolved around the purpose of personas. I am not sure how we got around to talking about personas (I think I brought it up!), but one seriously insightful individual said the following (I want to call if out for emphasis):

Personas are a way to enable a shared reality with your team

Take a minute to absorb that… Personas are a communication tool for a shared reality. Their purpose is to enable everyone to empathize with your persona and understand them on some level, with the hope that everyone has a similar enough understanding that we are all working towards the same goal.

My biggest beef with personas coming to the meeting was that there was very little buy-in, but how can there be buy-in when I created the personas in a vacuum and then presented them to the team? The team has no stake in the persona, it is just another piece of paper to them. They didn’t invest the time to observe, digest, analyze and write-up the data. They can’t see through the personas eyes as I do, because they have not breathed and lived it like I have. In my experience, the team often takes on look at it and then forgets about it. Which brings me to the question – can a persona adequately communicate a shared reality if the rest of the team was not invovled in its creation?

I am coming to realize that this is not possible, and that the entire team needs to be involved in persona creation (which includes data collection). Then the persona needs to be created as a team (nice whiteboard exercise there!), so that everyone already shares the reality before the formal document is created, and the document is just there as a nice reminder – a solidified form of our shared reality if you will.

Bringing this entire conversation full circle, it seems to me that the *act* of persona creation is the important aspect here, because creating the persona is how one achieves the shared reality with the team, the actual artifact is less significant.

Filed under: UX , personas, sketching, UX