by Alexandra Leisse | alexandra@iterate.no | @troubalex
This is a written and slightly tidied version of the lightning talk I gave at this year’s Javazone.
We designers have long been told that we should learn how to program in order to really understand the medium we’re working in, and to develop a common language with developers. While I believe this to be true, I also believe that it should go both ways.
I regularly encounter a number of misconceptions about how to work as a designer. Let’s get those out of the way first.
One is born a designer
This is equally untrue as “one is born an engineer”. Just like everything else, design needs practice, and is hard work. There are plenty of excellent resources such as “the Complete Beginner’s Guide to Interaction Design” by Andrew Maier on UX Booth or “Designing for Interaction” by Dan Saffer.
Or, how Steve Krug, the author of “Don’t Make Me Think” and “It’s not Rocket Surgery”, puts it: a lot of what we do is advanced common-sense.
Design is creative chaos
Creativity is work. When designing an interface I go through a process of understanding the problem, researching UI patterns and solutions to similar problems, discussing what I find with colleagues, research some more, sketch, prototype, iterate, and refine designs.
This is the process of almost every developer I have talked to, and I refer to it as advanced problem-solving.
There are no rules in design
Good design is based on a number of principles. It combines elements of psychology, social sciences, and computer science into a coherent result. David Kadavy’s “Design for Hackers” and Google’s “Material Design Guidelines” do an excellent job to explain some of them.
Design is much closer to applied science than anarchy.
Collaboration needs shared skills
Designers and developers are two sides of the same coin. We work towards the same outcomes on our projects, we hope to achieve the best possible results, and we have similar but complementing problem-solving skills. For true collaboration, we need to learn about our respective disciplines.
Collaboration of course is not a goal in itself. It is the outcomes I want to improve when I ask developers to start designing.
Better quality in less time
Jeff Gotthelf, author of Lean UX, argues for cutting deliverables and focussing on quick iterations. When we work towards the same goals from a basis of shared understanding, we can move much faster, and can spend less time on meticulously documenting all our work.
Having [the developers] involved from day one meant that they were included in a lot of our design reviews. They began to understand the thought process behind our design decisions, and everyone could holistically understand the system we all were building together. – Katie Kovalcin in A List Apart
The moment we all understand what we’re building and why we’re thinking about building it a particular way, we can trust that we are all making decisions based on the right intentions. We can finally stop micro-managing, and spend our time on the details.
You are ALREADY designing
In reality, you are making lots of design decisions already today, simply to get you’re job done.
The biggest reason, though, for involving developers is that they will end up making design decisions anyway. The truth is that, as a developer delves into building a project, they will have to make decisions that affect and refine the design. Designers rarely have the time to consider all nuances of a website. The rest fall to the developer.
By involving the developer in the initial design discussions, they will be in a better position to fill in the blanks. And when compromises in the design must be made, they will be in a better position to make those calls. – Paul Boag in Smashing Magazine
In other words, the more you know about the reasoning behind a design, the better the quality of your decisions. The blanks to be filled are small each on their own but seen as a whole make quite a difference, even more so if done really well.
Shared problem solving
But there is an even better reason for why you should learn about design: you’re smart! I want you to take part in my design discussions. The more comfortable you are with what you know, and with what you think could be a better solution, the more interesting the discussions become. I’ve seen it happen, I want to see it happen more often.
But where do you start once you have decided that you should know more about design? At work.
It’s okay to learn on the job
If you have access to the designers on your project, it’s easy: simply ask them to explain the decisions they’re making and to be included already in early design discussions. This is obviously not as easy if you’re working with a design agency. In that case I encourage you to pester other designers.
What you can do regardless is to be aware of the decisions you’re making and the impact they have, to read design blogs such as Smashing Magazine or A List Apart, and to dissect interfaces of applications you’re using.
