An experiment in designing with code

So late last year I decided to undertake an arduous task most designers are always telling themselves “they’ll do tomorrow” – update my portfolio. And not just update but a total, honest to goodness, from the ground up redesign.

After doing a bit of house keeping, defining some of the key personas that my site was going to target, writing some content, outlining what key metrics for success would be and how I could measure them… etc etc… I got to the part where it was time to put pixels to screens and start redesigning the UI. And while I was at it, I figured hey — why not try something new? Over the past couple of months I kept coming across article such as this. And this. Which talk about the idea of “designing in code”. But be it in articles or in discussions with my friends and coworkers, anytime the idea was discussed, it was in a pretty limited scope.

It’s one thing to animate an SVG or build out and “design” simple components in code. To prototype out already existing designs and design the interactions in that medium. It’s another to take an entire design, from initial sketches and ideas to production in nothing but a browser and editor.

“That sounds like a terrible idea!” I can hear you say… And yes, it does. But that’s never stopped me before so why should this time have been any different. Plus silly experiments can sometimes still net useful insights. I figured I’d try something new and hopefully have some fun along the way… or that’s how I justified the decision to myself anyway. The result?

A new portfolio

Ultimately I ended up with something I’m pretty happy with (for now). Would I do it again? Hell no – but I learned a ton along the way. About building type and colour systems that scale and work for both dev and design. About building simple as well as slightly more complex components. A ton about animation and trying to optimize performance. The list goes on but in terms of what I learned in relation to “designing in code” , here are the highlights:

The pros and what worked

Realtime validation of design decisions
It’s one thing seeing an interaction in your head, or sketching out a layout on a whiteboard. Even as we move to more high fidelity in Sketch, what works in an artboard or in your head may not actually work in product, on real devices. Most designers understand this, but sometimes there is just no way of knowing what works and what doesn’t till things move off the canvas.

Working in code and having my design live and evolve in the browser meant I had immediate validation and could test how something looked and “felt” almost instantly. This is invaluable especially when it comes to responsive designs that have to scale gracefully across a number of different devices.

Early on I tried a 3 column layout that worked great on paper but just didn’t translate to the screen the way I wanted it to, once I started building it. Designing straight in code allowed me to catch this and change direction much earlier than a more traditional workflow would’ve allowed.

And since all my work could be viewed in a browser I could at any given moment send someone a link to my local environment and be like “hey can you hit this? What do you think of ____________?” And get feedback on the actual product… not a deck or an InVision prototype. How cool is that?

Working in code works great for fine tuning, and jumping through many rapid small to medium iterations on a design. Less so for big pivots… but more on that later.

Typesetting
This is both one of my favourite and most dreaded things. I’m a total type-geek so the visual designer in me can spend ages dialling in line heights, kerning, finding the right combination of font weights etc… Doing this straight in code let’s you sidestep the frustration of painstakingly setting up your typescale in something like Sketch or Illustrator, only to realize that actually your font of choice renders like ass in IE / Edge at smaller sizes, and that 12px caption should really be 14px, which might throw of your design completely.

Google Fonts and other repositories do an ok job of showing you what a font will look like in browser, and tools like Typecast allow you to take things a step further by plugging your type setup into a few prebuilt layouts, but there is simply no substitute for seeing how a font(s) work in your UI, with your content, and being able to change it all out on the fly.

Consistency and layout
Using tools like SASS made coming up with a basic design system and crafting layouts a breeze. I did my initial explorations around colours in Sketch but once I had a first pass at the values, I assigned them to variables, started using (and tweaking) them as I went and never looked back.

Since all my colours, my spacing and sizing (padding, margins, line heights, even heights and widths of static elements) were driven by a single set of variables and mixins I reused across the site, consistency was baked in by default. And when I decided to tweak one of my greys to better contrast with the new yellow I was using, they were both single line changes in my code that took 2 seconds, rather than minutes or hours.

Sketch addresses this to an extent with things like Text Styles and Symbols you can reuse across your design. And credit where it’s due, nested symbols and overrides are another big step in the right direction, but frankly they’re still no substitute. Symbols and symbol libraries start creaking once you try to build out reusable components of even moderate complexity.

And until my Text Style palette doesn’t look like this if I want to have a comprehensive set of colour options for my typefaces, Sketch (and all other competitors) still got some catching up to do.

The cons and what failed

Up front cost
This can probably be mitigated with a proper seed project / repo you can reuse, but this process is *very* front heavy. My first few sessions were spent with just laying the groundwork. Setting up my stack / looking for and installing the right node modules, troubleshooting, configuring Gulp and setting up my build process, tying in my local server so it works with my watch task in Gulp etc… And that was just the start.

When you’re designing in a piece of software like Illustrator or Sketch, you’re just focused on building your UI. And you take it for granted that everything just works.

When you’re designing in code, and you have to first set up a build process and decide on the technology you’re using etc, it’s almost like you end up having to build the tools themselves before you can even start working. (You can mitigate this by using an existing library or framework but it depends on how much control you want and how familiar you are with the framework). And when you’re building your own tools, it’s not only an extra time sink but things also break more frequently. You might be using a package or plugin with crappy or non existent documentation. I spent a good two evenings just trying to wrangle what initially looked like a promising gallery plugin into submission, because I didn’t want to build my own, before giving up and going a different route.

Any time you might save by working directly in code could (and the first few times probably will) be eaten up by just this alone.

Technical debt
I hinted at this above when I mentioned that it was difficult to make big pivots. Working in code is great in terms of being able to quickly work in small iterations on a design, but the process really fell apart for me when I was a bit further into the project, where I had some architecture going, things I had already built out. But sometimes it was the process of building out those components and designs which spawned new (sometimes pretty different) ideas I wanted to explore.

There were a few times where I either had to refactor a component or view completely, because the markup and css architecture I previously committed to just wouldn’t work. This in turn brought my velocity to a crawl…

As time went on I decided to take some shortcuts (you know where this is going)… Which meant technical debt. Lots and lots of technical debt. I still have zombie code in there that I have to go back and clean up. This is fine for a personal portfolio and site but not so much when you’re working on a team where a) someone else will inherit your code and b) your code has to go to production. I know it still happens but god damn it, I refuse to ship crap other people have to clean up.

A process that doesn’t scale
This is somewhat of a niche problem, but it’s something I think about all the time, with all my processes; how do I scale this in a way that doesn’t just work for me, but for my whole team? Building basic prototypes on your own to demonstrate an idea is one thing. Working, collaborating with and sharing assets across a team of 20+ designers like we do here at IBM is another. I tend to be pretty meticulous with my layer and group organization when building out designs. But even if someone hands me a file that’s not organized at all, I can usually grab the parts I need and keep going in less than a minute. If someone hands me spaghetti code (or even if it’s clean but just something I’m not familiar with) it’ll take me way longer to consume and figure out what’s going on and why it isn’t working when I merge it in with my code.

Now maybe I’m just a shitty dev and you can get around some of the above by having really strong training around best practices and really strict linters, and you get your whole team on the same page — but that’s a lot of overhead for something that requires no thought or effort at all in any design software.

Truth is, outside of doing either basic prototyping with no real need to exchange designs with other designers as your team iterates, I struggle to see how designing only in code (or even for a majority of the process) would scale to a team of any more than 2–3 designers at most.

Next steps

There is still plenty of work to be done on my portfolio. It’s not perfect, but I finally got it to a point where I feel I can release it into the wild. (What’s the old saying? You reach a point where a release is always “80% done”?) The rest are enhancements, like switching over to Vue, and building out other parts such as the blog — Medium gets my writing more exposure but I’d like a greater degree of control over the presentation and details of my work. Plus I also just need to clean up my code.

But this was also a valuable exercise. Designing in code really forces you to think in terms of patterns and systems and you very quickly find out what works and what doesn’t work. What’s too restrictive and what’s too loose.

Working this way sorta lead me to a whole different way of thinking about and treating typography when it comes to building design systems (which I’ll write a whole other post about — it’s the next thing on my list).

I’m also batting around the idea of putting together a basic prototyping starter kit / seed repo. Something that anyone could clone and by running npm install && npm runget:

  • a basic node server up and running
  • gulp setup to watch for all sass, js and html changes and restart/refresh on update
  • Some basic atom level stuff such as variables , includes and mixins for themes, sizing, typescale, timing functions and breakpoints built in
  • all of it strapped to a simple index ready to edit.

Something simple enough for anyone with nothing but a rudimentary knowledge of HTML/CSS to get up and running with, but flexible enough for someone wanting to do something a bit more complex to make use of as well. (If you’d be interested in something like that — gimmie a shout and if there’s interest I’ll put it together! Or alternatively if you’ve found a good example of something that already does this, also gimmie a shout, I’d love to hear about it).

Anyway that’s pretty much it. If you’re a fellow FED or designer and you’ve experimented with designing in code, let’s connect — I’d love to hear about what you’re doing. Thanks for reading!

Like what you read? Give Lehel Babos a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.