Suggestions
Jeff Zych
I make developer tools easy to use and beautiful to look at
Jeff Zych is a dedicated and passionate humane designer and technologist with a strong focus on leveraging technology to enhance the quality of people's lives. He holds a Master of Information Management & Systems from the School of Information at the University of California, Berkeley, where he also studied Usability, HCI, and design. Additionally, Jeff pursued his Bachelor of Science in Graphic Communication and Computer Science at California Polytechnic State University-San Luis Obispo. Jeff has an extensive professional background across various reputable organizations, where he held prominent roles in product design and management. His experience includes positions such as Lead Product Designer at Pragma, Owner & Principal Designer at PB & J Designs, Head of Product Design at LaunchDarkly, Product Design Manager at Gladly, Senior Product Designer at Casetext, and leading design roles at Optimizely. Jeff also contributed to academia as a Lecturer at the School of Information, UC Berkeley. His diverse professional journey includes stints as a UI Engineer, Frontend Engineer, and Graduate Student Researcher, showcasing a deep understanding of design, technology, and research.
Highlights
In my many years of designing for developers, I’ve learned some lessons that fly in the face of many common design best practices. Avoid these common pitfalls to design killer developer experiences:
-
Don’t remove as much information as possible in the name of “simplifying” the UI. I’ve seen designers remove “unnecessary” information like IDs and API keys because they think it’s rarely or never used. But in actuality it makes the product harder to use by hiding technical information that developers need to do their job.
-
Be wary of wizards and other “spoonfeeding” flows. These can be too slow and too many clicks to complete a task. Sometimes they hide “advanced” options that developers commonly access, once again in the name of “simplicity”. I’ve watched developers go through these flows and exclaim, “I know what information I need to enter, just give me a damn form to fill out!”
-
Similar to the above, don’t automatically jump to adding coach’s marks, tutorials, walkthroughs, or other common onboarding patterns to your sign up flow. I can’t tell you the number of times I’ve seen developers just click right out of these and start clicking around in the product. (Or worse yet, they can’t click out of it and get frustrated that they can’t just start using the product and bounce). Developers like to learn by doing and figure stuff out on their own, so let them use the actual product as quickly as possible (and a well-designed product should make it clear where to go and what to click, right?)
-
Although developers like to figure things out on their own, sometimes they get stuck or want to learn more about how something works. So make it easy to get to the docs. Page headers, empty states, and creation flows/modals/drawers/etc. are all great places link to documentation. And don’t just rely on a generic link to the docs homepage — link directly to the concepts they’re looking at.
-
More generally, I’ve seen designers (and PMs) become myopically focused on the product and forget that almost all developers tools are being used in concert with IDEs, the terminal, and other tools to get their job done. There’s an ecosystem of tools that your product needs to be used within. Never forget that.
A good way of avoiding these errors is to not just blindly copy design patterns from other apps (which is the number 1 reason I’ve seen designers make these mistakes). As with all UX design, the key is to understand your users and their context. What are they trying to accomplish? What information do they need to do their job? What’s their workflow? If you do that, you’ll be fine.
What common mistakes have you seen when designing developer tools?
“I look with a kind eye at people.”
This line from tennis coach Patrick Mouratoglou (Serena Williams’ former coach) in Nick Kyrgios’ “Good Trouble” YouTube series struck a chord with me. ( https://lnkd.in/gKMkM4uc )
Patrick said he always looks for the positives in players. Commentators and the peanut gallery is quick to judge and point out flaws and what they need to improve, rather than looking for the positives.
It made me realize I’ve always been someone who looks at people with a kind eye as well. Friends, family, coworkers, everyone.
But it also made me realize that as a manager, the clashes I had with leadership and a company’s culture stemmed from it being a place where they don’t have a kind eye. They take a critical eye to everything and everyone.
This was in especially sharp relief when doing performance reviews for my team. I would always bring their strengths to the conversation, while my peers and leadership would only see weaknesses.
These interactions made me doubt myself. “Am I not looking with a critical enough eye at my team? Am I deluding myself about this person’s abilities?” But watching this interview made me realize not having a “kind eye” isn’t a liability - it’s a strength. If it worked for Serena’s coach to lift her to 23 grand slams, then it can work for me.
