Learning to prototype is more important than learning to code
There’s still an ongoing debate about whether designers should learn to code. I think it’s more important that designers learn to prototype.
Prototyping doesn’t mean that you have to write code or build software.
A prototype should be the quickest, cheapest way you can find to learn about something, or to test an idea or hypothesis.
Prototyping can be used for everything from policy, to services, products, ways of working, tools and even tech and software policy within an organisation.
This is more of a mindset and way of working, rather than a fixed set of tools. Prototyping can be lo-fidelity (e.g. pen and paper), involve modelling and changes to a physical space, and even role play through simulating new face-to-face interactions within a service. All these things can be just as important as building models of user interfaces presented on a screen.
I taught myself to code about 15 years ago–mostly through books and practice (view source, and webkit type browser extensions were essential at the time). It was a useful skill because I was mainly designing for the web. As the scope of my work has broadened–especially, thinking more about complex products, and even more broadly about services and systems–I’ve found these skills less useful.
I can still build a basic prototype in code (at least something that’s bootstrapped in code), but this is usually only part of what we need to test. Often, the most important thing we need to learn about is the viability of a new service/business model within an organisation ie. not just the digital components or transactional parts of a product/service.
I can now compare this to when, in a previous life as a UX designer, I would primarily prototype to test the usability and feature set of largely web-based products.
The important thing here is to see prototyping as more than just a way of learning about the interactions of what happens on a screen. Those interactions are important, but prototyping as an applied skillset and way of thinking about problem solving is much more valuable than this.
I’ve found that the tools, and expectations for the tools we use change over time, and it feels like design tools, including prototyping tools, are progressing and changing rapidly at the moment. That’s fine, but having a consistent approach to learning is the important thing here.
I would also say the same about any set of tools and about the expectations we put of people to depend on a fixed set of tools. Designers shouldn’t have to learn Axure any more than they should feel pressured to learn to code.
The important question is what do you need to learn about next? Or, how can you make an idea or concept real enough to put into a real world situation that enables you to learn from what happens.
Knowing how to code is a useful skill for designers working on digital products, and parts of services. But knowing how to prototype in a range of scenarios is a much more flexible set of tools to apply throughout a multi-layered design process.
Footnotes: I do think it makes a lot of sense for anyone specialising in Interaction or Product Design to have at least a basic understanding of code, or they should know how to pair and work directly with developers. I’ve never had a lot of time for wireframes that try to re-create a “website experience” – it feels wasteful and I think we can find better ways to embed design as part of engineering/development teams.
This is my blog where I’ve been writing for 20 years. You can follow all of my posts by subscribing to this RSS feed. You can also find me on Bluesky and LinkedIn.