First lessons in product design. A time traveller’s account.
With warm weather on our hands, I’ve decided to use the longer days to build a time machine and write a letter to give myself back in 2011. The time machine’s going to be the trickier piece so I decided to start with the letter.
In a few months I’ll be finishing up my fifth year of working as a designer and my second in product design at a startup. As I’ve tried to gain a handle on this torturous mistress called design, I’ve started to develop a point of view of what it means to approach the field as a practice that we must continuously strive to perfect. Here’s what I’ve learned along the way.
Lesson # 1 : People will get frustrated with us for thinking too big and thinking too small. This is a sign that we’re doing our job.
A characteristic of great designers that I’ve learned to appreciate is their ability to zoom in and zoom out. As my friend Rachel Kroft likes to say, you have to keep one eye in the telescope and one in the microscope.
The truth is that there is a natural amount of friction that exists when transitioning from being up close and personal with a micro interaction and out loose and theoretical with a blue sky proposition. With others involved, it’s unavoidable that moving back and forth between these two areas will interrupt project schedules. The thing is, to design great product you’ll have to operate in both worlds. It’s part of our job. As for the friction between these two modes? It’s the necessary but messy bit that they didn’t tell us about in designs school.
Sometimes I’ll get stuck up in the clouds or down in the wires and it’ll take an elbow from others to make that switch. Accepting this elbow from others with open arms is something I’ve just recently become comfortable with. How do you learn to get comfortable with others telling you when to step back or dive down deep? Allowing my team — which has ranged from 5 to 47 over the years — to share ownership of the design process has been the biggest step towards deflating my design ego. By continuously teaching my teammates when it’s right to do what types of design work, their once aggressive elbows have become productive nudges to help us keep projects on the right track. And these are nudges that I now (mostly) enjoy getting.
Lesson # 2 : To ship great product, we’ll need conflict.
As I’ve gotten deeper into product design, frameworks, and workshopping techniques, I’ve continued to be tempted to seek out the fabled land of peaceful problem resolution and a conflict-less work existence. If only I can nail the right workshop techniques, I’ll mutter, work would be an endless parade of hugs! After having run seemingly great projects with ineffective results, I’ve learned to be wary. My biggest take away on managing design as a process has been that it’s easy to get inclusive design confused with conflict-less design. While yes, it is possible to make it through design projects without any conflicts, a project without conflict is often a red flag.
One of my favorite definitions of product design is solving problems within constraints. In their brilliant book Wiser, Hastie and Sunstein describe all decision making processes as a movement between identification and selection. In design terms, identification is the going wide, divergent part of a design thinking process while selection is the convergent, narrowing down bit. Identification is the ideation heavy part of decision making that is most reinforced in design education and what drew me into design in the first place. Find an unsolved problem, say yes to any broad mix of ideas, and smash those ideas together. Thats identification.
The tougher and equally important peace of design is deciding on which ideas and directions to move forward with. This is the part Hastie and Sunstein call selection. While you can let selection be dictated by your own intuition when working alone, this isolated and heavily biased approach doesn’t work so well when working on a team. I’ve found that it’s often our job as designers to make sense of the different opinions that come into a project, separating emotions from the work itself, and making the most of our team’s collective intelligence. Along the way, I’ve learned some techniques to help moderate these conversations and I recommend diving into these techniques whole heartedly. The caveat is that, unfortunately, there will always be conflicts and, instead of trying to dispense of these conflicts all together, we may be better served by making these conflicts as healthy as possible.
When conversations do get heated, I’ve learned to make sure that I have the tools I need to make these conversations productive (pro tip: make reading Crucial Conversations a required part of your design education this year). Because our role often places us in the middle of project team, designers are in the perfect position to be the moderators of these conversations. Combined with our training in group critique and workshop facilitation, it’s only natural that we fully adopt this role into our practice by continuously developing our communication skills.
Being able to transform messy conflict into a healthier version of itself has turn what was once a source stress into a source of learning that has has helped me question my own assumptions about what it takes to build great product.
If design is like sailing an ocean, then process and workshop methods are like a compass and map. Having the right tools will help us get where we need to but, no matter how prepared we are, the sea shall have its storms.
Lesson # 3 : Asking important people dumb questions will always be tough. To get used to it, make it part of your practice.
My favorite definition of strategy is the intentional use of available power to devote resources towards a well defined goal that would otherwise not be achieved. One of the benefits of working at a startup is having proximity to that power; i.e. the founders and the board. What I’ve learned is that proximity to power isn’t the same as access to power and that accessing this power relies on my willingness to actively participate in the conversation.
As I’ve progressively become more useful to my teams, I’ve been invited into rooms with progressively smarter people. And this has been a good thing. The tricky part is that, as the rooms I’ve been in become smarter, it gets scarier to ask or say anything at all. Combine this with ‘Imposter Syndrome’ and one can find themselves playing the part of the quiet kid in the corner that occasionally nods. I get it. Putting yourself out there is scary and head nodding is oh so safe.
So how do we break out of this safe, head-nodding bubble? One way is to become comfortable with asking dumb questions. But how do you make asking dumb questions less intimidating? I’ve found it useful to reframe my fear of asking seemingly dumb questions as a simple communication breakdown. In this case, the communication breakdown is that a gap exists between my courage to speak up and the safety that I need to exercise that courage.
As opposed to waiting until I work up the courage to ask intimidating questions in hight stakes situation, I’ve found the easiest approach is to start with safer situations i.e. less risky moments to ask dumb questions. I’ll ask a group of friendly developers to spell out what a MySQL server is. I’ll talk with a design mentor about how he decides on new hires. Let your mind wander through seemingly obvious questions, wait for one to set off that quiver of anxiety inside of you, and take that quiver as a sign that you’ve stumbled onto a question that sits at the edge of your comfort level.
Real talk: As far as I can tell, that little quiver we get when we ask a question with a seemingly obvious answers will always exist. My best advice is to make it part of what defines you as a designer. Become known as the person in the room that asks dumb questions and you’ll realize it’s not that big of a deal.
Lesson # 4 : The group mind resides uber alles.
My biggest take away from studying improv in Chicago is that the foundation of a strong improv team is a common understanding of reality. This is often referred to as a group mind. The aha! moment for me was when I realized that this same group mind has been the foundation for every good product team that I’ve been a part of.
Never assume that your team shares the same understanding of reality in their heads. In all likelihood, they don’t. This heuristic especially holds true when it comes to defining problems. Having a different understanding of a problem can cause systemic breakdowns for a team further down the road and I’ve found it to be a common culprit when I feel like I’m arguing over details of a solution. Creating the group mind, or a common understanding of the problem that you’re trying to solve, is the necessary step to get to this common understanding. The tough part for me is that it is often a step that seems unnecessary at the time.
So whats a simple first step for creating this mysterious group mind? One way is frameworks. For those uninitiated to my personal obsession (i.e. those with better things to do than geek out on process), a framework is just another word for a model that can be used to categorize a bunch of things and understand the relationship between them.
While words can be incredibly powerful, I’ve found that words are limited by the fact that they’re often just pointers to very different ideas in each of our heads. This limitation is multiplied by the fact that each one of us comes from a rich and unique history. Using frameworks is a way to look at concepts from new perspectives and make the nuances of a problem that are often hidden open for discussion. As Kim Erwin notes in her book Communication The New, this limitation of words holds especially true when we’re trying to communicate new ideas. New ideas have yet to be given a common definition for all of us to hold onto and it takes a mishmash of descriptive elements, each exposing a problem or idea in a different way, to communicate them clearly. Frameworks are a great tool to do just that. I found that starting with a basic set of frameworks that I can confidently use and make adjustments to has helped me start to build a collection of my own.
Sometimes when I create a framework I’ll become so obsessed with getting it right that I won’t want anyone else working on it. I’ve realized that in these moments I’m missing the point. While frameworks are partially about getting a unique perspective on a problem, they having nothing to do with getting a view that is absolute or dogmatic. I’ve found that focusing instead on creating a map that I can refer back to when things get abstract can keep me from getting lost in the clouds. Most importantly, I’ve learned that this map needs to be one that everyone on my team can feel like they own.
Important note: group mind is NOT the same as group think. The first is about having a common understanding of the world, the second about ignoring the strengths and opinions of the individuals in that world. Check out Wiser for deets.
Lesson # 5: Every team has its own innovation shape. (Stick with me here)
One wonderful symptom of the growth of design thinking is the widespread availability of out of the box workshop models. From the IDEO Field Guide to Human Centered Design to the brilliant Google Ventures Design Sprint, we now have access to enough copy and paste processes to fill a double sized trapper keeper. I’ve often been tempted to take these workshop models and apply them word for word. And I think this is the right thing to do. At least once. What I’ve notice pretty quickly is that every problem and team is its own little snowflake and requires an equally unique solution. This uniqueness means that it’s often up to us to take the best bits and pieces of these different models and adjust them to the unique makeup of our teams and the problems they’re solving.
Because teams change over time, I’ve been best served by making sure to make adjustments along the way. Unfortunately, accepting this approach means that you will never have a plug and play design process. We’ll have to constantly build up our repertoire of tools and focus instead on developing an intuition for when it’s right to take which approach. While this may sound like a lot of work, as design professionals, it’s our responsibility to push the limits of the field. One way I’ve made this more approachable is to apply a 2-week sprint model to my design process and implement the all mighty post-mortem. This just means taking some time every couple of weeks to look back at the approaches I’ve been using with my team and make any adjustments that feel are right.
Taking this iterative approach also means that new methods that I’m trying out are just low weight trials. If a method doesn’t work I can just toss it out, no harm no foul. Having a willingness to create new tools and trying out untested methods has been my approach to moving beyond the application of others’ techniques and on to making contributions to design as a practice, however small these contributions may be.
If I had to pick one concept that has most transformed how I think about my role as a designer it would be identity. What characteristics do I choose to define me as a designer? What can a designer bring to a team that will make it a better version of itself? For me, the answer to these questions lies in taking on the identity of being endlessly curious at the cost of always knowing the answer. To act as a force of learning and exploration on a team, especially when asking questions that we think we know the answers to. I’ve said before that I believe that design leadership’s message to traditional leadership is that we don’t know all the answers yet and that’s ok. These past couple years has given me confidence that this is the most effective frame of mind that a designer can adopt when focusing on continuously getting better at solving messy problems. That is, as far as I know right now.
