It's 2014, and that means big changes - not just for Elon Musk, but for small UX consulting firms too!
To shake things up a bit, Design For Use has recently overhauled our process from a longish-term Waterfall methodology to the very sexy newish Lean design and testing approach. After attending numerous UX conferences and networking meetups, we were inspired by the iterative and revelatory nature of Agile and Lean methodologies - and, of course, the major perk: less time spent on creating those beautiful deliverables.
Armed with guidance from books like Lean UX and Running Lean, as well as a flurry of compelling conference presentations, we were ready to take the Lean world by storm. We knew we would not fail in overhauling our design process and user testing methodology. Lean meant fewer deliverables! More iterations on design! More frequent user testing! More collaboration with stakeholders! Lean UX was going to revolutionize the way we did business and served our clients!
So. Is Lean UX everything we dreamed it would be?
Yes and no, dear reader. Yes and no.
What Is Lean UX?
Before we get into the nuts and bolts of our roller-coaster ride with Lean UX, here's Lean creator Jeff Gothelf's elevator pitch for those of you less familiar:
Lean UX is the practice of bringing the true nature of our work to light faster, with less emphasis on deliverables and greater focus on the actual experience being designed.
Sounds easy enough, right? Here's how it works, in a nutshell:
Basically, we're looking at design in pieces. You design a piece, you prototype it, you get your coworkers' and stakeholders' feedback, you get users' feedback, and then you do it all again - over and over. As Jeff Gothelf said, less paperwork, more experience.
Lean Square One
So here we go. How did we get started? Well, our trusty project manager told us what to do, of course! (Okay and we read all the books and the blogs and the articles.)
Basically, Lean UX projects are comprised of "Sprints" - short design cycles in which you choose a piece of functionality or a set of screens to focus on, you wireframe, you prototype, you test, and you iterate. Lean projects usually have about five to eight Sprints, depending on the nature of the design. But no matter the number of Sprints, the process should be consistent, structured, and siloed.
To bang out a lean project, here's what you should do: Start out with the Project Kickoff, which is a meet-and-greet of sorts. Then move on to Sprint 0, which is the main Research phase of any Lean project. This is comprised of those all-too-important stakeholder interviews (where you get to hear all about your clients' deep dark secrets) and a user profiles exercise (where you figure out who the target users are and what they want).
After that, the serious Sprinting begins. This is what those Sprint cycles should look like:
And, to top it all off, after we get sign-off on Sprint 1 prototype, visual design gets under way in the background...
As you can see, there's a lot going on here. What did we expect? All our dreams to come true. What did we get? Some surprises, some perks, and some room for improvement.
Lean Project Management
As you can probably tell from the previous section, project management had a few hiccups of their own in adapting to the Lean process.
First and foremost, Lean means much more face time with clients and stakeholders - which means lots of planning, lots of meetings, and lots of emails. Bonus? Our rapport with clients is the best it's ever been.
With all the emails and all the meetings, sometimes minor - and not so minor - things had a tendency to get lost in the shuffle. Like email threads with 100+ back-and-forths about prototype tweaks... And formal sign-off at the end of each Sprint before beginning the next Sprint.
Lessons learned here? Well, first of all, establish a feedback process that is more formalized and more structured than your clients sending you gads of emails with bulleted lists of things to change. Try a tool like Notable! It allows collaborative feedback so everyone sees everyone else's comments all in one place - and in the context of the screen/wireframe. Awesome.
Another lesson learned has to do with the formal sign-off from the client after each Sprint. It may seem like everyone's on the same page and sign-off is just an awkward formality - but it's a necessary one. Don't leave room for miscommunication!
Yet another issue we identified with our Lean approach was the tight two-week cycle. Even just one extra day would have saved a lot of designer stress (see Lean Interaction Design below). We planned it so that prototype review fell on a Tuesday and testing of the prototype happened the day after - leaving little to no time for those designers to make any prototype tweaks before getting it in front of users.
We also did a lot of melding of steps in an attempt to get everything squared away - which resulted in lonnnnnng meetings covering all kinds of different steps in the process and pieces of the design. Not ideal. And not Lean. Keep the meetings focused on one step in the Lean cycle.
Learn-as-you-go is really the way to do the project management - and that's exactly what we did! - but that doesn't mean it's always smooth sailing. Luckily, Flexible is our project manager's middle name.
I'm not going to sugarcoat it - the research workload was hit hard. After the initial Sprint 0, in which research plays the main role conducting stakeholder interviews and profile workshops, Sprints 1 through n fall into a routine of not too much research going on.
Each Sprint lasts two weeks, with one day in the middle of the second week devoted to user testing. That means that out of every 10 days, 1 day is devoted to research.
Here's a chat I sent to one of our designers during a testing off-week:
Ummm...Hey, Natal...You need me to design anything for you?
And here's one I sent to our project manager that same week:
Uhhh...Hey, Christine...You need me to Google anything for you?
Don't get me wrong - research doesn't have those other 9 days totally off. Research attends Sprint Planning meetings, wireframe reviews, prototype reviews; we offer feedback and advice when designers or clients ask (and sometimes when they don't); we create test guides and mini-reports of user feedback and behavior.
But the Waterfall approach puts a major emphasis on those deliverables that the Lean process eschews - and those deliverables are the province of the researcher. Data analysis reports, testing protocol, test guides for clients, observer worksheets, a Rainbow Spreadsheet, a lonnnnng testing report delineating findings and recommendations. All of that stuff gets rolled up into a few emails and a few conversations.
Too, the Waterfall approach makes testing sort of a bigger deal. We'd typically spend two weeks preparing for a two-day, ten-participant, in-person test, complete with an outside recruiter, a test protocol, observer guides, a user testing lab, a whole lot of technology, and a bunch of stress. But with Lean, testing ain't no thing. We work with the clients to do the recruiting on our own, we set up maybe three or four remote tests, we take a morning or an afternoon to moderate the tests from our office, and then the designer gets back to work. And we do this every other week, rather than at the end of a long design process.
So which is the better research approach - Lean or Waterfall?
Well, it's hard to say. The Waterfall process allows a lot of time for research and analysis, a deep dive into what users, stakeholders, clients, etc, want. And that time allows for more reflection and more insight on the part of the whole team. Writing things down and organizing thoughts in a structured way (i.e., reporting/deliverables) definitely adds value. But does it add enough value to justify the time it takes?
The Lean process still focuses on the user, still gets at users' motivations and behaviors, but constantly and consistently rather than at the tail end of a long design process. And we still allow ourselves time to debrief and construct ideas and recommendations based on what we see in testing. We have received such valuable feedback and so often that our designs have absolutely benefited from this iterative "guerrilla" testing.
Also, avoiding the hectic two-day, ten-participant, in-person test where some technology or other always malfunctions at the worst possible moment is a major perk. Major.
Is there a happy medium between Lean UX and structured reporting?
Lean Interaction Design
The design workload has taken a huge hit too - but in the opposite direction from research.
Going from Waterfall to Lean for designers was literally the difference between a marathon and a sprint. Runners are trained for one or the other, yeah? And so it is, sort of, with designers. Our designers, at least, had been trained on Waterfall and had been working in that marathon mind-set for dozens of projects. And all of a sudden some of that training got thrown out the proverbial window.
It hasn’t been as dramatic as all that, really, but it has certainly required some adjustments on the part of the designers. Rather than working through a full deck of wireframes and prototypes with stakeholders and coworkers over a six-week cycle, the designers had to switch gears and work through tiny pieces of a full deck with stakeholders, coworkers, and real users, and all over a two-week cycle.
It isn’t just a matter of breaking down the component parts of a site or system and methodically going through and designing piece by piece; it requires a ton more up-front strategizing and brainstorming, on the part of both the designer and the stakeholders. We ask a lot of both parties – think big but design small – and inevitably, that up-front collaboration forgets key pieces of the design that will need to be worked in later, typically in the middle of a sprint, or the morning before user testing…
The Sprints themselves are so fast-paced and high-energy (it’s not just a clever name) that sometimes it’s hard to remember where we are in a cycle – especially for the designers, because they get so wrapped up in brainstorming, wireframing, and prototyping that they forget to come up for air.
Here’s an excerpt from one of our daily team huddles during our second Lean sprint ever:
Natalia (designer): So, I’m working on finishing up the prototype for testing so we can have everything ready to go tomorrow at 9.
Christine (project manager): Great.
[a beat passes]
Christine: Wait. What? Today’s Wednesday. Testing isn’t until Friday.
[another beat passes]
Natalia [heaving a relieved sigh]: Oh! It’s not Thursday? Oh, good. I was planning to be up all night.
So what’s the up side? Well…yeah, it’s super fast, and yeah, sometimes we have to make allowances for the design components that get overlooked…But at the end of the day, we’re testing early and often, and that makes our designs stronger and better and focused on the user.
Lean Visual Design
As alluded to earlier, visual design was happening sort of in the background after Sprint 1 was squared away. And...let's face it: If something is "going on in the background," that's probably not the best.
So visual design on Sprint 1 started when Sprint 2 began - which is a problem in and of itself. Because visual design wasn't worked into each Sprint, and instead carried on in the background, it didn't feel like part of the process. We needed a more formalized approach and a stronger tie from visual design to each Sprint.
The other major issue we uncovered - which is considerably less easy to fix - was dealing with major prototype changes between Sprints. If during Sprint 4, the researchers and interaction designers decided to dramatically change the direction of a section of the prototype from Sprint 1, visual design essentially had to start over from square one - and the designers, understandably, were not overly pleased with that approach.
In Waterfall, we wait until we have sign-off from the client and often until after we've tested the prototype with real users before getting started on visual design. In Lean, that's not really an option. The solution? Well, we're not quite sure. But we'll keep working on it.
Wiping the Slate Lean
So...all in all, what's our Lean consensus? It's taken some maneuvering of expectations and re-jiggering of processes, but hey - we're in the business of iteration, right? We start out every project knowing that the first go-round isn't going to look anything like the finished product...so why should it be any different with introducing a new system for us? We'll just keep iterating on our Lean approach, and we'll get there...
...And then someone will design a brand-new luxury process and we'll start all over again. Yeah!