Remote collaborative brainstorming and sketching – Part I

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.

We prepared a very brief (~10 slides) setup presentation that explained the problem statement we were going to try and solve, customer testimonials and data illustrating that this problem was indeed real, the constraints of the solution space and a very brief recap of our customers’ needs. All of this went over very well and the teams understood the material clearly given their existing subject matter expertise.

 

Priming the pump with affinity mapping

Since this was their first collaborative sketching session, we didn’t want to jump right into drawing. To prime their creative pump, we kicked things off with an affinity mapping exercise. Typically these are done with sticky notes and a white board when the team is collocated.

Local Affinity Mapping

 

In this case we used a shared Google Doc spreadsheet to conduct the exercise. We asked everyone in both offices to sign in to the shared spreadsheet. The spreadsheet itself had a column labeled for each person. We had 8 team members in the document at the same time.

 

Blank brainstorming spreadsheet

The team was asked to come up with as many ideas as they could think of to solve the problem statement that was presented to them. Each team member would write one idea per cell in the column marked with his or her name. They had 5 minutes to generate as many ideas as they could. Some brief Q&A preceded the timer starting to clarify the constraints and guidelines for the exercise and the team was off! 5 minutes later we had a spreadsheet filled with about 60 ideas for various ways of solving the problem.

Completed brainstorming spreadsheet

Completed brainstorming spreadsheet

The next step involved each team member reading his or her idea out to the distributed team. Some ideas went by quickly while others were discussed with a bit more detail. The initial purpose of this was to simply have everyone in both locations aware of what was proposed by their teammates. While they could certainly read the spreadsheet on their own, it was much more powerful for each individual to read their ideas. The goal of affinity mapping is to then group these ideas into overarching themes around which the team can agree. In the physical world this is done by moving sticky notes around into the same physical area on a whiteboard or wall.

To simulate this in the shared spreadsheet, the facilitator (me, in this case) began a second sheet in the document using a personal laptop. The second sheet had column headers that reflected themes I was hearing as the group read out their ideas. Each column represented a theme into which a few of the ideas could potentially fit. This was done largely for efficiency of the process. We certainly could have started the second sheet as a group and figured out the initial set together but given this was their first time and we were starting to get a bit behind schedule I took the initiative to create an initial set of theme proposals.

The team was then instructed to take each idea they came up with and copy/paste it into the matching theme on the second sheet. If it didn’t fit they were instructed to create their own theme and were highly encouraged to change the wording of the themes if they felt it was not representative or misleading. Each member proceeded to do this for the next two minutes or so. We ran into some copy/pasting over each other issues. Google docs does indicate when another user has focus on a particular cell with a unique color for each user and their name. This helped a bit but this portion of the exercise got a bit messy. All in all, no theme names were changed and only one new theme was added. My guess is that the team was not completely comfortable with making changes to something that was already presented to them. I expect this to get better and easier with each run through this exercise.

The end result was a spreadsheet sorted into themes with each theme populated by at least 2 ideas and some with as many as 8. We reviewed the themes again as a team, discussed for a bit and agreed that this was a comprehensive set of solutions.

The plan was to break here and move straight into the sketching portion of the exercise but at 2 hours, we ran out of time for this meeting. We schedule part two of the exercise for two days later and allocated another 2 hours to it.

Note: following this exercise, the site cardmapping.com was brought to my attention. It looks very interesting and can potentially replace a physical whiteboard and stickynotes in this exercise. I’ll dig into it further but haven’t had a chance to run it through a proper exercise yet. Any opinions on it would be greatly welcomed.

Collaborative sketching with remote teams

When we reconvened we went through a modified version of the setup deck to recap the problem statement, constraints, user pain points and the themes we came up with during the first session. We then presented the team with the logistics of the collaborative sketching exercise.

The team was provided with a 6-up template:

6-up template

6-up template

and a 1-up template:

1-up template

1-up template

and a set of Sharpie markers. We explained to the team that we were going to ask them to sketch 6, high-level ideas based on the themes we brainstormed in 5 minutes. They were encouraged to draw, not write words and to use the sharpies to illustrate 6 separate screens or a set of workflows they felt made sense.

Five minutes later the team produced 8 sets of 6-ups that were filled out with visual ideas about how to solve this particular problem. We asked the Vancouver team to use an iPhone to photograph their sketches and email them to all the folks in NYC. We did the same for the Vancouver folks. We had initially considered simply holding the sketches up to the camera in each conference room but the resolution and the stability of the presenter’s hand made this sub-optimal. The process of photographing the sketches and emailing took about 5 minutes. It was a necessary task but it took a bit of wind out of the sails of the activity, as momentum was built up and people were anxious to share their ideas and see what others did.

With dual monitors we were able to view sketches on one screen and see the remote team on the other screen. This helped connect the dialog and the artifact to the conversation. Typically in Skype conversations participants don’t talk to each other but instead talk to the screen. I was happy to see the team members presenting their ideas both to their collocated team and the remote portion.

 

Remote design studio and collaborative sketching

Remote design studio and collaborative sketching

Remote design studio and collaborative sketching

Remote design studio and collaborative sketching

Each team member presented his or her ideas to both rooms. Given this was the team’s first time, there were the expected awkward moments of silence but a little proactive moderation through Skype helped move things along. The Skype connection held up well and allowed the remote teams to participate in relative real-time in the critique portion of the exercise. Having the sketches up close on local monitors was critical to the success of the critiques. It allowed up-close inspection of the artifact and direct, relevant questions and answers from the team. In doing some up front research for this activity, several recommendations came in to purchase an IPEVO document camera. It’s relatively cheap at $70 and has a great camera and stand for document photography and transmission. We didn’t use it for this initial round but are seriously considering it for the next go-around. It will be interesting to see how it compares to the simple iPhone-snap-and-share technique we used. At $140 total cost for the experiment (1 camera per office) it’s worth the gamble.

Another tactic we’re eager to try to speed up the sharing of the photos (if we end up sticking with that tactic) is getting them into a Dropbox folder automatically. We’re checking out ifttt.com to see if there’s something we can set up there that will automatically share pics from a phone to a shared folder. I’m aware that the site allows you to have Instagram photos dropped into Dropbox but am concerned that photos taken in that app don’t have the necessary resolution for this exercise.

Conclusions

The team that experienced this remote brainstorming session had never done any kind of exercise like the ones described earlier. This was perhaps a boon for us since we didn’t have to live up to previous expectations of processes and success. It allowed us to run the session as if this is the way it’s always done. The flipside, of course, is that, with no context, the team couldn’t tell us whether this was a better or worse way to elicit the same results. What they could tell us was that they enjoyed the inclusion in the ideation process and the ability to share their ideas with a cross-functional group.

I would deem this remote technique a success. We succeeded in having an 8 person team brainstorm together, share their ideas, draw together and come together around collaborative solutions for a specific problem statement. The distance was a challenge but was largely overcome with technology. Perhaps we were lucky to have a solid Skype connection as I’m sure a spotty one would’ve caused the exercise to fizzle. We learned a lot about what works well and the challenges of facilitating two teams in two different rooms. As with everything, this process is iterative and next time can only get better.

What do you think? Is this a viable technique for your organization? Have you done this before? What’s worked well for you when dealing with distributed teams?

[Jeff]

P.S. — In Part II, I’ll follow up with any learnings from the next round of remote collaboration exercises.

 

Posted in agile, Lean UX, Productivity, Uncategorized | Leave a comment

I’m leaving TheLadders….and launching Proof!

“Go to the edge of the cliff and jump off. Build your wings on the way down.”
– Fahrenheit 451 author Ray Bradbury

 

jump off, build wings on the way down

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.

Continue reading

Posted in brand, career path | 5 Comments

Using personas for executive alignment

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 ☺ .

Continue reading

Posted in agile, Lean UX, Research | 4 Comments

Announcing: The Lean UX Book!

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.

Continue reading

Posted in agile, design, Lean UX, Uncategorized | 6 Comments

Lean UX Let Me Down

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.

Continue reading

Posted in agile, Lean UX, Productivity | 2 Comments

What The Karate Kid Can Teach Us About Agile and UX

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.

Continue reading

Posted in agile, design, Lean UX, Productivity, startups, ux team, work ethic | 6 Comments

Lean UX is not just for lean startups

Try something new today

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.

Continue reading

Posted in agile, design, Lean UX, Productivity, startups, Uncategorized | 4 Comments

Adding Game Mechanics To Agile Processes Part 2: Limiting In-Flight Cards


Traffic control

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:

Continue reading

Posted in agile, Productivity, ROI, work ethic | Leave a comment

Adding Game Mechanics to Agile Processes Part 1: Card Aging

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.

Continue reading

Posted in agile, Productivity, ROI, work ethic | 3 Comments

Lean UX presentation audio now available

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.

Thanks.

[Jeff]

Posted in agile, Conferences, design, Productivity, ux team | Leave a comment