Comments on Agile + User Experience = Parallel work streams

Preston McCauley — Fri, 18 Jul 2008 21:00:52 GMT

THere are a few commentes I wanted to make that stirred some thoughts up in my head. Quick background: I’ve been doing UI design for almost 10 years now here are many things I have experienced.

1. What frequently happens when increasing a team’s literacy in a corporate environment is it’s extremely hard to do.

A smaller company or start-up this is practical and possible. In a larger enviornment I have found this next to impossible. People become extremely territorial. You have to be extremely patient to change the culture.

2. Trying to stay ahead of the sprint / development cycle from a UI perspective is a lot of hard work. This is especially true when non-technical and non-UI people can’t visualize a lower fidelity design – such as a paper prototype. I’ve resorted to hybrid proto-typing methods with interactive PDF’s and notations and physical demonstrations of these.

3. In several companies I have noticed teams of UI designers and a lead UI person to coordinate the overall design vision.

It becomes really hard to do this if you are the Only UI designer. Every design decision becomes increasingly complex and sometimes justifying your designed experience becomes a daily occurence.

4. Your developers not just the Product owners and UI designers must share the same vision. This is easy to say hard to do.

Jon Moore — Wed, 16 Apr 2008 01:44:01 GMT

Well, at the very least I’d suggest throwing those requirements out on a wiki somewhere. If the generic requirements can also be elucidated with examples (and anti-examples!) then that might go a long way towards helping educate. Also don’t forget the “why” on these requirements—this is one of the easiest ways to motivate the requirements but it is often all to easy to leave them off (incidentally, this is why I think user stories which explicitly state the value they are extracting are great).

After that, I’d say it’s probably just a continual process of interacting with team members, and referencing the wiki docs when you do—“teach the team to fish.”

Austin Govella — Tue, 15 Apr 2008 17:11:52 GMT

One of my goals has always been to increase the team’s design literacy. That’s just good practice in any organization with any process. Design literacy enables faster, better, more advanced collaboration, and that’s exactly what an agile process needs.

We’ve divided user tasks on the site into four major groups, and we have a set of ‘generic’ requirements for each. (More like best practices for that kind of task.)

I’ve been struggling with the best way to communicate these requirements to both engineering and design. Any suggestions?

Jon Moore — Sat, 12 Apr 2008 05:32:36 GMT

I think what you’re describing is a skillset bottleneck—not enough “UX” folks to go around. Classic agile solution is to have other members of the team (engineers, designers, product folks) pick up some of the simpler tasks, with UX review/guidance, and let the true UX folks focus on the hard/new stuff. On the engineering side, for example, we have backend engineers do some minor frontend work when our frontend guys are overbooked, allowing them to do all the crazy CSS styling stuff.

Do you think that kind of model would work? I’d imagine after working closely with a set of designers/product folk/engineers they would catch onto your style and tend to come up with an almost-there solution that could be quickly reviewed and tweaked.