Back to all posts

The real issue with the ‘Should Designers Code’ question

Should Designers Code?

No, Part One.

There’s a recurring debate in our industry over whether or not designers should write code. Some developer will pose the question on Twitter, then pundits, practitioners, and gurus answer it. Everyone has an opinion, tempers flare, then people agree to disagree, and the discussion subsides. But a few weeks later someone else poses the same question and social media blossoms with yet another instant replay of the futile, never-ceasing argument.

The debate follows a characteristic pattern: people discussing a question of personal taste as though it were a universal truth. It’s like someone asserting that because they don’t personally like avocados, avocados are a terrible food and others should shun them as well. The issue — obviously — is not in the avocado but in the individual, but emotions conceal the obvious.

I see two reasons why we can’t just ignore this meaningless debate. Firstly, it’s important because young people — ill-equipped to properly assess the question — are liable to waste a lot of effort and opportunity on it. Secondly, the very fact that it recurs, always disguised as a broad and serious question, convinces me that its persistence hides some deeper issues, some lurking motivations.

I consider myself uniquely qualified to comment on the question. Before I developed the practice of interaction design, I built a successful career writing some of the most innovative software for personal computers in the 1970s and 80s. Despite my qualifications, my own tweet storms are inadequate for this challenge. There are too many issues and too much nuance for brief expostulations. Thus, my thoughts on this topic are here.

There are several arguments to make against the premise that designers should code, but I only see one argument for it. The problem that none of the arguments addresses is that the entire question isn’t really relevant. It’s a symptom of other issues in drag. The main effect is to hide the one meaningful, important issue of how practitioners should work together. I’ll talk about that one later.

The primary arguments against designers coding are as follows:

  1. You can know without doing. There are many examples of coaches, choreographers, trainers, and executives who direct the work of practitioners without ever actually doing it themselves.
  2. Performing a task does not automatically teach you the implications of that performing it. Just because you code, it doesn’t mean that you automatically understand the effects of your code on others, or on the organization.
  3. There is a tremendous breadth of skills, tasks, and job roles in the software development world and making assertions in the simplistic duality of “designers” or “developers” fails to recognize the complexity and nuance of these roles.
  4. Why are we even asking this question? It always seems to be posed by the practitioners with the least empathy for others, asking for empathy from the far more empathetic group, while ignoring the truly important challenge of empathizing with the user.

The one argument to make that favors designers coding is really just a broad generalization that doing someone else’s job for awhile is a good way to gain an understanding of the challenges that person faces. So, yes, it is generally a good thing for designers to spend some time coding. Of course, by this same argument, coders should spend some time designing. And by designing, I don’t mean designing screens. I mean interviewing users and then making sense of what they learn.

However, I emphatically don’t believe that production coders should do production design. That would be equivalent to asking the programmer to do the bookkeeping. Sure, they are probably capable of it, but why? What a waste of good programmer talent on common bookkeeping. Good programmers and good designers are rare. It is foolish and wasteful to make them work outside of their particular special skill.

The real issue.

The truly serious fault with all of these arguments is that they avoid the single most important question: how do we create software?

A lot of software gets built every day in the world, but that doesn’t mean that we actually know what we are doing. Stuff does get built, and human nature being what it is, we regard that as normal. But infamously, in the waterfall world of enterprise development, some 80% of all software projects fail. We have been building crappy software systems for decades, and we still can’t seem to figure out how to do it effectively. Typical projects never get out the door. Those that do get deployed are often pathetically weak versions that lack power and flexibility.

Agilistas gloat over the failure of conventional software development methods, but their more modern methods of creating software aren’t significantly better. Mostly the failures are smaller, faster, and easier to hide. I don’t want to get into an argument on this point, because I think that agile is a wonderful and tremendous leap forward in the world of practical software development. But it sure hasn’t lived up to its billing. It confounds management. It is notoriously difficult to perform at scale. It often sidelines real user-centered design. It is reactive rather than proactive. And worst of all, many of its practitioners utilize managerial and technical hand-waving, smoke-blowing, bogus claims, and prestidigitation as a fig leaf to conceal ignorance, incompetence, and a refusal to work well with other necessary disciplines, most notably, interaction design (Yes, this is a blast at agile, but — for the sake of perspective — I believe that agile is better than all the other development methods we have).

Worse yet, is that teams are constantly bickering over turf, blaming the various disciplines for their inability to meet deadlines. There are people who claim that “software deadlines” is an oxymoron, and establishing them is prima facie evidence of a lack of understanding of the medium. Frankly, I’m one of those people. Just about every single coding effort is a sally into the unknown, and it usually takes a couple of trips through to learn the territory. Prediction is impossible. I’m fond of comparing software development to walking through a minefield: if you don’t step on a mine, it’s quick and easy. Anybody who gives you a prediction of how long software development will take is dissembling. And if you ask someone for that prediction, you are encouraging prevarication, and you are sustaining the industry wide myth that developing software is predictable.

This article was originally posted at:

Can we take you from stuck to unstuck?

We'd love to hear from you

Product Design

The ‘Product’ is the website, service, application, interactive thing being worked on by the business. The practice of Product Design is similar in a lot of ways to UX Design. It involves the coming together of many specific design disciplines...

Call to action (CTA)

A call to action is a marketing term that refers to a prompt that invokes a response leading to a sale. When referring to a call to action (CTA) in the digital design world we usually mean the interactive element that leads to the next step in the experience - something that needs to be clicked or tapped.

User testing

User testing refers to a technique used in the design process to evaluate a product, feature or prototype with real users. There are several reasons why you might want to undergo usability testing, the most common is that it allows the design team to identify friction in a user experience they are designing, so that it can be addressed before being built or deployed.


WYSIWYG (pronounced WIZ-ee-wig) is an acronym for "What You See Is What You Get". It helps identify an an interface that allows user input resulting in an output that is rendered in a similar way. For example; a word processor application interface might resemble a piece of paper,so when printed the user can see how the output will appear.

Content Management System

A content management system (CMS) is an tool that allows a website editor/administrator to manage the content that is displayed. Websites are made of HTML and CSS to create pages. Pages can be hard-coded but would require technical development skills to make changes. A CMS usually allows a person without coding knowledge to amend existing and add new content to a website using a WYSIWYG interface.

Responsive Web Design

Responsive web design refers to a web page that dynamically adapts its layout to fit the size and orientation of the device on which it is viewed. A responsive design allows for a more optimised user experience across desktop and laptop computers as well as smartphones and tablets of varying sizes.

User Stories

User stories allow the functionality of a product or service to be expressed as written descriptions of an experience as seen from the users perspective. The writing of user stories creates a list of design and development tasks to complete in order to create any required functionality.

User Interface

A user interface (UI) is a conduit between human and computer interaction - the space where a user will interact with a computer or machine to complete tasks. The purpose of a UI is to enable a user to effectively control a computer or machine they are interacting with, and for feedback to be received in order to communicate effective completion of tasks.


A persona in UX Design is the characterisation of a user who represents a segment of your target audience. On a project you might create any number of personas to be representative of a range of user needs and desires. The solutions you design must answer these needs in order to deliver value to your target audience.

Card sorting

A great, reliable, inexpensive method for discovering patterns in how users would expect to find content or functionality. Card sorting is used to test the taxonomy of data with a group of subjects, usually to help inform the creation of the information architecture, user flow, or menu structure on a project.


A technique used to generate ideas around a specific topic. Often done in groups, but can be done individuals. The process usually involves writing down all ideas around a topic onto paper, a whiteboard or stickies often implying some kind of association.

Minimum Viable Product

An MVP is a product that has the minimum set of features to prove the most essential hypothesis for a product. Businesses building a new product can create a Minimum Viable Product to prove that an idea is viable and warrants further investment. A further benefit being that the next stage of development can be informed by feedback obtained from testing that MVP.


A sitemap is a diagrammatic representation of a hierarchical system. It usually depicts the parent-sibling relationship between pages in a website, showing how sub pages might be arranged underneath their parent groupings. This arrangement forms a map of the site.

User journey

A user journey represents a sequence of events or experiences a user might encounter while using a product or service. A user journey can be mapped or designed to show the steps and choices presented as interactions, and the resulting actions.


A prototype is draft representation built to test ideas for layout, behaviour and flow in a system. Prototypes are an indispensable tool for resolving a large number of potential issues in a concept or business before too many resources are deployed to put a design into production.


A Wireframe is a visual schematic that conveys a basic level of communication, structure and behaviour during the design of a system. Wireframes are low-fidelity designs that bypass including a detailed user interface or visual design, conveying just enough to get across the core idea.


To say something is usable is a qualitative statement about how easy that thing is to use. Usability is an assessment of how learnable a system is and how easy a user finds it to use. The usability of a system or product is a key factor in determining whether the user experience is a good one.

Information Architecture

Information architecture is the design and organisation of content, pages and data into a structure that aids users understanding of a system. A more organised system enables users to more easily find the information they require and complete the intended tasks.

UI Design

User Interface Design is the discipline of designing software interfaces for devices, ideally with a focus on maximising efficiency, responsiveness and aesthetics to foster a good user experience.

UX Design

The practice of User Experience (UX) Design is the coming together of many specific design related disciplines to improve the usability, responsiveness, uptake and aesthetics of a product or service.

User Experience

A general term that covers all aspects of a user's participation while engaging with something that has been designed. Usually when talking about User Experience in the digital design field it refers to the interactions, reactions, emotions and perceptions while using an app, service, website or product.