Looking back on a year at a startup
--
Prior to being a Product Designer at Envoy, I was studying Economics and Psychology at UC Berkeley. I had no real idea about what I wanted to do, except that I had a fascination with behavioral economics and a desire to take care of people. Happily enough, product design fit the bill for both. After putting together a portfolio of personal projects, design challenges, and class projects, I started a long recruiting process that ended with me finding a home on Envoy’s design team.
This isn’t advice on “how to break into the industry” or “how to be good at product design” — there’s already a wealth of resources online (I found the Facebook and Dropbox teams particularly useful). Instead, I’ve gathered some thoughts on what’s helped me in my first year as a product designer: things I’ve learned, and things I think about often at work.
Understanding problems
It’s hard to design a good solution to a problem until you understand what the problem really is. Without adequate understanding, you risk building a solution that doesn’t satisfy your user’s needs.
One of the most valuable skills I’ve learned is to challenge assumptions and ask questions. When I started working as a product designer, product specs felt concretely defined, and I went into the design process without really asking why the requirements on the specs were there (and thus not understanding the problem being solved).
But I’ve learned over time that specs are living documents.
Now before I start a project, I try to pick it apart and ask why it is important.
I make sure I understand the problems the user is facing by digging into existing research and customer feedback. By focusing on the problem at hand, I can contribute more to the spec-writing process and have a bigger role in the high-level product approach.
Shipping things
Though it might feel daunting, shipping and being wrong is better than not shipping in the pursuit of “perfection.” You can work on “perfecting” a feature to no end (see Parkison’s law), but until the feature is in customers’ hands, you won’t know if you’re truly solving a problem.
Sometimes you need to learn by trial and error. I recently designed a feature that extended into the legal domain — I read through the required laws, conducted user research, consulted with a lawyer, and did usability testing, but our first release still overlooked an important customer use-case. Shipping and iterating quickly helped us create the best solution in the end.
When I first started working, I knew in concept that product teams need to ship quickly, but in practice I would get stuck on designing optimizations and solutions for every edge-case. When I started designing experiments with the Growth team, my approach to design evolved.
Growth projects were more about designing proofs of concept, then testing them to see how they performed. It was still important to create a good user experience and visual design, but it was clear that there were low returns to finessing a design that may be scrapped.
I adopted a mentality of expediting experiments so we could gather data, measure results, learn, and iterate; I now apply this mentality to my work for all teams.
Getting feedback and asking for help
Since I didn’t come from a formal design background, I came into my first job wanting to learn all I could. Getting feedback and seeking help allowed me to constantly improve and avoid feeling stagnant.
When you’re early in your career, don’t be afraid to ask for help! It’s really okay to say, “I don’t know; can you help me?”
I encourage you to lean on others and ask for their input. At Envoy, my coworkers bring up great suggestions and help me think about things that I missed. They also provide me with additional perspectives when I’m deciding between several options. Try to think of feedback as another input in your design process that you can accept or respectfully decline.
I’d be lying if I said I never felt frustrated when getting feedback. Though easier said than done, try not to take feedback personally. It helps to remind yourself that the people giving you feedback want you to produce your best work. Think of feedback as well-intentioned and coming from a place of genuine curiosity. Feedback is an invaluable way of getting out of your own head, rooting out potential weaknesses in early stages, and opening productive discussions.
Imposter syndrome
Everything that can be said about imposter syndrome for designers has already been said in some blog or Medium post somewhere.
But it’s real, it comes in waves, and I feel it regularly.
Before I worked in product design, I read a lot of those articles about designers feeling inadequate, which made me feel panicked; if these seasoned professionals didn’t feel like they were up to par, what did that mean for me?
After I started working at Envoy, imposter syndrome took on a new form. In the back of my mind I had the notion that I had somehow lucked my way into a job that I didn’t deserve. But at some point, it occurred to me that while luck and fit may have been a part of it, multiple people who I respect and consider to be very smart went through an extended interview process and ultimately decided that I was qualified and that they wanted to work with me — I can’t discount that.
Whenever I feel imposter syndrome creeping up on me. I try my best to remind myself of a couple things:
- Fake it ’til you make it.
- Don’t let feelings of inadequacy stop you.
- Stop feeling bad about not feeling good enough.
I’ll be honest, these can be difficult to internalize, but repeating them helped shift my mentality from “I’m not good enough” to a more positive mindset.
Even with prior knowledge about imposter syndrome, I still grapple with it. If you’re feeling like you’re not good enough, it probably just means you have high expectations for yourself, you care about your work, and you know you have the potential to do better. There’s an Ira Glass quote about that somewhere.
Learning how to code as a non-technical designer
I don’t consider myself a technical designer. I can currently make HTML and CSS changes to help out the engineers with visual tweaks, but I’m trying to learn more. My first exposure to coding was using HTML tags to generate sparkly cursors on Neopets, though most of what I know now I learned in a student-led web design course I took in college.
I want to code more at work because I want our visual design to be consistent and polished; I want to be able to execute on my design visions; I want to communicate more effectively with engineers and help out the front-end engineers when I can; and it will make me more valuable as a designer.
It’s something I’m interested in and want to get better at, but learning to code is a process.
I recently set out to change a page margin and ended up spending hours trying to run our local environment, search for answers, and find where the code for that margin lived. I eventually asked one of my coworkers for help, but I felt immensely frustrated because having the ability to make fixes myself was the reason that I wanted to code in the first place. I feel a little bit of pride with every pull request I make, but I wonder what the impact of that contribution is and whether my time would have been better spent on user research or design explorations.
I’m still going to continue to help out with front-end code and try to learn more — I’d like to learn Ember.js to be able to create reusable components as part of a joint initiative between the product designers and front-end engineers to close the gap between design and code.
In summary…
While I couldn’t have anticipated everything that happened in the last year, I’m happily reassured that product design is a career that I’m passionate about. I’m excited for what’s to come for product and design at Envoy.
Finally, if you have questions about pursuing product design, or if you’re also starting a career in design, don’t hesitate to reach out! A lot of people helped me (and are still helping me) navigate my way through, and I’d love to do the same for you.
Thanks for reading! Be sure to visit envoy.design and subscribe to get notified when we publish something new.
