you are what you ship
What do we deliver as product designers? Ideas? Wireframes? Prototypes? While these things are certainly critical to a designer’s role, we're ultimately held accountable for really one thing: the end shipped experience.
This principle is obvious in other design disciplines. Wouldn't it be absurd to celebrate Jony Ive for his prototypes rather than computers that people can use? What if car designers were judged by their renderings rather than cars that people drive? Architects celebrated for their blueprints rather than buildings? What you deliver is what matters in these fields, and product design is no different.
On the other hand, we don't always have total control over the end product. Building a product is a complicated process. It requires proper scoping and prioritization; approval from executives and managers; collaboration with developers and product managers. Given these limitations, how do we get close to a good shipped experience with as little compromise?
There are 3 possible approaches:
You rely on persuading other people: If you're good with people and convincing them of your ideas, you can maybe use this skill to tell them what to do. There are many problems with designers telling developers what to do (worth another post), but the biggest downside is that this method is limited by whom you work with... and people come in all shapes and sizes.
You work with skilled front-end developers: If the FE developers you work with have a knack for UX and the finer details, you're in luck! There's minimum requirement on your end. The problem again is that this approach relies on external factors in whom you work with.
You know how to code: The best way to take charge of your own destiny is to learn how to code. Not only will you build rapport with your fellow developers now that you speak their language, you can tweak, iterate, and build whatever you want (within reason), especially the small details that are so often missed. It's the best way to repeatedly ensure a good shipped experience, and it scales well to any team or organization.
With Approach 3, I don't think this means abandoning Sketch (or your design tool of choice). Good shipped experiences still require tinkering and exploration, and design tools are still the best way to do this. Design tools also excel in communicating a vision which is difficult to do in code. But I do think this means spending less time in design tools and more time in code (especially in a world where design systems are becoming more prevalent). This also doesn't mean you stop communicating or collaborating with your team members. Design is futile in isolation.
I'm currently on a long journey to learn front-end development. So far, Free Code Camp has been a helpful resource (they're free!), though the best way has been finding an excuse to code and fix small issues at work.
As always, thank you for reading. If you'd like to read more on this topic, Intercom Design had a few things to say in a recent tweet storm.
Posted from London at 11:21 PM BST, 03/31/2019