6 reasons why designers should know more about coding
Just a personal opinion
Some time ago I put this topic on the table in the company where I work. I received different types of feedback. On one side there was an approach against designers knowing deeply about code. It was based on the statement that everybody should be specialized in their part of the complex process that means creating a product, and it makes sense. But, on the other side, there were some comments about how it can be healthy to know what the developers do.
Before sharing my thoughts on this topic, let me tell you briefly my personal experience with coding. I started learning some basic HTML and CSS to build my personal portfolio website a long time ago, in early 2010, just after playing with Flash and ActionScript and realizing that the future was not there (thank you for that, Steve Jobs). Years later, I was interested more in mobile programming based on a small app I designed with the help of a developer friend from Nashville. It had some success. I gave it a try to Objective-C, but the syntax was a little above my poor dev skills. Then Swift appeared at the right moment. I decided to learn it and apply it to make a game in the space of 2 months. And I did it (this is the game by the way, it’s free!). Swift was my first experience with a real developing language, it allowed me to know about the MVC model, and also the SpriteKit framework was very interesting to play with, it gave me a really good experience manipulating objects. Later, I’ve been working closer to real and talented developers in my current job for more than one year, and little by little I’ve started to have a curiosity about all the technology behind the products we’ve been making. It looked scary at the beginning, but with the right motivation, everything is possible. I’ve started with RoR (Ruby on Rails), I made some stuff like this small product (which is in its very early stage). Now I’m learning React, and in some near future, I hope to go deeper into React Native.
But I’m not a developer, I’m a designer, and I will continue being a designer…
So, why I’m learning all this stuff? Here are my reasons. Many of them are personal statements, but I hope they can be the beginning of a series of articles focused on sharing more knowledge about programming from a design perspective, because I know how difficult it can be for a designer interested in the topic to find information like that.
1. To know the technology where your design will be built
This reason, the most important in my opinion, is about responsibility. It has been a long time since our profession (yes, this is a profession, folks) was seeing it just as a complementary part of creating a product. Design has become more important since then, and with that, the responsibilities for the designers have increased. Look at it this way:
Every small decision we make in our designs will have an impact in Production, and the final Product.
How are we going to be able to design better products, if we don’t know how they are going to be made? It’s like an architect trying to design a building without knowing about structures. In the case of the architects, it’s part of their discipline, so coding also should be part of ours. My theory is that knowing more about the technology behind, it will make us better designers. Because, yes, part of our work is about thinking outside of the box, which is great, but just take a look at all the nice, spectacular and inspiring shots that you can find in Dribbble. How many of them are doable? How many of them are going to be real products? A lot of our work is about imagining experiences like those, but if we want to make those experience something real, we need to know, at least at a high level, how to make it real. Innovation will not happen if, from the design area, we are not able to design products that can be built in a more effective way… or at least things that can be built!
2. To be a better team player
I’ve tried to share this statement every time I could. It is probably because I have some disagreements with the current Agile approach that is applied in the majority of the tech companies, which in my opinion, creates communication problems. My ideal scenario is a place where everyone can feel as part of a team where each piece is committed to a bigger goal of making a great product, beyond their field of specialization. But that means to understand what does the person you’ve at your side.
The key for a successful team is communication, and there will not be good communication if everybody doesn’t speak the same language and share the same philosophy.
For example, many studied cases had tried to figure out why Apple succeeded in the past, even when their approach was to create huge divisions between their design and engineering areas. Again, not the best approach from my perspective, but besides that, they did something very important; they spread their design philosophy among each member that was involved in the process to create a product. So, even developers knew the expected results in terms of design. That resulted in beautifully designed products end-to-end. Imagine how better would be those products if this design philosophy could also include the concerns and expectations from engineering!
As much as I love Apple products, I have to admit that sometimes they screw it up, overriding design decision over engineering problems. My guess is that a better integration between engineering and design could have created a more integrated team full of Product Makers, more than just designers and engineers working separately. That will make you a better and more valuable team player.
3. To put order in your designer brain
Having experiences with both sides, it’s clear to me that the processes behind design and engineering are very different.
In design, there is a little moment when you have a bunch of requirements and the whiteboard in front of you. In that situation, “chaos” turns into something necessary. That’s how the creative process at that stage is efficient because only through that chaos, great things can appear. It’s natural then, for us as designers, being against any attempt to fit into a very static, planned and structured process.
Engineering has a very different approach. There, the order is the king, because only having an order in your processes you can be able to build a more understandable and effective code. A code that is reusable, flexible and can perform, whatever it needs to perform, using the less amount of resources. That’s the reason why old products led only by engineers had less room to innovate. It’s not the rule, but innovation requires a good amount of creativity assets, which it’s hard to reach in a very structured environment and mindset.
You can think: “Great, the only thing they need to do is to be working together.” But that’s not as simple as it sounds. Because even when our design work’s core is this chaotic phase of creativity, that’s only near to the 10% of all the work we need to do. Because designing a big product, or even a small MVP, we have to be aware of many of the engineering concepts, like the most important one: consistency. And it’s really hard to manage consistent components across your designs if you don’t have that sense of order that engineers have. Or in other terms, you need to be on the same page with them.
Designing a product is a complex process where creativity is important, but it’s just a small part of the whole process.
I realized that coding could help you to start thinking about design not just as a bunch of screens that needed to be made, but also as the process to build and create a more coherent product structure. Working with reusable components and making your designs as something that can fit better into the engineering structure. That’s the reason why we need to put an order into our designer brain and think not just from the user’s POV (Design Thinking), but also considering the engineering POV (a catchy name in progress and patent pending).
4. To be able to create your own experiments and functional prototypes
If you’ve decided to be in this field, it’s probably because your passion for making good products is not recent and you share a similar profile with me. For example, in my case, since I was a child, I had this curiosity to know how things work. I broke a lot of toys just to discover that. So, almost on the same level of interest for creativity, engineering, in some way, was always an important interest too. I love science, and in school, I loved maths and everything that can explain in a logic way, how things work. If you had a similar background, probably that’s the reason why you love being a designer in this tech industry.
At some point of your career, I’m sure you’ve had this frustration of storing tons of ideas for products in your head without being able to do nothing with them because you couldn’t make it real. That’s when learning how to code becomes a valuable asset at a personal level. Because coding will allow you to turn those crazy ideas into something real (or at least will help you to measure how really “crazy” your ideas are).
The simple idea of making your dreams go real can be the beginning of amazing things.
That was my main motivation to learn a little bit more about coding. I’m aware that my code is not the best, that it probably looks like shit if you compare it with the code of professional developers, but it works. Not efficiently as I wish, not in the best way possible, but at least it helps me to test my ideas. If you want to put any of your ideas in some market, this functional prototype is a very important first step you should take, before investing real money or more of your time… or somebody else’s time.
5. To use another part of your brain you didn’t know about
This reason is based on a personal experience. I’ve passed through some health issues because of the accumulated stress. Designing something is awesome, but the activity in that part of your brain can be so intense that designing for long hours through the day can be dangerous (believe me, I have a big scar in my cranium that can second that). When things like that happen, the usual medical prescription is “to rest,” but that can be misunderstood. It doesn’t mean to do nothing; it means that the part of your brain that is stressed should rest, that’s how hobbies or other activities work, they keep your brain busy with other things. Now, what I discovered after my surgery was that the coding activity was my best medicine to reduce the stress from my design work. I need to talk with a psychologist or neurologist to confirm this, of course, but my assumption is that, in order to perform more analytic and logic activities, your brain uses another part of it, and the activity is so intense there that it literally shuts down your “designer” brain part, letting it rest.
Your brain is an amazing tool, don’t be afraid to explore it, but be smart about how to use it.
Why is this important? Because that’s a smart use of your spear time. I’m not suggesting that you should stop other activities that you like to do. But in case you’re looking for something to distract yourself from the daily stress. I highly recommend start to code. If you have the right profile, you are going to love it.
6. To evolve
This reason can seem as a fuzzy concept, but just play along with me for a little bit. I mentioned before the concept of a “Product Maker.” In the past, this profile was recognized as an “inventor” and basically was a person who makes a lot of efforts to create something, from scratch, mastering, or at least having a good knowledge of design and engineering at the same time. The technology evolved in past ages thanks to the efforts of people with that profile. Now, everything is more focused on the processes more than the people, that’s the reason why this profile is rare, and as I said at the beginning, it makes sense. The industry has grown so much that the only idea of one person inventing the next big thing is not possible. All the markets are full of competitive products; you can’t compete there alone.
A Product Maker can be anyone, I don’t see it as a new speciality, rather than a new approach for the industry.
Here comes the assumption: although processes are highly important for productivity, I’m afraid that the tech industry has started to be a slave of those processes. Why am I afraid of that? Because static processes create paradigms about how things are made, and there is not a worser enemy for innovation than that. That’s the reason I have some disagreements about companies with a blind trust for Agile. If that’s the path the industry is following, the future is not as bright as we can imagine, but I still think that designers, engineers, and more brilliant people involved and working with their companies in this industry, can evolve it. If everyone inside the processes can have the best of both worlds; creativity and technical knowledge, it’s possible. In few words: It’s on us!
And there you have, my 6 reasons. Thank you for reading. Stay tuned!
Please, if you’re interested in learning more about coding, let me know in the comments, I’ll be happy to share more detailed knowledge based on my experiences through this publication.
