He got me interested with his approach to design and (luckily) we got along well enough to decide to share an office, since we both did not feel good working from home.
I clearly remember my surprise when, during my first days at the new office, I discovered that Patryk spends almost 8 hours on design… Writing a code in Framer.
My knowledge of programing at that time allowed me to edit the code of simple websites written in HTML and CSS. Writing websites from scratch was a challenge for me, so try to imagine my face when I saw the guy (designer, what’s worth to mention) designing a prototype in Coffee Script.
My approach to design at that time was as standard as the toolset I used. Adobe CC + Sketch for design, InVision for prototypes and Principle for animations. That was it.
What is worth highlighting… In my brain, designing was completely separated from programming. Of course, I knew the differences between front-end and back-end, I know what Bootstrap is and what the programmer’s work looks like and, what’s more important — how to design without making programmer’s work more difficult. However, it would never have come to my mind that I could benefit from programming knowledge being a designer.
For 8 months, I had daily contact with a designer who was programming every day. It helped me to learn programming a little better, but most of all it changed two very important things: my approach to programming and my thoughts about what design is, even if by that time I was thinking that I already had that figured out.
First of all… I have improved my design process. Not only I started using Framer on my daily basis to create prototypes, but also I developed more pragmatic approach. I’ve started understand that the design process is something way much more than just pixels.
And I’m not talking about testing in a way where we just turn on a preview on a device. Framer grants me access to all technologies inside the device. Thanks to that I can for example, gain access to the microphone in the smartphone and test my solutions when designing a voice controlled app. The possibilities are almost unlimited. More about that can be found on Framer’s blog.
I believe that expanding the knowledge on programming influences our thinking about design and, as a result, we notice problems we wouldn’t be aware of otherwise. What’s important — it does not influence only the way we see the problem but also our awareness of possible solutions.
Together with our limited horizon the probability that our product will encounter many problems along the way is increasing and later we can see serious consequences which could influence how the target audience would receive our product.
Good design is not limited to GUI, aesthetics or completion of business goals. We all call ourselves Product Designers or User Experience Designers but have those roles not lost some dimensions when they were popularized?
Limited knowledge on programming causes us to reluctantly approach solving problems connected to purely technical side of building a product. We, designers, think that those are problems for programmers. And that is one of our biggest mistakes. Different teams working together on building product can bring amazing results. And it does not apply only to designer-programmer cooperation.
Designing is the ability to select means for goals and solving project problems connected with something more than just GUI.
One of the most important skills I developed last year is project building. Before I dive into programming, I thought about project building only in the context of my own tasks as a designer. I did not consider whether the app will be written in Swift or in React, or whether the website will be written quickly and with the least amount of work, so it might be designed and developed with Bootstrap. Those and many other problems were for me the problems of programmers but the truth is that its also my task too, as a designer.
We all probably know the most popular quote among designers, but do we really understand its value? The quote that we, designers, should remember and hold dear is completely different.
The eternal, forbidden question is: Should the designers code? But the truth is that its should be formulated differently: Should the designers be programmers?
And the answer is: No.
Your task as a designer is solving problems. Looking at the problems from a programmer’s point of view will allow you to see problems connected with product building from a wider perspective. Your work will become more effective and as a result… You will become a better designer and a great team player. Your teammates will quickly see that you are a person they can talk to about many aspects of product building and as a result they will not be afraid to ask for your advice and that will lead to sharing experience with each other which is mutually beneficial.
Just because you will start learning programming does not mean that you will be expected to code your designs by yourself or that when the programmer takes a day off you will be expected to replace them. Programming, to you as a designer, should be a way to broaden horizons and gain experience that will make you even better. As much and as little as that.
To answer the question: Yes, we do need more product designers. However, we need those who design with many aspects and level of project building in mind. Design does not end with the user.