Collaborate Better Handbook
07

Building Together

Go farther

by Eli Woolery

 

A well-known proverb says: “If you want to go fast, go alone; if you want to go far, go together.” In this chapter, we’ll investigate different ways of building together. We’ll hear from Seth Godin about why starting a project with writing will keep you on track. John Cleese will teach us why writing helps us build on one another’s ideas. 

From people like Sandy Fershee (who used to lead D-Ford Detroit, Ford’s design lab), and from Joanna Peña-Bickley (who led research and design for the Alexa team at Amazon), we’ll learn about why prototyping is critical. We’ll finish up by exploring the importance of getting prototypes into the real world and testing with users, with stories from Dan Winger at LEGO, Marty Cagan at Silicon Valley Product Group, and Margaret Gould Stewart at Meta.

Start with writing

When thinking about building a new product, writing isn’t necessarily the first thing that comes to mind. So I was a little surprised when Jony Ive—the famed Apple designer whom I’ve had the good fortune to welcome as a guest lecturer for my product design class at Stanford—told our class that he starts all of his projects with writing.

He went on to tell a story of how his landscape designer started a project with him. The designer could have provided Jony with plans and illustrations, but instead, he wrote about specific details that would be impossible to convey otherwise: how the night garden would smell a certain way when it was in bloom, and how the paving stones would radiate warmth from the day before as you walked through the garden in the evening.

When Jony started projects at Apple, he felt that the lack of restrictions in writing opened up avenues for designing new products that more constrained modes like sketching or 3D modeling would have blocked. Not to mention that written communication might be the only thing connecting teams with diverse skill sets, like engineering, marketing, and design.

No matter what your role is in your organization, developing your writing skills can not only help you advance your career, but can also make you a better leader and contributor to your team. Seth Godin recommends writing every day in a blog or journal. As he says, “if you go to bed knowing you gotta write something, when you wake up in the morning it will be a productive opening for you.”

Now, we don’t want to get hung up on, “Oh, it has to be a design brief, and we have to fill in all the blanks.” Because that’s a form of hiding, that if you read most big company design briefs, they say absolutely nothing. They’re like mission statements. They’re undeniable.1

The purpose of writing is to write something that is deniable: to write something that says this, not that. And all of us have words. And even if you’re not well-spoken you can put those words in order on the screen or on a piece of paper. —Seth Godin

Writing regularly can also be a way to set career and life goals for yourself. Jason Mayden, entrepreneur and former designer for Nike’s Air Jordan brand, writes a creative direction for himself every few years. It helps him stay true to his goals and take action when he strays off course.

In addition to the personal motivation gained from having a daily writing practice, writing can also help leaders communicate with their teams, building cohesion and trust. When Katrina Alcorn took over one of the largest design teams in the world (she manages a team of over seven hundred people at IBM), she used her background in journalism to try to understand the challenges her team was facing, and began to write blog posts as a way to get feedback.

After she published her second post, her team asked her to keep going. They found that seeing her vision written down gave them a chance to think about it and react to it. The series of five blog posts she wrote for IBM has provided the foundation for the vision she is formalizing for her team.

So I was a journalist and a documentary filmmaker. That’s where I did my graduate work. I had this whole very short but exciting career. I made a PBS show that was broadcast on many stations. 

And when I switched to tech, I noticed that these skills around writing and speaking and just putting the right words to thoughts were missing in our industry. And so I do feel like that’s something that set me apart over the years, and I’m still figuring out how to use those skills in this environment. —Katrina Alcorn, IBM

Writing doesn’t have to be a solo act, and writing with your colleagues can also provide an opportunity to build on one another’s ideas and be more innovative. In the realm of comedy, John Cleese found that working with a collaborator helped him not only gauge whether a particular bit would be funny, but also get somewhere he would never have gotten on his own:

Now, I’ve got to the point where I have a pretty good idea whether it will be amusing, but what I really can’t tell, even at my advanced age, is whether it’ll be a little bit amusing or a lot amusing. Sometimes I write things I think are hilarious and they just get sort of … a reasonable amount of laughter. 

And then I write something that I think is fairly sort of straightforward and obvious, and it gets a huge laugh. So it’s very helpful to have another person there to give you a bit of confidence and to bounce things off. And the other thing it causes is that you build on each other’s ideas. So you can finish up by getting somewhere that you would never have got on your own, because of course a misunderstanding can lead to something wonderful. So it doesn’t really matter when you’re creating. There’s no such thing as a mistake. —John Cleese

One concrete way to kick a project off with writing is to use a product-planning template. The design team at IBM uses their template to prepare for a productive product-planning session by creating a shared product strategy, involving a cross-functional team, and imagining new products or refining existing ones (Fig 7.1).

Equipped with a written project plan and the knowledge gained from understanding your colleagues and customers, it’s time to start answering questions about your most critical assumptions. This is where prototyping comes in.

Prototype your way forward

Prototyping is the act of creating a version or subset of the product, service, or feature you are working on that your colleagues, customers, and/or users can interact with and that your team can get feedback on. Prototypes help us learn, resolve disagreements, and test ideas quickly and cheaply.

Once your team is aligned on the problem you are trying to solve and has generated lots of ideas to explore, it’s time to come back to the convergent, “tortoise mind” mode of working. You can now begin building prototypes to test your team’s hypotheses and answer critical questions about your project.

Prototypes can take a wide variety of forms, from low-fidelity pen-and-paper mockups to fully functional applications and physical products. It’s important to consider your audience when deciding on the fidelity of your prototype. To work through simple user interface issues within a design team, pen-and-paper sketches and wireframes can be very fast and effective. But if you’re working with other colleagues or customers, you’ll likely need a higher-fidelity prototype to make sure they understand the intent, and aren’t taken out of the experience by too much explanation and hand-waving.

When she led the design lab at Ford, Sandy Fershee would create a range of prototypes, from sketches on paper to medium-fidelity prototypes made from foam core and plywood, with digital interfaces wired in.

And then you would see some of the prototypes that would be inclusive, both of physical and digital, and it would span a whole horizon of low fidelity to medium fidelity—because of course in the automotive world, [a] high-fidelity prototype is really like the actual vehicle.

And of course, beyond that … we’d be running or simulating things that might look more like app development as you know it today. So you’d see a whole range of different prototyping solutions and action going from the very earliest sketch phase on paper, all the way to potentially working prototypes to demonstrate an MVP. —Sandy Fershee, former director of D-Ford Detroit

Prototypes can also be used to envision a future that doesn’t yet exist. Jony Ive spoke to my class at Stanford about creating elaborate—if somewhat jerry-rigged—prototypes to simulate multitouch devices before the technology was actually built. And when she led design for Alexa devices at Amazon, Joanna Peña-Bickley would rely on prototypes to “pressure test [ideas] against the future.”

This is something that I have to tell you as an Amazonian leadership principle that we live and take very seriously. Customer obsession means that we start with our customer and we work backwards from there, and we work vigorously to earn and keep their trust, and we pay attention. We’re paying attention to our competitors, but we obsess over the customer.

But at the same time you are balancing the ability to think big, because we do believe that thinking small is a self-fulfilling prophecy. I think that one of the things that Amazon has done remarkably well is to be a leader that has created and communicated a bold direction that inspires our results.

And when you couple that with this idea that we are here to invent on behalf of the customer, the customer may give us some really good signals as to where’s the space to pay attention to, but we expect and require innovation and invention from our teams to to go, “That’s super complex, that area. How do we simplify that?” It’s about being externally aware and looking for new ideas from everywhere … [and] always try to be one or two or three steps ahead of that customer in the area of invention and the simplification of our experiences. —Joanna Peña-Bickley, former head of research and design for Alexa devices at Amazon

With so many options for creating prototypes, it can be a little daunting to choose a path forward. What makes a good prototype? In most cases, it’s quite simple: a good prototype is the fastest, cheapest, simplest option for answering questions about the biggest risks in your product, service, or feature.

There is, of course, an almost infinite number of risks your project might face, so how do you identify the most important ones? Marty Cagan, author of Inspired: How to Create Tech Products Customers Love, talks explicitly about what those risks are: value, usability, feasibility, and viability. As he explained to me and Aarron:

When I go and look inside a team, first of all, are they tackling the risks upfront? What that means is every product has these four risks I alluded to before, it’s gotta be valuable. It’s gotta be usable. It’s gotta be feasible. It’s gotta be viable. [For] a lot of things we build, those are not straightforward … that’s super hard. 

Obviously, we use our judgment and we decide: Where are the risks? And then based on those risks, we tackle them. Normally it’s tackled by prototype. And of course, I like to make sure everybody understands that there is no one kind of prototype. There are at least four major kinds of prototypes and every good team I know needs to be capable in all four so that they use the right tool for the job.

There are different risks … and so there’s different prototypes around them. And also we have different kinds of products with different kinds of customers. And so you have to make sure you’re picking the right kind of prototype for the job, the right tool for the job. And then of course you have to decide the right way to test that prototype. —Marty Cagan, Silicon Valley Product Group

Marty goes on to define the four different types of prototypes he believes are critical for addressing risks in digital products: user prototypes, feasibility prototypes, live data prototypes, and hybrid prototypes:

Yes, there are four kinds of prototypes. The most frequently used prototype—and I love them for this, but it’s unfortunately not something that works for some very important cases—[are] user prototypes, which are simulations. These prototypes, they can look very real. In fact, they can be so well done that you don’t really have a way to know they’re not real … but they’re totally fabricated, totally fake. Those are the most common, there’s many tools … that are terrific for that.

We also have some things, though, that are very different. Like a feasibility prototype is when the engineers are not sure they actually algorithmically know how to build something; machine learning is a popular example right now. In a feasibility prototype, this is actually some code—it’s not a lot of code, but it is some code—and so it does require some developer time. Most prototypes are actually created by the designer, but there are a couple of exceptions and this is one of them. 

Feasibility prototypes have been around a long time. They are critical for when they’re needed. They’re not needed all that commonly, but when they are, they’re critical to do. And in fact, any time I find one of those efforts that everybody thought was going to be like two weeks and it’s already been going for months, inevitably, they didn’t do a feasibility prototype and they should’ve. They could have, and should have, known this way, way at the beginning. Very often though, the engineers, it was already committed before the engineers even saw it. 

The third kind of prototype—[a] fabulous kind of prototype, but the hardest one to explain—they’re called live data prototypes. These are created when we actually need to collect some data to see what’s actually happening, when we’re not sitting down with a user face to face. Live data prototypes are kind of special because they aren’t products, but they do collect actual live data, under very controlled situations and usually with very limited distribution. So it’s not five or ten users, but it may be a few hundred, it may be a few thousand, it depends on the scenario. These are also created by a combination of the engineers and the designer, but they’re very limited. A live data prototype might take a few days to create instead of a few hours to create like a user prototype. 

And then the fourth kind of prototype is a custom prototype called a hybrid, where you look at the four risks—value, usability, feasibility, viability—to decide what are the particular risks in this particular product. And you create one prototype that’s meant to address each of those risks. So it’s often got elements of user prototypes, elements of live data prototypes, elements of Wizard of Oz prototypes. Each scenario is very different, but some of the most creative prototyping going on in our industry are actually hybrid prototypes. So those are the four main kinds of prototypes. There’s lots to learn behind each of those four. —Marty Cagan, Silicon Valley Product Group

Once you’ve built your prototype(s), it’s time to get them out into the real world, to test your hypotheses with your colleagues and customers.

Test your assumptions

For a long time, focus groups were seen as the gold standard for getting consumer reactions to things like new products, advertising campaigns, movies, and TV shows. Get a group of people in a room together, pay them a few bucks, provide them with coffee and a snack, and ask them what they think about your project.

The problem is that they are highly flawed. As Jacob Nielsen, founder of Nielsen-Norman Group, writes: “As with any method based on asking users what they want—instead of measuring or observing how they actually use things—focus groups can produce inaccurate data because users may think they want one thing when they need another.” Not to mention the fact that in front of other people—strangers especially—people won’t often say what they truly think, or will take the lead from the loudest voices in the room (Christian Madsberg speaks to the flaws of focus groups in Chapter 4 as well).

Instead, consider following Seth Godin’s lead: “It doesn’t matter what people say. Watch what they do.” Godin tells the story of a focus group that was asked to evaluate a new $100 electronic gadget. Everyone loved it, and spoke excitedly about all the new features they found delightful.

But when given the choice between being given one of the new gadgets or taking home $25, everyone took the cash. In short, one of the few things you can learn from a focus group is how much people are willing to pay for something, if you set up the experiment correctly.

Testing qualitatively

There are better ways to test your prototype. The first way is qualitatively: one-on-one with your customer, in such a way that you can observe their reactions. At LEGO, product designer Dan Winger knows that while he can hazard a guess at what kids will like, he’ll never really know until he and his team can observe them interacting with a new prototype:

We try to test every couple weeks at the end of our sprint cycle. So, we’ll create a minimum viable product, sometimes it’s a matter of mocking up [the] UI for apps or building actual products with LEGO bricks. You get initial insights and then take those insights and further refine the prototypes and the experience, and reloop. —Dan Winger, LEGO

Often the design team will take the lead on user research and testing prototypes, but it’s a lot more helpful if others on the team are involved as well, from developers to marketers. At Google, when she led the UX team for Google Maps, Margaret Lee created a practice of including engineers in user tests. 

Although she faced some initial skepticism, the developers eventually began to see real value in the experience. They almost always found new bugs to squash, but, more important, they gained empathy for their users and the challenges they faced.

Testing quantitatively

We prefer to test qualitatively because it’s fast and cheap, but that is not enough for some of the things we do. And so that’s when we use quantitative techniques. Any good product team is trained in these skills and these techniques so that they can choose the right tool for the situation. —Marty Cagan, Silicon Valley Product Group

As Aarron discussed in Chapter 4, the other way to test prototypes or new features is to do so quantitatively, running experiments at scale with tens, hundreds, or even thousands of users. The most well-known quantitative test is the A/B test, where different customers are shown different versions of a feature, focusing on a single variable, and data is collected on customer behavior. Google, under Marissa Meyer’s product leadership, famously tested forty-one different shades of blue for a toolbar button before landing on a successful variant.

Again, the challenge with qualitative testing is that it will tell you what people are doing, but not why they are doing it. That’s why it’s important to balance quantitative and qualitative research. As Margaret Gould Stewart, vice president of product design and responsible innovation at Meta, told us (emphasis added): 

I think every time we take engineers or product managers and designers out into the field and they’re able to observe the real people who are using our products, either for their personal lives or for their work … we get very inspired to do the best job that we can, but we also come back understanding that in those charts and graphs, with all of those unfathomable numbers, every single one of those data points is a human being, with a family, or livelihood, or some goals they’re trying to accomplish. It just brings back the importance and the responsibility that we have to do the best job that we can.

In addition, it helps us again to not only understand the whats, which is what the numbers are really good at—“This is what people are doing”—but it helps us understand the why. Quantitative data is not actually that effective at understanding why those things are happening, so I think it’s really the combination of things that help you get to that point where you’re assessing success, not just measuring it, because not everything that’s important can be measured.

It’s combining different types of data, both qualitative and quantitative; it’s making sure that we never forget that there are humans behind these numbers; it’s getting people out of … the Silicon Valley bubble that’s very easy to live inside of. We have the benefit of being able to travel and do research in countries all around the world, just to really face on a regular basis the diversity of the population we’re designing for. And seeing firsthand the impact, hopefully positive impact, but sometimes the areas where the products aren’t doing what we want or expect them to do, and then being in a much better position to respond to that. —Margaret Gould Stewart, Meta

The very best teams combine qualitative and quantitative testing and research in such a way that they get insights into customer behavior that lead to good product decisions. At Netflix, Rochelle King, vice president of creative production, calls this being “data-informed” versus “data-driven.”

I think the difference is not letting the data make the decision for you. Data-driven, you’re just letting the data tell you what answer to do, what’s the right thing, and just letting that push you. Data-informed is that data is one of the many inputs that you use in making your decisions. And so it’s informing your decision, but it’s not driving the decision. —Rochelle King, Netflix

In Chapter 4, Aarron highlighted how Marty Cagan believes that good product teams get into a regular cadence of both quantitative and qualitative testing, “going to the customer no less than three hours a week.” And if the team is working on something intense, “like a redesign or a new app, [they’re] probably doing it more like five to ten hours a week.” He cautions that, as previously discussed, you should be careful with focus groups and “be super careful with surveys, unless you really know what you’re doing.”

If you’re able to include as much of your team as possible in this entire process, from writing the initial product planning document, to creating early prototypes, to testing with customers quantitatively and qualitatively, you’ll find that not only will you make better product decisions, but your team and other stakeholders are also much more likely to be aligned on those decisions.

Conclusion

Building together will help you to go far, but sometimes the hardest part is taking the first step. Often that first step requires getting your team to accept that you don’t know where your explorations and experiments will take you. Being comfortable with ambiguity is one of the most common traits in highly creative and innovative individuals and teams.

If you can embrace ambiguity and take the time to understand your colleagues and customers, you’ll have a solid foundation for creating experiments that align with your mission and vision. You’ll learn together with your team, and you’ll make better products and experiences for your customers. 

If we’ve learned one lesson from all of the people we’ve interviewed for the Design Better Podcast, it’s that a sense of curiosity and an ability to learn from other disciplines are fundamental to successful leadership and creativity. We have taken this lesson to heart. We hope that you will, too, and we can’t wait to see what you go on to create.

 1At first glance, this might seem to undercut the importance we place on mission and vision in Chapter 5. What we believe Seth is trying to say here, though, is that, as with any tool or framework, there can be good and bad ways to execute a mission statement. Many examples of corporate mission statements are bland and unspecific. That’s what we want to avoid.

About the Authors

Eli Woolery
Senior Director of Design Education / InVision

Eli Woolery is the Senior Director of Design Education at InVision, and co-host of the Design Better Podcast. His design career spans both physical and digital products, and he has worked with companies ranging from startups (his own and others) to Fortune 500 companies.

In addition to his background in product and industrial design, he has been a professional photographer and filmmaker. He teaches the senior capstone class Implementation to undergraduate Product Designers at Stanford University. You can find Eli on Twitter and Medium.

Aarron Walter
Author and co-host of the Design Better Podcast

Aarron Walter is the co-host of the Design Better Podcast, and author of Designing for Emotion. He was the Director of Product on the COVID Response team at Resolve to Save Lives, and prior to that, the VP of Design Education at InVision. He founded the UX practice at Mailchimp where he helped grow the product from a few thousand users to more than 10 million. He’s the author of a number of books, the latest of which is a second edition of Designing for Emotion. Aarron’s design guidance has helped the White House, the US Department of State, and dozens of major corporations, startups, and venture capital firms.

You can find Aarron on Twitter and LinkedIn.

Back
Back
Loading...
Loading...

The visual collaboration platform disguised as an online whiteboard
Try Freehand