Navigating The Unknown: Code
YEAR
2024
CATEGORY
ARTICLE
ROLE
DESIGNER/ENGINEER
ORGANIZATION
PERSONAL
Should designers code? This question has sparked countless debates across Twitter threads, podcasts, and design conferences. Everyone has an opinion, and what I'm sharing here is mine - shaped by experience, but certainly not gospel. If you're a designer contemplating this leap, perhaps my perspective will offer some clarity. My answer is straightforward:
if you want to, then absolutely!
If you've ever felt constrained by static mockups or frustrated by prototypes that only hint at your true vision, code becomes the logical next step. Yes, no - code tools like Framer, Play, and Webflow have democratised development, but they still require you to peek under the hood when you want to push boundaries. The nuanced animations you can craft with native Swift, or the precise interactions possible with custom JavaScript - these simply can't be replicated with drag-and-drop interfaces (and don't even get me started on the generative art possibilities with Processing and P5.js). This isn't to diminish no-code tools; they serve their purpose well. But code? Code is where the real magic happens.
Should designers code? This question has sparked countless debates across Twitter threads, podcasts, and design conferences. Everyone has an opinion, and what I'm sharing here is mine - shaped by experience, but certainly not gospel. If you're a designer contemplating this leap, perhaps my perspective will offer some clarity. My answer is straightforward:
if you want to, then absolutely!
If you've ever felt constrained by static mockups or frustrated by prototypes that only hint at your true vision, code becomes the logical next step. Yes, no - code tools like Framer, Play, and Webflow have democratised development, but they still require you to peek under the hood when you want to push boundaries. The nuanced animations you can craft with native Swift, or the precise interactions possible with custom JavaScript - these simply can't be replicated with drag-and-drop interfaces (and don't even get me started on the generative art possibilities with Processing and P5.js). This isn't to diminish no-code tools; they serve their purpose well. But code? Code is where the real magic happens.
Should designers code? This question has sparked countless debates across Twitter threads, podcasts, and design conferences. Everyone has an opinion, and what I'm sharing here is mine - shaped by experience, but certainly not gospel. If you're a designer contemplating this leap, perhaps my perspective will offer some clarity. My answer is straightforward:
if you want to, then absolutely!
If you've ever felt constrained by static mockups or frustrated by prototypes that only hint at your true vision, code becomes the logical next step. Yes, no - code tools like Framer, Play, and Webflow have democratised development, but they still require you to peek under the hood when you want to push boundaries. The nuanced animations you can craft with native Swift, or the precise interactions possible with custom JavaScript - these simply can't be replicated with drag-and-drop interfaces (and don't even get me started on the generative art possibilities with Processing and P5.js). This isn't to diminish no-code tools; they serve their purpose well. But code? Code is where the real magic happens.
An unlikely reference source, but the closes representation of how it feels as a designer who can code. Artwork for Tool
An unlikely reference source, but the closes representation of how it feels as a designer who can code. Artwork for Tool
Here's where many designers stumble - not from lack of ability, but from an overwhelming array of choices. HTML and CSS for the web? Swift and SwiftUI for iOS? (Android developers, you're not forgotten -Kotlin deserves mention too.) These are merely entry points into what quickly becomes a fascinating rabbit hole. My advice:
start with purpose, not platform.
Identify a specific problem you want to solve, then choose the technology that serves that goal. Align with either the platform you resonate with most or where the most compelling work is happening in your field.
For me, it was SwiftUI - I wanted to build a wearable app for our real estate agents at PropertyGuru, to receive instant lead notifications. Having identified clear intent, my next step was defining exactly what I wanted to build.
How to Start: Overcoming Decision Paralysis
Update: Its 2025, and if you are still not involved with code somehow, then you are missing out on something amazing!
My experiments
Building Your First Real Thing
What's Next
Learning to code as a designer isn't a destination - it's an ongoing journey, and honestly, I'm still very much in the middle of it. I'm not a full-fledged developer by any means, and some days I still feel like I'm googling basic syntax. But that's okay. The immediate benefits are already clear:
I can have more meaningful conversations with developers.
Make more realistic design decisions, and
Prototype interactions that would have been impossible before.
Once you've survived the initial reality check and accepted that your first attempts won't be perfect, it's time to tackle your actual project. For me, this was the wearable app for lead notifications - a seemingly simple concept that quickly revealed the complexity hiding beneath the surface.
Scope creep
What started as "display a notification when a lead comes in" quickly spiraled into lead quality scores, custom sounds, device syncing, and CRM integration. As designers, we're trained to think holistically, but when learning to code, that becomes paralyzing.
Embracing the MVP
Version 1.0 did one thing: receive a push notification and display basic lead information. Few animations, less custom UI, no advanced features. Just core functionality that solved the actual problem.
Constraints as a Design Tool
WatchOS limitations - small screen, limited interactions, battery concerns, etc, forced me to strip away unnecessary elements. The result was cleaner and more purposeful than what I might have created with unlimited freedom.
The Reality of Shipping
By the end, I had something functional running on actual devices. It wasn't beautiful by design standards or elegant by developer standards, but it worked. The gap between "designer who codes" and "developer who designs" isn't as wide as it seems - it just requires getting comfortable with imperfection.
The watch app that I finally ended up building
The long-term possibilities feel exciting, even if they're still a bit fuzzy. That app idea I had but dismissed as "too technical"? It doesn't seem quite so impossible anymore. Those startup opportunities that felt out of reach? My growing hybrid skill set is starting to open doors I didn't expect. The key is accepting that you don't need to become a senior developer to benefit from coding skills. There's no single "right" path, and you definitely don't need to choose between being a designer or a developer. My advice: keep building small things. I'm still learning something new with every project, whether it's a cleaner way to write a function, discovering a useful library, or just getting more comfortable with the development workflow. The combination of design thinking and basic technical skills creates a perspective that feels increasingly valuable, even if I'm nowhere near calling myself a "real developer." You're not trying to replace anyone —you're just expanding what's possible in your own work.
Start with Purpose, Not Platform
Don't get paralyzed choosing between technologies. Pick a real problem you want to solve, then learn whatever tech stack serves that goal. Having a concrete project keeps you motivated and gives your learning direction.
Key Takeaways
Embrace Imperfection Early
Your first coded projects won't match your design standards, and that's okay. The gap between design vision and coding reality is part of the learning curve. Ship working solutions first, then iterate and refine.
Consistency Beats Intensity
You don't need marathon coding sessions to make progress. Dedicating 5-7 hours per week with free resources over a few months is enough to build real things. Small, regular practice sessions compound into significant skills over time.
After weeks of watching tutorials and bookmarking resources, the moment arrives when you actually sit down to write your first line of code. For me, it was opening Xcode and staring at a completely blank canvas - not the familiar artboard of Figma, but an intimidating text editor filled with cryptic syntax and zero visual feedback. The humbling reality hit immediately: my decade of design experience didnt't automatically translate to coding prowess.
This is not the way that designers are used to working.
That muscle memory of cmd+D to duplicate, or the intuitive drag-and-drop interactions I had mastered? Useless here. Instead, I was fumbling with semicolons, indentation, and googling "how to change text color in Swift" like it's my first day using a computer. But here's where it got interesting - my design background became both a superpower and a curse. The superpower: I inherently understood user experience, visual hierarchy, and what good interaction design feels like. When I saw a clunky interface or poorly structured information architecture in a coding tutorial, my design brain immediately flagged it as wrong. I knew what the end result should look and feel like, even if I can't code it yet. The curse? I had incredibly high standards. While other coding beginners might be thrilled to get a button to appear on screen, I was already frustrated that it's not the right shade of red, didn't have proper corner radius, and the typography felt off. I knew exactly how it should look because I had designed it already - but translating that vision into code felt like trying to paint a masterpiece with oven mitts on.
Your first coded prototype will not match your Figma designs. Accept this now.
That perfectly aligned grid system you spent hours perfecting? It'll probably break on different screen sizes. Those smooth micro - animations you envisioned? They might feel janky or take weeks to implement properly. The beautiful type hierarchy you're known for? Good luck finding the exact font weights and spacing that make it sing. This gap between design vision and coding reality isn't a failure - it's the learning curve. Every designer who codes has been there, staring at their screen wondering why something that took 30 seconds to design is taking 3 hours to implement. The key is remembering that you're not just learning syntax; you're learning an entirely new way to bring ideas to life.
First lines of code 😅
The Search for Learning Resources
Here's the reality: there's no single holy grail resource that transforms you into a coding expert overnight. Instead, you'll discover valuable insights scattered across YouTube channels, Twitter accounts, and blog posts. Some of my go-to sources included
Hacking with Swift (Paul Hudson's comprehensive SwiftUI tutorials)
Following folks like @twostraws, @johnsundell, and @donnywals on Twitter for daily Swift tips and insights.
The design-engineering community on Twitter is particularly valuable - accounts like @rauno, @emilkowalski_, and @shadcn share incredible examples of design and code working together. Beyond these mainstays, I found myself diving into countless Stack Overflow threads and obscure documentation pages, hunting for the exact functionality I envisioned. The learning process becomes a treasure hunt - and that's actually part of what makes it engaging.
Let's be honest about what this journey actually requires. I dedicated about 5-7 hours per week to learning, spread across evenings and weekends over roughly 4 months before I felt comfortable building something real. The best part? I didn't spend a single dollar on paid courses. Everything I learned came from free resources - Hacking with Swift's comprehensive free tutorials, YouTube channels, Apple's official documentation, and countless blog posts from the developer community. The only "cost" was my time and the mental energy to push through frustrating moments when nothing seemed to work. I found that shorter, regular sessions (1 - 2 hours) were more effective than marathon weekend coding sessions. The abundance of high - quality free content means the barrier to entry is incredibly low - you just need consistency and patience. Your mileage may vary, but expect to invest 3-6 months of consistent practice before you can build something meaningful, all without spending anything beyond your time.
Cost and Time Investment
The next step involved a slightly different approach than my usual design process. Rather than diving straight into Figma, I decided to design directly in code as I built the wearable app. This meant thinking through user flows and interaction patterns mentally first, then letting the design emerge through the development process itself. This approach proved both challenging and enlightening - it forced me to understand the technical constraints upfront rather than discovering them later when translating designs to code. Having a clear functional goal of providing instant lead notifications for our real estate agents at PropertyGuru kept me focused, even without traditional mockups to reference. Once I had my concept solid, it was time for the next essential step: finding the right learning resources.
Designing the Solution First
Here's where many designers stumble - not from lack of ability, but from an overwhelming array of choices. HTML and CSS for the web? Swift and SwiftUI for iOS? (Android developers, you're not forgotten -Kotlin deserves mention too.) These are merely entry points into what quickly becomes a fascinating rabbit hole. My advice:
start with purpose, not platform.
Identify a specific problem you want to solve, then choose the technology that serves that goal. Align with either the platform you resonate with most or where the most compelling work is happening in your field.
For me, it was SwiftUI - I wanted to build a wearable app for our real estate agents at PropertyGuru, to receive instant lead notifications. Having identified clear intent, my next step was defining exactly what I wanted to build.
How to Start: Overcoming Decision Paralysis
Should designers code? This question has sparked countless debates across Twitter threads, podcasts, and design conferences. Everyone has an opinion, and what I'm sharing here is mine - shaped by experience, but certainly not gospel. If you're a designer contemplating this leap, perhaps my perspective will offer some clarity. My answer is straightforward:
if you want to, then absolutely!
If you've ever felt constrained by static mockups or frustrated by prototypes that only hint at your true vision, code becomes the logical next step. Yes, no - code tools like Framer, Play, and Webflow have democratised development, but they still require you to peek under the hood when you want to push boundaries. The nuanced animations you can craft with native Swift, or the precise interactions possible with custom JavaScript - these simply can't be replicated with drag-and-drop interfaces (and don't even get me started on the generative art possibilities with Processing and P5.js). This isn't to diminish no-code tools; they serve their purpose well. But code? Code is where the real magic happens.
An unlikely reference source, but the closes representation of how it feels as a designer who can code. Artwork for Tool
Update: Its 2025, and if you are still not involved with code somehow, then you are missing out on something amazing!
Home
Stories
Play
About
Here's a small gallery of what Ive built for myself as well as for PropertyGuru.
My experiments
Start with Purpose, Not Platform
Don't get paralyzed choosing between technologies. Pick a real problem you want to solve, then learn whatever tech stack serves that goal. Having a concrete project keeps you motivated and gives your learning direction.
Embrace Imperfection Early
Your first coded projects won't match your design standards, and that's okay. The gap between design vision and coding reality is part of the learning curve. Ship working solutions first, then iterate and refine.
Consistency Beats Intensity
You don't need marathon coding sessions to make progress. Dedicating 5-7 hours per week with free resources over a few months is enough to build real things. Small, regular practice sessions compound into significant skills over time.
Key Takeaways
Learning to code as a designer isn't a destination - it's an ongoing journey, and honestly, I'm still very much in the middle of it. I'm not a full-fledged developer by any means, and some days I still feel like I'm googling basic syntax. But that's okay. The immediate benefits are already clear:
I can have more meaningful conversations with developers.
Make more realistic design decisions, and
Prototype interactions that would have been impossible before.
What's Next
The long-term possibilities feel exciting, even if they're still a bit fuzzy. That app idea I had but dismissed as "too technical"? It doesn't seem quite so impossible anymore. Those startup opportunities that felt out of reach? My growing hybrid skill set is starting to open doors I didn't expect. The key is accepting that you don't need to become a senior developer to benefit from coding skills. There's no single "right" path, and you definitely don't need to choose between being a designer or a developer. My advice: keep building small things. I'm still learning something new with every project, whether it's a cleaner way to write a function, discovering a useful library, or just getting more comfortable with the development workflow. The combination of design thinking and basic technical skills creates a perspective that feels increasingly valuable, even if I'm nowhere near calling myself a "real developer." You're not trying to replace anyone —you're just expanding what's possible in your own work.
Once you've survived the initial reality check and accepted that your first attempts won't be perfect, it's time to tackle your actual project. For me, this was the wearable app for lead notifications - a seemingly simple concept that quickly revealed the complexity hiding beneath the surface.
Building Your First Real Thing
Scope creep
What started as "display a notification when a lead comes in" quickly spiraled into lead quality scores, custom sounds, device syncing, and CRM integration. As designers, we're trained to think holistically, but when learning to code, that becomes paralyzing.
Scope creep
What started as "display a notification when a lead comes in" quickly spiraled into lead quality scores, custom sounds, device syncing, and CRM integration. As designers, we're trained to think holistically, but when learning to code, that becomes paralyzing.
Embracing the MVP
Version 1.0 did one thing: receive a push notification and display basic lead information. Few animations, less custom UI, no advanced features. Just core functionality that solved the actual problem.
Embracing the MVP
Version 1.0 did one thing: receive a push notification and display basic lead information. Few animations, less custom UI, no advanced features. Just core functionality that solved the actual problem.
Constraints as a Design Tool
WatchOS limitations - small screen, limited interactions, battery concerns, etc, forced me to strip away unnecessary elements. The result was cleaner and more purposeful than what I might have created with unlimited freedom.
Constraints as a Design Tool
WatchOS limitations - small screen, limited interactions, battery concerns, etc, forced me to strip away unnecessary elements. The result was cleaner and more purposeful than what I might have created with unlimited freedom.
The watch app that I finally ended up building
The Reality of Shipping
By the end, I had something functional running on actual devices. It wasn't beautiful by design standards or elegant by developer standards, but it worked. The gap between "designer who codes" and "developer who designs" isn't as wide as it seems - it just requires getting comfortable with imperfection.
The watch app that I finally ended up building
After weeks of watching tutorials and bookmarking resources, the moment arrives when you actually sit down to write your first line of code. For me, it was opening Xcode and staring at a completely blank canvas - not the familiar artboard of Figma, but an intimidating text editor filled with cryptic syntax and zero visual feedback. The humbling reality hit immediately: my decade of design experience didnt't automatically translate to coding prowess.
First lines of code 😅
This is not the way that designers are used to working.
That muscle memory of cmd+D to duplicate, or the intuitive drag-and-drop interactions I had mastered? Useless here. Instead, I was fumbling with semicolons, indentation, and googling "how to change text color in Swift" like it's my first day using a computer. But here's where it got interesting - my design background became both a superpower and a curse. The superpower: I inherently understood user experience, visual hierarchy, and what good interaction design feels like. When I saw a clunky interface or poorly structured information architecture in a coding tutorial, my design brain immediately flagged it as wrong. I knew what the end result should look and feel like, even if I can't code it yet. The curse? I had incredibly high standards. While other coding beginners might be thrilled to get a button to appear on screen, I was already frustrated that it's not the right shade of red, didn't have proper corner radius, and the typography felt off. I knew exactly how it should look because I had designed it already - but translating that vision into code felt like trying to paint a masterpiece with oven mitts on.
Your first coded prototype will not match your Figma designs. Accept this now.
That perfectly aligned grid system you spent hours perfecting? It'll probably break on different screen sizes. Those smooth micro - animations you envisioned? They might feel janky or take weeks to implement properly. The beautiful type hierarchy you're known for? Good luck finding the exact font weights and spacing that make it sing. This gap between design vision and coding reality isn't a failure - it's the learning curve. Every designer who codes has been there, staring at their screen wondering why something that took 30 seconds to design is taking 3 hours to implement. The key is remembering that you're not just learning syntax; you're learning an entirely new way to bring ideas to life.
Here's the reality: there's no single holy grail resource that transforms you into a coding expert overnight. Instead, you'll discover valuable insights scattered across YouTube channels, Twitter accounts, and blog posts. Some of my go-to sources included
Hacking with Swift (Paul Hudson's comprehensive SwiftUI tutorials)
Following folks like @twostraws, @johnsundell, and @donnywals on Twitter for daily Swift tips and insights.
The Search for Learning Resources
The design-engineering community on Twitter is particularly valuable - accounts like @rauno, @emilkowalski_, and @shadcn share incredible examples of design and code working together. Beyond these mainstays, I found myself diving into countless Stack Overflow threads and obscure documentation pages, hunting for the exact functionality I envisioned. The learning process becomes a treasure hunt - and that's actually part of what makes it engaging.
Let's be honest about what this journey actually requires. I dedicated about 5-7 hours per week to learning, spread across evenings and weekends over roughly 4 months before I felt comfortable building something real. The best part? I didn't spend a single dollar on paid courses. Everything I learned came from free resources - Hacking with Swift's comprehensive free tutorials, YouTube channels, Apple's official documentation, and countless blog posts from the developer community. The only "cost" was my time and the mental energy to push through frustrating moments when nothing seemed to work. I found that shorter, regular sessions (1 - 2 hours) were more effective than marathon weekend coding sessions. The abundance of high - quality free content means the barrier to entry is incredibly low - you just need consistency and patience. Your mileage may vary, but expect to invest 3-6 months of consistent practice before you can build something meaningful, all without spending anything beyond your time.
Cost and Time Investment
The next step involved a slightly different approach than my usual design process. Rather than diving straight into Figma, I decided to design directly in code as I built the wearable app. This meant thinking through user flows and interaction patterns mentally first, then letting the design emerge through the development process itself. This approach proved both challenging and enlightening - it forced me to understand the technical constraints upfront rather than discovering them later when translating designs to code. Having a clear functional goal of providing instant lead notifications for our real estate agents at PropertyGuru kept me focused, even without traditional mockups to reference. Once I had my concept solid, it was time for the next essential step: finding the right learning resources.