Other questions to ask than ‘should designers code’?

‘Should designers code?’ is a question with  many competing takes. I will not provide another answer here. Instead I’ll offer an alternative route for consideration—questions that favor descriptions of what is over prescriptions and value judgements. Hopefully they’ll bare someone more nuanced fruit…

  • If we take “code” as a transitive verb, the question becomes “Should designers code [thing]?” What then is the thing? Are there different categories of coded things in question here? (The reader may be familiar with the concept of high and low level prototypes, but a low level prototype of a multi-player game does not present the same problems as a low level prototype of a resteraunt landing page.)
  • How much coding (and of what sort) does a designer have to do (whether yearly, monthly or daily) in order to be a ‘designer that codes’?
  • Are there criteria for excellence with respect to the things coded? Can these be used to establish minimum and expert level coding aptitude? 
  • What are the distinctions betweens novice, intermediate and advanced levels of capability with respect to the above? What does it take to develop these skills at these levels?
  • Do designerly programming skills break down into different domains?
  • What has been produced by people with some or all of these skills?
  • What kinds of (design) problems have been solved (or investigated) through programming?  
  • What are problems that designers have tackled through programing that they wish they didn’t?
  • What problems did designers not tackle through programming that they wish they did?
  • Are there specific programming skills that can be abstracted to more traditional design areas? What about reverse?
  • What are some best in category ‘interaction/interactive designs’?
  • Who made them?
  • What were the skills of the people on that team?
  • What were their responsibilities?
  • Are there any ‘good’ ‘interaction/interactive designers’ who can program? How ‘well’ do they program exactly?
  • How do they use their skills (if at all)?
  • What are their overall methods like?
  • What kinds of projects do they work on?
  • What kinds of problems do they solve?
  • What kinds of teams do they work with?
  • What are their day to day responsibilities?
  • Are there good ‘interaction/interactive’ designers who do not program?
  • How do their methods, responsibilities, activities, problems and projects compare to those that do?
  • What other (sub) skills “should” a designer have (or not have)?
  • What investment is necessary to develop what aspect of these skills to what degree? What resources are available? How does this compare to other skills designers develop?
  • For the designer asking if they should [learn to] code: do you like to code? 

Finally, If you absolutely need an answer, you could do worse than weighing Alan Cooper’s negative argument from “Should Designers Code?” (2017) against the affirmative point of view from John Maeda’s “Design in Tech” reports (2017, 2018).



2 Replies to “Other questions to ask than ‘should designers code’?”

  1. To state the obvious, the list could be doubled by distinguishing the verbs ‘code’ and ‘program’, i.e. working with symbolic notation vs crafting instructions and processes.

  2. To tie this post to the central point of this blog—assuming that a designer can have a ‘feel for’ or ‘sense for’ interactive-aesthetics and that this is a kind of tacit knowledge and that this knowledge is built, in part, through the experience of iteratively crafting interactive artifacts, we are left with a question about how a designer might ‘best’ build this background experience. It is probably the case that programming artifacts (in some sense) is the path with the most opportunities but with the highest investment cost; however it is hardly the -only- way. In order to make our way though the thicket, it behooves us to be more specific about the actual designerly needs and what can be ‘achieved’ through programming, at some level, and of some kind.

Leave a Reply

Your email address will not be published. Required fields are marked *