Coding as a Designer

7 min readMar 1, 2019

Design inspirations

As a designer, I collect design inspirations from all possible sources —dribbble, behance, pinterest…, favorited lots of contents under under each accounts. There is also a big folder on my hard drive full of inspirations. Collecting and saving inspirations is fun and simple. However, managing and finding them usually are not that much.

Having tried desktop apps like Inboard and Pixave, both have nice features for managing your local images. However, let alone the fact that both of them are not actively upgrading, only being able to browse files on your local storage feels a little.. disconnected — we are in an internet era after all. You want to get new design inspirations and trends everyday, not just looking at the ones you saved weeks ago.

So I thought, how about having a place where you can visit all the great online resources, in the mean time also can connect with your local inspiration library?

That’s why I started to work on References.Design, a tool where you can browse online contents, bookmark them, save them into your local library, as well as import your local images to manage everything in one place.

But hey, product introduction is not the topic today. I’m here to talk about some behind-scene stories about how I coded it as a designer.

Coding vs. Programming

By saying that I “coded” the app, I meant that I wrote a few lines of code for the user interface, to make it look the way I designed it. Plus a few more lines for some dynamic contents. It is not really “programming”, which my friend and partner Tom did most of the tough works.

Does a designer need to code?

There have been lots of discussion about the topic “Should designers code?” I don’t think there is a right answer here. It really depends on your working environment and the career path you plan to go.

Prior to this project, I worked at companies like Autodesk and IBM, where lots of talented programmers are doing the hard job — converting the pixels into code and working products. I never had to touch on any code and thus I had almost zero particle knowledge on how to code.

I knew Tom years back when we both were working on the SketchBook product line. He has always been a reliable partner who delivers results fast and with great quality. However, it simply takes much more time to code a product than just designing it. Being able to code certainly would help us to speed up, that’s why I started to do some basic coding.

me coding like a programmer (image source)

Does it worth the effort?

Certainly it does! Not only it sped up our schedule for implementing the product, by doing hands on coding, it also helped me to understand which parts of the code are difficult and which parts are easier to do. I could quick measure the value vs. cost and do necessary design changes on the go.

We can only build perfections in our dreams, in real life, it’s always about finding the right balance between quality and cost.

The hard part

But, let’s admit it, coding is hard.

As a designer had no idea how a programming project should be organized. I was expecting it would be a single packaged file, like a PSD or .sketch file. While the fact is that, they were just tons of different files, folders and subfolders putting together. I had no idea where to start looking at.

Finding the bridge between design and code

It’s an unknown, deep and dangerous sea in front of me. I couldn’t just jump in without any protection. So I took a step back to look for some designer-friendly tools which could bridge the design and code worlds.

I started with Webflow. I used it to build our home page from scratch. It is such a great tool which focuses you on the design part, while in the mean time you can reach deeper into the basic concepts like padding and margins (as I said, I have zero coding knowledge prior to this), to more complex animations and interactions. I learnt the basic CSS and Javascript concepts by building the home page piece by piece. Then I exported all the source code and started to manually tweak the details.

It was a sample-based learning. I didn’t need to write the code from scratch. I just looked at the well-generated code, made a few changes and see how it worked. Since the whole project was created by myself and I knew exactly what kind of goals I was pursuing, it was much more efficient than watching someone else’s sample or tutorial. I learnt fast during this experiment.

Dive deeper in the sea

Now that I had learnt some basics of “coding”, I feared no more about looking at our project folders and started to read and edit them.

By the way, the tool of my choice for coding is VS Code. It is a free, open-source, and light-weight code editor.

I started to adjust, move and resize some of the in-progress UI elements to make them exactly the same as in my design. I also realized how hard it was to do some small visual changes so that I could switch to an alternative version of design.

I used to spend lots of time building design prototypes with tools like Flinto, Marvel and Framer, but no matter how much efforts you spend on prototyping with these tools, they are not real! It is very common that you would find the original design isn’t working so well in the real product, especially with the real user data.

In our later stages, while Tom was busy building up the infrastructures of the application, I was able to read (part of) his code and did some quick experiments in the real product. This was not possible before because it takes time to move back and forth to find the right solution. You simply don’t want to waste your senior developer’s time to tweak some small visual elements with you — they should have bigger visions.

It took me half a day to tweak the transition details, which you can’t afford with your senior developers

The cons

Everything has two sides. Being able to code certainly helped a lot, but what are the cons for coding as a designer?

Well, you have limited energy, spending time learning code means that you are spending less time designing. Though sometimes they can help each other in surprising ways, still your time is limited. It is already hard to be good at one thing, it’s even harder to be good at everything.

While I was learning hard on how to code, it reminded me a lot of how I spent time learning the 3D modeling tools in my school time and my early career life. The 3D software are typically complicated with an overwhelming user interface. For example in an industrial design software, to be able to generate high-quality, “Class-A” surfaces, you have to learn a lot of modeling technics, which sometimes even requires a lot of mathematic knowledge.

Eventually, when you’ve learnt so much about how to model beautiful, Class-A, manufacturing-ready surfaces, you may find yourself becoming a talented modeler — not necessarily a designer.

Same for our designer/coder topic, at the beginning learning to code may help you become a better designer, but if you cross a certain line, you may find you are going away from the design world, focusing too much on a better tech solution instead of spend the time finding a better design solution.

What is the right balance between design and code?

Let’s move back to the webflow example, I didn’t really need to learn any coding to be able to use it and build the whole site. The auto-generated code was almost there for production. I could easily send that over to a developer for final deployment. There wouldn’t be any surprises from your “design” to the final product.

Now try to recall how many times you cried when you looked at an app screen which was far away from your .sketch file? Why couldn’t this happen to our app design workflow — I send you the .sketch file, with all the interactions and animations already there, and you just hook up with the data in the backend without having to rebuild the user interface all over again?

The idea situation should be that: a designer draws the interfaces, adds all the necessary frontend interactions, connect with some sample contents, and then export all stuff as a package for (backend) developers to connect it to the production environments. In most cases, if you are not build super complex applications, it should be more of just “configurations”, instead of coding.

So I guess, the real question should be asked, is not “should designers code?”, it is not even “Should design tools code?”, but instead, it should be:

When our design tools can deliver production-ready code, so that the front-end could be designed and implemented all in one place?

It is only by that time, then we designers could really focus on the design itself, without worrying too much about how the implementations might be different from the design.