Usability, IXD and Research are all componants of what we generically refer to as "UX" in my job.  I like to explain that we "solve user problems", "understand user goals and the way then work", and "validate that the interface is easy to use or at least easy to learn to use".

Agile UX Hat Switching…..

Uban Dictionary Def 10/22/09

Urban Dictionary Def 10/22/09

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.

UX - Venn

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:

NNG

Neilsen Norman Group, to purchase a copy of the report, download from: http://www.nngroup.com/reports/agile

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.

Sketch of UX activities during an iteration.

This sketch shows UX activities during 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!

no home button

UX Design in the Agile Stories

I was hired at Intel some years ago on a contract BA position, I wrote endless requirements documents and drew use cases and swim lanes. it was very helpful to see an entire system put together on paper — but it took forever. As the UX/IA for an Interactive Design Agency back in the late 90s, I remember drawing and working with the IA to draw very detailed wire frames of an application for a web-based freight forwarding system we were building for an airline. It was an 11X17 book with 200 pages. At the end of the project, the client insisted that we go back in and update all the drawings to match the application.

I still kind of hate MS Visio.

What I love about Agile: We jump right in and start doing stuff. A strong UX team member on an Agile project can add tons of value — while working in the Agile framework.

It takes work.  Let’s face it:  Agile is a method designed by developers, for developers dude.  Interaction design and usability can be easily overlooked and left to happen as a side-effect of the coding.    Even though I shudder when I say it, it is perfectly feasible for developers to do interaction design and usability — joking– some of my best friends are developers.

I believe that for interaction design and usability to be taken seriously — and even RECOGNIZED by program managers in many cases, activities and deliverables must be assigned story points on equal footing with the coding. This is not always easy to sell to a team.

UX activities need to be recognized as explicit components of the methodology .    We haven’t really figured out how to do it as a team yet. As you know, with Agile, the development of a product is broken down into smaller parts that are completed one at a time. This works really well for programming functional components, but is tricky when it comes to designing an integrated user experience.

What we really want is a product where different features work consistently and help users build a coherent conceptual model of the system. With 6 developers each working on different stories — that first build can look like a scary mash-up patchwork of craziness. (We don’t have UI designers at my company — developers do the design individually as they attack a story.)

The opportunity that this situation has presented to me, as the first UX person to be integrated into the team, has been to take it one step at a time. Working with the BA who has been here a long time and knows the users and system really well, we’ve decided to draw sketches that embed the UI protoype into the story. In Mingle we do this by creating a wiki that holds details on our story cards in the form of sketches.

wiki

Here is where we link to Wiki Pages that have links to prototype sketches done in Balsamiq

The BA — who is a developer with a mad design streak — draws awesome sketches using Balsamiq, a tool I turned him onto when I got here. Once they are posted in Mingle, I do a review and post my notes as you can see in this picture.

This is a prototype associated with a story.  We use Balsamiq to do quick and dirty mock ups.

This is a prototype associated with a story. We use Balsamiq to do quick and dirty mockups.

After he gets the notes, we tweak the screens a little, and then take them to the developers during a story review. That’s where they tell us if we are crazy and how many points its going to take to make that thing.

The next thing we do is show these prototypes to the business owner during story sign-off. One thing that we’ve done that makes the process a bit easier, is to use the click through feature in Balsamiq so that we can show the “Customer” how we’ve interpreted what they’ve told us they want.

At this point, I can do some guerrilla UX testing by putting together several stories into one that is a complete user story.   We have a team of second tier support folks who are on the revolving door calendar. Thursday is test day. Everyone on the team knows this. We’ve worked into a nice rhythm there that I will talk about at another time. Right now, however, I have to get out to the loading docks!

Call Me "MacGyver"

Call Me "MacGyver"

I’ve been looking for a good way to unobtrusively video people using the mobile device while they are in my “lab” — any conference room I can grab.   I still haven’t come up with a sexy way to keep from hovering over users with a camera when I am out on the docks,  but I am proud of this rig I came up with.   What you see in this image LOOKS like an ordinary goose-neck desk lamp, but is actually a stealth camera.
I got the idea from Kelly Goto’s site, and made some tweaks using an old Logitech notebook camera I had in a box somewhere.  The cool thing is that I am a little compulsive about saving packaging, so I had the plastic shrink wrap cover to use as a holder for the lamp screws.  NB:  Put the camera on upside down.  That way when the jig is swiveled over, the device is recorded upright.


Lately I have been using Camtasia Studio 6 on my teeny little HP Mini running XP for a super portable testing rig.  I can set this up in a conference room in about 10 minutes. It has been very agile….

The best part about this setup is that I don’t have to hover over the test participant with my video camera. We can sit and have a conversation, and they don’t even notice the camera recording what they are doing. The main thing that needs to be improved is the quality of the video.  I wish I had a better camera; this one is OLD and slow — but it fit perfectly into the desk lamp I confiscated from my husband.See for yourself in this video clip from a recent session.  I am not going to lie — this is 14 minutes long report out — barely edited and super geeky.  Not for the easily bored — but if you watch a minute or two, you will get the idea. NB: Click on the picture to go to the Vimeo movie.

Vimeo Movie of UX Session on Handheld

Vimeo Movie of UX Session on Handheld

Mobile Device UX Session from Julie Booth on Vimeo.