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

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

and a 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

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.

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

I considered many options when thinking about the next thing and, not surprisingly, it was the entrepreneurial spirit of TheLadders that inspired me to start my own business. Along with two ridiculously talented and smart partners, Josh Seiden and Giff Constable, I’m thrilled to announce the launch of Proof. Proof is a product innovation and design studio applying lean principles to traditional product development. Our goal will be to work with corporations seeking innovative product design but unsure how to achieve it within their current processes. We will be product focused (not deliverable focused – no surprise there) and intent on not only building products but also teaching the process along the way. In addition, we will offer workshops and coaching for select clients.

I’m very excited about this new venture and what 2012 holds in store for us. It’s a new set of skills to master and a new way of working from which to learn. Like every other entrepreneur out there, our success is in our own hands.

I’ll miss the friends I made at TheLadders and the camaraderie that grew out of my time there. I wish them the best of luck. Time for me to build some wings.

If you’d like to work with us or just learn more, email me at jeff@proof-nyc.com and please follow Proof at @proof_nyc so you can keep track of what we’re up to.

Happy new year!

[Jeff]

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 decided to pitch the organization on a proto-persona (aka ad-hoc persona) exercise where the executive team would articulate who they believed we were building products for and how our current and future offerings would meet their needs in the near-term future. My belief was that in each of their points of view, the executive team had a different target audience in mind. In addition, I believed that many of them were approaching corporate strategy from the inside out – in other words, from their particular discipline (e.g., marketing, products/features, services, customer support, etc) and not from a customer-centric point of view. The goal of the exercise was to get everybody’s points of view out on the table and then consolidated into a single, shared consensus about who we believe our customers are and what needs of theirs we should be solving in 2012 and beyond.

via Jeff Patton & Luke Barrett who re-created the cartoon from an unknown origin.

My timing could not have been any better. The team was going through the nascent stages of 2012 planning and, if I could have the exercise pulled together quickly, we could build it into their process. I built a quick proposal where I articulated a problem statement, the objectives and goals of the exercise and the specific methodology we would employ to achieve those goals. Michelle and I reviewed it a bit and off it went for executive approval. Luckily for us it was quickly approved and I was cleared to book the executive team for two, 3-hour meetings over the next two weeks.

(It’s worth mentioning that our target audience had broadly expanded in the month prior to these exercises. In October 2011, TheLadders had expanded its market reach from jobs and employers in the $100k+ salary range to all professional jobs. This opened our products and service to a whole new set of potential customers. )

Day 1 – persona creation

Pens, paper, ipads and pizza. What else would you need?

The first day consisted of pulling the team together from noon to 3pm (pizzas were brought in) and presenting them a short introduction. The presentation stressed that we were going to look at the company from the customer’s point of view. Our goal was to articulate who the customer was (or were) and what needs they have that we could choose to serve or not serve. Michelle and I introduced the executives to the concept of an ad-hoc persona by explaining that these were going to be “people” they believed were going to be our customers now and in the coming future. It was important for us to stress the difference between real personas and ad-hoc ones. These were not going to be research-proven customer archetypes. They were however going to be reference points which the team can use as filters in the 2012 planning and decision-making process. We closed the short pitch with examples of what they’d be creating.

The team was going to sketch quadrants for each persona. Here is an example of a finished persona:

Example of ad hoc persona

The top left quadrant was for a sketch of the individual, a name and some basic demographics.

The top right quadrant was for behaviors and beliefs of the persona.

The bottom left quadrant was for demographics.

The bottom right quadrant was for needs and goals.

The team was given 15 minutes to create as many personas as they could or felt were necessary.

Once complete, each executive presented their persona to the team. They read the persona out loud and posted up on a wall. The team would then provide some feedback on the realistic qualities (or not) of that persona and some real-time adjustments were made.

Marc, CEO of TheLadders, presenting his personas

Next, the team was asked to place each persona on a set of 5 spectrums. The spectrums were: years of experience, education, ambition, risk tolerance and tech savviness. Each executive was given three Agile planning poker cards. The cards had the numbers 1, 3 or 5 on them and the team was asked to vote by raising the card they felt most appropriately mapped where each persona fell on each spectrum.

Team voting with planning poker cards

Much like Agile planning poker, if there was consensus there was minimal discussion. If , however, there were outliers or a broad distribution of opinion on where a particular persona lay on a particular spectrum, we encouraged the team to discuss and debate that. In many cases, the outliers managed to sway some votes. In other cases the majority won and in still other cases the team made real-time adjustments to their personas to more closely match their view of our target audience.

As each name was voted on the spectrum, their name was written on the whiteboard in the appropriate spot. Almost instantly, patterns began to form. There were clear clusters and clear outliers. At the end of the 3 hours exercise we had a board filled with personas and persona names mapped to spectrums.

Spectrums with names mapped on them

We ended the exercise by thanking the team and letting them go for the day. Michelle and I spent the next few days consolidating the 20+ personas that were created down into a manageable size based on their spectrum distributions. We wanted to get to 3-5. We ended up with 6.

Completed persona

Day 2 – Persona verification and design studio

Day two began with donuts. It was morning and it was early. Donuts help. A lot.

We began the exercise with the team by going over the consolidated set of personas. We’d sent the team the document in advance of the meeting so they would come in , in theory, prepared to discuss. We projected each persona and began a vigorous discussion around their validity not only as a “real” person but also as a customer that we wanted to support moving forward. This part of the exercise truly engaged the team. Strong opinions were presented and an excellent debate ensued around some of the newer customer types were now attracting to the site.

Reviewing the consolidated personas

Each persona was reviewed in detail and adjusted, in real-time, to provide a representation that the team could agree upon. This was probably the part of the two-day exercise where the most consensus was built. At the end, we still had 6 personas but they were now modified enough to where the team was comfortable with all of them as viable customers (Note: interestingly, one contentious persona had to get down to a vote and made it in as a customer by a vote of 5-4).

The second half of this exercise was a design studio. Many articles have been written about how to run these and we use them regularly with the staff at TheLadders. We modified this one for time and focus. The first 5 minute round of sketching consisted of a single 6-up template for each executive team member.

Sketching at design studio

Each executive presented and got critique from the others. The team was then split into two groups based simply on where they were seated and asked to consolidate their sketches in to one big sticky note drawing. The drawings were all supposed to be of TheLadders.com home page articulating value propositions that were relevant to the 6 personas. Each critique session asked how the designs presented were valid for the various personas. The teams consolidated their visions into two big drawings that amazingly enough converged on similar themes.

Big sketchin'!

We dismissed the team, thanked them for their time and asked for any feedback (good or bad) on the exercise. We followed up with a summary email that recapped what we did and what the themes were that we found. In addition, we stressed again that these were our beliefs and that, now that we had them, we will be using them to drive recruiting for usability studies, compare them against other customer samples and will update and adjust them as we find characteristics of real customers that go against our initial beliefs.

The one final asset we created was a printed deck of persona cards so that these ideas could easily come to any executive meeting – especially the ones where we were not present.

Persona cards - front

Persona cards - back

Learnings

We had several goals when we set out to run this exercise with the executive team. The first was to introduce them to the concept of personas. We achieved this goal to the extent that the team now knows what this tool is and what components make it up. Given that these were ad-hoc personas, it is incumbent on us, the UX team, to continue to update the 6 personas we created as we learn more from actual user interactions. We must then update the executives with these new details.

The second goal was to get the executive team thinking from a customer-centric point of view. For the duration of the exercise we succeeded though it was a constant effort to keep the conversation focused this way. Each executive’s tendency was to fall back to their traditional points of view based on their responsibilities and, as moderators, it was our job to bring the focus back to the customers. One additional thing that I found particularly interesting was the team’s tendency to present their feedback and insights to me, the moderator, as opposed to their teammates. Our goal was to have the team debating each other and, while that happened at times, much of the conversation was happening with the moderator (Michelle or I) as the initial recipient who would then bounce the dialogue back to the team. Beyond the exercise, it’s too early to tell how successful we’ve been. Our hope is that the printed card deck will serve as a reminder for the team.

The third goal was align the executive team around a target audience and get them to debate and agree upon value propositions that serve the needs and goals of that audience. Again, within the constraints of the exercise I believe we were successful. We created over 20 ad-hoc personas and consolidated down to an agreed-upon set of six. We designed landing pages for those personas that spoke to the value of the products and services we’d offer them in 2012. There was consistency in the themes the team raised and a general acknowledgment of a shared understanding. Will this alignment last into future planning meetings? Again, it’s too early to tell but early indications point to only minor erosion of these initial ideas.

Finally, there was an unspoken goal to bring design thinking, gamestorming and traditional UX practices into the executive suite. We wanted to see how it would fare and how the team would react. It was our hope that this would give UX an even stronger foothold at the executive level then it enjoys today. Given the feedback received, the team enjoyed the exercise and saw value in it. Whether we’ll get invited back will be answered in time.

[Jeff]

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’m very excited about this project (it’s the biggest one I’ve ever undertaken) and I hope you’ll follow along with me both here on this blog and on Twitter as I get closer to the book’s launch. I’ll continue to blog here throughout the process but there will also be several guest posts published on other terrific publications. The articles page has all the details.

Finally, if you’d like to be updated on the book’s progress and publication date, I’ve put together the nifty little Google docs form below. Put your email in there and every now and again I’ll reach out with an update (your address stays with me, never to be shared).

Sign up to stay in the loop:

Thank you!

[Jeff]

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.

Then, a couple of days from the end of the sprint, I pulled up a chair next to one of the engineers to do some co-design in Firebug. One question led to another and the “tweaks” grew in complexity to the point where a 15 minute session turned into 90 minutes of real-time redesigning. In the end we had to make some fundamental logic changes to the page. The rabbit hole could have gone much deeper had we not been constrained by burn rate and a pending company-mandated deadline.

With each update of the CSS and markup came more questions. Why was this happening? How had we not seen this in advance? The answer became evidently clear at the end of that co-design session: we had not grasped the complexity of the business and UX logic of the page BEFORE we started working. We dove in, like we normally do, and started designing and coding. Had we slowed down for a few minutes and asked some more questions we would’ve designed the page to accommodate the scenarios we uncovered so late in the sprint not to mention saved the team a chunk of refactoring work.

So what did we learn? We learned that:

- spinning an extra cycle or two to understand legacy systems saves
redesign and rethink work

- confirming that a proposed design meets the needs of those legacy
(and new) business rules is crucial when incorporating into existing
workflows

- creating new features is much easier and far less risky (as far as
system compatibility goes) then reworking existing ones

- a deep understanding of your existing product is crucial in order
for Lean UX to work well

I learned a valuable lesson today. Understanding where our process broke down and why helps us evolve that process and make it better. The Lean UX process we practiced today, let us down. The process we’ll practice tomorrow will be better.

[Jeff]

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.

You want me to paint this fence?

“Show me, paint the fence!”

This is what Daniel-san heard the first day he came to learn karate. He arrived ready to learn how to punch, kick, block and defend himself. Instead he found himself painting a fence. Confused but determined, Daniel painted the fence – day in and day out. It was exhausting, humiliating, and ultimately very frustrating as the weeks went on and it appeared that he was not learning a thing about karate. Instead it seemed to him that he was essentially providing free labor for the old man. Finally, Daniel had enough and complained to Mr. Miyagi who, through a series of task-based commands, illustrated to Daniel how the motions of painting the fence and waxing the car were actually the same motions used in karate. Unbeknownst to Daniel, he was learning the craft all along – initially through ritual – but as he got better the ritual melted away into unconscious practice.

A very powerful lesson

There is strong correlation between rote repetition of exercises and the mastering of a process or skill. In other words, what initially looks simply like “going through the motions” can ultimately translate into process mastery and success. Initially, the calisthenics approach seems meaningless. In Daniel’s case he was painting a fence in a very specific fashion. In a designer’s case, one might take on drawing the same elements every day for a month. In an agile team’s world, this could translate into any one of the standard Scrum practices like the daily stand-up, story gathering or estimating.  But by going through the motions, the ritual becomes inculcated as learned behavior. After enough practice, the purpose of the ritual starts to make sense (even if it didn’t in the beginning and seemed like a waste of time). In the designer’s case, it’s an understanding of how to render a particular form or communication. In the Agile team’s case, it’s an understanding that the daily stand-up not only allows the team to catch up on current events related to their project but also begins the bonding process for the team, which paves the way for greater trust and transparency.

What’s even more amazing is that, as process mastery progresses, again through repetition, it begins to bury itself into the teams collective unconscious to the point where, in essence, there is no explicit process – just visceral reactions to inbound stimuli from the work, the team, and forces beyond the team. Daniel found this level of mastery in the final tournament where he anticipated his opponent’s moves and ultimately defeated him. An Agile team achieves this when they trust each other implicitly, react as a cohesive unit to change and manage that change as well as any conflict with little impact to productivity or quality of work.

This approach is even more impactful when integrating user experience design into an Agile process. Initially, the designer may not understand why they’re going through the rituals of Agile every day. They may seem useless and time-consuming; removing the designer from their element and core competencies. In essence, in the early days, the designer is literally “painting the fence” – she is going through the motions because that’s what’s expected of her. As time wears on, the benefits start to manifest simply from the designer spending time with the team. Camaraderie and joking around are the initial signs of inclusion. That inclusion begins to grow into trust as the rituals force the team to interact regularly. Trust develops into transparency where the designer is now including developers in her process and developers are seeking out the designer as they code the experience. The final step is integration, driven heavily by this trust and transparency. It’s at this point that the “process” has melted away. The designer no longer hides behind their screen incanting secret spells made manifest in documentation. Now, they sketch in the open, pair design with developers, and invite developers into the co-design process itself. The team is working on an unconscious level, reacting to input, solving problems collaboratively without consideration for “what’s next” in the Agile playbook.

It takes time to achieve this stage of process enlightenment. It requires the team spend time together, struggle together, go through conflict together, fail together and ultimately win together. Designing a schedule of ritual practices provides a framework for the team to start working together. Teams that go through this process begin to evolve beyond the textbook practices and evolve into high-functioning teams. By initially “painting the fence,” the team can achieve a level of process mastery that pushes the boundaries of their productivity, quality and responsibility.

[Jeff]

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.

Many of the questions I get regarding the viability of Lean UX center around three types of organizations – midsize/enterprise level companies, interactive agencies and “other” non-Agile environments. While I won’t address every single challenge and opportunity Lean UX faces in each of these situations, I want to take a high-level look at how this type of thinking can be applied for the benefit of each organization.

Larger companies (i.e., not startups)

Steve Blank describes startups as organizations designed to find a repeatable business model. When those organizations find that business model they shift their focus to scale – i.e., executing that business model at greater quantities and efficiency. This shift drives growth and that growth depends on repeatable processes. Teams are built around these processes leaving little room for iterative evolution of that process. For Lean UX to take root in a larger organization, it needs to start at the team level. An execution team needs to actively decide to try a new way of working. By opening up a new level of communication amongst the team members, new conversations can happen. Members of the team who were never involved previously in the design process are now welcomed in and are not only involved but are encouraged to participate. Design direction and decisions become a broader conversation that brings in fresh internal voices (developers, business owners, subject matter experts, et al) as well as stronger input from your customers.

The goal for this team is to prove the validity of their design solution as early as possible. The designer has the onus, in this type of organization, to break new ground. The initial step is to get buy-in on the design direction from internal members of the team. Conversations around feasibility, scope, general design direction and user experience can all happen at a very early point in the design cycle. Before committing your ideas to pixels even, start shopping them around in their most raw format to ensure that, as you design, you’re heading in the right direction. In addition, you make your teammates aware of that direction empowering them to start aligning their planning and contribution much earlier than they would have in the past.

In all but the most confidential environments, it is usually possible to get a hold of a customer or two. Even if you can’t show them actual work, discussing your proposed solution helps you refine the idea. If through these efforts you learn that the proposed direction is either not feasible or fails to alleviate your customer’s pain points, the investment level made to get that feedback (i.e., sunk cost) is minimal enough that making changes is relatively cost-free.

Enterprise teams can grow to large numbers and the scope of projects can also get big. To break ground for Lean UX, I recommend picking a smaller effort – perhaps even a non-customer-facing project. Taking on a low-risk project allows you to carefully feel your way around your organization’s existing methodologies while proposing new ideas around efforts where failure would have minimal impact both to your team and this new approach.

Agencies

There are many flavors of consulting companies and agencies. For the purpose of this post, the word “agencies” means interactive and advertising agencies who take on primarily website design and development work. One of the biggest challenges in this environment is separation of the teams. There is, typically, a client-based product team, the agency provides the user experience and design team and a third-party usually provides the technical side of the equation. Traditionally, an agency will kick off a project with a client, disappear for a while, perform voodoo/witchcraft/magic and return to the client with a shiny object. That object may or may not meet the client’s (or their customer’s) needs and edits/redesigns/negotiations ensue from here.

Applying Lean UX in an agency context means engaging your clients on a much more frequent basis. I recommend setting aside two to three 15-minute meetings a week with the client. These can be virtual, phone or in-person but the purpose is to have an ongoing, regularly cadenced conversation about the direction in which you are heading. In addition, these conversations should always include artifacts that show the progress the agency team has made. These artifacts should be of whatever fidelity and polish is available that day. It’s not necessary to push for pixel-perfect mocks at each one of these meetings. That’s wasted effort, as the feedback will undoubtedly force the relocation of some of those pixels. The goal is to show day-over-day progress and iteration on the concept – yes, revealing to the client the way the sausage is made.

This is critical because it makes the client feel like a part of your team. Their input and feedback inevitably makes its way into the product and they begin to “own” the work. The more they feel ownership over the work the more they will defend it and buy in to the vision you’re selling. If a third-party is providing technical support for this effort, they should also be included so that they can weigh in on feasibility, scope and cost of the features being proposed. In addition, they too will begin to feel as part of the team motivating them to create higher quality product more efficiently.

Non-Agile environments

“But my [insert company type/size here] is not an Agile shop!”  Lean UX has its roots in Agile but its practices are not limited to those environments. Regardless of what your methodology is there is always room to be more collaborative and inclusive in your design while reducing waste. The trick is to jump the rut of historical momentum. Just because it’s “always” been done a certain way doesn’t mean that tomorrow, you can’t come in to the office and try something new. And that something new doesn’t have to be a radical re-architecting of the way your company builds products. It can simply start as subtle change to your design process. For example, instead of disappearing behind your monitor for a day or two on a particular task, take a crack at it with your sketchpad and then walk over to one of the developers on your team (or stakeholder, product manager, whatever) and ask them what they think. Share your idea and get their feedback. Tweak the sketch in real-time until you are both on the right page. With this one simple step you have reduced waste in your process, opened lines of communication and iterated on your product design. Nifty.

These small steps can then be strung together into larger shifts in the way your team works. Find the things that resonate and build on them. As your team becomes more efficient and collaborative, other teams take notice. They begin to ask questions and ultimately want to work “the way” you’re working. It’ll take time but the payoff can be big. Regardless, the change has to start small so it may as well be you, the designer, who kicks it off.

Summary

Lean UX is a different way of applying the broad user experience and design tools we’ve been using for years. In addition, it promotes a greater role for cross-functional collaboration and transparency that has, traditionally, not been a part of UX processes. Interpreted in that light, it’s easy to see that the application of Lean UX can span any type and size of company as well as any development environment. The trick is to have an open mind, try something new, see how it works and iterate from there. Small steps lead to small wins. Credibility comes from those small wins on which you can build bigger change. Give it a shot and let me know how it worked out.

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:

1. It focuses the team – in many cases a team can start to drift in an iteration by working on cards that are near and dear to a specific developer or are “cooler” than other cards, neglecting features that were higher in priority on the backlog. Limiting the cards forces the team to focus on the tasks at hand and motivates completion of those tasks to open up slots for new cards to be taken from the backlog (perhaps including that really cool one someone had their eye on).
2. It broadens the team’s knowledge – with one less card than developers, at least two developers have to pair up. This benefits the team with an increased pace of completion but what it also does is teach some of the developers something new that they couldn’t have learned through paired development.
3. It speeds up your stand-up – the reduced number of cards ensure that there is always progress being made on all of them and that only those features get discussed. The pace of the daily stand-up quickens and only explicit deltas from yesterday’s status are reported. This is effective for teams of any size.

There are actually even more benefits than just these three but I figured this would be enough to at least get you try it. If you do (or already practice this way) please share your feedback in the comments.

[Jeff]

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.

Card aging consists of physically indicating on each card how “old” it is. Age is determined by each day that the card is in-flight. At TheLadders we age our cards quite literally. On day one the card is a baby and is awarded the baby magnet.

Awww....it's a baby.

With each additional day in-flight, a new avatar is assigned to the card. The card “ages” from baby, to boy, to man, to old man finally, death.

It's a boy!

He's getting tired.

Now, he's old.

The end.

The switching of the avatar happens every morning at our stand-up marking a very explicit transition. The team members assigned to that card, while not called out explicitly, become keenly aware that their card is still in the in-flight column. At a certain point, the scrum master or dev manager begins to notice that a card is aging and will jump in to see what can be done to move the team forward.

Boy avatar hanging on a card on the board

In this way, card aging serves as a daily reminder of how quickly the team is moving forward. If the board is full of babies, we’re in good shape. As the avatar population ages, however, it becomes evident that the team needs to focus more. The goal is to avoid the “death” avatar. If a card “dies” on the board it becomes the top priority to move through and other developers may be pulled over to help unblock that issue.

An additional incentive for us to stay out of the “death” phase is a counter we’ve placed on our board that mimics the accident safety records of physical production facilities. Our goal is always to increase the “days without death” count. It’s actually quite disheartening when that number gets reset to zero.

Days without death.

Card aging has worked well for us as a technique to focus the team and make it aware of issues before they arise. The addition of a counter has helped make this focus top of mind and motivates the team daily to keep that number high. Do you think this type of technique would work well for your team? Do you already do something like this? Leave a note in the comments.

[Jeff]

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]