Skip to Content
2016.5.15

How to Design While Developing

Moving be­yond the idea that the de­signer and the de­vel­oper on a web pro­ject are dif­fer­ent peo­ple, and that some­how those are dif­fer­ent things.

For a long time, web­sites got made with one per­son de­sign­ing how it should look and one per­son de­vel­op­ing the code that made it look that way.

A lot of times, this is still how things get done - one team makes sta­tic Photoshop comps, and hands them off to a team of de­vel­op­ers who know stuff like whether React or Ember or Node or Ruby is the best thing. This can some­times cause fric­tion. The de­signer ex­pects the web­site to look ex­actly like the comp, the de­vel­oper writes a bunch of cus­tom CSS and HTML to fit the de­sign, and who­ever needs to make sure the whole thing is WCAAG com­pli­ant spends weeks hat­ing both of them. When the next comp comes down the line, it all hap­pens again. For a big site, this leads to de­sign drift, and a hugely tan­gled code­base that’s a night­mare to try and un­tan­gle.

This split­ting of sys­tems is an ar­ti­fi­cial one that’s sus­tained by or­ga­ni­za­tional as­sump­tions: we need de­sign­ers, and we need de­vel­op­ers. The thing about Design though - cap­i­tal D de­sign - is that it’s sim­ply a method of de­cid­ing on a struc­ture to ac­com­plish a pur­pose. The de­sign tools and meth­ods one uses to ac­com­plish good de­sign is al­ways in tune with the thing be­ing made. A build­ing does­n’t go from paint­ing to con­struc­tion draw­ings, nor does a car go from mod­el­ing clay to race­track. The clay and the paint are very use­ful steps to start the process of de­sign. They help us to be cre­ative and loose and ex­plore new so­lu­tions to the prob­lems at hand. This ex­ploratory work helps us to un­der­stand how a thing will feel in the world.

These ini­tial draw­ings and sketches get trans­lated into their fi­nal struc­tures, and trans­la­tion is a process that can en­rich both what is be­ing trans­lated to as well as what is be­ing trans­lated from. Every pre­cise mo­ment may not align di­rectly, since dif­fer­ences in con­text can have deep im­pli­ca­tions for mean­ing.

We turn our draw­ings into ob­jects with all the con­sid­er­a­tions of the fi­nal ma­te­ri­al­ity pre­sent. We can’t ig­nore the shape of the en­gine or struc­tural code re­quire­ments, al­though our mod­els and paint­ings cer­tainly can. Design is pro­vi­sional un­til the point at which it ex­ists in the world, and when talk­ing about the web even this is­n’t any sort of end­ing. A web­site is its own sort of thing, with its own struc­ture and re­quire­ments that need to be pre­sent and known through­out the en­tire process of de­sign.

A draw­ing and a web­site will never look the same. This is mostly be­cause a web­site is­n’t sta­tic. Because of this, what a web­site looks like is just a small piece of what a web­site is. A web­site is what it en­ables its users to ac­com­plish, what its de­vel­op­ers have to do to keep it sta­ble and mov­ing for­ward.

The best way to meet our goals as peo­ple who make good web­sites is to fo­cus less on those draw­ings right away. Instead we should think more about sim­plic­ity and el­e­gance than the de­tail ori­ented per­fec­tion of a jpeg.

Don’t get me wrong - the jpeg can be im­por­tant. It shows us how we think we can solve our prob­lems, a glimpse of how we want our web­site to looks and feel, and the tone we want to com­mu­ni­cate. Through all this it needs to have to room to change and breath as it comes to life and be­come a real thing. Our draw­ings should not be on the level of what does this look like” but what prob­lem does this solve and how”. At every step in the process we can work to make the real thing bet­ter, to solve new ques­tions that arise as we move through the process of de­sign / de­vel­op­ment — a process where there is no gap be­tween those two ideas.

To de­sign a web­site is to de­velop it - and as we de­velop a web­site we are con­stantly mak­ing de­sign de­ci­sions. A de­signer can­not ab­di­cate their re­spon­si­bil­ity to de­sign by say­ing well, my jpeg looked great.” A de­vel­oper can­not ab­di­cate their re­spon­si­bil­ity to a code­base by say­ing well that’s what they wanted in the comp.”