Why I learnt to code — a designer
After spending the last few years working as a designer — sometimes in product, other times in disciplines I had no business — I had reached a point where I was confident in my skills. There is rarely a product design I can’t replicate, or do myself.
Something was lacking though, as always, since the beginning. Keep in mind, I have the utmost respect for all the engineers I’ve ever worked with. But this much was obvious;
No one is likely to pay more attention to the design details than the designer.
Backstory
Now let’s rewind to before I became a full-time designer. I was learning it all — as I, unfortunately, tend to do every time. I had picked up the basics of HTML, CSS and Javascript, and even some React. Granted, I was too excited to skip ahead. I may not have spent enough time with the basics as I should have. This cost me, but I was too excited by my new superpowers to notice. It all didn’t matter in the end — I got a full-time job as a designer.
I went all in, rapidly getting better, so much so that I couldn’t look at anything I worked on longer than 3 months ago without feeling deep shame. But it was a sign that I was growing, I was happy.
Then it happened the first time. I had worked on a product and sent it off to engineering. When I got the test link I was aghast, it was … ugly. Now, I must take primary responsibility as the designer for its ugliness (remember, deep shame). But man, did they take it all the way.
After my initial wave of slight annoyance. I thought to myself, it’s nothing a design review wouldn’t fix — I was right. So I put together a doc, taking screenshots of the differences between the live site and the design, with a brief comment on the difference, why it mattered and how to fix it, so the engineers didn’t have to go back and forth in Figma to resolve them. And it worked, for the most part. I found that the tinier the detail, the more reluctant the engineers were to fix it. “It doesn’t matter” they often said. But I was relentless, and eventually conceded on some so that peace would reign.
I’m certain no designer reading this is unfamiliar with that story, I could write a lot more about *this* topic, but then I would be derailing this article by just airing my beef, we move.
There were a couple of other things I noticed from my experience. I routinely saw other designers struggle to communicate with engineers in ways that I did not — I knew some of the lingo. More interestingly, I often saw other designers get into arguments with engineers about their design, and the possibility or impossibility of it. You see, designers had become so far removed from the actual building process that they were satisfied as long as they had used the most sophisticated technique in their arsenal, not caring how it got built, but then being upset at the inevitably bad outcome. I came to a conclusion; the more I knew how to code, the better I became as a teammate (and as a designer).
Side note: I remember being very excited when Figma added the auto-layout feature. I remember saying to my friends “this is flexbox, amazing”.
Product Manager? K*** me now
A few years down the line, I found myself working (unfortunately) as a product manager, still reaping the fruits of the little code I wrote. This move brought me much closer to the engineering team, and that did two things for me.
Firstly, it gave me insight into the entire process of building (an app).
Like I said earlier, I was too excited to learn work correctly. So I had no mental model of how backends or APIs worked, just fighting with divs and buttons.
I was in a lot more conversations with engineers about planning work, what to build, how to build and trade-offs. Suddenly my luck had run out, nobody was talking about divs!
The second thing it did was to make me see how much the final experience of the product came from what the engineers did (not the designer).
This made me uneasy, I know, as designers, we are always “solving problems” and “crafting experiences”. But in reality, maybe we did some problem-solving, but the engineers certainly did the crafting.
The users will never experience the Figma file, what they experience though is the code written by the engineers.
After working in a few teams and with a few people, I figured there are many ways to ensure your best “experience people” have the most sway on the final experience. Some examples are;
- A proper hand-off culture: where all screens are red-lined and annotated with all the important design details, forcing the engineers not to ignore them.
- Sign-off culture: where designers had to sign off on work done before it is approved/merged etc. This empowers the designers and makes them ultimately responsible for the outcome of the experience.
- A top-down culture of attention to detail: where the top people in the company are obsessed with the details, and this (naturally) trickles down since no one wants to lose their job, lol.
All these are certainly great to have as a company. But the best experiences I’ve had were the ones where the engineers themselves were enamoured by the design, and so they religiously coded every last detail. Obviously, being able to fall in love with a design as an engineer is a special trait which companies who care about design should hire for, but I digress.
Learning to Code
I could go on about all the noble reasons I learnt to code, but it was mostly to satisfy my curiosity. I had gaps in my knowledge that needed filling. So this time, I took a more systematic approach and started again from the basics (of javascript). I immediately went after the gaps I had identified over the years.
First up for me was fetch. This one was major for me, I just had to know. So I did the easiest-smallest thing. An “app” that did just one thing; making an API request and displaying the response.
I built a random joke generator. It was simple, you hit a button, you get a new joke. I learnt how to work with async processes and altering UI based on the response, a fun little project.
Meanwhile, I decided to brush up on my CSS too. Lots had changed and I enjoyed the thrill of writing pure CSS — a purist, I know. So I decided to focus on that for a bit, making a simple expense management app which received much praise (for some reason). The thing doesn’t even work that well, only looked nice.
Then, a to-do app. Where I learned some new CSS features and old ones that I couldn’t be bothered to learn earlier.
React
Next up, I wanted something more complex. So I started re-learning react. This one was super hard because MANY things had changed in those few years, but the course I took on YouTube was great.
After the course, I built my next app, a food recipe catalogue. This time with more than one API request and even some advanced features — like search, favourites (using localStorage) and some CSS animations. This one was very fun and fulfilling and I could see it all coming together.
Typescript
I had heard a lot about it and wanted to give it a try. I immediately saw the benefits and I now refuse to write javascript unless I HAVE to. My first project with Typescript + React was tumultuous, but I survived. It was another fun project, an art gallery with search and all (and debouncing? marvellous ).
NextJS
It took me a while to settle on which framework to learn but I chose NextJS in the end. After taking the course, I decided to build myself a new portfolio site. This somehow led to me writing this article but deserves an article of its own. With my track record, I hope it doesn’t take me another year to get to it.
This journey has been great. I certainly now have more confidence talking to engineers, designing better web-based apps and managing the entire process.
Next up for me is tackling full-stack apps and I’m in the middle of figuring that out. Already working on my first one but using Convex as my backend. Started learning about Postgres but that is certainly a longer road. I think getting comfortable with how databases work will allow me to learn the backend better — so that's my strategy.
Unsolicited advice, thoughts, and hot-takes
- Designers should learn to code. Not to take an engineer’s job, but just enough so they communicate and design better.
- More teams should have a Design Engineer. Someone whose job it is to be a go-between. To ensure proper alignment and execution between both teams.
- Companies should care more about design, and empower designers in that regard.
Selah
Hi, from the present :)
This article was written much earlier this year (2024) and I now have more hot takes since I started learning Vue, Nuxt & Supabase .
Stay tuned for the next article ;)
