The Secret Lives of Product Designers
What I really do for a living
You’re at a party. Having a good time, laughing with a drink in one hand, leaning into a conversation with the new friend of a friend. You’re invincible- charming, kind, funny. You think man, my therapy is really paying off, when suddenly they ask- “So, what do you do for a living?” Your heart starts pounding. Your vision narrows. Your knees buckle. You feel the sweat start dripping down the shirt you just thrifted for your I’m a chill person now summer. The problem? You’re a Product Designer.
Found footage of me after being asked this very question
In a social setting I’ll usually take a deep breath and deliver a rousing run-on sentence like “Uh my undergrad was in computer science and my master’s was in information and now I work for Flatiron Health we peddle in data about cancer and there are lots of steps in packaging that data to our pharma customers so they can use it to make better cancer drugs and treatments faster so I mostly help design interfaces that help us process the data and tools that help the customers use the data”. And usually they pick up on how exasperated I am and generously allow me slip into the familiar role of interviewer in order to ask them about their (seemingly) more straightforward day job.
In the workplace this approach hasn’t been very effective for me, so instead I’ll usually say that a designer’s job is twofold:
Make sure we’re building the right thing
Make sure we’re building the thing right
It’s not that my job is more complicated than others’ (I know for a fact that it isn’t), it’s just that there seem to be a lot of misconceptions about what a designer does. For example, I feel the need to emphasize the first part of my job (building the right thing) over the second (building the thing right) because the latter is usually the more visible work that my colleagues already assume is included in a designer’s purview. People assume the designer’s job is to make things pretty, when in my experience the designer’s job is to make sure that what we’re building actually solves users problems and actually works. Yes that includes designating interaction patterns, picking color schemes, and moving buttons around, but the critical work is gathering the information that informs those decisions. What I find I usually have to explain over and over again, is that the decisions that a designer needs to make in the later stages of a project are informed largely by the information gathered at the start of the project.
With the caveat that these are my shoes and likely won’t fit every designer you meet at a party, let me put you into the shoes of a product designer:
What goes into making sure we’re building the right thing:
Mapping 🗺️
Planning 🏹
Detective-ing 🕵️
Kicking off a project is like firing an arrow. If we want it to hit the bullseye, we have to get the angle right. Firing from an angle that’s off by even just a few degrees will land us yards off-target. The first thing I like to do when I get to join a project from the jump is to help the team align on what problem we’re actually trying to solve. When I make them write it out in a collaborative visual space (like a dry erase or Miro board) they’re often surprised by how different the problem space looks between stakeholders. There are different ideas of what’s in scope, who the users are, and generally this step also surfaces assumptions, many of which are likely inaccurate. At this point what matters is that we get a sense of what we don’t know in order to firm up and fill in our shared knowledge.
Once I’ve helped the team establish what problem we’re trying to solve, I can start planning our research. We start with all the things we don’t know and turn them into questions. For example, if the problem space is that cookie crumbs keep ending up on the office carpet, a question we might have is “who is eating cookies in the office?” These questions are research questions, which inform how we go about gathering the answers. I might perform interviews, observe users in context, or analyze the competitive landscape in the problem space. For our example research question, an interview question might be something like “What foods did you and your colleagues eat in the office yesterday?” Hot tip: good interview questions don’t have a yes/no answer.
Once I’ve conducted research we need to synthesize our findings. There are countless ways to do this, but the general principle is that we generalize our findings and pull out key takeaways to make sure we calibrate our bow to the right angle when firing our arrow.
What goes into making sure we’re building the thing right:
Brainstorming 🧠
Testing 🧪
Iteration 🔁
Now that we know our problem space and have shared knowledge, I can finally start actually thinking about solutions. A great way to kick this off is with a collaborative team brainstorm. The good rule of thumb here is quantity over quality. In whatever method works best for my team, we’ll record as many ideas as we can. For our example problem they can be as mundane as “vacuum the cookie crumbs” or as outlandish as “design a crumb-catching sleeve for all employees as part of a new mandatory dress code”. Unexpected ideas can help spark elegant solutions. Once we have a lot of different ideas for how to solve the problem, it’s time to start prototyping and testing the most promising ones.
When prototyping, fast and cheap is best. We call this fidelity: a low-fidelity prototype might be a pencil sketch on paper or a cardboard shoe. A high-fidelity prototype might be a real-looking clickable website mock-up, or a VR simulation. I start with whatever the bare minimum is that I need to build in order to test whether a solution works. How do I test whether a solution works? Through usability testing.
Usability testing is different from feedback. As opposed to asking someone what they think, usability testing tests what someone does. Generally I will give the prototype to a user and ask them to solve their problem or accomplish a task with it. I am testing the solution, not the user. As I observe them trying to accomplish a task with our solution, I understand more about them, how they think, and what their expectations are. It’s most helpful when the user speaks their thoughts out loud. Once I’ve learned about how the user interacts with the solution, I can iterate on it. Iteration is the process of making changes: I might keep one element, throw away another, and tweak something else. I’m trying to make the thing better for the next round of usability testing.
Once I’ve done enough testing and iterating that we’re satisfied with our solution (there’s no perfect answer to when this happens), we move into implementing it. My job here is to communicate our solution to the team building the real thing. For a software interface this might mean visuals and text to allow software developers to get all the interactions right, for a physical product it might involve specs to make sure it’s manufactured accurately. And as it gets built, I’ll be there along the way to redirect any designs that aren’t working as planned, or to catch mistakes as it gets built out.
Here are some of the hard parts of my job, that can show up at any time:
When a potential solution touches a lot of other pre-existing products and solutions, so I have to think about how it all fits together and scales
When I need to get up to speed on a problem space that is particularly complex or niche, as often happens in the healthcare tech landscape
Working with a vulnerable or specialized audience/user base
When my friends & colleagues have no idea what I do for a living and I have to write a whole article on it
Auf Wiedersehen
I hope this helps you out the next time you have to explain the job of a Product Designer: we make sure the right thing gets built, and make sure the thing gets built right. Now if you’ll excuse me I have a very chill and laid back life and career to get back to. Take it easy and see you around.