When will design become social?

With the rise of Git & GitHub, we’re living in a golden age for programming “together”. How long must we wait for the same thing in design?

Alasdair Monk
Dec 11, 2014 · 3 min read

I consider myself a bit of a dabbler when it comes to development. I love hacking around with stuff with no real goal or purpose. It’s mentally challenging in a different way to design and I find the reward of writing some nice code, or building something, more of an instant rush than the ever-iterating, “it can always be better” approach that doing design as a day job instills in you.

Working daily with both design and development projects for the last few years, it seems odd that the thought only just struck me yesterday: “why is designing for the web still so painful”. Sure, we have better tools now than we once did. We have new toys like Sketch & Framer, which are many times more elegant and appropriate than creating mockups in a programme built for photo manipulation but let’s compare this with the sea change of productivity that front end development has seen in the last few years.

Off the top of my head: we’ve seen the rise of version control (Git), a wealth of frameworks (Angular, Ember, Backbone, Meteor), core services (Amazon S3, Heroku), new processes for building (Grunt, Gulp) and even entirely new stacks (Node). Frontend development is barely recognisable from the ugly old days of editing text files off a server directly using FTP. It has grown up and, most importantly, it has become social.

Everyone and anyone can easily work on a single project together. The Git-powered programming economy has arrived and there’s no going back now.

Design, on the other hand, is still done in a silo. It is unsocial. I’m talking about design production here, not the wireframing, sketching, and planning that happens with pen and paper. In a typical design team the process for creating some ideas for an app, for example, goes something a bit like this:

  • A designer (let’s call him Jim) begins work on a project: “Dashboard.sketch” — nice work Jim
  • Jim designs away, iterating upon his own ideas towards a solution
  • Jim’s colleague, Tim, will chatter about some ideas **he’s** been having for the Dashboard. Jim asks Tim to flesh them out
  • Tim will duplicate Jim’s current file and call it something like “Dashboard-Tim.sketch”

At this juncture, I can interrupt this gripping narrative because from here onwards it’s all gone to shit. At this point of divergence, the work becomes harder to do, share and discuss because it’s in two different places. What’s more is, the more designers you have, the more this problem is amplified.

This introduces various problems. How will we decide on standards between the two documents? What if Jim likes Tim’s buttons and wants to ‘merge’ them into his document? What if Tim replaces the lorem-ipsum content with real copy? This is solved by Git elegantly and simply, but despite the efforts of some (Layervault et al) there exists nothing as powerful for designers.

It’s a complex problem but it doesn’t seem beyond the wildest dreams of Avarice. What’s more, surely there most be dozens of people working on this problem intently as I write this.

How much longer do we have to wait for design to become social?

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store