Last week we sponsored Communitech’s Design for Change session, hosted by Barry Katz. Barry opened with a few stories about ‘design‘. I put design in quotes because that term can mean a few things. In this context, it doesn’t mean the look of the thing you are building. In this context, it means how designers figure out how people’s lives intersect with the problem you are trying to solve. In this context, a designer is someone who’s solving a problem, not a graphic designer, or a UI designer, or a UX person.
Here’s an example. At Tesla, the designer sits at the table with everyone from concept sketchers, to chassis architects, marketing, the battery mechanism team, upholstery team, infotainment team and more. At other automakers, design is mostly shoe-horned into a platform or an existing concept sketch, and it follows a more linear process. Every intersection the driver has with the car is factored into the design…not just the aesthetics, but the design of the experience.
Barry introduced Design Thinking as a philosophy, not a process or a method. The danger of labeling Design Thinking as a process, or method, is that it might be interpreted as a step in a bigger process model. One of my favourite quotes from the day was when he said, “we want design thinking people, not a design thinking department.”
The context of our day was to use Design Thinking to work on a problem most, if not all, organizations have: how do we attract, and retain, talent?
After a couple of simple warm-up exercises, we started day 1 by exploring ecosystems. That is, how do all the elements of an ecosystem interact with each other? How are other parts of the ecosystem affected when we make a change to one area? For example, in KW (Kitchener/Waterloo), a new company came in and bought an abandoned bank. The owner of this company didn’t know that the abandoned ATM vestibule was actually the downtown homeless shelter, so he inadvertently kicked a few people out of their homes. Before you change something, you need to be aware of the consequences your actions have on the whole ecosystem.
We started by looking at the entire ecosystem, such as what assets does our region have that attracts, and retains talent? What’s missing? What do we think we need? How are these interconnected? Our team generated insights on sticky notes, using a different colour for each category, and then we voted on what we felt were the most important things to focus on given we only had about a day to work on the problem.
Fast-forward a couple of hours, and we decided there were two primary factors in this problem:
(1) Having facilitated innovation through Communitech who has many programs and options for helping companies thrive, access to funds, and a strong foundation of technology with U of W.
(2) Lifestyle, culture and values of the region keep people here, or entice them to come back after they’ve gone to Silicon Valley or downtown Toronto to get their yaya’s out!
Next up, it was time to validate our assumptions. Communitech arranged for each team to interview someone from a local company, or government. My team was lucky! We interviewed one of the urban planners for downtown Kitchener! Our interviewee gave us a ton of data about this problem. Barry refers to data, it the grander sense. It’s not specifically survey results, or statistics or what-have-you, it’s everything you notice in the context of this problem. For example, did our interviewee react differently to different questions? Did he get excited while talking about a specific thing? In our interview, yes, he did. We asked him why he hasn’t left and he perked up and instantly answered: “I grew up here and have seen so much positive change in the last decade, that I want to stay and see what the next decade holds”
A survey response can’t help you design a solution, compared to the feeling of talking with someone face-to-face.
After synthesizing our data, each group did a show-and-tell:
Our goal wasn’t to solve the problem, our goal was to understand how the lives of the people in this ecosystem wove their way in and out of our problem. You could say we needed to apply a process to this problem, but it’s more complex than that. There’s no process that tells you how many people you should talk to, or how long you should interview people, or what’s the right way to synthesize the data.
Barry gave all the facilitators the ability to do what they felt was right to help their team. Some of us timeboxed brainstorming sessions, or the customer interview, used dot-voting when necessary, did retrospectives after the interview and more. I would wager that all of us used a different process, but each team ended up with tons of data, and a prototype by the end of the day and half session.
If you’ve been to a Lean Startup weekend, this session was similar. The difference was, we heavily focused on the whole ecosystem, versus following a prescriptive process of creating a lean canvas, creating assumptions, and running experiments to validate, or in-validate, those assumptions.
Perhaps most important, we had fancy desserts!
The lessons from this session, in my view, were:
- focus on stories
- pay attention to the details (how interviewees react, body language, tone, shifts in energy)
- diverge -> converge (brainstorm using any technique, pull the team back in to focus when you feel the time is right)
- have a large facilitation toolkit (LSP, dot-voting, silent brainwriting etc)
- understand ecosystems
- practice, practice, practice!! (The more you do, the more you figure out how to approach problems)
- don’t assume people don’t care about the problem, they might simply care about something else more
- design was a necessary consequence when Apple released the Apple II. The question was changed from “will hobbyists buy kits and assemble personal computers” to “what can people do with a fully assembled computer” Whether you love or hate Apple, they’ve been a lifestyle company ever since Steve Jobs figured out that the technology was the trigger for a larger, more compelling story about how that technology affects our lives.
- An ecosystem cannot be transplanted: Many organizations are trying to copy Spotify’s culture based on their engineering culture videos, or they’re trying to copy another companies innovative culture. It can’t be done. Structure can be copied, culture cannot.
We’ve facilitated workshops with the University of Waterloo (MBET Program), and numerous clients, including Telus, Rogers and more and we want to share what we learned in an upcoming free webinar on May 2 at 1pm EST.