16 lessons from the design world
Over the past decade, I’ve had a chance to experience life as a professional designer in a wide range of projects and environments, from agency to in-house, freelance to full-time, web to mobile, illustration to UI/UX, graphic design to game design, and user research to product design. No matter what I was doing, there were some common themes and strategies that helped me succeed and grow throughout my various stints, so here’s me sharing some key learnings that hopefully everyone can get something out of.
These pointers are written as advice and insights from one designer to another, but they’ll be valuable to anyone looking to understand the design process more closely or learning how to collaborate with designers better. The roles and responsibilities of design currently have a huge degree of variance in the industry, so use what’s applicable and take the rest with a grain of salt.
1. Fall in love with the problem, not your solutions
Like most designers, I got into the industry with a love for good design. I loved obsessing over how elegant the curves on the iPhone are or how intuitive the UI on the Nest thermostat is. But rarely did I ever step back to think about how the creators of these products found themselves even attempting to go about willing those solutions into existence in the first place. They were obsessed with the problem, and stuck with it for an incredibly long period of time while constantly re-framing it and iterating on a variety of solutions.
Within the broader problem space, there’s a slew of hyper-specific problem statements that could all have vastly different solutions. Just like you do your due diligence with exploring multiple options and approaches in the solution space during the design process, you also need to be doing the same in the problem space to make sure that your thinking is properly constrained when ideating on the design. If you gain a key insight or learning, the problem should be re-framed to reflect it. Ideas and concepts will be whizzing by in your head in a state of constant flux, but the problem needs to stick in some corner of your brain forever.
If you don’t spend the appropriate amount of time thinking about the problem, it’s very easy to fall in love with a solution you’re designing and stray too far with it. I’ve made the mistake of getting too emotionally attached to a specific feature or concept only for it to live out the rest of its life as a Sketch file, never making it to users’ hands. In the back of my head, I always tell myself that there’s a 50–50 chance that my designs ever see the light of day, which has served me as a good mental hack to never fall in love with my work.
I still find myself struggling to ride the fine line between when to flip my thinking switch from problem to solution. It can be very tempting to give one quick look at a problem statement and immediately open up your dot grid notebook to start ideating on potential solutions. Fight this urge. I’ve started to carve time out to explore all the options in the problem space and get to a very specific problem to try and tackle, which has resulted in a lot more relevant ideation in the solution space.
2. Focus on learnings, not your final deliverable
Iteration is something that we’ve all accepted to be an integral part of the design process. We’ve learned the value of quickly exploring different ideas and eliminating the bad ones before polishing them up too much. But we’re not great at identifying why something doesn’t work. I’m guilty of this myself. I’ll constantly make the same mistakes of iterating in the same way for different designs, without realizing that I had been down that road before.
The best lesson I’ve learned here is to just stop and think. Every time you’re iterating on a design and it’s not quite working, you’ll find a moment where you’ll catch yourself saying “this doesn’t quite feel right.” Pause here for a second. Start taking notes right next to the design. What about it doesn’t feel right? Is it the tone? The colors? The copy? The visual style? Write it all down. This will help you identify what you actually want it to be, spelled out in clear and confident statements. Then, you use those as the benchmark for the next iteration, continuing the cycle until you come to a version that checks off all the boxes and actually “feels right.” It’s a process of converting the ambiguous subjectivity of the design process to concrete, digestible information.
We mostly make judgement calls when it comes to the look & feel of a product, but when you’re able to describe what you’re going for in words, it suddenly makes the design process accessible to everyone. No longer is it some magical process that happens in the designer’s mind for endless cycles, but it’s a documented set of guidelines you’re working with that helps constrain your thinking and allows others to chime in with feedback, which you can then translate into designs. The ability to do this right is what separates good designers from the best ones.
Not only does this help your team understand what you’re doing, but it helps you improve as a designer yourself. Knowing that you’ve solved two design problems and are working your way through the next three gives some sense of quantifiable progress, as opposed to discarding entire versions of designs simply because “something didn’t feel right about it.” Try to learn why each iteration failed for each objective, and see where you can mix-and-match the versions to one that satisfies all constraints.
When Pentagram was working on Slack’s logo redesign, I imagine they went through a similar process. Here’s a sample checklist of how I imagine a designer might have broken this work down:
- [ ] Has to resemble and morph out of the existing octothorpe logo
- [ ] Must work with the existing color palette to retain a sense of familiarity
- [ ] Should represent Slack’s evolution from a startup to enterprise brand
- [ ] Needs to work at all scales and should be usable across the brand’s physical and digital identities
The right side of the above image only shows the iteration work on the very first bullet point here. You could spend days on just the form before moving on to thinking about color and type interactions. Even across these iterations, you can tell that the designer is struggling to figure out some things, like whether the visual elements should make their way into the wordmark or if they should stay in the brandmark. Things like this only become clearer as you go through the process and talk through them with the client. You learn and define what the brand actually is by answering these questions and making decisions on them as you do the work.
So don’t get bogged down by the quality of the final deliverable, just make sure you’re transparent about everything it’s achieving (and not achieving). Treat the final design as a by-product of this process, and you’ll feel even better about it because you can point to the drawbacks of the past iterations and speak with confidence about why this is the best one. As a final cherry on top, being transparent with this process provides an excellent framework for the rest of your team to give feedback on your work, as they can lean on specific talking points and know exactly what you are and aren’t trying to do in a given iteration cycle. This works wonders for building the trust of your teammates, because they can now defend your work and explain with confidence what the thought process was for every component of the design.
3. Be thick skinned and prepared to deal with all kinds of reactions
People generally don’t have strong feelings about how a project manager writes a product roadmap. A marketer won’t ever go to a developer and comment on the quality of their code. But everyone will jump at the chance to react to your designs any day. Positive or negative, they’ll have an opinion. It’s very easy to get discouraged or gain false confidence in your work based on what people say, so dealing with fallout of these reactions requires a thick skin and a conscious effort to realize that it’s not a personal attack on you.
By nature, design is extremely subjective. Humans react to things based on instinct and gut feel, not with carefully considered thoughts or a detailed list of pros and cons. Design is something that’s very easy to react to, because all you have to do is think about how it makes you feel and then say exactly how you feel. It’s far easier to pinpoint the flaws in someone’s design than create something yourself from a blank canvas.
The biggest lesson to learn here is to just remember that when people are reacting to your work, they’re not criticizing your ability as a designer and aren’t questioning the quality of the design itself. They’re just reacting to it, so don’t let all of this take an emotional toll on yourself. They may not be able to create these designs themselves, but they’re absolutely allowed to have an opinion on it. Making this mindset switch me far more comfortable sharing my work and dealing with wildly varying opinions from the rest of the team.
The best approach I’ve found when drowning in this quagmire of gut reactions is to pick your battles. Playing the game of emotions and feelings that a design evokes is almost always a losing fight that typically ends with a final call made by the most senior person on the team. Instead, focus on what problems a design is trying to solve and back it up with as much evidence as you can collect. Direct user feedback, quotes from qualitative research, and any data or metrics around usability goes a long way to instill confidence about the design amongst your team.
4. Seek feedback from everyone
This is a skill I frequently get lauded for, and it forced me to break down what actually makes me effective at it. A part of my drive to keep seeking feedback is to constantly be getting fresh eyes on the work I’m doing, as I often find myself overlooking simple things due to being too close to the work and getting tunnel-visioned (which is totally natural and happens to the best of us). Another part of it is to make sure I’m always incorporating a diverse range of thoughts and opinions into my work, which only works if you actively seek feedback from a wide range of people.
Asking users
Getting feedback from actual users is an absolute must. Some best practices here are to set the expectations correctly — let them know that you’re testing the design (not their abilities), and provide some context about what you’re showing them. If you’re making a change to an existing interface, always show a before-and-after to easily tell the difference. Provide a few questions for them to frame their thoughts around, while being careful not to bias or prime them in any way. For example, asking “How often do you find yourself using this?” will result in vastly different answers than asking “What would be the impact on your workflow if you could no longer see this information?”
Even if you do this right, just be aware that users aren’t great at explaining their thought process. You’ll get the common “I like this better” or “I’m confused by this,” but you might find it particularly difficult to get them to explain exactly why as you try to dig deeper to what they’re really trying to say. Asking these questions correctly and following-up on users’ core motivations and goals is an entirely different skillset, so I’d highly recommend pairing up with a dedicated UX Researcher or Usability Tester who can help you navigate the muddy waters of endlessly interrogating users until you get the answers you need to validate or invalidate your designs.
Asking your teammates
Asking internal team members for feedback is trickier. Users at your company are almost never in the target audience you’re designing for and typically have a much higher degree of tolerance and familiarity with technology. A good example is in one of my previous jobs, where I needed to test some quick copy for an error state in a mobile app when it was offline.
Internally at the company, everyone read the copy which said “Network connection not found”, understood that their network connection was off, and turned it on from the device’s system menu. But things took a turn when testing with real users in-market. Users blamed the product because they didn’t know that their network connections were controlled by their device’s SIM card, not the app they were using. The copy made absolutely no sense to them because it didn’t conform to their mental model of what being online meant. This directly led to a UX improvement where we spelled out what was happening in simple English and explicitly laid out the steps users needed to take in order to get back online and actually use our product.
If you can’t get feedback from actual users and must rely on your internal team for it, there are still some ways to go about it. Non-designers typically aren’t ever coached on how to give proper design feedback, so you’ll need to do a bit of training. Print out design critique cards and hand them out at random to everyone on your team. This makes it really easy for them to ask directed questions about specific aspects of your work while giving you a chance to defend it, which leads to either validating the idea or rethinking the approach entirely. And it’s a subtle way of infusing a design-oriented mindset within your team.
Asking designers
Finally, your fellow designers are simultaneously the best and worst sources of feedback you can lean on. Your eagle-eyed peers are excellent at pointing out UI inconsistencies or improper color usage in your design, which can be very helpful. But they also tend to get so bogged down by these design execution details that they often fail to question the bigger goals of the design. I learned how to give and receive design feedback from Julie Zhou’s excellent blog post, which has some great guidelines on how to present your designs to other designers in order to set yourself up to receive the most valuable feedback.
This can all seem like a lot. You’re getting tons of feedback from all over the place (even unsolicited) but ultimately, it’s up to you to incorporate them into the design. You’re the final line of defense between what everyone is saying the design should be and what users actually end up seeing and using. Simply adding in the thoughts and ideas of twenty different minds will result in an unfocused and confusing design that tries to do twenty different things and doesn’t manage to do any single thing well. When going through the feedback, ignore the ones that aren’t appropriate and eliminate the ones that don’t work as long as you can justify them. No-one will be offended when you have good reasons to back up your decisions. Only apply what you genuinely think makes the work better, and leave the rest to dust. After all, everything is in service of the users who are the ones going to be using it every day, not the people building it.
5. Be highly flexible collaborator
One of the engineers I worked most closely with wrote a detailed post about his career learnings, and I had the good fortune to make a little cameo in it:
Akhil can throw out a hundred solutions effortlessly, even if ninety-nine of them are thrown away. Fortunately, I balance out the equation by discarding the ninety-nine and quickly find the one that works best. Akhil is a Generator, while I am a Synthesizer.
What makes this work is that Akhil never assumes bad intent. He knows that all feedback comes from wanting to give users the very best product experience. With that understanding, my continuous commentary is food for Akhil to generate new ideas. We repeat this process over and over, our ideas sometimes meandering, sometimes wandering, and sometimes repeated. We’re quick to recognize when we’re moving in circles and know when to step back and put a stake in the ground or rule out a distracting edge-case so we can make progress. This organic ebb and flow leads to solutions far beyond what either of us could have come up with on our own, even if time was not a factor. I’ve learned that when paired with a Generator, my effectiveness skyrockets.
Much praise. Reading this made me realize that I tend to constantly switch my collaboration process depending on who I’m collaborating with. I don’t consider myself a “Generator”, but can effectively play that role. I’ve ran design sprints in the past where I’ve played the role of the “Synthesizer” simply because the people in the room were highly vocal and extremely opinionated people. You have to be the one collecting all the divergent ideas and drive them towards convergence in this situation, because if you don’t do it, no one else will . I tend to throw out my own ideas here too, but 80% of my time in these design sprints was spent collecting ideas, combining similar ones, and eliminating bad ones.
Contrarily, if you’re paired with people who are better at processing ideas rather than throwing them out, you have to be able to turn your “Generator” switch on and go wild throwing ideas out. You’re doing the divergent thinking, and the others will jump in to synthesize all your crazy ideas into a solid few that they feel strongly about. I genuinely believe that this ability to read the room I’m in and adjust my collaboration process accordingly is one of the skills that has gotten me to where I am in my career.
Practice this yourself. You can probably think of a few people at work who would be good Generators and who would be good Synthesizers. The next time you’re brainstorming something, pay close attention to what the other person is doing and switch your role accordingly. You may have to switch roles twice in the same session depending on how the ideas are flowing and where they’re coming from. If you find yourself struggling to play one role more than the other, keep working on that until it feels effortless. It’ll pay off in the long run because you’ll be able to collaborate effectively with almost anyone, and they’ll be very impressed with your flexibility in the process.
6. Explain your thought process
This one might sound obvious, but there’s a lot more to it under the surface. When you have the title of “designer”, everyone expects you to “design.” They’re expecting your output to be an interface or an illustration or some interactive animation. While these snazzy mockups will get you lots of Dribbble likes, there’s no substitute for walking people through your process.
In order for anyone (prospective employers, engineers you work with, your design peers) to trust you in that you know what you’re doing, you need to explain your process. Tell them a story. Start with the user problem, show pictures of your ideation process, show all the alternative scrappy concepts you started making but threw away, explain why you threw them away and what wasn’t working about them, say what you learned, and call out every single design decision you made as you were creating the final version.
I’m big on this because it shows that you’re able to work within a set of constraints and iterate while eliminating bad ideas and learning about what makes a good product along the way. I’ve gotten hired to most companies I’ve worked at by writing lengthy blog posts about my design process. Here’s an example one for a video game I worked on and another for a big product redesign. The final outcome of your work doesn’t have to be worthy of putting up on Behance, it just needs to tell a good story and give you lots of talking points about your design process.
Even when reviewing portfolios of fellow designers and hiring new ones, I’m always looking for the ones who can explain their process well. Sure, there’s a certain bar of quality that their core design work has to meet, but beyond that, the ones that are able to explain the nuances behind every detail are the ones who stand out. Why does this animation need to use this specific spring curve? Why do we need a swipe gesture to transition to this next screen? What’s the value of having such thick strokes on these icons? Be prepared with answers to everything. The worst thing you can say when asked “Why did you choose this primary color for these cards?” is “I don’t know, it felt right to me.” Do your research and back up your claims with evidence. This intentional decision making will naturally lead to better design work.
7. Embrace what you don’t know
When I entered the industry, I naively assumed that someone with the title “Designer” in their job title essentially did the same thing no matter where they worked. I had no idea how this title could mean vastly different things at different organizations, and how much difference there was in the day-to-day activities of a designer even within the same company.
When doing freelance design, a lot of my time was spent researching problems and creating moodboards to sell clients on the viability of my approach. At an agency, most of my time was spent presenting my work and learning how to run design sprints. At an early stage startup, I spent most days doing competitive research and conducting user testing to find product-market fit. Now at a mid-stage startup, my days are mostly spent working on shipping designs for big projects within the teams I’m embedded on. Across all these positions, my title was “Product Designer.”
The title means completely different things at different places. Every time I switched jobs, I had to re-train myself out of the habitual behavior loop that I had acquired in my most recent role. There’s a great blog post by some designers illustrating the differences of this role at large tech companies. The best trick here is to just ignore the title and treat every new role as a learning opportunity for acquiring brand new skills that will be valuable no matter what ends up happening.
Beyond just the design skills, there’s a whole swath of skills that you’ll need to learn in order to be effective at your job. Design school doesn’t teach you how to write SQL queries to pull the data you need for A/B testing or how to setup an experiment to validate the learnings from it with proper statistical significance. Oftentimes, there wasn’t a dedicated role for this type of work at places that I’ve worked in, so I found myself having to learn and do it myself.
Similarly, you don’t need to be able to write code to be a great designer (yes, I said it), but you need a basic understanding of how codebases are maintained, how values are stored in database tables, and some programming basics like how conditional logic works in order to effectively communicate with your developers. Writing my own code for prototyping purposes in tools like Framer has actually given me a solid footing in the technical underpinnings of the complex front-end JavaScript environments that can sometimes make or break the feasibility of a proposed design.
It can be so intimidating to learn these new things that it’s easy to say “not my job” and push it off on someone else, leaning on just design as your safety harness to justify your role in the team. But having that baseline level of knowledge in other skillsets has enabled me to communicate with those disciplines in their language and push for things that would’ve otherwise never happened. By speaking their language, I’ve been asked to pitch in during product and metrics review meetings where I’ve gained a better understanding of what we were actually tracking and looking for, which led to tighter integrations between design and data science when it came to testing experience improvements and making small tweaks to move some numbers.
Embrace these things and treat it all as part of the design process. My golden rule has been “if it’s helping you be a more effective designer, then it’s worth doing,” and this hasn’t failed me yet. I’ve gotten a much better understanding of how product companies work and how design fits into it, both operationally on a day-to-day basis and holistically on a cultural level. Organizations want to be design-driven and are great at hiring designers in order to get there, but aren’t quite sure how to incorporate them into their existing process. It’s up to you to figure out all the moving parts and elevate the value of your work as a crucial component in the organization’s workflow. You’ll pick up a lot of highly valuable skills by learning bits and pieces of the other disciplines and will end up delivering design output that fits far better into the company’s operational process, so there’s really nothing to lose here.
8. Use your unique superpower
“It’s easy to solve a problem that almost everyone sees. But it’s hard to solve a problem that almost no one sees.” — Tony Fadell
In his excellent TED Talk, Tony Fadell spoke about how we become so numb to certain things over time, like habitually peeling the stickers off of fruit before eating them, that we don’t even see it as a problem anymore. We just accept it as a fact of life. Before Steve Jobs mandated that iPhones should come fully charged right out of the box, almost all electronic products were shipping with a “Charge before first use” label. Consumers just expected that from gadgets, but were delighted to discover that they could start using their iPhones right away after unboxing it without having to charge them first.
It’s these problems that we find incredibly difficult to solve because it’s hard to even notice them in the first place. Design-minded individuals have a special superpower in that their observational skills allows them to spot these flaws. And you don’t have to be a designer to do this. You just need to notice and pay attention to the things you do every day and start taking note of it. Why does plastic wrap have to be that way? How can we make paper grocery bags easier to carry? Why is choosing the right lightbulb for your floor lamp such a difficult process? Start observing and noticing these things.
As designers, critiquing the design details is actually pretty simple. We’re good at pointing out frictions in an experience or when something doesn’t feel right. It’s easy for any product-oriented person to look at a complex on-boarding experience and come up with a way to improve it, like making sure to provide value to the customer before asking them for payment. They can look at a landing page and immediately point out how to simplify the copy to just get to the point and not get too wordy with it. But if the problem doesn’t exist in plain sight and you’ve developed a habit to tune it out over time, then you need to train your observational skills.
There are invisible problems all around us, ones we can solve. But first we need to see them, to feel them. Our challenge is to wake up each day and say, “How can I experience the world better?” — Tony Fadell
In his talk, Fadell lays out how difficult it really is to do this and provides a few key takeaways: think broader, closer, and younger. Zoom out to the larger issue, hone in on the little details, and think with an open mind. It will help you pay attention to things you normally take for granted and will let you see them in a new light. You likely didn’t care about how tedious it was to change the temperature on your thermostat until Nest showed you how easy it could be. Likewise, you probably don’t spend too much time thinking about your toilet until you go to Japan, where you’ll be so blown away by how amazing they are that it’s all you’ll be wishing for after you come back (true story).
9. Share your work frequently
When I started working at Drift, the “Show your work” cultural value was the most difficult one for me to adopt into my workflow. The team expected daily posts updating everyone on what you were doing in order to provide visibility into your work and give everyone a chance to chime in with feedback. This was quite different than how I used to work before, with me spending most of my time researching and ideating for hours (sometimes days) before sharing anything with the rest of the team.
I struggled to adopt this style of work because something felt off to me about posting half-baked UI work that hadn’t been properly researched or vetted through a proper ideation and exploration process. It’s much easier to pinpoint flaws and poke holes in a design that’s still a work-in-progress than one that’s been thoroughly iterated upon. I was used to filling up entire dot grid notebooks by sketching loose UI concepts for hours and hours before opening up Sketch to mock up three out of the seventy ideas I had. I had to train myself out of this habit. Showing this work early had an added benefit: it let me understand what the team actually cared about in the feature.
When you post these loose concepts and early ideas, you’ll notice that people will be all over the place in terms of their feedback. Product managers will comment on very specific use-cases where the design falls apart, engineers will remark on the necessity for investing in a third-party animation library to even think about doing this type of stuff, and data scientists will start suggesting how to run variants of the experiment to A/B test some crucial assumptions we were making. If anything, the feedback generates a lot of open questions that you can then use as constraints for the rest of the process.
When you begin the design, you’re playing in an open field. There’s little to no constraints and you’re sort of wandering all over exploring things. As you keep sharing the work and keep getting feedback on it, you’re given a chance to narrow down the design so that it fits within all these constraints that are now being exposed to you. You’ll find that many times, different teams aren’t even aware of these constraints until they all start chiming in with their feedback to the design. Just make sure to not get so bogged down with business and technical requirements that you ignore the user problem you’re solving for. If you disagree with what someone’s saying or genuinely believe that a specific interaction model or interface solution is necessary to the experience, speak up and vouch for validating your hypothesis with a quick user testing session. It always clears everything up.
A big win here is the team’s exposure to how the design actually evolves through this process. They’re able to visibly see how it has been shaped over time by all the feedback that has been thrown at it. They gain an understanding of design being a continuous cycle of iteration rather than something mysterious that a creative person does in a black box for twenty hours. They start trusting the design process and in turn, start trusting you.
I’ve started doing this in my freelance projects too and it has improved the client-designer relationship tenfold. I’ve started to convince clients that they’re paying for the process, not the outcome. I share lots of early ideas, frequently show work informally to update them on where I’m at, and often post up sketches or thoughts that I would normally have thrown away or never given the honor of making it to Sketch. Another added benefit is that clients give better feedback during the review sessions when they know they’re paying for the process. They’re consciously aware that everything they say will have a huge impact on the quality of the final deliverable and thus treat them more seriously. Give it a shot if you aren’t used to working like this. It often leads to better outcomes than the traditional process.
10. Make designs that spark conversations
For a while, I had my Slack status set to “sparking conversations all day” with a silly Pikachu emoji. A few co-workers have DM’d me saying that they like the pun (I also happened to be the designer on a product that had to do with managing actual conversations in an inbox at the time), but I was being dead serious. I see sparking conversations as a huge part of my job.
Before you create anything, the thing you’re building exists only as written feature requirements and abstract ideas in everyone’s heads. They have some reference of how a competitor does it but have no clue what their version of it would be. This is where you’re uniquely positioned as a designer to provide the visual image. Even if it’s loose, even if it’s just conceptual, even if it’s very high-level, just share it out to get a conversation started. If you don’t, you’ll have no idea whether the direction you’re pursuing is right or not.
“Ideas are misunderstood unless they can be visualized. When a visual is put up on a screen or a prototype is passed around, the whole conversation becomes more productive and specific.” — Scott Belsky, The Messy Middle
A largely underrated benefit of doing this early in the process is that it exposes all the potential issues we could run into when building and deploying it. A mobile app I was working on wanted a “quick-view” feature that showed only a few essential elements picked out from the detail view of the item, which had over a hundred descriptors about the thing you were buying. Everyone assumed it would be a simple and easy feature to build. Once I shared the designs out, people started realizing how big of an impact this would really have on the user experience.
My proposed design was a swipe-through set of cards that would come up and lay on top of the entire UI when users triggered this quick-view. It caused a lot of chatter amongst the design team about how we would be covering up other callouts underneath the cards, concern amidst the product managers about about how users could fall into a state of endlessly swiping through these cards, and uneasiness within the engineering team about how they’d go about implementing an idea as crazy as this that required fluid motion, overlapping UI elements, and highly responsive animations.
Because this was shared out so early, we managed to talk through our most pressing concerns and resolve them immediately. We added the appropriate CTAs on the cards themselves, restricted the set of swipe-able cards to fifteen (not infinity), and decided to validate some other UX concerns through user testing with high-fidelity interactive prototypes. We ended up implementing an embedded card carousel within the existing content on he screen instead of doing the full-screen overlay takeover.
“Sharing a design quickly aligns people. Without it, people are trying to interpret something in the dark feeling one edge at a time. A mock-up or visual is worth countless meetings and debates. A mock-up turns the lights on.” — Scott Belsky, The Messy Middle
This back-and-forth debate is what aligns your team to pursue a particular approach, and I can’t overstate the importance of making it a habit to consistently keep doing this. Don’t ever feel like you’ve “wasted” time making concepts that never ship, because the value those concepts provide to everyone else cannot be understated. I often have a very clear idea of what 3–5 various visual implementations of an idea might be in my head, but the rest of the team doesn’t until I mock it up and show it to them.
My only gripe here is that there’s no good way to measure the impact you’re having within the organization by doing this. You could spend 2–4 weeks just ideating and sharing concepts, and your output is clarity within the team about what you’re all collectively working towards. Oftentimes, teams don’t even know there is a lack of clarity until you expose the problem by showcasing the wide variety of reactions to your design. The team will need to naturally trust you and in the design process for this activity to hold any merit, which only comes with experience and repetition.
11. Be data-aware, not data-driven
When one of the companies I joined said they made all their decisions based on data and metrics, it definitely scared me a little. Would I be able to come in and pitch designs without any numbers to back me up? How would I ship customer value if most of my work is based on subjective appeal and can’t be properly measured? The anxieties slowly subsided when I started incorporating a less aggressive integration of data into my design process.
I‘ve written a more detailed blog post about this, but the essence of it is as so: being data-driven is the most hardcore approach you can take, optimizing and fine-tuning the smallest deviations in your metrics down to an art form. It’s relentless obsession with hard numbers and validating results with statistical significance. Then there’s being data-informed, which is essentially weighing your quantitative testing against the qualitative insights gained from user research or usability testing. It’s a delicate balancing act of taking objective data and backing it up with subjective feedback. And finally, being data-aware means that you’re highly conscious of the limitations that metrics have and only use them as a backup to justify or contradict firmly held opinions about how a product should feel or behave. Being data-aware doesn’t mean you don’t pay attention to the numbers, it just means you don’t fall into the trap of prioritizing metrics over actual customer experiences.
And it’s probably no surprise to you that design works best in one of these buckets, the data-aware one. The gist of it is that data can only tell you what happened, not why it happened. It’s great at identifying when things aren’t working, but doesn’t provide a clear path on what to do next. All it does is surface the deeper complexities of the problem. It then takes some clever A/B testing, rigorous experimentation, and many design iterations to really validate your learnings through metrics.
There’s an excellent post about how to become a more data-aware designer, which I’d highly recommend reading. In one of the High Resolution episodes, Spotify’s VP of Design Rochelle King explains the huge benefits of becoming data-aware in your design process. Depending on where you work, you may be forced into a data-informed approach to your designs. This can still work, as long as you constantly remind the rest of your team to balance the numbers with what you’re actually hearing from customers.
12. Observe and listen more than you talk
“We’ve got two eyes, two ears, and one mouth. Use them in that proportion.”
When you’re asking veteran users of your product research questions about usability or their workflows, you’ll get a lot of mixed feedback. Pay close attention and you’ll realize that these users are consciously forming their opinions about what you asked them on the spot right as they’re answering the question. They get so accustomed to using common products and features that it can be difficult for them to express how they really feel about it.
I once had to ask a series of questions about what types of files users were uploading as attachments to their messages. They’d respond with the usual “you know, images and stuff, etc.” I’d take notes, ask what image file formats as a follow-up question, and move on. Midway through the tests, I noticed users were just blurting something out just so they had an answer ready for me. What they said may not have been what they actually did.
So I switched up my strategy. I asked the question and then they responded with their first answer. Instead of following up to the question, I just sat there in silence. Sometimes for ten to thirty seconds. This felt very awkward at first, but it allowed the participants to ease up and think a little deeper about what was asked. One user mentioned he recalled trying to upload a video file that caused the upload bar to get stuck. Another user mentioned he frequently uploaded his resumé as a PDF with the same filename, and that the system sometimes had trouble overwriting the previous upload with the new one. And both these people initially answered with “mostly images and pictures.”
Had I just followed-up and moved on, we would’ve never arrived at these great insights. The time and silence that you give the users allows them to ease up and think a little deeper about what’s being asked. It reinforces to them that you’re genuinely there to listen to them, not just incessantly pester them with a series of questions about what they do in the product. Again, this is extremely uncomfortable to do as the moderator, because we’ve been trained from childhood to hold a conversation and keep it going, so allowing for long pauses like can feel quite unnatural at first but gets easier with time.
The same goes for simple observation. Just watching users use your product without asking any questions can provide so many valuable insights. You’ll pick up on things users are subconsciously doing that even they’re not aware of. I was sitting in a usability testing session for a mobile app where a user was going through a prototype I had designed. They were holding the device comfortably with one hand the entire time. One of the tasks required them to share a link, so they clicked on the relevant item and the default iOS Action Sheet popped up from the bottom of the screen. Then, they instinctively clutched the device with both hands and chose an option in the menu with the thumb of their other hand. It was an automatic, instinctive motion with no forethought or intent.
Despite there not being a huge spatial distance between where they triggered the menu from and where the menu options popped up, something in the user’s brain told them that it’s more efficient to move their entire other hand over and use it instead of just re-adjusting their grip with the existing hand. This may not sound like a big deal, but imagine if they were on the subway and needed that other hand to hold on to something. There’s situational friction in the experience. Now that devices are getting larger and larger, ergonomic issues like this are more important than ever to consider for accessibility and inclusive design.
“Interrogation and empathy can get you incredibly close to your users.”
Usability tests and research sessions are great to figure out where your designs and prototypes fall apart, but try to listen more than you talk and try to really observe the subtleties and nuances in their actions. Your questions must be combined with a sense of empathy for the users’ goals in order for the true user experience to fully reveal itself to you.
13. Keep Calm and Design On
No amount of coaching in art school, design school, or a UX bootcamp really prepares you for how chaotic things can really get at tech startups. There’s always disagreement amongst teams about what the right course of action is and second thoughts on tough decisions that need to be made. Once you start mocking up some of the ideas, it gets even crazier with everyone chiming in with their thoughts on what should be changed or improved.
The best trick in the book here is to simply maintain your composure through the chaos. Always be grounded and never lose your cool. As a designer, you’ve likely already come to terms with the fact that the design process can be messy. Others haven’t, though. They don’t live and breathe design every day. People will disagree with your approach and will sometimes switch up the product strategy entirely based on what the mockups are starting to look like.
Throughout all this, all you have to do is not freak out. Accept it as part of the process and just go with it. Believe it or not, you’ll garner even more respect from your peers by being the epitome of calmness amidst the frenzy. The ability to persist in the madness and just constantly keep doing the work is an extremely underrated skill of being a good designer. Being able to carry yourself with enough patience and confidence with your execution skills ends up paying huge dividends down the line.
I should also mention here that it’s still up to you to fight for the user experience. The design team tends to be severely outnumbered in most product teams by engineers, data scientists, business analysts, and product managers. They’re all mostly laser-focused on their most crucial job functions, and even though they care deeply about a good user experience, they’re not necessarily prioritizing it over the work they need to get done. You may find yourself in a position where you absolutely need to speak up and say that you’re not okay shipping a feature that doesn’t meet the bar for a good user experience. Ultimately, the shippable version ends up being a compromise due to time and resourcing constraints, but just know that you’re the strongest advocate on the team for shipping a good user experience.
14. Visibility & optics matter
My “design process” used to be the same for a long time. I would be presented with a problem, and I would go down a research hole for a while. I’d scope out competitors, weigh it against our product strategy, and familiarize myself with the nature of the market. Then I’d start doing design research by looking at UIs and benchmarking best practices while taking a mental note of all the conventions being used that users would be familiar with. Then I’d loosely sketch out a bunch of ideas and approaches in my notebook to quickly invalidate the bad ones and decide on one or two worth pursuing.
Until this point, everything that’s been done isn’t visible to my peers. It’s all in random screencaps and pages of a sketchbook, along with some screenshots or GIFs of me tinkering with competitor products. This process can take up to an entire week for really complex problems, and not having a deliverable yet results in zero visibility to your team into what you’re actually doing. And people start wondering what you’re really doing if you’re not “designing.”
At Drift, there’s an internal rule that every designer posts what they’re working on twice a week, every week to a public #design channel in the company’s Slack. The post can be anything from an entire flow to a small screenshot of a new toggle somewhere deep in a Settings page. It can be in any format, like a clickthrough InVision or a simple GIF animation. What this does is provide visibility to the rest of the company into what the designers are actually doing. Even if all you have is a basic wireframe, you’re encouraged to share it. The purpose isn’t for anyone to attack your work and tear it apart, it’s just for them to look at it and go “ah, so that’s what this designer is working on.” It also gives them with a good chance to provide some off-the-cuff feedback about copy or UX, which they normally wouldn’t have a chance to do until the very final version that I would’ve normally shared out.
I initially found this rule difficult to incorporate into my process, but it got much easier as time went on. It served as a nice forcing function to not spend too much time dabbling in the research phase and actually put something together in order to get some people reacting to it. Even if it isn’t final, it gives everyone a basic sense of where my head’s at and what direction I’m thinking of pursuing with a specific problem. If something does require a lot of upfront research, we can always post a teardown of a competitor product critiquing the UI and calling out things that do and don’t work well for our purposes. At the very least, it’s actually letting people know that I’m doing the research, which they wouldn’t have known if I hadn’t posted anything.
Note that this will vary depending on where you’re working. At creative agencies, it’s understood internally that the design process is chaotic and we sometimes need to fumble with a some creative approaches for a while before arriving at something good. At one point, I expressed concern to my manager that I was spending too much time crafting emails to clients explaining my work and specifying what type of feedback I was looking for. I wanted to spend more time actually doing design work. My manager responded by saying that convincing clients and properly communicating your thoughts is all just a part of the design process, and that it’s okay to spend most of your week writing emails and cleaning up your presentation slide deck.
Early-stage startups that haven’t quite achieved product-market fit yet expect designers to spend a lot of time doing user research to figure out some key insights about the market. But at established tech organizations that have a solid product pipeline, you’re expected to constantly be shipping UIs and you’ll quickly need to adjust to how often you’re sharing your work, because the optics are a big deal in ensuring that everyone knows you’re working on the right things.
15. Never stop learning
Putting this in here at the risk of sounding cliché, but it’s an incredibly useful lesson. No matter how experienced or how good you get, there’s always something you can improve on. Design has so many areas you can go broad and deep with overlapping skillsets that it’d be a waste to not at least try everything out. If your day job primarily involves UX, flex that illustration muscle through side projects. If you tend to work solo on projects at work, try to do a group project with other design disciplines whenever possible. The opportunities are all there, and you might discover an area of design or product that you really like but never had the chance to properly explore.
Even as you advance strictly in your specialization, you can learn a lot or pass on your learnings to the junior designers. It’s quite easy to spot out the strengths and weaknesses of your peers, so try to make a habit out of learning the skills that you know you aren’t great at from the ones who are and pass on some learnings about things you actually are good at to those that could use it. There’s a great blog post out there about the difference between junior and senior designers that exposes the behaviors and thinking of more experienced designers from the younger ones, so keep an eye out for these and train yourself to see the bigger picture.
Depending on where you work, the things you do on a day-to-day basis can be so hyper-specialized that you don’t have a good baseline for what other designers at other organizations are doing. Listening to interviews or podcasts is a great way to keep up with that’s happening. The High Resolution interview series is an excellent one to listen to design leaders talk about how they organize and manage their teams, Slack’s Work In Progress is an excellent resource for a fresh take on the general nature of work and life, and NPR’s How I Built This is a fascinating look at how the most recognizable brands and apps today got their humble start. Beyond that, there’s Abstract, the Netflix mini-series about design and the consistently good episodes of the 99% Invisible podcast.
And of course, there’s over a hundred design books I could probably list off that are excellent reading material, but if I had to condense it down to five, it would be: The Elements of Typographic Style, The Design of Everyday Things, The Shape of Design, Designing for Real Life, and Understanding Comics. All of these take a unique look at design from very different lenses and I credit most of my biggest learnings to these books.
16. You can’t be good at everything
“Getting good at doing what you love means having the confidence to recognize what you know, the humility to recognize what you don’t, and the courage to extend our respect to those who make our faults more visible.”
When I was first getting into design and learning the ropes, I was filled with a fresh kind of energy to learn everything I possibly could and excel at every aspect of design. I wanted to make amazing visual effects, master typography, become the best motion designer, understand animation really well, know color theory so well that I could make palettes in my sleep, and come up with novel interaction design patterns that felt incredibly intuitive on my first try.
As I got older, I quickly started realizing that I simply couldn’t be all those things. I definitely tried, but it either became painfully obvious that it just wasn’t for me or that I didn’t certain aspects of design enough to keep pushing myself to get better at them. I had to very consciously think about what parts of design I actually enjoy struggling through and persisting until I arrive at a good solution, and leave the rest for others who were better at it than I was.
“Great designers realize you can’t know everything and are comfortable with high levels of ambiguity. “ — Andy Budd
Five years ago, I would jump at the chance to do any design work that anyone needed with gleeful optimism. Today, if someone needs a logo made, I politely decline and refer them to three designers who I know can do a much better job than I could. But if someone needs to run their app’s navigation structure by me, I’m all ears. And this is all because I’ve recognized that I enjoy debating the nuances of navigational UX in a product far more than obsessing over the details of emblems and symbols that make a good recognizable logo for a brand. And I can do it for far longer and make meaningful contributions to improving the navigation, whereas I’d likely fumble and mess around with the logo a few times before going “ehh, this seems good enough”, knowing full well that it would’ve turned out a lot better if a designer who cared more about it were to have tackled it instead of me.
As I keep growing in my design career, I’m constantly re-thinking what my strengths within design really are and am making a conscious effort to hone in on to those. This can be tough because it means giving up things that you know you enjoy doing but aren’t necessarily the best at. But it’s a sacrifice that must be made in order to get even better at what you do enjoy doing and are indeed good at. It’s a stark difference in the way I approach projects and problems, and it can be quite liberating to accept your weaknesses and substitute them for your strengths.
Closing thoughts
“People may forget what you said, but they’ll never forget how you made them feel.”
You’ve heard the quote, and it holds true for your interaction with products and people as well. Fifty years from now, we won’t remember the micro-interactions of Slack or what channels we frequented. We’ll remember the overall experience we had in it and how we felt using the product. I’ve watched a ton of movies and played a load of games, but there’s something that made the memorable ones stand out. The takeaway is simple to say but incredibly difficult to accomplish: make your products feel memorable.
The same goes for your co-workers and people that you built these products with. They likely won’t remember what you worked on or what products you shipped, but they’ll remember what it was like talking to you and interacting with you. The more seamless and pleasant you can make this, the better your interactions will be with everyone (not just at work, but in life too).
The path forward
It felt a little strange to even write all of this out, because many of these learnings only happened in hindsight. None of them were obvious as they happened to me. It was only after two or more years of intensive retrospection that I was able to frame what really happened in the context of my actions. As I keep growing, I expect I’ll keep learning and reflecting on even more key lessons. Just like a painter constantly has to step away from the easel to examine the overall balance of color, form, proportions, and feel, we constantly need to be re-assessing not only our own design work but also how we fit in to our organizations and where we’re going in our own careers.
Overall, I hope these insights have been valuable to other designers looking for some advice in navigating the messy waters of design in their early career. There aren’t many lifeboats out there and it’s easy to feel like you’re drowning instead of riding out the waves, but having the right mindset and expectations can keep you afloat for much longer than you might think. Stay ambitious while being humble, and the resulting currents of curiosity will carry you to some really exciting shores.
Thanks for reading! As always, please feel free to leave responses below or reach out to me directly via email or Twitter for any thoughts, musings, contemplations, and comments. For further reading, I have some more longform writing on my personal blog about design and other topics.
