Highlights from Cooper’s Design Leadership Course

Bret S
Sumo Logic UX
Published in
7 min readFeb 8, 2018

Two weeks ago, a few of us went to San Francisco for Cooper’s Design Leadership course. The highlights included meeting many talented designers, and learning from their expertise as well as that of our instructors, Jenea and Reed. The typical format of the course was guided discussion on a topic, followed by a hands-on activity, and then a regrouping to hear experiences. As expected, we were energized and excited after the course, and we went back to work ready to tell everyone all about it. Also, now that we’re talking about it, many of our takeaways seem fairly logical and perhaps obvious. That’s a strength of these workshops — we’re forced to pause and reflect on our habits and how to improve.

Product managers’ response to our excitement

As far as the learnings from the course and what we’ll be implementing into the Sumo Logic environment, we were enthusiastic about both tactical and strategic techniques. For us, tactical techniques are direct and specific, and we’re able to implement them right away. Strategic techniques are higher-level, require coordination of more pieces, and have a longer-term outlook.

Tactical Techniques

Tactically, we were most interested in precise meeting agendas and handling feedback. Our meeting situation at Sumo Logic can be a bit of a wild west — we’ll schedule a meeting with a specific title and a notion of what we should accomplish. We’ll frequently wander through several topics before arriving at the desired conclusion. But hearing other designers talk about setting an agenda in the meeting invitation and then reinforcing it during the meeting was mind-blowing. Doing this at Sumo Logic in the past week has already resulted in more efficient meetings and clearer next steps.

Rebecca and I were also interested in feedback, although different frameworks called to us. For design feedback, Rebecca loved dot voting for delivering feedback and she implemented it immediately with her wedding save-the-dates. This method involves posting a variety of visuals on the wall. In this case, Rebecca posted thirteen versions of her save-the-date (dedicated bride). Each individual from the design team had an equal number of red dots and green dots. Then we placed our dots on the save-the-dates, indicating ideas that we liked or disliked. Afterward, the group discussed the the most liked, disliked, and controversial visuals. The output of this exercise gave Rebecca many thoughts to consider for her save-the-dates, saving her from the fiancé who loves all of them.

Feedback on Rebecca’s save-the-dates

I was also interested in Cooper’s method for delivering feedback on soft skills, as I am conflict-averse most of the time and the idea of delivering negative feedback is a bit vomit-inducing. Cooper has a framework, called COINS, to guide feedback delivery by including specific details.

  • Context: When and where did something go awry?
  • Observation: What did you observe?
  • Impact: What happened as a result?
  • Next Steps: What should we do in the future?
  • Stay: Allow time and space for a reaction and discussion.

In practical terms, that might look something like this: “During today’s design session, I noticed that you were extremely sassy with our new interns. Unfortunately, I’m not sure that they know us well enough to interpret seriousness and silliness. Let’s maintain directness for specific meetings, at least until they know us better. How do you feel about playing a game with the interns after work today, and then tomorrow we’ll take all meetings seriously?”

We practiced using this framework, and while I think it’s a bit rigid to use directly, I would use it as a starting point when contemplating my feedback approach instead of the typical panic.

Strategic Techniques

Our strategic learnings from the Cooper Design Leadership course were much larger and less tidy. Rohan and Daniel were interested in implementing workshops as a way to drive projects forward and to facilitate alignment. Workshops paired with specific meeting agendas will clean up the UX process and increase efficiency.

But the biggest idea for us was Cooper’s notion of pair design with generators and synthesizers. The concept is that pair design should include a generator and a synthesizer. The generator is a firehose of unedited ideas, while the synthesizer asks a million questions and keeps the generator connected to the big picture. Cooper initially thought that these two roles were more tied to personality, and thus less malleable. However, their thinking has evolved over time, and their current stance is that a senior-level person should be able to inhabit both roles successfully. After a quick exercise during the workshop, Rebecca and I identified with the synthesizer role, while Rohan and Daniel were squarely in the generator camp. For all of us, this revelation felt like taking a stunningly accurate personality quiz and learning something obvious about yourself.

Rohan & Daniel — generating ideas about glasses
Rebecca & Bret, all the synthesis

Pair Design in Practice

The larger question is how we’ll use this information. Sumo Logic is a late-stage start-up, and one of the most important things right now is process as we scale. We are creating new roles and building new teams, and our future success depends on how effectively we create and implement processes. When people know what to do and what to expect, their energy is focused on actually doing that work instead of the black hole of ambiguity.

The design team at Sumo Logic loosely follows the concept of pair design, based on the idea that two minds on a problem are generally better than one. We organically fell into pairs that happened to work quite well together, and we didn’t examine that chemistry until Cooper introduced the generator / synthesizer framework.

As the design team grows, we’re seeing that certain pairs are better suited for designing together. We lucked into our previous situation, and now it’s time to put in a bit more process around these pairings. It’s quite ideal to pair a synthesizer and a generator, but realistically we’ll also end up with synthesizer / synthesizer and generator / generator pairings. How can we best prepare for those?

  • Synthesizer / Generator: All is good during the project. Everyone loves having an assigned role and clear expectations about what they’re doing. The title can also create a sense of relief, as it feels less daunting to be responsible for half of the process instead of the whole.
  • Generator / Generator: The biggest pitfall of this relationship is a ton of half-baked ideas without a hard conclusion and next steps. Rohan and Daniel were at a career fair at the University of Michigan a few weeks ago, recruiting for our summer internships, and they were an explosion of ideas about what to do and what to bring to the career fair. They were faced with the conundrum of how to pare down those ideas into realistic things that could happen in the necessary time frame.
  • Synthesizer / Synthesizer: Rebecca and I live this daily! The hardest part for us was getting through the trust situation. With a synthesizer / generator pairing, the generator has to trust-fall into the arms of the synthesizer, meaning that the generator needs to stream unedited ideas without any self-consciousness. The synthesizer, in turn, respects that bravery and asks questions that continue the generator’s confident flow. With two synthesizers, there’s no trust-fall and it can take a bit longer to build that trust. Initially, with Rebecca, I felt a bit awkward when presenting her with an idea and feeling the rush of synthesizer questions. I would further self-edit before presenting her with the next idea, resulting in fewer ideas coming out. Eventually, we reached an equilibrium point where we play both roles with each other.
Still enthused. Thanks, Cooper!

Our next steps with the generator / synthesizer framework are to formalize the strengths and weaknesses of these relationships within real projects and to talk to the entire design team about it. When everyone feels comfortable with their role and expectations, we expect that projects will run a bit differently. We’ll update on the results of our experiment, and please do leave us a comment if you have thoughts or insights to share.

--

--