Friends and colleagues have asked me what design thinking or design research is. They want me to write down the steps to understanding people like it is a 10-point checklist.

Design research is the process designed to learn more about people and their situation. You are designing research to learn: what user’s aspirations are; how they wish to be perceived; what their specific goals are; what the other relevant parts of their life are.

To do this, you can’t follow a script. There isn’t a checklist.

A few weeks back, my colleagues at Conde Nast — designers, developers, journalists and audience experts — were able to participate in a design research session I facilitated. They were witnesses to the chaos of design research. On day one, we all shared our biggest fears. I feared the next three days would be too messy — unpredictable, unstructured, uncontrollable chaos.

We called the three days a dCamp, a term I adopted from other design thinking superheroes I’ve worked with in the past.

What does the “d” in dCamp mean? Design thinking. There are five stages — empathize, define, ideate, prototype and test.

Why is it a camp? We came together under a common mission to answer this question:

How might we help editorial teams have a frictionless experience from pitch to create to build to publish to optimize?

Empathize. The group started the week by learning more about copilot — the custom platform Conde Nast is building for its brands so that they can share their content with the world. It’s an application, not a CMS! The product and engineering leadership graciously allowed the group to interview them about copilot so they could better understand why copilot before better understanding the users of copilot, editorial. The group then got to know the motivations, goals and challenges of editorial through a method called “storytelling.”

Define. During storytelling, the group heard real stories of those working in editorial which were gathered through one-on-one interviews. Then, the group broke into four smaller groups to unpack what they were hearing. What is the difference between a writer, producer and editor’s needs? Is there a difference in what motivates them? What are the themes?

Each team then came up with personas that represented these themes — the goals, motivations and attributes of copilot users.

Ideate. After the users were better defined, the group brainstormed concepts that would help them achieve their goals. One group focused on helping editorial optimize, while others focused on making the editing process more of a conversation, giving life to the copilot application.

Prototype. The winning team focused on some of the opportunities the copilot team has around photos. Specifically, they pitched a better, more efficient way to manage photos within copilot instead of using an outside tool, such as photoshop.

During these three days, not only did we generate a ton of empathy for editorial and begin to see the real opportunities or jobs to be done, we also got to learn people’s backstories, their favorite beer and how fond they were of cold brew.

This was the first time editors from different brands came together with the platform team to discuss similar challenges and they did it with engineers sitting next to them. Engineers explained rels. Editors explained deks. We are closer to sharing a common language although we still have a lot of work to do. It is amazing what can happen when you put people together that would “never, ever” work together.

Slide from Jason Scott’s prezo at #brooklynbeta

#brooklynbeta