This article is a guest post by Jeff Gothelf, Director of User Experience at TheLadders in New York City. Jeff has been promoting the use of Lean UX as an effective method to spur greater innovation, quality and productivity in startups as well as within teams in larger organizations. Jeff keeps a blog here (www.jeffgothelf.com/blog) with tweets available at @jboogie (www.twitter.com/jboogie). Jeff will also be joining us on stage at Startup Lessons Learned 2011, where he will be presenting a case study on his experience blending design, Lean Startup, and large company culture.
Lean Startups need to make snap decisions, iterate quickly and pivot when needed. Can an established organization with a recognized brand, proven revenue stream and an employee count in the hundreds or thousands embrace these principles? I’m happy to report the answer is “yes” as we’ve proven at TheLadders.
TheLadders is an eight-year-old company based out of New York City focusing on the $100k+ employment market (both jobseekers and recruiters). TheLadders’ subscription model has proven to be successful and the company has enjoyed solid growth with the employee count crossing 400 recently. Originally a waterfall shop, we transitioned to Agile development about two years ago. We entered the process largely blind and have had to feel our way in the dark until we found processes that worked for each team (you can read more about our transition here). Now entering our third year with Agile we’re continually trying to improve the efficiency, productivity and velocity of the various teams. Levels of Agile adoption span the full spectrum across our 6 Scrum teams. Some teams are still working to get beyond the gated approach of various phases and approval cycles while other teams are beginning to break down the silos of roles and focus on team-wide problem solving and velocity.
The most advanced of these teams, by adhering to the build-measure-learn methodology, has managed to reduce so much waste from their process that they’ve actually become an internal version of a lean startup within the context of our larger organization.
Here’s what’s worked for them:
Lean UX
TheLadders’ suite of products has UI components throughout the experience meaning some level of design is required for each feature to ship. A dedicated User Experience (UX) designer is assigned to this team. Traditionally the focus of this designer’s efforts has been a highly-detailed set of deliverables that included workflow diagrams, sitemaps, wireframes, annotations and detailed UI specification docs. These deliverables however had a detrimental effect on the collective problem-solving power of the team. They favored the “designer as hero” approach where an individual would disappear for an extended period of time and return with a fully-baked solution to present to the team. The team would then have to push back on issues of appropriateness of solution, scope and feasibility and terrifically time-consuming negotiations would ensue.
Driven by a desire to implement a highly-iterative approach favoring the validated learning of actual customer usage of our products, the team adopted Lean UX as their design approach. Covered extensively here and here, Lean UX is a team-wide acceptance of significantly lighter-weight design deliverables that are used to drive conversation, estimation and validation both with internal stakeholders and ultimately customers. The approach demystifies the design process by involving the other team members (yes, developers too!) in the problem-solving process.
The deliverables are low-fidelity – meaning the designer has spent a minimal amount of time creating them. Investment in these documents is low with their real purpose being to spur discussion – both within the team and beyond it to business owners and customers. The low-fidelity nature of the deliverable also encourages non-designers to join the discussion. The fear of “messing with” a beautiful mockup dissipates and a healthier discussion over functionality and workflow follows.
“Demos have become our design reviews.”
Examples of these low-fi deliverables include whiteboard sketches, pencil/pen and paper sketchbooks, wireframes, hacked screenshots (i.e., screengrabs that have been quickly manipulated in Fireworks) and even rough prototypes (in such varied tools as Powerpoint, Adobe Fireworks and even paper). This level of design takes less time to create and to iterate upon. As feedback is collected by the designer from team members and stakeholders, the next version of the design asset is turned around in hours, not days. This gives the project a powerful feeling of forward motion and progress. In addition, the build-measure-learn cycle can be executed much more quickly (even inside the walls of a larger organization) with this level of design.
This whiteboard sketch serves as an adequate representation of a proposed user experience and feature set. The conversation around this sketch provides enough directional insight for the rest of the team to voice any concerns, to begin the estimation process and to start coding.
Mobile designs require the context of the device to truly get a sense of the experience. Using readily available (and free) wireframe templates, we were able to quickly create this representation of a proposed mobile UI focusing on validating the content and workflow rather than creating pixel-perfect graphics.
Initially, the biggest challenge was to increase developers’ comfort level with such low-fi assets. In the past, every pixel and interaction was spelled out with extreme detail. With these lighter-weight designs, the missing documented details are conveyed through conversation. One of the ways we achieve this level of understanding and comfort is by including the entire team (a product manager, 4 developers, a QA analyst, UX designer and a dev manager) in solving each problem.
A member of the team participating in a brainstorm activity.
The implicit decisions that were not covered by these assets became innate product knowledge through this team-wide involvement. For example, in the mobile wireframe above, nowhere does it actually say what happens when the user clicks the “Follow” button (something that would’ve been meticulously document in our past process). That workflow was discussed and agreed to as part of a team conversation around feasibility and scope.
Beyond that, we face the challenge of getting business owners to make decisions based on these rough representations of customers’ end-state experiences. This is an ongoing challenge. The most effective way we’ve found to mitigate this is by holding live, weekly demos of working (unfinished) code to which these business owners are invited. At these demos, our rough designs come to life allowing business owners to react and provide insight and feedback prior to the push to production. Given that we push code live every two weeks, these demos have become our design reviews.
Competencies over roles
One of the interesting outcomes of implementing this process at TheLadders has been the gradual breakdown of the concept of “roles” within the team. Roles, such as software engineer, user experience designer and product manager, come with narrow and explicitly-assumed responsibilities. For example, software engineering write code. UX designers create wireframes and product managers gather requirements. Traditionally, team members were only expected to work on the tasks directly associated with their roles (e.g., deciding how the UI was laid out and what color certain elements were was always the realm of the “designer”). As the team has matured through multiple iterations, roles have given way to competencies.
An individual may have multiple competencies. There is usually a core competency they are best at (e.g., writing code) but they likely have other competencies that can contribute to the team’s goals. By demystifying the design process, the team has provided a venue for other team members’ competencies to shine. Conversely, input on coding decisions have also become open to non-coders. Yes, we all still have titles that are aligned with these traditional roles but the work we do now spans the various competencies we all bring to the table. It may seem like a subtle difference but it’s powerful.
Transparency builds trust
The Lean UX process has increased transparency into the way designers work. This transparency is, at times, uncomfortable for designers because it moves them away from the hero-based designer attitude. Instead, it shares the risks and rewards with the entire team. Historically, a designer wouldn’t reveal a design until they felt it was “ready.” This usually meant a prolonged period of time working alone followed by a dramatic reveal of “the solution” to the team. Lean UX pushes for validation (both internal and external) much earlier in the design process requiring the designer to reveal their thinking in its infancy. Providing insight early allows the rest of the team to move forward as well. For example, if the UX designer is considering implementing a real-time statistics feature, showing the team a sketch of the elements proposed to go on that screen and discussing their behavior provides them with enough information to figure out how to get that data to the presentation layer.
Letting the rest of the team into the design process yields a much stronger level of trust. Surprises are minimized while scope issues are resolved sooner. Repeated over multiple iterations, this process begins to build a shared understanding of the team’s capacities and constraints. This understanding matures into trust over time making intra-team communications more efficient since they’re no longer burdened with posturing and politics. The team is able to address the core issues faster and learns how to solve problems much more effectively.
Freedom to fail
Critical to the success of this team is freedom – freedom from micromanagement, freedom from review cycles and most importantly, freedom to fail. Senior management has entrusted this team with a problem statement, set short-term KPI’s as goalposts for the team to strive towards and allowed them to go and execute. The Lean UX team at TheLadders is tasked with solving the issue of communications between jobseekers and recruiters. Given the problem statement of figuring out how to get these two parties communicating more effectively and guided by KPI’s such as response rates and number of communications sent through the system, the team comes up with its own solutions. Those solutions are implemented quickly, the results of those changes are measured and the learnings from the analysis of those measurements are applied to the next iteration.
In the cases where conflict may occur with other teams or with senior management, the development manager working closely with the UX designer (who, in this case, happens to be relatively senior) protects the team by reminding the organization that anything implemented is a short two weeks away from its next iteration should the learnings reveal that it was a suboptimal decision.
Proven over many iterations, the build-measure-learn cycle has insulated the team from the micromanagement of the past. If an estimation is wrong or an iteration falls short of its original number of story cards, no one gets fired. The trick is to keep management aware of your activities and intentions, justify those intentions with the learnings from each iteration and (most importantly) show progress. Hit a milestone? Tell the business owner. Exceeded your original expectations? Tell your boss. Learned something completely new about your audience? Stand up in front of the company and explain it. It’s this proactive approach that keeps the micromanagers at bay and the team free to solve problems as it sees fit.
Self-organized “enlightenment”
What’s surprised the team the most as it continues to mature is the nature of their process – or lack thereof. It seems that as a team matures and the trust bonds between the members grow, the rituals of formal process fall away in favor of less-prescribed, more “understood” cadences. The role of scrum master has become less relevant as each team member owns their own accountability. Participation, coordination, conversation all begin to just “happen” without the need for external prodding. Elements of scrum have begun to get mixed in with kanban seamlessly as the way the team works continues to evolve and improve every two weeks. Seemingly minor tactics like limiting the number of “in dev” cards at any time and visually “aging” each one based on how many days it’s been in flight have driven up awareness, focus, productivity and quality while reducing project management overhead.
The team’s board holds a constantly prioritized and updated backlog of stories for each iteration. A maximum of 4 cards (one for each developer) can be in-flight at any given time. Even if no UI assets have been provided for the next card in the backlog, the team begins development assuming certain design tactics based on existing style guides. Paired developer/designer sessions refine the UX. The “release target” is a moving line. Unforeseen complexities or reprioritizations force the team to move stories above/below the line for each release.
Each in-flight story card is aged using magnetic avatars. On our board each day in-flight is equal to a day in the life of a man. As the story ages, the avatar ages – from a baby through adulthood to old age and finally, death. Our goal is to never let a story die. This technique keeps the team keenly aware of where they’re getting bogged down and urges resolution.
We keep our important KPI’s updated on the board daily to let us know how we’re progressing. We also keep count of the number of days we’ve gone without a story reaching the “death” stage on the board. Finally, every team member who’s late for stand-up owes $1 (which inevitably gets spent on beer).
Conclusion
The Lean Startup approach is not limited to small companies. The drive to minimize waste, work collaboratively, solve problems and develop customers can manifest inside larger organizations eager to continue innovating. By broadening the application of these principles to disciplines which, in the past may have been seen as bottlenecks (like UX design), a team-wide approach is developed. The Lean UX process personifies this and has proven its value within TheLadders organization. When applied to a team that is tasked with solving a problem, not implementing a solution, and complementing that with an environment where autonomy and accountability are held at the highest regard, a truly productive and invested team emerges. We’re actively working to train the rest of our teams to work this way. As we do, we’re learning that the training extends beyond the teams to their business owners and stakeholders as well. Lean UX has proven successful at TheLadders. Give it a shot at your organization and share your story.
