The Evolution of UX

usage_ux_process_methodolgy

Ian Armstrong has put together a fantastic article here called The Evolution of UX Process Methodology. I could try to paraphrase, but it’s too good, so I’m not even going to try. Check out Ian’s article. I will add a few of my own points based on my reading of the article, but a full read is a must.

Ian states that “in its purest form, UX Design is waterfall based.” These days, in most circles where folks are talking about UX, ‘waterfall’ is a dirty word that hearkens back to rigid PMBOK processes and exhaustingly long requirements gathering sessions, but Ian’s absolutely right. You have to get a sense of requirements, gather perspectives, mock things up, test out assumptions, wash, rinse, repeat. It’s waterfall. There’s no way around it.

Ian nails one of the key problems with being outcome based, what we work towards with agile vs. requirements based. This is a conundrum that many of have faced and still work to reconcile:  “Whereas classic UX is requirements based, Lean UX is outcome based… Designers found themselves under immense pressure to fill a sprint backlog before they really understood what they were building. As a result, a lot of development cycles got burned on features that never made it into the final product.”

So much development and rework lost trying to anticipate product needs… <sigh>

I’ve read a lot about Google Ventures Design Sprint, and attended a session at an O’Reilly Design conference where they talked about it, but even then, Ian’s explanation is as succinct and spot-on as any I’ve come across:

“Google Ventures conceived the design sprint, which allowed teams to rapidly define and test a low-fidelity prototypes. This jump-started the Lean UX cycle on emerging product teams and effectively eliminated the waste and rework problem.”

I’ll put a pin it there. Check out Ian’s original article.

Lean UX and agile – The one-two punch to quickly knock out great work!

usage_lean_ux_agile_diagram

It’s probably because it’s something I do everyday. I don’t think much about it. Or, maybe, I don’t want to think much about it, because day in, day out, it’s where my focus is. However, I do think that it’s supremely important… I’m talking about integrating UX into agile.

One day I’ll probably write a book about it. I love giving practical advice and sharing my experiences, in fact, that’s one of things about agile that I really love, the community-based, open source aspect of the community around agile. Whether you’re looking at scrum, kanban, scrumban, or something else, agile is a great way of working with your development team and it’s also excellently positioned to take advantage of UX practices.

Specifically, (WARNING: Much jargon ahead) I’m a fan of Lean UX, say, as opposed to, agile UX, which honestly, it looks like it is falling out of favor for some of the reasons that the Nielsen/Norman group captured here in their article Doing UX in an agile world, specifically:

…most teams don’t conduct user research on a consistent basis, if at all. People cite tight deadlines and staffing shortages as reasons for deficiencies in user-centered activities.

Research and user testing are two areas that are very difficult to integrate into agile UX. Lean UX, on the other hand, considers this, and in some ways is really an agile UX 2.0. This is important, because the need for that research and testing to happen in real time is super important to the ongoing design and development process. Unlike a waterfall approach, there usually haven’t been requirements or JAD (joint application design) meetings; instead, you start with a basic road map, some use-cases, a couple user stories and get to work. Lean UX thrives in this situation.

Ok, I say, Lean UX thrives… yes, that’s true, BUT… teams have to get used to working with one another and they have to round off the rough edges and bad habits, whether of the development or the interpersonal variety. Lean UX and agile don’t leave a lot of margin for getting mired in unnecessary details and some of the interpersonal issues that may pop up when a team is just getting started. Nevertheless, when it comes together, and when the gelling starts, the team’s pace and work can be exceptional!

I find Lean UX or the idea of UX that can work at the speed of agile to be very exciting, especially if you’ve ever been involved in a waterfall development project or something that was just slow moving. Lean UX and agile are the one-two punch to quickly knock out great work!