The earliest process I knew as a designer was no process at all. That was my job at the Racing Form where in addition to managing the company news site we ran a Web hosting service for a dozen race tracks and bettor’s information services spread out across the country. We built each site by hand. I did the UI design and client-side coding and two other talented guys did the back-end stuff.
It sounds waterfall-ish but we kept the documentation light and put an emphasis on small teams working closely together, so it worked. I remember the “Process and You” training session they had us attend to this day. It was based on an old-time elementary school theme and they handed out three ring binders and cardboard pencil boxes to everyone. I think we even got Bazooka Joe bubblegum.
We did the waterfall pretty much full-on at my next job after that. I wrote 100-page Functional Specs like they were going out of style … and then they did.
Now everything’s Agile. Scrum. Kanbaan. DaD. I’ve done all of those and in each instance I’ve watched the teams struggle at the beginning to get things right. The people who kept an open mind and were willing to learn mastered things soon enough. But the dinosaurs (as they came to be known around the office) who wouldn’t inspect and adapt were serious obstacles and prevented some teams from gelling at all.
But what about UX? I was in a Director, UX position when we first attempted Scrum. I read some case studies. There was one at Yahoo that stands out. And something at Ericsson. I knew it could be done in spite of what I heard from some nay-sayers in the industry.
To me, it boiled down to this:
And Scrum (like all of the other Agile methodologies I was reading about at the time) came with a BUILT-IN customer focus!
At least in theory.
What we, the UX group, found on our Scrum projects was that the teams would often gloss right over the customer part of the process and jump straight into building something, which was usually whatever the Alpha dog engineer wanted to do or what the Product Manager told them to do. UX wasn’t consulted until the end and UX weren’t even members of the sprint team back then, so they had no visibility. When we were called in it was usually to “have a look at the UI.”
This was not good for two reasons:
- This put us in the age old position of having to explain that UX ≠ UI; something that Eric Flowers addressed brilliantly in what’s become a semi-famous write up in UX circles.
- Something that I was quoted on in UX Magazine came blasting out of my mouth when encountering this situation: “The same thing can be said about UX that is said about QA: You can’t just add it in at the end!”
An interesting thing happened as the UX team worked on changing this equation: 4/5ths of the team ended up become Product Owners on their Sprint Teams. That’s amazing, isn’t it? In many cases, it was a majority of sprint team members who basically elected the UX Analyst to take on the PO role. They wanted them involved. But what happened was our ability to do real UX work – to interview customers and analyze competitors and test things with users – was greatly diminished. The Analysts-turned-POs were too busy with their PO work in the sprint.
Ironically, I found myself promoted to VP, UX around this time and yet I was looking at a team that had pretty much no capacity to do the UX work that I was hired on to do. My plan was to change the org chart and add a specific UCD research branch, like this:
But that never came to fruition. To this day, I still have half the team entrenched in the Product Owner role and another half doing the UX Analyst work. I think that’s okay … But I’m still pondering what this all means.
So in the end (it feels like it’s time to wrap on this subject), here’s what I have to say about designing in an Agile world:
- The built-in customer focus is an advantage, but you must get everyone on-board to REALLY follow through on this commitment and resist the urge to go straight into building something without ever talking to a customer.
- I still think that the UX analyst belongs on the sprint team as a team member and that they can only do their best work when mixing it up with others real time and in person vs. testing something after the fact.
- What’s worked for us is to do our UX homework up front regardless of whether or not the time is given on the project, which includes demanding to meet with customers or customer proxies and to enter the Agile workflow with a CLEAR AND CONCISE understanding of what = success from a user perspective.
Let me crib a recent example from a team member. This is what Fred Hall, Sr. UX Design Analyst, put together at the onset of his project. I had a pretty big hand in this as well, and I’m proud of the outcome.
[Link to PDF to be added later.]
What I kept preaching to the team around the time this was created is that it’s their responsibility to develop an intimate understanding of what = good design on the project. And they have to back that up with research that includes customer / market feedback. And finally, I told them it’s their job to present this to the other Sprint team members and to make it visible so everyone knows it and can keep their eye on the prize.
For Fred, it came down to this one slide:
This slide made it into the stakeholder presentations at the beginning of the project. It was also used as a point of reference for the team to keep pointing back to along the way. Everything they did traced back to accomplishing these three things. The customer focus was crystal clear.
And that, to me, is the first major responsibility UX has when designing in an Agile world.
(More on this topic to come.)