I am a designer who codes because I love both. In fact I think about both the same way: Design and code both benefit users, ultimately. I’ve been at the intersection between design and code for a while now. I started in Front-end Development before JavaScript frameworks became a thing in production which meant that HTML and CSS were given functionality by jQuery.
These days React, Tailwind and a design system mean a lot of CSS development is unnecessary unless you want to customise the look and feel of your site or application. This frees up us designers to focus on user journeys rather than button colours.
Understanding your design system and using it in Figma really helps you provide prototypes that make a lot of sense for your engineering team and have the consistent look your product managers and owners expect.
Here’s six reasons why knowing code can help you do great work by building bridges between your team domains:
1. Knowing code empowers your designs
You might be afraid to let the tech determine your designs, but when you take a balanced approach you can let your design influence your development and vice a versa in a way that is natural and respects both modes.
I use Codepen to work out design challenges in code (you can start with the generative AI tool of your choice). Here’s an example where I wanted to think about Notifications and how they can be simplified so users understand the problem, and how to fix it:
In this example, the design challenge included the need for simple wording, an actionable next step, and a design that matched the future vision for the product I was working on.
Using this coded mockup, the team was able to not only visualise it but have a play. We were able to brainstorm ideas together in a real way, rather than theoretically and we shared this across different teams to get lots of feedback.
2. Technical feasibility is baked into design decisions from day one
Understanding this space between design and tech also means you can communicate more clearly with stakeholders and engineers. This eliminates a lot of the confusion that happens when you don’t understand technical implementation.
Think backwards using a simple example like a loading spinner or skeleton loader for pages. Users hate waiting for page load without knowing what’s happening. This is called the “Doherty Threshold“.
Progress bars help make wait times tolerable, regardless of their accuracy.
This works to such an extent that users even see the delay as a sign a lot is happening, even when it isn’t. 🙂
3. Functional prototypes
Another advantage are functional prototypes. In the Notification Previewer example, developers can respond to the implementation as far as its feasibility. They can either adapt it to their codebase or ask for changes.
Developers can see the prototype implementation and be inspired by it, and they can also provide helpful guardrails and things to watch out for if the prototype might cause implementation issues down the road.
It’s much cheaper to catch these issues at the functional prototyping phase.
4. Faster iteration cycles
When you start with generative AI and give it your engineering team’s tech stack, you can get pretty close to the environment they know well, increasing the chance of a smooth handover of the code.
As an example, you can tell AI to use React + ShadCDN + Tailwind for the code it gives you, then add those to codepen so your prototype is real code. Or, you can get your developers to load it to their system and you can work on it together there.
Be specific about your prompts and get your chosen AI tool to be pragmatic and fix errors as they happen. Have a look at your browser console and feed these errors to it. With that context it can be much more helpful and even offer additional ideas as you go.
5. Bridge between design and engineering
Once this faster iteration cycle is achieved a bridge between design is created. Don’t confuse this for “Design to HTML” – that is a pipe dream for the most part, even Figma’s Make has a long way to go to achieving this parity.
However, once you create a 1:1 comparion between design and code, you can iterate much faster. Developers start understanding design and are able to make suggestions based on experience. A win-win!
6. Initiative beyond assigned work
Being able to code shows developers you’re a curious designer (stop short of telling them how to build it!) and it shows your team and management you have additional initiative.
The additional benefit is your managers start to understand how the product is built and can work through you with a deeper understanding of this process. This increased trust and understanding means estimates are much better received because they are understood. This bridge makes it happen.
More thoughts
Do you have more reasons to add? Let me know in the comments.
