There’s a debate raging in the design world on whether or not it’s a good idea for designers to learn how to code. Some argue that it’s wasted effort, a distraction that keeps designers from truly honing their craft. Others say that it’s beneficial to know some front-end development in order to have knowledgeable conversations with development teams when it comes time to implement their designs. Valid argument on both sides…
Well, in my infinite wisdom, I ignored both arguments and learned development from front to back.
To be clear, I didn’t learn enough where I can compare myself with a professional full-stack developer. I learned just enough in order to be able to build a couple of apps I had in mind.
But why, you ask? The simple answer is that I thought it would be fun.
If you’ve ever written a line of code in your life, you understand the exhilaration of making a computer do exactly what you want. There’s a rush of dopamine every time you identify a problem in the code and find a solution. I wanted to take it to the next level and create a complete application, a usable product that I first imagined and then built with my own hands.
It wasn’t easy. I spent nights and weekends watching tutorials and Googling error codes. It took me a year to create two applications, either of which a full-time developer could have made in weeks. Now that they’re done, only a handful of people are even using them. Do I regret making them?
Absolutely not. I learned an incredible amount building them, most of which apply to my job as a product designer. I want to summarize the major lessons for you here in this post.
Through experience as a product designer, I learned which features are technically feasible and which features are not. But when I built applications for myself, I learned exactly how difficult those features are to implement. You’d be surprised how some seemingly complex features can be built quite easily and vice versa.
There’s a lot about coding that people have misconceptions about
For example, I learned there’s a lot going on in the background when you press that “I forgot my password” button. First, an email has to be sent containing a link to a secure URL. To make it secure, you have to generate a unique token that’s encrypted with things like a secret phrase, the user’s email address, and some kind of expiration. To store the new password, it has to be hashed using a special function so that if the database is hacked, passwords are still protected. This took me hours and hours of work and debugging.
And then it took me only a few minutes to deploy my whole app because of an awesome service called Heroku…
Knowing these things now informs my decisions when I’m designing something professionally. I know exactly where I can save my developers from headache and where else I can push them for polish. I also take them much more seriously when they ask if I can alter my designs due to some technical hurdle. This makes the relationship between design and development infinitely better, which is nice in a small office like the one I work at.
When you learn how to develop an app, you’ll understand how the world works and be able to dodge bullets like Neo. Ok, that was a lie (and also a pretty outdated reference). But you will learn how information is transferred and stored across the Internet, which is basically just as good.
When I was just designing interfaces, I had a general idea of how applications worked. I knew there is a front-end, which is what the user interacts with, and then a back-end that occasionally pushes information to the front-end to make it dynamic. What I didn’t know was all of the intricacies necessary to make that flow happen.
There are databases, cloud storage services, content delivery networks, third-party APIs, communication protocols, domains and more. This is the stuff that the World Wide Web is built off of, the whole foundation of our modern culture.
Development gives you a more holistic view of application structure
To the average person, that stuff probably sounds like a bunch of technical jargon that would be useless for a designer to know. I say nay! Having a holistic knowledge of how applications send and receive information can affect fundamental design decisions in the planning phase. If I’m designing an account setup screen that requires the user to enter their location, I know I can integrate Google’s map API to predict what the user is typing. If I’m designing a mobile app where users need to be able to invite their friends to download the app, I know we can use Twilio to send invitations via text message.
Having this perspective has also helped when presenting work to clients. After I’ve shown my designs and walked through a prototype, clients will often have some pretty technical questions on how everything will work. There are no developers in the room when this happens and I don’t expect the sales rep to know. When I’m able to look a customer in the eye and tell them exactly how we plan to solve their users’ problems, you can bet it gives them a big confidence boost in our abilities as a company.
This is one that’s more about product in general than it is about design and it was by far the hardest lesson to learn of the bunch.
While I was building my apps, I became so close to them; I thought the sheer fact that I made them as a non-developer made them amazing. When I showed them to friends and family, they gave a polite “That’s great!”
But in the real world, no one cares.
Every idea for a product or service likely has 3 or 4 competitors doing something similar. If there’s already an established player in the market you’re going after, you have to be ten times better in order to convince people to switch. If your product is truly original, there’s a good chance there’s not a great market for it and you will have to convince a bunch of people to give your offering a shot.
These are valuable lessons to learn. Many entrepreneurs spend tens of thousands of dollars on failing apps to learn exactly what I did. The Internet is a wonderfully flat ecosystem where there are no gatekeepers and every website is equally clickable. However, that also makes it that much more difficult to stand out from the crowd with your product. It’s one thing to read this stuff in a book or blog post, but another to actually live it; developing and marketing my own apps gave me that opportunity.
There are a bunch of other things I learned from my time spent developing, these are just the highlights. In case you’re wondering if I actually developed two apps or am just full of crap, I linked them below. My first project was a mobile app where users can upload photos of street art, pinning them to a community map for others to find and enjoy.
StreetView - Street Art Mapped - Android Apps on Google Play_Upload your favorite street art on a community map for everyone to find!_play.google.com
My second project was a web app similar to Dribbble, but with a focus on getting critical feedback on early-stage designs.
Clemango - Critical Design Feedback_Share your work or give your feedback in a community trying to improve designs, not show off._www.clemango.com
If you have any thoughts on whether or not designers should learn to code, I’d love to read them in the responses. My advice is to just make some stuff, whether it’s through design, development, poetry, whatever. When you learn something valuable, I hope you share it with the world.