Designer or Developer?

Shane Edwards's picture
1, Oct, 2014 by Shane Edwards

Designer or Developer?

0 comment
Designer or developer

To a lot of people in my line of work being web design and web development they regard each as two very distinct disciplines. This is primarily due to the nature of each requiring very different mind sets.

Design requires a person to creatively look for a solution, which in turn implies the use of abstract lateral thinking given an unknown amount of parameters over scientific "vertical" thinking that requires pre-determined set of parameters.

Design problems are often solved by thinking around different problems and thus lack a pragmatic approach favouring idea generation.

Whilst web development certainly has room for creative approaches (there is certainly more than one way to program any feature requirement), a more structured pragmatic approach drawn from convention such as iterative testing and usage of design patterns is preferred. This is drawn from a very real fear of potential complexities creative approaches could introduce. Scientific "vertical" thinking such as a person concerning themselves with all the details of understanding a fixed set of parameters of a given problem makes developers feel empowered with greater confidence in making changes.

David Heinemeier Hansson & Kent Beck hang out

I recently watched a Google+ hangout discussion between David Heinemeier Hansson (creator of Ruby on Rails) and Kent Beck (Creator of Test Driven Development), who recently debated a similar topic about TDD. It was interesting to see that David moved more towards a creative line of thought and questioned how useful TDD actually is. The gist was basically that over-testing can introduce too much intermediary code and consequent complexity. Kent’s train of thought is much more scientific, his approach (Test Driven Development) marks successful application design through testing/knowing as many parameters of the system as possible in order to confidently make changes.

Given the nature of my work I regularly get asked which I lean more towards and which I’m better at. For me this is a tough question because 1. That would assume I could make a judgement to compare the totality of my knowledge against everything I haven’t learnt yet. 2. It also implies that you can compare progress in an idea based subjective discipline, which in my opinion is unmeasurable without limits with a knowledge driven discipline of a more structured finite value.

I enjoyed David and Kent’s debate because the argument resembles an internal battle I have with myself on a day to day basis when making choices in both disciplines. Don’t get me wrong, I prefer to create design and code separately and isolate changes to each as much as possible, primarily for my own sanity and to the benefit of colleagues working on the same code base. But I regularly see benefits to port bits of methodology from each discipline over to the other. Such as making design decisions while coding and coding decisions whilst designing.

What are the benefits?

This blurs the boundaries between worlds and I find it quite efficient. It saves me time and empowers me to make better decisions because I’m less likely to make a mistake in one phase that would affect the other. At the other end of the scale, it opens hidden doors employing a greater focus on customer needs and user interaction. Couple of examples;

If I was given a Photoshop mock from a designer and asked to produce a component for an existing application from the file supplied, I would hope to find that everything is layered clearly with an easy to navigate folder structure that semantically makes sense. I would also expect things like repeating textures to easily tessellate when cut to code, steps I take to make life a lot easier.

Equally important, if work is driven and passed from server-side development and design is considered after a control is implemented, I would expect consideration for the right amount of flexibility that would allow me to plug-in the design with functionality for optimal user experience. I review the code and interpret what’s missing from either end.

And imagine (humour me);

  • Version controlled design mocks.
  • Creating design straight in the browser with version control – collaborative design merging.
  • Design mocking as part of regular Sprints (Why shouldn’t your designer be part of your Agile team?).
  • Experimental unconventional development (Break the rules).
  • Programming solely for the pleasure of great user experience (Gamification is a good example).
  • Automated test driven design using something similar to Protractor that self-learns popular design methods and automatically augments A/B testing and usability design solutions.