If you’re anything like me, at some point in your design career you have asked yourself ‘should I learn to code?’. There have been endless debates, articles and posts on this subject. The question doesn’t come from a desire to become a developer, or a belief that we would be particularly good at it. It comes from an insecurity that we do not understand how our designs are built. Leading us to believe that there is something missing in our skill set. Like an architect who doesn’t know how their buildings are built, or an industrial designer who doesn’t understand manufacturing.
I have attempted to learn to code on and off for many years now, using online courses from the likes of Udemy and Codecademy. I even had a weekly coding dinner with one of my best friends in London, uncreatively named Swift Tuesdays. But that was mainly an excuse to meet up, cook each other dinner and get mad at why our code kept failing (during the Swift 1.0 days). On the plus side, I did successfully build Biggie vs 2pac Naughts and Crosses.
The motivation to conduct this learning exercise came from a personal goal, rather than a work or project need, and that was almost the problem. I have always been fortunate enough to work closely with an abundance of talented developers. Which has allowed me to always focus my efforts on design tasks, not requiring me to write a line of code during my 9–5.
Whenever I learnt to code, I mainly did so using the material in the courses. Using the projects and examples it set out. The issue with learning in that way was that it took the creativity and problem solving out of the task. I was solving hypothetical problems and I knew the answers were waiting for me on the next ‘click’.
I knew that learning through online courses and returning to a role where I wouldn’t be coding would not yield the right results. As for why I wouldn’t just begin to code at work, it is simply due to the pace at which we work and the way our team delivers products & projects. Plus, I’m sure no-one wants to pay for me to code at this point! My efforts so far, half-arsed as they were, were futile.
Coding for real
I recently kicked off a side project with two friends, and like any good side project, we needed a website. Even though I was the designer of our team and we already had a fantastic developer, I saw this as a great opportunity to reignite my coding efforts. I wanted to design and code the entire website from scratch (no Bootstrap or SquareSpace allowed). This way I could attempt, learn and fail with no real client or restrictions, except the one we set ourselves. Plus, our developer was happy to let me run with this task anyway. Worst case scenario, he comes to the rescue!
From there it was not all smooth sailing. One evening I spent two hours trying to figure out why my hover states and jQuery scroll were not working. After exhausting every possible Stack Overflow post on the subject, I realised that I had an invisible ‘div’ covering the elements. That rush of emotion, a mixture of extreme relief and frustration, was something I hadn’t since university. I suddenly had a lot more empathy for developers! On the other hand, I received immense satisfaction when I solved a problem and built what I had envisioned. It almost made me want to become a developer! (Almost…)
Real projects = real outcomes
So my advice to you is, before learning to code, have an idea or project in mind. Something you wish to build with the new skills you gain. Then learn to code by actually building it, using the courses, books & websites as guidance along the way.
There are three main reasons for why I’m such a huge advocate for learning by tackling real projects:
- There are no quick & easy answers for the tasks. You are required to research, apply and understand before you can reach the solution you desire. This increases your chances of learning and remembering how to solve the problem.
- You will be motivated by the project and its outcome. A hypothetical project is just that, hypothetical. When you’re tackling a real problem, you will actually care about the outcome and have something real to show for it at the end.
- As you are the designer of what you are building, you will take greater pride in how it looks and works. Realising what you can achieve in code should leave your inquisitive mind pushing to learn more. You will likely find yourself improving your designs directly in code.
I‘m not a developer, so why learn to code?
We have covered the ‘how’ to learn, but we should probably touch on the ‘why’. Many designers out there have shared the virtues of learning to code. For me the greatest benefits are:
- Gaining a better understanding of the rules of a particular platform. Such as, what are the native elements you can build? How does the UI react across different form factors? What may be particularly difficult to implement? This is especially important for mobile. Documentation, such as the iOS Human Interface Guidelines, are fantastic resources to learn about a platform. But actually using Xcode and learning a little Swift will give you a deeper level of understanding. As well as allowing you to communicate better with your developers.
- It prevents designers from creating something that is novel just for the sake of being novel. Is that custom interaction you designed actually more useful & usable for the user? Or is there a better way to design it natively? Note — this should not be used to stifle creativity. It is to provide guidance so that we focus the efforts for novel interactions to where it adds value.
- When designing an MVP solution for your product, you will have a greater understanding of what is quicker & easier to build. The faster you can get your product out of the door, the faster you can get feedback, iterate and improve.
‘Any additional features or work beyond what was required to start learning is waste’ — Eric Reis, Lean Startup
Now I’m not saying every designer should be a developer. If anything, I think most of us shouldn’t code, at least not production code. But I do believe learning to code will make you a better teammate and a better designer of digital products. Additionally, we should not let our high level knowledge of coding languages limit our creativity. We should still look to our developer teammates to understand the technical implications of our designs.
I do cringe a little when I write about learning to code. As I know I have only scratched the surface of the immense skill and dedication it takes to truly ‘learn to code’. That could also be a bit of the old imposter syndrome talking. Yet there is a huge empowering feeling you get from understanding how these products are built. You are able to take an idea from concept to design to development, finishing with a real working product at the end. That’s the joy of making, which is likely what drove us to start designing in the first place.