Stop looking for Designers… Become one!

On why Developers need to learn design.

NOTE: This is a very old post, even if it comes up on searches quite often, it’s now outdated and just left up for posterity.

This post is an excerpt from a talk I gave at Upfront some time ago.
You can find the slides here.

There has been a lot of hype in the last 1–2 years about “Designers should learn how to code”.

At some point I started thinking: Ok, poor designers, they have to learn how to code — but what about Developers? What would happen if they would learn some design principles? Would that improve the workflow of their daily work and consequently the final product?

I spoke with a lot of designer friends and they all agree in having sometimes big difficulties while communicating with developers. It often seems like there are communication issues whenever they want to make some changes. Most of them struggle when trying to explain why they decided to design something in a certain way in the first place.

I found out this often creates tension in the teams and leads to a Developers vs. Designers situation.

Metamorphosis

When I moved to London I started exploring the design scene there: London is famous for the vibrant landscape of meetups, design events, design jams etc. Few months after I started my “design self-training” I noticed something starting to happen: I started to notice flaws in a lot of the tools that I was interacting on daily basis.

I work as full-stack developer and in the last two years I have been freelancing a lot. This led me to work on a variety of different projects, clients, user bases and methodologies.

For my work I use a lot of different tools. A lot of open-source tools and a lot of dev-specific tools.

I clearly remember when I first started using AWS. AWS is an amazing platform developed by Amazon that allows developers to run a lot of different services in “the cloud™” without the need of setting up your own datacenter and hardware.

Let’s say you want to deploy your application on a web server, you can easily configure one from the web interface, start it and deploy your app in minutes. Amazing! I use it everyday for all my projects!

So this is the interface:

The Amazon AWS Console, first screen after login.

You can clearly see from the massive amount of information that it is a powerful tool. You can do probably anything with this. But what if you are a beginner? Well it’s hard to understand what you actually have to do or how you are going to do it. At the end I just want to deploy my web app, right?

For another project I gave a try to Heroku.

Now, just to be clear: I am not trying to compare the two platforms on a functionality level. AWS is clearly richer and more powerful. I want to focus on the user interaction here.

What Heroku does is to provide a subset of the AWS functionalities: automated code push, deploy of your app, app starts — no need for configuration.

Heroku web interface, the first screen after login.

After using both of them I realise somehow Heroku looks and feels way much easier to use. So I started wondering: “Wait a second. Why is this?”
If my goal is just to serve a web app on the internet, why essentially the same tools provide a completely different experience?

Is it because the first one is more developer oriented?

It is true that developers are more comfortable using highly technical tools and most of the time we don’t have big problems in diving deeply into complex software. But we also visit websites, use apps and a lot of other applications as well like any normal user too.

So, aren’t developers, in a certain way, normal users too?

Why is AWS less attractive than Heroku?

I don’t think it’s because Heroku uses a nice palette or a more attractive typeface. I do believe it’s because the Heroku team had usability in mind when they started designing the platform.

After this first realisation, I started noticing these problems not only in developers tools but in most of the apps, website that I use on a daily basis.

Misconception

At this point I want to make you all aware of a big misconception that I often encounter while working for a lot of companies. This can be summed-up by a single sentence.

“Hey we just finished to implement [insert feature], let’s call the designer and make it look nice.”

I’ve heard this sentence so many times that now, I literally turn off my brain when some fellow developer start saying something like this. When I talk about design, I am not thinking about changing colours or designing a nice UI.

When I talk about design I refer to User Experience Design, what is commonly referred as UX Design.
I think of the people who help in shaping the interaction between a Machine (that can be an app, a website, an IoT device) and a Human (our users).

[EDIT]: As Giuseppe Burdo kindly made me notice, the last paragraph can be a bit misleading. I didn’t mean to put UX Designers and HCI researchers at the same level. There is a difference between the UX industry practice and the HCI research even if the treated topics often overlap.
A nice article about the relation between the two can be found here.

Design As A Service

Until not so long ago, we were in a situation that I like to call Design As A Service time.

Essentially the process was quite linear:

• I have a business need
• I call some design agency to design what I need to implement
• The designers pass the spec to developers
• The developers implement them
• ???
• Profit.

Agencies from all around the world facilitated this (and still do) providing designers as a service: people who would work for a short-medium amount of time on a project, deliver and then move on.
If something changes on a business level, we re-do everything again.

Nowadays the situation has changed.

Discussing with some friends, we noticed that big agencies are being acquired by big corporations or working as incubators for new products themselves (think about IDEO joining kyu, fjord sold to Accenture, Mint Digital spin-offing companies for years now or the now defunct Berg that at some point became Berg-Cloud).

Also, most of the startup and small to medium companies started to have their in-house design team. Even governments are following the trend: the UK Government, with their Service Design team, are actually shaping the discipline on a global scale.

Shift

Thanks to the agile methodologies shipping software has become way more fast and change-prone. This was led by a lot more competition and the need to change fast but also from the introduction of concepts like design thinking in the development cycles. Concepts brought in-house by those design teams.

It’s interesting to note that most of those agile methods perfectly intersect with the design thinking workflow:

Brainstorm -> prototype -> ship -> user test -> iterate on prototype.

Companies have finally understood that design is not just “making it look nice” but is something that has to be fully integrated in the development process. This change in methodologies brought a huge attitude shift in how we design and ship products. We are not building something “just” to solve a problem but we are trying to deliver the best experience for it.

The classic example is: think about how many image sharing app are out there and why you use Instagram over Flickr. WhatsApp over Signal. Mail over Gmail. In most of the cases there are already several apps solving a specific problem. And most of the time the winning app is the one with the best UX.

We are designing, building and shipping an experience not a product anymore.

I firmly believe this requires a shift in how our organisation works.

Task Driven Teams vs User Drive Teams

More than likely your organisation is divided in teams (if you are working for a small startup maybe you are part of the only team in the company).

I like to classify teams into two macro-categories:

• Task driven teams.
• User driven teams.

The first ones are the implementers.

The Task driven team receive a bunch of business spec, implement them and go home and enjoy the weekend. They try to solve a specific task or business problem.

For developers this means to receive the specs from the designers, implement them and join the rest of the team at the lake. They see the specs as a technological challenge to solve.

On the other side, a User driven team focus on solving not a business nor a technological problem but a user problem. They ask themselves:

Why is the user not using a certain feature?
Why should I put that button here instead of there?
Should I focus first on which functionality?

Developers and designers are not just implementers: they both collaborate together with the business and marketing unit. They all actively discuss and challenge each other while keeping the user need in mind.

What I found out talking with many colleagues is that a developer that codes with the user in mind is going to deliver better experience to the final user compared to a developer “just” trying to solve a technical challenge.

Let’s be honest (and a bit brutal) at the very end, the end user doesn’t give a damn about the implementation details. It’s sad, it’s frustrating but it is like it is.

So, how do we stop being “Task Solvers” and become “Experience Creators”?

User Centered Design

A framework a lot of companies and startups started to adopt in the last few years is called User Centered Design.

The term UCD was first used by a professor called Dan Norman in his book “The design of everyday things” and it’s used “to describe design based on the needs of the user”.

It’s a framework with the goal of “[..] simplifying the structure of tasks, making things visible, getting the mapping right, exploiting the powers of constraint, designing for error, explaining affordances and seven stages of action [..]”. [source]

UCD uses mainly three tools to make the analysis of a problem:

• Personas: A persona is [..] “a user archetype used to help guide decisions about product features, navigation, interactions, and even visual design. In most cases, personas are synthesised from a series of ethnographic interviews with real people [..]”. [source]
• Scenario: A scenario created in the UCD process is “[..] a fictional story about the “daily life of” or a sequence of events with the primary stakeholder group as the main character. Typically, a persona that was created earlier is used as the main character of this story [..]”. [source]
• Use case: a use case “[..] describes the interaction between an individual and the rest of the world. Each use case describes an event that may occur for a short period of time in real life, but may consist of intricate details and interactions between the actor and the world [..]”. [source]

I am quite sure if you are a developer, especially the last one, sounded quite familiar.

“Use cases” are often used together with user stories in development sprint to fix and describe the implementation details of a specific feature.

What about the scenario and personas? These other two tools are often seen as less important or completely ignored by developers. Why?

All three are intrinsically connected between each other and a slight change in one of them will probably affect the other two as well.

Cultural clash

Here’s the cultural clash. I believe the “Designers vs. Developers” is all about this.

We established that a designer that knows how to code will understand that sometimes a small change might be not so “small” to implement. In the same way, a developer that keeps in mind the user, knows that implementing a feature in a slightly different way could potentially impact (or invalidate completely) the user research made before.

Developers learning design is not about learning how to use illustrator, create a persona or design a wireframe. It’s about understanding the implication of the features we are implementing.

Developers learning Design is about prototyping and testing a feature and not being angry if something changes in the future. Because a failure in the user testing phase could and probably will happen.

Developers learning Design is about killing over-engineering to facilitate that testing.

Finally, it is about facilitating the communication between the two.
It’s about speaking the same language and challenge each other in finding the best solution for the user.

What we do is not about fancy animations or buttons.
It’s not about an incredibly sophisticated cutting-edge technological solution.

It’s all about creating an experience for the final user, in the form of a product they will easily use, love and retain.