I’ve been facilitating design studios with collocated teams for years. Many, including me, have covered the benefits of collaboratively sketching new ideas and concepts with a cross-functional team. Recently though, I was tasked with bringing this exercise to a distributed team. With the product and user experience team in New York and the development team in Vancouver, it proved to be an interesting challenge. What follows is a play-by-play of how we set up the exercise and executed as well as an analysis of the successes and failures of this first attempt. It’s worth noting that this was the team’s first design studio ever – which added another layer of complexity to the event.
We gave the teams a brief heads up of what was going to happen and asked everyone to come to their individual conference rooms with their own laptops. Each conference room had a Mac in it with a location-specific Skype account (i.e., it wasn’t a specific individual’s account – it was the “office” account). The two offices connected to each other via their office Skype accounts so that we could see each other as a group. This was critical as it was the closest we could get to physically being in the same room.
“Go to the edge of the cliff and jump off. Build your wings on the way down.”
– Fahrenheit 451 author Ray Bradbury
Image courtesy of @fakegrimlock and @ericries blog
It’s a new year. And even though it’s mostly an arbitrary point in time, there’s a distinct you-should-do-something-important-right-now feeling to this time of year. Coincidentally, I’ve been thinking about making some changes for quite some time. As the title of this post alluded to with zero subtlety, I’ve resigned my position as Director of User Experience at TheLadders. I’ve spent a rewarding three and a half years over on Varick St. helping make the job search and placement world a little bit more effective, efficient, easy to use, friendly and hopefully successful for hundreds of thousands of job seekers and employers. In the process I’ve built an amazingly talented team (of whom I’m incredibly proud), integrated UX as a core discipline, built and honed an effective Agile UX methodology and earned a seat at the management table. I’ve learned much during my tenure and the time has come to take those ideas to a broader audience.
A few weeks ago my colleague Michelle Zassenhaus suggested we pitch the executive team on a persona research project. We discussed the need and merit of this project for a while without reaching a clear consensus. Where I was getting stuck was the need for this exercise given how much face time we actually have with our customers. We run usability testing every week. We call customers on an ad hoc basis but it amounts to nearly weekly conversations. The company has an annual focus group initiative and our customer service teams are always vocal with prevalent customer issues. In short, we know our users. So why would we need to create personas?
I posed the question to several folks including Tristan Kromer. Tristan suggested that instead of trying to sell the organization on an expensive project where they weren’t sure what they would be getting for their money and we, the UX team, couldn’t cohesively articulate why we were even doing it, we should introduce the executive team to the concept of personas as a corporate alignment tool. The idea seemed not only viable but also valuable. At the end of that lunch-time chat, I promised Tristan I’d write a blog post recapping the activity and its results. And so, here we are ☺ .
I’m extremely proud (and partially terrified) to announce that I’m writing a book! The book’s topic is Lean User Experience and is tentatively titled, Lean UX: Getting Out of the Deliverables Business. It will be published by O’Reilly (creators of the famed “animal series” of books). While I’m not sure if my book will get an animal or not, I’m vying for either the unicorn or the honey badger .
The book writing process (a brand new experience for me) has begun and my hope is for an early Q2 2012 release date. I’m targeting an audience of designers of all flavors, product managers, software developers and executives trying to fit more efficient, agile design methods into their product creation and design processes. As with all of my writing, the book will provide practical advice and tactics that readers will be able to apply immediately. These tactics will be illustrated with case studies from Lean UX practitioners proving out the methodology in real-world situations. The case study list is shaping up to be an all-star cast of designers, developers and instructors.
I talk a lot about the benefits of practicing a Lean UX approach todesign and software development. I also practice it daily. Through these daily trials and errors I’ve come to trust the process and, in many ways, rely on it. Today, however, Lean UX let me down.
Let me explain. The team I design with was taking on a seemingly innocuous presentation layer redesign for a highly trafficked page on our Recruiter application. We ran through our usual routine of shared understanding of the problem statement, high level sketching, initial code-based mockup and visual design refinement. Daily stand-ups facilitated regular progress updates complemented with ad hoc team-wide conversation. Business as usual.
The Karate Kid was awesome...you know it!
In the Karate Kid (the first one, aka the good one) the seemingly innocuous Mr. Miyagi takes on wayward Daniel-san and teaches him to totally kick-ass in karate. While the movie is a prized trinket of 80’s pop culture, heartwarming and by all measures a classic at this point in time (it came out in 1984!!) there are some terrific lessons to be learned from the way Mr. Miyagi taught Daniel-san how to fight. These lessons translate directly to learning any skill but, for the purposes of this post, I want to apply them to Agile and user experience design.
It's always time to try something new
As the conversation around Lean UX heats up in the blogs, Twitters and conferences a lot of reference is made to the ideas of lean startup promoted by Eric Ries, Steve Blank and others. Many discussions focus on how user experience and design can exist in the highly iterative and test-driven world embodied by that movement and the companies that employ it. Indeed, lean startup thinking along with Agile philosophies served as inspiration for the Lean UX methodologies and practices I and others have promoted. It’s no surprise then that when the conversation is focused on other types of organizations the Lean UX approach meets with skepticism.
This is probably too many in-flight cards to have at any given time.
In the second part of this two-part series on adding game mechanics to Agile (read Part 1) processes, I want to discuss limiting the amount of cards a team has “in flight” at any given time.
By in-flight, I mean cards that are actively being worked on by developers. Limitation is defined as not taking another card from the backlog until there are less cards being actively coded than the limitation. Specifically, consider limiting this number to one less than the number of developers you have on your scrum team. There are several benefits to this technique. Here are three:
Seems like everybody wants to gamify everything these days. Far be it for me to not jump on this bandwagon as well .
When properly harnessed, adding game mechanics to certain processes can make them more fun, engage the team performing them and increase the productivity and quality of output from that team. As we continue to evolve our Agile practices, we’ve experimented with some game mechanics to see what, if anything, is effective in increasing our velocity as well as the quality of our work. In the inaugural post of this series, I’d like to show you how aging your feature cards can help your team focus and unblock itself.
Just a quick note that the audio from my South by Southwest presentation, Lean UX: Getting Out of the Deliverables Business is now available on the SXSW site. The slides are available on Slideshare. I’ll work on melding the two together as time allows.