Should UI Designers Code? – Discuss.
When i started Make Us Proud almost 3 years ago, I came from a background of UI engineering, UX and Visual Design.
I’d always felt that the combination of Engineering, Design and UX really helped me create products that felt great to use.
I founded Make Us Proud with a nag in my mind of wanting to work with Designers who can understand the technical nature of our medium (computing devices) in depth, people who can Design and Code. However, finding these people has always proven to be challenging.
Recently, i’ve been questioning my expectations, and I hope this brain-dump adds something to the dissonance of this perpetual argument!
Do better designers code?
When we work from a design perspective, we’re trying to define how the application should behave to help it’s users achieve their goals.
We get the applications behaviour right through empathy as Designers; understanding how our users think, how they expect interactions to work, and how we can help them visualise and achieve their goals in the simplest manner.
Getting a clear grip on these ingredients help us to define our UI and the behaviour of our application. It also helps us understand when they’re working as we expect!
This pursuit of designing application behaviour led me to believe that designers should code. My opinion at the time was that by being able to implement our imagined behaviour (through code) helped us Designers think and work in behaviour.
This lead us to designing better solutions for our users more rapidly than we could otherwise.
So, What Do I Mean by Thinking in Behaviour?
A long while ago, I gave a talk at UX London that covered Jerome Bruners 3 modes of representation.
I used his theory to explain how we can be better designers through Code, Sketches and Experiencing our end product.
So for those of you who missed the talk (aka, all of you…) let’s recap.
Jerome defines 3 modes. Symbolic, Iconic and Enactive.
The Symbolic format is language based. For example, English, or JavaScript.
An example could be a formula for calculating the length of a bike chain, or a description of how the chain interacts with the crank.
This domain is most frequently used by developers, linguists or mathematicians, but it’s also a space for designers; We work with easing values, sizing calculations, line-heights etc.
The second domain, the Iconic, is image based. It focuses on the necessary elements that visually describe a system. For example, a diagram that shows how a bike chain wraps around it’s crank.
This domain is most often explored by UX Designers, Graphic Designers and Product Designers, along with Engineers as they visually represent a linguistic structure.
The final mode is the Enactive mode. This is action based; physically using something. If we continue our bike analogy, it would be the experience of riding the bike itself!
What’s interesting about the Bike analogy, is that you can only learn to ride a bike by actually doing it. We only get to experience the actual work we’re creating for our users in this format.
You can’t look at the diagram of how a bike works, or look at equations that define the laws of physics to learn how to ride a bike. It’s human learned. An intuitive behaviour derived from the system in action.
In my talk, I suggested that as designers, we should aim to consider how we can move through these 3 modes of thinking to help us design better solutions. If I’m stuck in the Symbolic domain, can i unlock my next steps by moving to the Iconic domain? Perhaps I should move to the Enactive domain to experience the product itself, and learn how it feels to ride the bike? What can this do to inform our earlier Design decisions?
Until recently, many Designers have been limited to the Iconic and the Symbolic domain. They’ve been unable to access the Enactive domain without the help of a Developer; unable to experience the product until it’s near completion.
Our Design Tools Have Improved Immensely
A photoshop file, or a Sketch file does not define the application; it’s devoid of the behaviour we need to experience the design, or to view the experience of others.
With a modern set of UI & Interaction Design tooling, we can bridge that gap between creation and experiencing the behaviour we’ve defined. As Designers, we can finally think across all 3 of the domains without coding.
This has lead me to change my mind. There are incredible products such as Flinto (with it’s behaviour designer) and Principle that give people who can’t code the ability to begin to think, and work in behaviour, and adjust it as they see fit.
But i’m beginning to believe that this can go even further than we can achieve in code. One of the benefits of working with UI is the abstraction of linear complexity, the ability to have a malleable canvas that evolves as we see fit.
Dealing with a constraint based layout system, or a huge number of break points in your CSS as a developer is a pain.
Dealing with them on a component level, with a clear UI that changes based on the size of your canvas (that you can interact with) and manipulating them directly is simpler, and easier to get to grips with in terms of the resultant behaviour.
The outcome and the input are intrinsically combined together, and result in an immediately experienceable behaviour. This helps us make more intuitive design decisions, and test our concepts immediately.
Do Designers Need to Code?
With modern tooling, I don’t think so. We have the ability to work directly with our UI, through almost every domain; Symbolic, Iconic and Enactive. These three domains are linked more closely together than they’ve ever been.
It’s worth considering who we’re designing our systems for; Are we designing for machines, or are we designing for people?
