by Jeff Gothelf
Organizational shifts aren’t easy, but they’re not optional. The world has changed: our organizations must change with it. Any business of scale (or any business that seeks to scale) is, like it or not, in the software business. Regardless of the industry in which your company operates, software has become central to delivering your product or service.
This is both empowering and threatening. The ability to reach global markets, scale operations to meet increased demand, and create a continuous conversation with your customers has never been easier. This power is also a double-edged sword: it offers these same opportunities to smaller competitors who would never have been able to compete before the broad adoption of software. This makes the need to adopt Lean UX all the more urgent.
Lean UX makes it possible for you to use the power of software to create a continuous improvement loop that allows your company to stay ahead of its competitors. It’s this loop that drives organizational agility and allows your company to react to changes in the market at speeds never possible, even just five years ago.
The Shifts
When we train teams, they sometimes ask, “How can we put these methods into practice here?” And on this point, we’re always a little hesitant. Although we’re confident that most organizations can solve these problems, we’re also aware that every organization is different. Finding the right solution requires a lot of close work and collaboration with your colleagues and your executives.
To prepare you for that work, we’re going to use this chapter to share some of the shifts that organizations need to make in order to embrace Lean UX. We’re not going to tell you how to make those shifts; that’s your job. But we hope this discussion will help you survey the landscape to find the areas you’re going to want to address.
In this chapter, we discuss the shifts your organization might need to make in these areas.
Changing Culture
As you implement Lean UX, consider these dimensions of culture:
Adopting a position of humility
Embracing new skills
Creating open, collaborative workspaces
No more heroes
Falling in love with the problem, not the solution
Shifting agency culture
Being realistic about your environment
Shifting Team Organization
To implement Lean UX, you’ll also need to rethink the way you organize teams:
Moving from limited roles to collaborative capabilities
Creating cross-functional teams
Creating small teams
Working with distributed teams
Working with third-party vendors
Shifting Process
Finally, your product development processes will change as well:
Shifting from output to outcomes
Eliminating Big Design up front
Speed first, aesthetics second
Embracing UX debt
Navigating documentation standards
Managing up and out
SHIFT: Humility
Imagine for a moment that you work on an assembly line that makes cars. The end state of your product is well-defined in advance. The cost of producing that product is clear. The process to create it has been optimized and the ways customers will use that car—based on more than 100 years of observation—is also clear. In situations like this, the focus is on quality, efficiency, and cost control.
We’re not building cars.
Our medium is software, and our products and services are complex and unpredictable. They don’t have an end state. We can continue to design, build, operate, and optimize our digital products as long as it makes economic sense to do so. Most perplexing is that our customers might use our digital services in ways we never imagined. In many cases, the best features of a system emerge over time as people use the system. (Twitter’s hashtag is a great example of this: users invented this feature, and then Twitter added support for it after the fact.) With so many unknowns, there is only so much confidence we can have in the scope, roadmap, implementation, and success of our product. The good news is that through the rise of the Agile and DevOps movements, we can move away from the assembly-line methods of past generations and adopt continuous production methods. When we pair that capability with Lean UX, we get the ability to learn very quickly how valid or invalid our ideas are.
To fully take advantage of these new capabilities, your organization must adopt a position of humility. Your organization must accept that, in the face of all this complexity and uncertainty, we just can’t predict the exact shape our service will have to take to be successful. This is not an abdication of vision. Instead, it requires a strong opinion about the shape the system should take, coupled with the willingness to change course if evidence from the market reveals that initial vision was wrong. Adopting this mindset makes it safe for teams to experiment, fail, and learn. It is only through this trial-and-error process that Lean UX can thrive. If there’s no room for course correction, the continuous learning that Lean UX promotes will be seen, at best, as a distraction, and, at worst, a waste of time.
SHIFT: Outcomes
Chapter 3 discusses the role of outcomes in Lean UX. Lean UX teams measure their success not in terms of completed features, but in terms of progress toward specific outcomes. Determining outcomes is a leadership activity; it’s one that many organizations are not good at or don’t do at all. Too often, leadership directs the product team through a feature-centric Product Roadmap—a set of outputs and features that they require the product team to produce by a specific date.
Teams using Lean UX must be empowered to decide for themselves which features will create the outcomes their organizations require. To do this, teams must shift their conversation with leadership from one based on features to one centered on outcomes. This conversational shift is a radical one. Product managers must determine which business metrics require the most attention. What effect are they trying to create? Are they trying to influence customer behavior? If so, how? Are they trying to increase performance? If so, by what measure? These metrics must be linked to a larger business impact.
Leadership must set this direction. If not, teams must demand this shift of them. Teams must ask, “why are we working on this project?” And, “how will we know we’ve done a good job?” Managers need to be retrained to give their teams the answers to these questions. They must be given the freedom to work with their teams to determine which features best achieve these goals. Teams must move from feature roadmaps to backlogs of hypotheses to test. Work should be prioritized based on risk, feasibility, and potential success.
SHIFT: Roles
In most companies, the work you do is determined by your job title. That job title comes with a job description. Too often, people in organizations discourage others from working outside the confines of their job descriptions (e.g., “You’re not a developer, what can you possibly know about JavaScript?”) This approach is deeply anticollaborative and leaves people’s full set of skills, talents, and competencies unused.
Discouraging cross-functional input encourages organizational silos. The more discrete a person’s job is, the easier it becomes to retreat to the safe confines of that discipline. As a result, conversation across disciplines wanes, and mistrust, finger-pointing, and CYA (“Cover Your Ass”) behavior grows.
Silos are the death of collaborative teams.
For Lean UX to succeed, your organization needs to adopt a mantra of “competencies over roles.” Every team member possesses a core competency—design, software development, research, and so on—and must deliver on that skill set. However, members might also possess secondary competencies that make the team work more efficiently.
Allow your colleagues to contribute in any disciplines in which they have expertise and interest. You’ll find it creates a more engaged team that can complete tasks more efficiently. You’ll also find it builds camaraderie across job
titles as people with different disciplines show interest in what their colleagues are doing. Teams that enjoy working together produce better work.
SHIFT: New skills for UX designers
Many companies only ask designers to create wireframes, specifications, and site maps. They limit their participation in a project to the design phase of whatever process the company happens to be using. Plugging designers into these existing workflows limits their effectiveness by limiting the scope of their work, which has a side-effect of reinforcing a siloed team model.
The success of a collaborative team demands more. Although teams still need core UX skills, designers must add facilitation as one of their core competencies. This requires two significant shifts to the way we’ve worked to date:
Designers must open up the design process
The team—not the individual—needs to own the product design. Instead of hiding behind a monitor for days at a time, designers need to bring their teams into the design process, seek their input, and build that insight into the design. Doing so will begin to break down silos and promote a more cross-functional conversation to take place. To do this, designers must employ a broad range of collaborative tactics, and must be both creative and deeply practical—seeking tactics that meet the team’s needs, advance the conversation, and respect the realities of team capacity and project timeline.
Designers must take a leadership role on their team
Your colleagues are used to giving you critique on your design work. What they’re not used to doing is co-creating that design with you. Design leadership and facilitation in group brainstorming activities like Design Studio can create safe forums for the entire team to conceptualize your product and showcase the synthesizing capabilities of the design team.
SHIFT: Cross-functional teams
For many teams, collaboration is a single-discipline activity. Developers solve problems with other developers while designers go sit on bean bags, fire up the lava lamps, and “ideate” with their black-turtlenecked brethren. (We kid.) (Well... only a little. We love designers.)
The ideas born of single-discipline collaborations are single-faceted. They don’t reflect the broader perspective of the team, which can illuminate a wider range of needs, be they the needs of the customer, the business, or the technology. Worse, working this way requires discipline-based teams to explain their work. Too often, the result is a heavy reliance on detailed documentation and a slowdown in the broader team’s learning pace.
Lean UX requires cross-functional collaboration. By creating interaction between product managers, developers, QA engineers, designers, and marketers, you put everyone on the same page. Equally important: you put everyone on the same level. No single discipline dictates to the other. All are working toward a common goal. Allow your designers to attend “developer meetings,” and vice versa. In fact, just have team meetings.
We’ve known how important cross-functional collaboration is for a long time. Robert Dailey’s study from the late ’70s called “The Role of Team and Task Characteristics in R&D Team Collaborative Problem Solving and Productivity,” found a link between a team’s problem-solving productivity and what he called “four predictors,” which included “task certainty, task interdependence, team size, and team cohesiveness.”1
Keep your team cohesive by breaking down the discipline-based boundaries.
SHIFT: Small teams
Larger groups of people are less efficient than smaller ones. This makes intuitive sense. But less obvious is this: a smaller team must work on smaller problems. This small size makes it easier to maintain the discipline needed to produce Minimum Viable Products (MVPs). Break your big teams into what Amazon.com founder Jeff Bezos famously called “two-pizza teams.” If the team needs more than two pizzas to make a meal, it’s too big.
If the task is large, break it down into components that several small teams can handle simultaneously. Align those teams with a single outcome to achieve. This way, all of them are working toward the same goal. This forces these small teams to self-organize and communicate efficiently while reducing the risk of each team optimizing locally.
SHIFT: Workspace
Break down the physical barriers that prevent collaboration. Colocate your teams and create workspaces for them that keep everyone visible and accessible. Make space for your team to put their work up on walls and other work surfaces. Nothing is more effective than walking over to a colleague, showing some work, discussing, sketching, exchanging ideas, understanding facial expressions and body language, and reaching a resolution on a thorny topic.
When you colocate people, create cross-functional groupings. That means removing them from the comforts of their discipline’s “hideout.” It’s amazing how even one cubicle wall can hinder conversation between colleagues.
Open workspaces make it possible for team members to see each other and to easily reach out when questions arise. Some teams have gone as far as putting their desks on wheels so that they can relocate closer to the team members they’re collaborating with on that particular day. Augment these open spaces with breakout rooms where the teams can brainstorm. Wall-sized whiteboards or simply painting the walls with whiteboard paint provides many square feet of discussion space. In short, remove the physical obstacles between your team members. Your space planners might not like it at first, but your stakeholders will thank you.
SHIFT: Distributed teams
In many situations collocation is not an option. When dealing with distributed teams, give them the tools they need to communicate and collaborate. These include things like video conferencing software (e.g., Skype and Google Hangouts), real-time communication services (e.g., Slack and Hipchat), simple file-sharing software (e.g., Dropbox), remote-pairing software (Screenhero), and anything else that might make their collaboration easier and more productive. Don’t forget that occasionally plane tickets to meet each other in the flesh go a long way toward maintaining long-distance collaboration. Perhaps the most important thing to remember if you’re trying to implement Lean UX with distributed teams is this: the members of these teams must be awake at the same time. The overlap doesn’t need to cover an entire work day but there must be some block of time every day during which colleagues can have conversations and participate in collaborative exercises.
SHIFT: No more heroes
As we’ve continued to work with a wider variety of teams there are still many designers who resist Lean UX. One reason? Many designers want to be heroes.
In an environment in which designers create beautiful deliverables, they can maintain a heroic aura. Requirements go in one end of the design machine and gorgeous artwork makes its way out. People “ooh” and “aah” when the design is unveiled. Designers have thrived on these reactions (both informal and formalized as awards) for many years.
We’re not suggesting that all of these designs are superficial. Schooling, formal training, experience, and a healthy dose of inspiration go into every Photoshop document that designers create—and often the results are smart, well considered, and valuable. However, those glossy deliverables can drive bad corporate decisions—they can bias judgment specifically because their beauty is so persuasive. Awards are based on the aesthetics of the designs (rather than the outcome of the work), hiring decisions are made on the sharpness of wireframes, and compensation depends on the brand names attached to each of the portfolio pieces.
The result of this is that the creators of these documents are heralded as thought leaders and elevated to the top of the experience design field. They are recognized as the “go-to” people when the problem has to get solved quickly. But can a single design hero be responsible for the success of the user experience, the business, and the team? Should one person be heralded as the sole reason for an initiative’s success?
In short, no.
For Lean UX to succeed in your organization, all types of contributors—designers and nondesigners—need to collaborate broadly. This can be a hard shi
ft for some, especially for visual designers with a background in interactive agencies. In those contexts, the creative director is untouchable. In Lean UX, the only thing that’s untouchable is customer insight.
Lean UX literally has no time for heroes. The entire concept of design as hypothesis immediately dethrones notions of heroism; as a designer you must expect that many of your ideas will fail in testing. Heroes don’t admit failure. But Lean UX designers embrace it as part of the process.
SHIFT: From BDUF to Agile-fall: same thing, new day
In the Agile community, you sometimes hear people talk about Big Design Up Front, or BDUF. We’ve been advocating moving away from BDUF for years. But it wasn’t always that way.
In the early 2000s, Jeff was a user interface designer at AOL, working on a new browser. The team was working on coming up with ways to innovate on existing browser feature sets. But they always had to wait to implement anything until Jeff created the appropriate mockups, specifications, and flow diagrams that described these new ideas.
One developer got tired of waiting and started implementing some of these ideas before the documents were complete. Jeff was furious! How could he have gone ahead without design direction? How could he possibly know what to build? What if it was wrong or didn’t work? He’d have to rewrite all the code!