Designing for the Internet of Things

Chapter 6. Understanding Critique

Conversations Matter

Whether you’re a developer, project manager, designer, business analyst, and so on, it’s more than likely that you’ve been in a meeting in which the topic of “design” has come up explicitly or otherwise. No matter what you’re designing—a tool, a service, a product, a brochure, a logo, whatever it might be—you’re going to be involved in conversations about how it works, what it can do, what it contains, how it looks, and more.

Collaboration and coordination are critical elements in the success of projects in most (if not all) modern organizations. There isn’t a single individual who is responsible for coming up with an idea, designing it, building it, selling it, and supporting it. Instead, these responsibilities and the expertise that come with them are divided among a variety of contributors who each bring knowledge to the team. So, we need to work together, combining our skills and know-how. And to work together, we need to talk with one another. We need to discuss what it is we’re designing, why we’re creating it, and how it will all come together.

But as many of us have experienced, conversations about design can turn painful. At a minimum, when these discussions go wrong, they delay progress. They seem to go nowhere. People disagree, argue, and team members walk away not sure what to do next.

Although individual instances like this might not seem like a huge deal, it’s the culmination of discussions that go this way that really affects a team. Over time, delays accumulate; the resulting lack of momentum and repeated questioning of what to do next gives rise to a sense that none of the team members seem to agree, which has a tremendous negative impact on people. They stop wanting to collaborate and they begin to care less and less about the project. In some cases they begin to silo themselves, feeling that because they can only control their own output, it will be their sole focus without regard to the other team members and how it effects them.

In some cases, though, these conversations can become much worse. As people talk about what they think should or should not be a part of the design, it’s not uncommon for individuals to become emotional. For some, this can be difficult to control, which can lead to people getting defensive, tempers flaring, yelling, berating, and lines being crossed.

The intent of this book is to help make the conversations that happen as a part of projects more effective and productive with regard to their objectives. These discussions are always happening. Sometimes, they take place in a formal setting such as a meeting. Sometimes, they’re more informal, perhaps when we’re standing in line to pay for a cup of coffee. No matter where these conversations occur, we need to be able to discuss our work.

Unfortunately, we don’t often take time to examine these conversations and understand what makes them good or bad. This book looks at the elements of these conversations and the patterns through which they arise. It also describes best practices for making these conversations more productive to projects and toward strengthening a team’s ability to collaborate through incorporation of critique, an often-overlooked component of the design process.

The Problem with Asking for “Feedback”

Requesting feedback on a design or idea is one of the most common ways design discussions are initiated. Feedback is a common element and activity in not just our workplace cultures, but in many social cultures, as well. “Feedback” is a word that’s become ingrained in our vocabulary. We use it all the time, à la “I’d love to get your feedback on something...”

During a project, a designer might just grab someone at a nearby desk because she wants to take a break from putting her design together and think about what she’s done so far. Or the feedback request might be part of a planned milestone or date in the project’s timeline, often called Design Reviews.

It’s not that either of these is a bad time to get other opinions. Rather, the real problems we encounter come from the word “feedback” itself, what it means, and how we ask for it.

What Is Feedback?

The issue with feedback lies in how nonspecific it is. Feedback itself is nothing more than a reaction or response. Designers talk about feedback and feedback loops as an important element in design all the time. In a feedback loop, after an individual takes an action, the object or environment on or in which that action has taken place changes (or reacts). The individual then interprets that change or reaction in consideration of what they’ll do next. (See Figure 6-1.)

Figure 6-1. The three stages of a feedback loop

Figure 6-2 depicts a feedback loop designed by the team at Ready For Zero. In it, as a user manipulates the sliders or values of the various fields in the form to figure out her payment plan on a credit card, the other values all adjust instantaneously. This allows the user to see the effect that adjusting a value, like her monthly payment amount, will have on the total amount she pays and how much she might save.

Figure 6-2. Example of a feedback loop in UI design from Ready For Zero

That reaction—the noticeable change in the appearance or state of the system—is the feedback. It is the system’s response to what the user has done. Feedback is a reaction that occurs as a result of the user doing something.

In human-to-human interactions such as the conversations we have in our projects, the feedback we receive might be nothing more than a gut reaction to whatever is being presented. And to be quite honest, even though we might not want to admit it, that’s often all it is.

Someone’s reaction tells us a bit about how he feels regarding what has happened or been designed, which can be useful in some cases, but also presents us with some challenges. Chapter 7 points out that a reaction on its own doesn’t go far enough to be helpful in allowing us to improve our designs and move forward in our projects. Not only that, the reaction might be based upon the personal biases and preferences of the individual who is reacting, which might or might not align with a mindset representative of the audience for our product.

There is a popular saying in many design communities: “You are not the user.” It’s important to keep that in mind when we’re discussing the things we’re designing and deciding what should or shouldn’t be a part of them. It’s not that we only want feedback from users, but when collecting feedback from people in other roles we need to ensure that the user’s needs, goals, and contexts are kept in mind.

The problem with asking for feedback is that, most times, we aren’t being specific enough in describing what we want feedback on and why we are asking for it. Sometimes, the feedback we receive might just be a gut reaction. Sometimes, we might get back a list of instructions or suggestions on what to change. Sometimes, we might get comments that describe how what we’ve designed doesn’t match what the critic would have designed. Weeding through all of that feedback to try to determine what’s of use to us—what will help us identify the aspects of our design that we should iterate upon—can be a struggle.

Central Idea

Feedback is an important part of the design process, but the term itself and the way we often ask for it is very broad and can produce conversations that aren’t useful. We can improve these conversations by understanding what feedback is and how we use it.

Three Kinds of Feedback

There are three forms of feedback, all of which vary in their degree of usefulness to us in the design process. Understanding these three kinds of feedback can help us understand the conversations we have with our teams and improve our own ability to react to and use feedback to strengthen our designs.

The first two types of feedback

Figure 6-3 illustrates how reaction-based feedback tends to be emotional or visceral. It happens quickly and instinctively. This type of feedback is often filled with passion. It’s driven by someone’s personal expectations, desires, and values. Essentially, it’s a gut reaction.

Figure 6-3. An example of reactive feedback

There is another kind of reaction-based feedback that is driven by the individual’s understanding of what they are expected to say, typically driven by a cultural understanding or what they think the presenter wants to hear. In this case, the reaction itself isn’t in regard to what’s being presented; rather, it’s in response to simply being asked for feedback in the first place. Examples of this kind of feedback often take the form of “That’s wonderful! Great work!” or “I love what you did with...”

Why it can be an issue

At best, this kind of feedback informs us about the subconscious reaction the viewer has to what you’ve designed. These kinds of reactions are something we do want to understand when designing a product or service. It’s not ideal to try to sell something potential customers or users cringe at or grumble about the second they see it. But are the people from whom you’ve asked for feedback reflective of your design’s actual audience? Are they looking at it the same way your potential users would? Does this reaction divulge anything specific about any of the design decisions you’ve made so far or their effectiveness?

Direction

Direction-based feedback, as seen in Figure 6-4, typically begins with an instruction or suggestion. In many cases that’s also where it ends. In this form of feedback, the individual providing it is often looking for ways to bring the design more in line with their own expectations of what the solution should be. You might also have encountered examples of this kind of feedback that start with phrasing similar to, “If I were to do this...” or “I would have...” or “I wish...”

Figure 6-4. An example of directive feedback

In all of these, the individual giving the feedback is trying to communicate her own vision for the design. It might be because she has her own detailed solution already in mind, or it might be that she feels a problem is not being adequately solved. In some cases, the individual will go on to describe why she is making the suggestion, which can shed a bit more light on her thinking and motives.

Why it can be an issue

Similar to reaction-based feedback, direction-based feedback without any explanation indicates nothing about the effectiveness of your decisions in meeting the design’s objectives. Sure, if the person giving you feedback is the one who will ultimately approve the design, she might supply you with a to-do list that you could act upon to get her approval, but getting that approval and creating an effective design are not necessarily the same things.

For situations in which the individual also gives some explanation as to why she is making the suggestion, you at least begin to understand the impetus and perhaps the issue she’s trying to address with it. But, it still does not help you understand how or why the design you have is or is not effective at addressing that problem.

Additionally, when left unchecked, this type of feedback leads to problem solving which, although an important part of the design process, is counterproductive to the conversation you’re trying to have. It’s not that the direction itself that is being given is a bad idea, but at this point it’s out of place.

For now, what’s most important is to understand what these forms lack in terms of their usefulness in helping us to improve our designs.

What We Really Need Is Critical Thinking

Critical thinking is the process of taking a statement and determining if it is true or false. When we’re designing something, we’re doing so to meet or achieve some set of objectives. When looking for feedback on our designs, we should be working to understand whether we believe that what has been designed will work to achieve those objectives. We should be looking for a form of analysis to take place. And that’s exactly what critique is.

Critique: The third form of feedback

It’s this form of feedback that is most helpful to us in understanding the impact of our design decisions.

Good critique is comprised of three key elements:

• It identifies a specific aspect of the idea or a decision in the design being analyzed.

• It relates that aspect or decision to an objective or best practice.

• It describes how and why the aspect or decision work to support or not support the objective or best practice.

Figure 6-5. An example of critique

Let’s look at Figure 6-5 and examine its parts to see how they align with these three elements:

• If the objective is for users to seriously consider the impact to their bank balance before making a purchase...

  This states the objective the person giving the feedback is analyzing.

• ...placing the balance at the bottom of the screen at the same size as all the other numbers...

  This segment identifies the design choices made that are being analyzed.

• ...isn’t effective because it gets lost in all of the other information.

  This part tells the designer that the critic does not believe the choices he made will be effective and why.

Critique isn’t about that instant reaction we might feel when seeing something, or about how we would change someone’s design to better solve an issue. Critique is a form of analysis that uses critical thinking to determine whether a design is expected to achieve its desired objectives (and adhere to any pertinent best practices or heuristics).

Those objectives can be any number of types of things. They can be about utility, for example giving someone the ability to complete a task. They can be about metrics and measurement, as in increasing the number of conversions for a particular call to action. Or, they can be experiential, for example making someone feel excited or surprised by something.

Knowing what we want and what we’re asking for makes all the difference in how our conversations play out. It might seem like little more than semantics, and it’s damned difficult to give up using the word “feedback” when asking to talk with people about an idea or design (in fact, we’ll be using it over and over again in this book). But, as you’ll see as you read the coming chapters, what’s important is to understand the differences in forms of feedback and to use that understanding to inform how you ask people and facilitate the resulting conversations.

Central Idea

Feedback encompasses three forms: reaction, direction, and critique. Reaction and direction are limited in their ability to help us understand if the design choices we’ve made might work toward the product’s objectives. Critique, a form of analysis that uses critical thinking, is feedback that focuses on exactly that understanding.

Critiquing Solo

This book centers on critique as a form of conversation we have with our teams. But it’s important to note that an individual can and should also critique alone, analyzing his own work.

When designing something, the brain operates as a toggle, switching between creative thinking—where individuals are generating ideas or assembling parts of ideas—and analytical thinking—where they are determining whether what they’ve designed so far is in line with what they are trying to achieve. Experienced designers, artists, engineers, and others have learned how to be deliberate in controlling when to make this toggle, periodically pausing their creative work to take a step back and critique what they have so far.

Why Critique Is So Important

Throughout this book we’ll dive deeper into the various ways critique fits into the design process, but as we get started, it’s important to identify these patterns and benefits in order to keep in mind the broader application of the concept.

Critique Builds Shared Vocabularies

Have you ever noticed how as people spend more and more time together they begin to talk like one another? They begin to use the same phrasing of words and names for things. This is a natural occurrence in social groupings—it’s part of a process called acculturation.

Intuitively, we seek out efficiency in communication with others. Communication between individuals grew out of the need of one individual to produce action by another. It isn’t very effective if we need to spend all of our time getting our point across. As we build a shared understanding of what words and phrases mean among a group, we instinctively begin to use them over other words that might mean the same thing. By avoiding words that aren’t as easily recognized by the others in the group, we streamline and improve the quality of our conversations.

One challenge project teams face in collaboration is the variety of language used by people in different roles. Members from IT, design, and business might all have different ways of referring to the same thing. By bringing your project team together to critique on a recurring basis, you provide a venue for this shared vocabulary to build up and take hold. As that vocabulary is being built, it’s happening across roles and silos, improving the ability of team members to communicate more efficiently with members of other roles.

Critique as Consensus Finder

Design-by-committee and “frankensteining” (the mashing up of design elements, features, and so on from various ideas and sources) are much-hated phenomena in the design community. Both terms are often used to imply the misguided amalgamation of ideas into a final design without any attention paid to their disharmony or whether they really work to achieve the desired outcomes.

In environments where this takes place, the driving force is typically to get those involved, particularly stakeholders, all saying yes to what is being designed without regard to whether what is being designed is actually the best solution. And so, bits and pieces are added to appease the various influencers of the project. But here’s the thing: there isn’t anything wrong with combining elements from different ideas to make a new one. The weakness here is the reasons why the elements being combined are selected. Critique is what’s missing from the process. Selections aren’t necessarily based on the elements of an idea that are most effective toward a particular objective.

In these environments, critique might still be happening, but it’s typically found happening in a small corner of the project team. A few people, maybe the designers and developers, are doing it but the entire team isn’t.

What Aaron and I have found in teams that carry a culture of critique is that, at any time, these discussions involve members of the team from across departments and disciplines. It becomes a natural part of the way they talk with one another. It isn’t always a formal meeting or a specific request such as, “Could I get you to critique something with me?” As the project progresses and decisions are made, critique is just part of the conversation. Members are consistently focused on and discussing the elements of the design that work best to achieve its goals. Consensus begins to be found around which ideas are stronger or weaker, and the design is strengthened as a result.

Years back, on a project that involved the creation of a new insurance application and processing platform, I got a call from one of the developers. She had been working on building out some of the functionality I had prototyped for the initial submission of an application. While doing so, she was stopped by a stakeholder who had an idea for a new piece of functionality that they were hoping could be added to the screens. A few minutes later, the developer had given me a call (I worked in another office), set up a screen-share, and she, the stakeholder, and I were discussing the new functionality and the ideas for its inclusion in the design.

As we did, we referred back to the task flows and scenarios we’d created for this particular set of functionally as well as the goals we had for individuals using it. In doing so, we quickly realized that the functionality itself didn’t fit the objectives we were after. It would have created an awkward branch in the task flow and more work for the user. We also saw, though, that the main point of this new functionality was to give the users (insurance agents) a view of a key piece of data that had been missing from our designs. When we realized that and agreed that being able to see that data was important to our objectives, we were able to generate a few ideas for adding the data value to the screen in an effective manner. The entire process took less than 30 minutes, and afterward, the stakeholder, developer, and I all walked away, confident that we had improved the design.

ADAM

In the preceding story, even though critique wasn’t sought out explicitly, it was a key part of the conversation and decision-making process. This is what we mean when we talk about critique being part of a great team’s natural language. Yes, the team might carve out specific times and meetings for a formal critique session, but critique also finds its way into other conversations. The team understands that in order to make good decisions about what to design and how to design it, it needs to think critically about its options and objectives.

Critique as Iteration Driver

Critique is part and parcel of an iterative process. If we’re going to look at design as an iterative process—something that takes a creation and evolves it from idea to final product and further—there need to be points in our process that drive that evolution and indicate where changes should be made moving forward (that is, the next iteration).

Many organizations use various testing and observation methods such as usability studies and beta releases to do this today, but depending on your market and audience, these approaches can take a lot of time. Sometimes, you just need to take a quick step back. In the early stages of design, my team at Mad*Pow might iterate three or four times on a design in a single day. All we do is ensure that after sketching and developing ideas for a period of time, maybe as short as 10 to 15 minutes or as long as a few hours, we stop and examine what we have so far against our objectives and best practices. Iterations don’t always have to be huge readjustments of the entire design. Sometimes, they might be much smaller and focused on a handful or even just one interaction, or flow or design element.

In these cases, the drivers of our iterations are the discussions our teams regularly go through. Most are self-induced, meaning that they’re not dictated by a date in someone’s project plan; rather, they can be initiated by the designer or design team when they feel like it’s time to take a break from designing and look critically at what they have so far.

Central Idea

Because critique, when done well, focuses on analyzing design choices against a product’s objectives, it also provides teams with additional benefits, acting as a mechanism for building shared vocabulary, finding relevant consensus, and driving effective iteration.

Critique as a Life Skill

By now, we hope that you are thinking about the processes your own organization goes through in projects. That’s exactly what this book is about, but hopefully you’ve noticed that what we’re really talking about here is something that applies beyond the boundaries of a business or organization. It applies any time and to any activity or thing you want to improve, whether it be improving a new recipe; honing your skills in Ultimate Frisbee; playing the ukulele; or painting portraits of people’s pets with macaroni, hot-glue, and food coloring. Whatever it is, you can incorporate critique to help you improve upon it.

As mentioned earlier, critique is really about critical thinking. As we work toward doing or designing something with a set of objectives in mind, we always have the opportunity to stop and analyze what we’ve done so far to better inform how we might go forward. Critique is an act of reflection. It is part of the learning process. If Aaron and I might be so bold as to say, critique is a life skill, not a design skill.

Giving Critique the Attention It Deserves

If critique is so important, why don’t people pay more attention to it? Why don’t teams take time to practice and talk about it?

Improving the quality of critique, or more specifically, improving a team’s skills at facilitating and giving critique, should become a priority. Doing so can be tremendously valuable and can result in better collaboration, efficiency, and designs. The first steps to doing this are to overcome three myths that are often part, if not all, of the cause for critique to be overlooked.

Myth 1: Critique is a meaningless term used to make feedback sound more important

This one is pretty weak, but it’s worth addressing because we’ve seen it come up in more than a few organizations with which we’ve worked.

In media today, the term “critique” has become a label used to categorize anyone’s opinion on something. Media personalities, writers, pundits—anyone, really—can offer their perspective on a new product, service, or policy and call it a critique. It’s come to mean nothing more than one person or group’s thoughts on what another person or group has done. The aspects of critical thinking and of focusing on what the originating person or group’s intentions were have gone out the window.

But we know that that isn’t really what critique is about. Understanding the qualities that separate critique from other forms of feedback—and helping our teammates understand those qualities as well—results in more efficient, useful conversations.

Myth 2: We don’t need to talk about or practice how we give feedback

When your team engages in a postmortem or retrospective for a project, what do you talk about? Most likely you talk about the decisions that were made, maybe a little about the process with regard to the kinds of meetings you had or when they happened. Have you ever talked about the language you use when talking to one another? Have you ever talked about how specific conversations were framed and facilitated?

When we think about our processes we tend to focus on a level higher than where the quality of critique is really influenced. Talking is something we take for granted, and so the details of how we do it are often glossed over. But there is that old cliché: the devil is in the details. Or, more accurately, it should be that the devil is in ignoring the details.

The ways we talk to one another, initiate conversations, ask questions, and so on all effect how our conversations unfold. If we really believe that those conversations are important to our team and project’s success, then it stands to reason that thinking critically about them, talking about them, and practicing our techniques are important actions for improving them.

Myth 3: Critique is something only designers or other creative people do

Critique can sometimes be thrown into the “creative professional” silo as something only artists, designers, and the like do. It’s not for everyone else.

What individuals and organizations that fall into this trap fail to realize is that when a project is tasked with making something, no matter what it is, every single team member is a part of the design process. Design doesn’t just happen in the design department. It happens with every decision about what will or won’t be part of the final product, whether that’s a feature, a paragraph of content, a color pallet, a user interface pattern—anything.

If we truly want to improve our processes and improve the way our team members work together, we can’t ignore the details and we can’t silo our critical thinking. Yes, there are roles and responsibilities that each team member will carry based on their expertise and knowledge, but critical thinking about what we’re designing is a part of every member’s role.

Incorporating Critique and Moving Forward

The remainder of this book is about that role and the best practices and methods we have at our disposal for making sure it’s fulfilled. As we dive deeper into the details, you’ll begin to see just how pervasive critique can be, how many places it can pop up, and how many parts of your process it can help you to improve.

The ultimate goal for teams that are interested in improving conversations and collaboration with critique is not to add one more tool or type of meeting to their ever-growing toolbox. Instead, it’s to change the way we talk about what we’ve designed regardless of the type of meeting or conversation we’re in.

Critique itself is often referred to as a soft skill. Soft skills are often thought of as interpersonal behaviors and characteristics that influence how we interact and communicate with others. Whereas hard skills tend to be applicable to a specific task, action, or type of work, soft skills apply broadly across most activities and work. As we examine critique throughout the book, it’s important to keep in mind two key aspects:

Critical thinking

This is the examination of what you’re designing against the objectives for its creation.

Delivery

This is how you present your critical thinking to the others with whom you’re working.

It should also be noted that critique isn’t just about pictures. Often, it can be seen as a process that only applies to a wireframe or a visual design mockup or maybe a prototype, but in reality, critique can be applied to just about anything.

Any time you or your team construct something or make a decision about something in order to reach a specific goal or fulfill a certain objective, it is something that can be critiqued. For example, you’re team might establish a set of design principles to help guide you in deciding between ideas for an interface. There are best practices for establishing and using design principles. A good design principle should help you eliminate more ideas than you pursue, and it should be specific and avoid overly subjective and ambiguous terms like “fun.” As such, with best practices like these, when your team creates principles for your next product or project, you have an opportunity for critiquing your principles against them.

Central Idea

To ensure that our conversations with teammates are as useful as they can be, we need to think about how we apply critical thinking to the topics we discuss and how we share with others the insights we achieve as a result of that critical thinking.

Wrapping Up

Over the course of a project, team members will have countless conversations in which they collect or provide feedback on designs. Sometimes, these conversations can be unproductive, painful, or even toxic. Improving these conversations begins with understanding what critique is, how it relates to feedback, and the value it brings to our teams, projects, and products:

• Feedback has three forms: reaction, direction, and critique. Reaction and direction are limited on their own in helping us understand whether our design will work toward achieving its objectives.

• How we ask for and collect feedback has a significant effect on which forms of feedback we receive as well as its relevancy and usefulness in helping us to improve our designs.

• Critique, the third form of feedback, is analysis that uses critical thinking to ask whether what we’ve designed will work to achieve the established goals and objectives. It can, and should, be a part of any formal or informal discussion we have about what we’re designing.

• Beyond the benefits we get from the analysis done in critique, it also helps teams to do the following:

  • Build shared vocabularies, making communication more efficient.

  • Find consensus based on product objectives when deciding between multiple design options.

  • Inform and drive iteration on aspects of a design where they are most needed.

Unfortunately, critique is often overlooked for a number of reasons, but by recognizing its value and spending a little time understanding what it is and how it fits within our teams and processes, we can improve the quality of the conversations our team members have and make critique a natural part of our communication and process.