What I Learned In My First Year as a Product Designer

For the past year, I’ve had an incredible experience contributing to the design team at Edmodo, a K-12 education startup backed by Greylock Partners, Benchmark Capital, and Union Square Ventures. While I wasn’t new to building stuff, having hacked projects together with friends in college, the last twelve months have afforded me the opportunity to ship world-class software alongside seasoned veterans. Now that I have a couple of product cycles under my belt, I’ve learned a lot about what to do (and what not to) when working on a multidisciplinary product development team. For those who have just graduated and are about to enter Startupland, here are some key takeaways:

1. Your job is to get good design shipped.
Sometimes it seems like a designer’s main responsibilities are creating immaculately layered PSDs, wearing skinny jeans and finding the perfect 400×300 area to Dribbble-crop. It’s easy to romanticize the creative nature of our work and put the blame on engineers when what we “delivered” wasn’t implemented correctly. Your mindset should be the product that goes out the door is the deliverable. The best way to ensure designs are shipped as intended is to work extremely closely with engineers during implementation. Like, literally sit next to them.

2. More communication is always better.
At every stage of the product cycle, it’s much better to over-communicate than under-communicate. You want as clear of an understanding as possible on the goals of what is to be built, the hard, release-blocking requirements, and what ultimately needs to happen for the project to be considered a success. The costs of over-communication are chatting with your teammates a little more often or sending a couple extra emails. The cost of under-communication? A waste of time and effort, finger-pointing, and somewhere, a unicorn dies.

3. Tighten feedback loops for faster iteration processes.
This applies to everything from communication between teams all the way down to your own personal workflow. To tighten your internal feedback loops, it’s important to immediately see the results of decisions you make while designing, through front-end code or high fidelity prototyping tools. The closer you can get to what users will actually be interacting with, the better. Within the company, you want to get feedback early and often from engineers, PMs, and fellow designers to build consensus and identify bottlenecks. External feedback loops matter too — once the product has shipped, find out how your design is performing with actual users by communicating with the data, user research and marketing teams. While you’re not obligated to incorporate any and every opinion you get, do your best to think through feedback critically with an open mind. You should be confident enough to propose a well-thought solution, but humble enough to discard it.

4. Explain “why” in their terms.
Make a deliberate effort to cultivate empathy for other team functions and be able to explain your designs to whoever it is you’re talking to, in their terms. It’s ok to use design jargon as long as you’re able to educate others on what the impressive-sounding words you use actually mean. Break down how your designs fit into the context of what they do and/or company goals. This requires you to get inside the mind of people in a variety of functions and gain a basic understanding and appreciation of what they do and can manifest itself in many ways. For a PM, it might mean analyzing the tradeoffs between an individual user’s experience and the network effects of introducing an “invite friends” flow early in the registration process, or explaining what you might stand to gain or lose if a project is delayed to do some last minute polishing. For an engineer, it might mean thinking through transitions, error states, edge cases, and user extremes so they don’t have to. Which brings me to my next point:

5. Engineers are your best friends.
Design is about relationships. Relationships between elements in a visual hierarchy, relationships between screens in a flow, relationships between the user and product and ultimately, the relationships from human to human. At the very core of every product is the designer-engineer relationship. It serves as the foundation for the basic building blocks of every startup — an idea, a design, and an implementation. Ultimately, engineers are the translators of your ideas into reality — without them, the pixel-perfect mockups you create remain exactly just that — mockups. They’re not real products. If you’re able to take the onus on yourself to educate those who are less design-literate and get them excited about building out your designs, things will go better and much more quickly. Go out of your way to build an understanding of the technical constraints engineers face and help set context on how final a design is so they can figure out how to architect code in a way that is more easily modified if things change.

6. Learn to steal well.
“Good designers copy, great designers steal”. Dissecting what makes other products tick, thinking specifically about what works well and why, and then figuring out how to implement them into your designs will greatly add to your repertoire. Even designs considered great and novel often apply concepts from other domains to the problem at hand. While you should avoid completely ripping off someone else’s visual style, taking elements of what works well in other products, like UX principles and interaction patterns, will make the work you produce better. There are plenty of examples of products that have been made worse in an attempt to create something new and original — things tend to fall naturally into an equilibrium of convention for the simple reason that they just work.

7. Design is like playing piano.
Braden Kowitz, Design Partner at Google Ventures, made this analogy and it really stuck with me. You can study all the music theory you want and listen to every great piece ever composed, but you’ll never become a stellar pianist without thousands of hours of practice. In the same vein, you can read about design theory, play with hundreds of products, and deconstruct user experiences to build and refine taste, but nothing can substitute or replace the actual hours spent designing. We all get into design because we have good taste, but the hardest and most frustrating part of when you’re just starting is that there’s this gap between what you’re able to do and what you would consider good (I’m definitely not there yet). The only way to bridge it is to do work. A lot of it.

8. Beauty is not the goal.
Design is different from art in that it’s about solving problems rather than purely for aesthetics reasons. Although many may dress the part, being an artist is not a prerequisite to being a good designer. If you have artistic abilities, use them to make your designs better instead of defining them.

9. Err on the side of caring too much.
Design is in the details, and it’s much better to care too much rather than too little when it comes to attention to detail. If you don’t have at least one engineer poking fun at your pixel obsessiveness from time to time, you can probably afford to be a little more thorough. Avoid the slow death by a thousand cuts by showing that you care enough about making the best product humanly possible. Setting expectations for a minimum acceptable level of quality is infectious and raises the bar for everyone. But…

10. There’s no such thing as “done”.
Don’t feel bad about shipping an incomplete design, because in a continuously iterative development process, nothing is ever finished. This doesn’t mean it’s ok to sacrifice quality. Better to ship a high quality product with smaller scope than planned rather than ship something full scope, but half-baked.