The One Reason Being a Designer Helps You Code.

Musings on rapid prototyping from a product designer into front-end development.

I love to code!

I don’t call myself a developer, but I know enough to get by building models of my designs. I first trained as an architect, so I’ve always believed in the importance of understanding the construction of what you design.

Some of my favorite moments on the job as a Product Designer were the hack days. Ideate, design & prototype in under 8 hours. It wasn’t about being perfect, but about getting something done.

Proving it’s possible, in a tiny amount of time.

When I say prototype, I don’t mean in the sense of a clickable

InVision link, but one of living, breathing code. I’ve always felt limited by software designed to imitate the browser. I prefer to create experiences you can throw out into the world and watch them function. Like the time I built a harmonica.

I’m lucky that I’ve worked in teams that expected

designers to code. A lot. Of course, we were still surrounded by developers who did all the hard work. Our job as designers was to make sure everything looked and felt right.

When a web product was built and needed a review, instead of opening up the browser’s inspect panel…writing lists of changes for developers to implement… explaining the problems… waiting for them to implement… before going through and checking everything again…we just got stuck in!

Cloned the repo, made the edits, pushed the code and, voila!

Design oversight complete.

No mess.

No fuss.

There was never a need to read “best practice for designer-developer relationships” articles. We loved working together. In fact, when I first saw these articles, It shocked me that someone even felt a need to write them. Clearly I’d been fortunate to land in such a great working environment for what was my first UX/UI design role.

I digress.

What I mean to say is that, despite all this,What I mean to say is that, despite all this, It never even occurred to me that someone would consider my development work to be fast. It’s not my job. I spend most of my time running workshops & interviews, planning product strategies, sketching designs and designing in Sketch. Not coding.

So when I got to jump into the code for my latest project (a UX + UI overhaul of a data visualization software for a local Vancouver startup), I was genuinely shocked to hear the main developer say to me after a day of coding:

Wow! You’re so quick!

It’s wonderful to hear positive feedback, particularly when you’re not expecting it.However, I’m not one for basking in compliments. Instead my mind immediately snapped to that common designer question of ‘why?’

Why would I be fast?

How might my process be more efficient than others?

As we discussed ideas around coding as a designer it sparked a thought. It’s not that my knowledge of SASS or HTML is better. It’s not my speed at getting the code on the page. I don’t have better software or a more powerful computer, and I don’t have any other technical wizardry helping me along.

Only one thing differentiates me from anyone else building my designs — I instinctively know what I’m building, because It’s my vision.

I’m not laboriously imitating somebody else’s idea from an image. The vision is in my head the whole time. Of course I still need to reference the designs, to ensure I’m on the right track — after all, recognition is better than recall. The designs themselves are a representation of the ideal version that I hold in my head anyway.

As I tap away at my keys, shapes forming in-front of my eyes, I can edit, adjust, tweak as I see fit. There’s less constant switching back and forth between designs and the code. Less repetitive checks of sizing, spacing and positioning. I express the vision in my head with occasional checkpoints that I’m on the right path.

There’s no substitute for designing with the real medium. Sometimes, what felt right on the artboard feels wrong in the browser. When it does, I adjust. No questions asked. No approval needed.

I save time on mocking up multiple states of objects and recreating animations in numerous different software. It’s all available right there in the browser to test as I build.

The web is awash with articles on whether designers should code or not. I’m not going to weigh in on that debate here. You’re the master of your own destiny–go do what you love and see where that takes you.

For me, it works.

For me, it’s just the next step in the design process.