How did you land your first couple of positions as a designer?
Straight out of high school, I knew I wanted to be a designer. I pursued a four-year bachelor’s program in Interaction Design at California College of the Arts in San Francisco. Design school gave me a ton of exposure—to not just the field—but to an array of adjunct staff who were also working professionals at companies like IDEO, Frog, and Google. My first few design gigs were primarily found through my professors and their extended networks.
Upon graduating in 2016, I had already gone through the gauntlet with many of my soon-to-be bosses and managers. Late nights in the classroom synthesizing insights on whiteboards and presenting Keynote pitches to my cohort would later serve as “round one” for many positions I’d be referred to.
Funny enough, this is actually how I ended up at Grain. David Merkoski, who taught a design course called “Sustainability”, would end up leading design at Grain. Over a few calls and park-side chats, he made a very persuasive argument for his design team and outlined opportunities for personal growth that would be hard-fought anywhere else. Looking back at these last few years, my time on David’s team has thoroughly changed the trajectory of my career and the way I think about my craft.
What’s the most underrated skill for designers?
An oft-repeated phrase at Evernote Design was “We don’t ship Figma files”. So often, discourse in design is centered around design artifacts. We champion solutions more vocally than we champion processes.
A product designer’s effectiveness, in my opinion, is made or broken by how well they can communicate—to their peers, during critique. To leadership during roadmap planning sessions. To their engineering team when scoping work, vetting feasibility, and throughout implementation.
Communicating not just what we’re doing as designers but why we’re doing it is easily one of the most underrated skills.
Design is inherently a collaborative practice. When a designer’s process fails to propagate the history, perceived value, and intent behind their decisions to their cross-functional teams, they’ve robbed their team of a chance to invest in the work themselves. An empowered engineering team doesn’t just flag edge cases during production, they understand the context of the work and can meaningfully return with solutions and suggestions. Not only do the artifacts and output themselves improve, but your own workload and chances for thrash get substantially reduced.
Spending a day working on your communication skills and talking with your team is worth 100x polished auto-layout components with named variants.
I could name a dozen books for improving one’s communication style—but a more radical and impactful suggestion would be to enroll in therapy. Speaking for myself and my compatriots, that’s where we’ve found the greatest insights and actionable feedback relating to communication and the human condition. And, in this wild world of ours, I truly believe everyone can benefit from a good therapist.
What’s a big mistake you’ve made in your career? What did you learn from it?
Investing too heavily in “perfection”.
When I started as a product designer, I was attempting to deliver the same caliber of work I’d regularly experience in my day-to-day life. I believed the only thing standing between a new Sketch document and a product that dominated the app store was my own ambition, talent, and work ethic. I was stubborn and self-critical. I was often unhappy and unsatisfied.
In truth, my lack of experience blinded me to the production limitations of the start-ups and consultancies I worked for. It takes a team of experienced and tenured workers to deliver work at the caliber of Apple or Pentagram. Setting the bar so high so early in my career hurt both myself and my overworked team.
Don’t get me wrong, there’s nothing wrong with giving in to passion and shooting for the moon. You care a lot about the work you do; it’s why you became a designer. But unless you manage to land a prestigious internship or junior design position at one of those name brand gigs (this journey would look very different than mine), I’d encourage you to take a beat. I’ve learned a lot from adjusting expectations. I’m happier and more satisfied for it.
Perfection is the enemy of good—especially when “good” at a startup usually means “fast” and “simple”.
Take a breath and remind yourself that you’re not designing for a product with hundreds of thousands or millions of users. You don’t need to future-proof and account for every corner case across time immemorial. Your job is to shoot for feasible, desirable, and viable at the scale aligned with your team, company, and market. You’ll have plenty of time later in your career to meet, exceed, and raise that bar. You’ll get there.
What are some tips you have for working with other departments outside of design?
I have two tips that each took me a while to internalize; both relate to my previous answer.
Number one: “Kill your darlings”. This quote, oft attributed to Faulkner in the context of writing fiction, absolutely applies to design. To me, this phrase hints at a tendency we creative folk have to get very attached to certain ideas, solutions, and feature sets. One must be able to let go of one’s “darlings” to truly deliver a solution that is best for the user, that can be marketed by your sales team, and can be built within the set scope of any given project. Sure, that fancy date picker component you spent a week on is gorgeous and would make a sexy entry in your portfolio, but maybe it’d be best to use an existing component that’s already been coded. Maybe a pre-built form field would work just fine—if not better—when getting your proposed solution into the hands and hearts of your market.
Number two: “Work in public”. No, I don’t mean opening up Figma in sunny Dolores Park. I’m intending to speak more about the value of working in a manner where product, engineering, and any other key stakeholders can see and engage with your work early and often. As a perfectionist, I can empathize with the desire to wait until something is “ready” before presenting it to a PM, a fellow designer, or front-end team. However, I’ve found a startling measure of success when bringing folks in during the formative stages of the design process to ensure you’re solving the right problem and working towards a solution that can actually be built. So long as: expectations are set appropriately, teams engaging with your work respect the design process, and your boundaries are being respected as an individual contributor, working in public—especially during the Covid pandemic when we’re each more isolated than ever—will almost always improve the quality of your output.
Mentioning Figma here feels like a cop-out. Still, it’s my answer. Figma.
I still remember seeing its power for the first time when joining Evernote. My manager at the time, Aiden Bordner, smiled once he’d learned I’d never used it. “It’ll change everything for you,” he said, booking a room for my Figma introduction. He was right.
I had used Adobe Illustrator for most of my career; even during those years when Sketch and InVision began blowing up on the tooling front. I had been using Illustrator for a decade. I was used to it. I knew where everything was. Even when I had to manually create redlines for specs forcing waterfall production, I held out on learning a new tool during my first few design jobs.
In the years since experiencing Figma, I’ve not opened Illustrator or Sketch more than a handful of times.
It feels cringy to say “auto layout” changed my life—but it did. I build everything with components. I maintain a design library for a cross-functional team. I’d even argue that my job is easier now than it was before Figma. Lots of “work smart, not hard” boons when the gap between wireframe and spec is virtually null.
It’s also a great place to get async feedback. After posting design progress in Slack, anyone can jump in and start giving their input in situ. Clarification can be requested and delivered right where the pixels get placed.
Figma changed the way designers work and collaborate for better. I would say the tool has earned its right to be referenced in nearly every interview that covers design tooling.
How can designers make user interviews more efficient and effective?
In this era of remote work, any designer, PM, or researcher can conduct user interviews virtually through Zoom or any other video conferencing platform. It’s how we’ve been talking with our users in recent years. With a tool like Grain, you now have the ability capture and leverage the actual voice of the customer with just a few clicks. Whether you’re defining a problem, advocating for product scope changes, or illustrating usability issues, you can now wield succinct video clips to tell your narrative and make a case.
No longer must we play this game of “telephone”. From your documentation to presentation, let the voice of the customer presents itself—indirectly enabling users to speak on their own behalf with all the nuances and caveats that often get filtered out.
The Grain platform records, transcribes, and indexes these conversations to allow you and your team to retrieve impactful moments from calls that may have happened forever ago (as research projects can span months and most insights never expire). Content can be organized and collated for presentation. Advanced filters and search capabilities aid with retrospectives. We try to cover the bases.
It’s incredibly meta to work with a platform that you also work on. As much as this might feel like obligatory marketing speak, I really do use Grain with every project and effort I undertake. I’ve always felt a pang of guilt when I’ve paraphrased. I’ve always yearned to effectively paint the full picture. I’ve now learned that the only thing better than advocating for your users is allowing your users to advocate for themselves.
What’s going to be “the next big thing” in product design?
I believe the gap between design and engineering is shrinking rapidly.
We are now seeing roles like design technologist, design system manager, and similar burgeoning positions that are often cross-disciplinary in nature. Designers themselves can build end-to-end experiences without learning a single programming language with visual tools like Origami (and even Unreal Engine’s Blueprint system if you’re looking to experiment with UX/UI for VR). The “no-code” movement is giving Webflow its rightful day in the sun. New design + code tools are being created every day; recently at top of my mind is Jordan Singer’s Prototyper (and really, there are simply too many talented folks building Figma plugins in that space to still be leaving design delivery at “here are bunch of well-named containers and rectangles”).
Designers will continue to embolden their teams as design systems rigor improves and we all start to agree on what to name components. Engineers and PMs at companies of all scales will (idealistically) be able to pull from libraries of well-thought pre-built components to better communicate and implement their design intent.
Tools are getting better.
We’re working smarter.
You’re doing great. Now go out there and make cool shit.
Thanks for chatting, Brett. 🙌