Breaking the “Should Designers Code” Deadlock

The ‘designers should code’ vs ‘no designer should code’ continuum is a dead end. To mature as a profession, UX needs to start asking itself better questions.

Cennydd Bowles tweeted this image from a session at UX Australia where a poll asks:

“A UX designer should be able to build front end code (HTML, CSS) for an interface they have designed.”.

79% of the audience did not agree. Now, this isn’t worth much as evidence. The sample size is small and the context is unknown. But why does this question keep coming back to us?

Let’s unpack this thing

It’s hard to come up with a short, final answer to “Should designers know how to code?” because it packs so many issues into one question.

A cursory glance reveals some practical issues. Let’s have a look.

If a designer codes the interfaces she’s designed:

• Which platforms should she be able to code interfaces for? Android, iOS and the browser? What about Windows and OS X apps? Set top boxes?
• Should her code be used in production?
• Who will test, refactor, secure and maintain that code over time?
• Who makes sure things work across the relevant browsers?
• Who makes sure that it’s accessible?
• If an existing service needs a tiny tweak, does she refactor the existing code, or start from scratch?
• If a CMS is involved, should the designer be coding templates?
• How does she keep tabs on developments in the areas above?

If a designer makes working prototypes of the interface she’s designed:

• Which platforms should she be able to prototype for ? Android, iOS and the browser? What about Windows and OS X apps? Set top boxes?
• How much time should she spend getting the UI details working right, versus getting the flow right, versus making sure we’re building the right thing?
• Should she hand-code everything in HTML/CSS, or use a tool? If the latter, which tool?
• And (to some, I will now be splitting hairs) if she’s using a tool like Principle, Invision, Origami (or the original Origami!), it’s not coding, so what is all the fuss about?

OK, “Should designers code” is a little thorny.

But there are three larger problems lurking in the background.

Problem 1: UX’s factory roots

Earlier forms of design — industrial/product, transportation, furniture, environmental, graphic and more — come from the factory. They were raised within the confines of mass-production and inherited the values of the first machine age. Division of labor is a given, everyone specializes, and everything is in its proper place.

UX inherits much from industrial design and graphic design. Its computing and HCI ancestry is no less industrialized. Words like efficiency, consistency and optimization oil the politics of automation that funds many a UX project.

However unwittingly, we take the ideas of the production line and the first machine age with us to work every morning.

Furniture designers prototype

Hans J. Wegner is one of my favorite furntiture designers. Originally trained as a cabinetmaker, he prototyped extensively when designing.

From the Hans Wegner monograph, Just one good chair, page 92

Expert furniture designers know their stuff. The properties and suitability of materials and production techniques. They make a host of prototypes to tests — with users, experts and manufacturers — and evolve, rework and redesign until the kinks have been worked out and the object can be produced at the desired scale. But then, that’s it, they’re done.

Shouldn’t UX designers prototype, too?

Now, from this we could hop back a few steps and say that expert UX designers know how to prototype the interfaces they’ve designed.

But, wait, what do UX designers do, exactly?

Well, it’s not a great label. There are so many specialities and sub-disciplines out there, but also so many different ways to fill that word with meaning. Even the best UX firms in the world can’t agree on what to call things.

Also, Design is a word with many meanings. I won’t go into it here, but see Clive Dilnot’s 1984 paper for more on that headache of a word.

What do you mean by designing?

Image from Design Magazine, issue 204, 1965. Source

In his Systematic Method for Designers (1963) Bruce Archer offered an explanation of what designing is, and it’s specifically not the making part. Because he is aiming to be precise, the explanation is not short. Here’s the first half.

An architect preparing plans for a house is clearly designing. So is a typographer preparing a layout for a page of print. But a sculptor shaping a figure is not. What is the difference? A key element in the act of designing is the formulation of a prescription or model for a finished work in advance of its embodiment. When a sculptor produces a cartoon for his proposed work, only then can he be said to be designing it.

Sometimes the word ‘creating’ is employed when there is no model or prescription between the formation of the idea and its embodiment. Thus a couturier may ‘create’ a gown directly into its final form, but if the gown is a model gown its ‘creation’ is the ‘designing’ of the line.

So, the prior formulation of a prescription or model is one necessary element. The hope or expectation of ultimate embodiment as an artefact is another. Hence the formulation of the idea for an office filing system may be designing, so long as it anticipates the laying down of ‘hardware’.

Similarly, the discovery of a chemical formula in general is not designing, but the prescription of a formula for (say) a new plastics material may be. Thus, we say that not only a prescription or model, but also the embodiment of the design as an artefact, are essential to the definition of designing. In this sense the composition of music, for example, although in many ways analogous, is not designing.

(I’ve included this long quote here instead of linking to it because it is is not available online, and good luck finding it in a library.)

Archer’s 229-step (!) method is little known today, but it’s one of the forebears of the way we design now. Here’s a simplified overview, from Dubberly’s How do you design? process compendium.

Do you see which part of this process isn’t right for UX?

There are several, actually.

• Once the Analysis phase is done, it is difficult to reverse course. If, down the line, you discover faults in a key assumption or come across a nasty unknown unknown, well, too bad for you.
• After the Solution phase, the designer is done, and gets sent home, which means that she doesn’t get a chance to see how her solutions is received/adopted/used/altered in the wild.
• If something goes wrong at the end, you are advised to change the constraints. Archer writes: “When severe snags are encountered at a late stage in development, it is often better to seek changes in the design brief or in the production constraints than in the design idea itself”
• There is no regime in place for learning and optimizing post-launch, because the method only deals with what happens in the project. In fairness, step 6.5 in the process is Validate Hypothesis (take that, Lean Startup!) but the last steps are Prepare communication, Transmit information, Wind up project and Close records.

The methods developed by Bruce Archer and others in what was called the Design Methods Movement seem mostly forgotten today, but much-simplified descendants should be familiar to every skilled designer.

Image from Dubberly’s “How do you design?”

For a number of reasons (well-explored in Reframing Information Architecture), the design professions aren’t great at handing down their histories and methods, a few iconic objects and people notwithstanding.

Why should you care? Because old design processes like the one above — which, I argue, is a bad fit for UX — have become the method that “everyone” today uses, without asking what it was designed to do.

If you’d like to know more about the Design Methods Movement, I recommend Nigel Cross’s A history of design methodology (13-page PDF) for a quick overview. If you’d like to know more about the incredible changes that the design professions went through World War II, due to the advent of cybernetics, ergonomics, etc., then you should read Alise Upitis’s Ph.D. thesis, which is excellent.

Living in a box

This is factory logic, and the (sadly popular) linear process of going from a brief to a wireframe (who needs research anyway!) to launch suggests that our profession uses it liberally and without much thought.

If we unknowingly use factory logic, approach our tasks as a linear “matter battle” (hat tip to Bryan Boyer for that term) and leave it to others to do the “making” work, without knowing why, then we are — to phrase it with factory words — not performing at the required level.

Meliora and the Masters

But we’ve inherited a bunch of values from the factory too: know your place and don’t overstep. Maybe there’s a class thing at work here. In the factory, an engineer simply does not suddenly don overalls, walk onto the factory floor and start welding. A professional practicing a trade? In that world, it is simply not done.

So, when someone says “Should UX designers code?”, that’s an affront to our inherited values. Mind you, I don’t think these are the values we need. But within that context, the question:

• Asks a professional to practice a trade
• Hints at a contempt for all skills but coding (ironic, since it’s markup, which has lower prestige than “real” coding).
• Implies that UX is primarily about screen mechanics
• Implies that all the other stuff the UX’er is doing serves little purpose
• Implies that it’s a job that one person can do on their own
• Asks the UX’er: “Why are you here, again?”

No wonder this question sets off such furious discussions!

2. A foolish quest for unicorns

Since our medium supports a different mode of working, one person could, in theory, do it all.

This effectively reverses the division of labor that helped bring about the industrial revolution and the society we live in today. This really only applies to people making software for a living, but within that tiny realm, it can mean different ways of working.

If you’re the only designer on the team, and everything everywhere needs design, then you’ve got quite a juggle on your hands.

Some think this is a good thing, and have given it a name: Full Stack Designer. There’s even a manifesto, which doesn’t mention users or needs, although it does mention validation.

Image from Ran Segall’s Full Stack Designer Manifesto. Source

My view is that this inevitably leads to a focus on just getting the damn thing to hang together, instead of understanding what your users need, figuring out how to make it right, and then let them hire your product/service to do that job for them well.

You see this in diagram above. First, they start off with market research, etc, and in the brief window between validation and product development, there’s a bit of time to do research and wireframing, and at the end there’s growth hacking to get the ball rolling. There’s no mention of users and needs .

Now, there are some great pieces of software out there, built by singular individuals, but they are the exception and, if you’re really that good, why go at it alone?

Unicorns are a mirage

We call these people Unicorns, for their rareness. Bred mostly in the clueless job ads of companies looking to become 100% customer-centric with just one hire, they are impossible to find.

We can change this, by changing the language we use. Let’s stop saying Unicorn and full-stack designer, and start saying:

• Generalist
• Jack-of-all-trades
• One-man band

I don’t know about you, but that’s not the kind of person I’d like to hire.

3. What’s so different about UX?

The roots of User Experience Design stretch back at least to the late 1940s, but as a profession, we have some way to go before our foundations are solid and our practices mature. This is normal, but we need to be aware of it.

Let’s compare UX to an older field: industrial design.

In industrial design, the high upfront costs and high risk of costly failure has led to higher of barriers to entry, more gatekeepers and more specialization. A product’s journey from idea to reality goes through many, many quality assurance gates. Even when the product gets made right, it’s really hard. Here’s an example, from Kickstarter, of how hard it can be.

Deep or broad T-shaped designers?

I would argue that the structure of the industrial design world puts pressure on designers to specialize, and develop deep and narrow expertise for an almost fixed context, rather than to work across different contexts with a broad, but shallow skillset. Looking at the specializations and career paths industrial design classmates with in the 1990s (where I started out), it’s my view that mastering one of the major 3D modeling tools is now a prerequisite for getting a job as an industrial designer.

UX doesn’t have the same clear distinction between prototype and production as industrial design. It doesn’t provide the same kind of ‘This is just broken on so many levels’ feedback that a physical prototype immediately conveys to everyone. And it doesn’t (yet) have the process failsafes built in, the way physical products do today.

This means that UX’ers are free to fail spectacularly because we can release a working version without having made the right thing (solves a real need) or without having made the thing right (fitness for purpose).

Our medium imposes fewer limits on us, so we ourselves must act with greater intelligence and restraint.

Additionally, UX doesn’t have to have the same clear distinction between designing and making as outlined by Bruce Archer for the development of physical products, so we can’t simply copy the old ways either. Our medium requires a different approach. But so does our context, and this I discuss below.

Organizations make designing different

OK, so can you have a successful career as a UX designer if you can’t code? Let’s look at the different roles in the UX team. I highly recommend Leisa Reichelt’s post (below).

There is no UX, there is only UX

That’s right, there really isn’t a UX team, it’s the whole organization. You’re designing with. Yup, you’re on a team, but that team is woven in. Or perhaps spliced in is a more precise term, because very few orgs have a deeply customer-centric and have integrated design capabilities.

Sabine Junginger’s model, laid out by Hugh Dubberly.

That’s a nice way of saying that a lot of companies don’t like/know their customers but need to be liked/loved by them. That’s a job for UX, isn’t it? (Eh, were both marketing and communications on vacation?)

UX really is different

UX is a big job, and the role frequently includes herding cats and wrangling organizations. Then there’s a matter of technology, which goes way beyond being able to code prototypes. Does the UX designer decide on API matters? Have a say regarding yield management? Build relationships with technology partners? Not to mention that big, vital component we call users, whose needs we try to understand and advocate for. That’s no easy feat.

You generally don’t see other design practices integrated into the organization itself the way UX is, by its many labels.

Ours is not the matter battle. This is not the factory. Spliced into the organization and designing with, not for, our job is different. The best people in our field are putting together ways of working better suited to this still-new medium of ours, and our insider status.

To mature, UX needs to ask itself better questions

Should designers code? The ‘designers should code’ vs ‘no designer should code’ continuum merely perpetuates a useless debate. Let’s break out of that destructive pattern, and ask some new questions instead.

“What sensemaking, process, organization, technical, people, and domain skills does a [designer] need to succeed in this role, context?” Could this help the designer do a better job, and her colleagues and managers support her better?

“What kind of team, strategy, structure, support, resources do we need to succeed in this particular venture?” Could this line of inquiry help us get better at getting better?

If we want to succeed at what we do, if we want to turn UX into a real, solid profession, then these are the kinds questions we need to start asking.

A big thanks to Christopher McCann for replies along the way, Amy Jiménez Marquez for her cheering and thoughtful post, Andrea Resmini for helping me unpack the tangled term that is “UX” , Cennydd Bowles for kickstarting this discussion and to Phillip Hunter for the lede, which I shamelessly stole from his tweet. You’re all making our field better.

And thanks, dear reader, for making it all the way through this very, very long rewrite of a tweetstorm.