5 Things Developers Should Know About Working with Designers
Without further ado, let’s go!
1. If something looks really simple it doesn’t mean it didn’t take a lot of effort to do. Simplicity is hard.
I’m sure at some point you have thought to yourself “I could have done that!”. To be able to narrow something down to its essence requires that you know precisely what you are trying to achieve. Often it also requires going through a lot of different options to see what works. Without seeing those iterations and knowing the often conflicting requirements coming from different directions, it can seem that not much of anything was done at all. Going through all the possible options takes time. Not everybody needs to use their time on that.
2. If you only consider the task at hand, a different solution might seem better than when you consider the consistency of the product as a whole.
You know the situation where a developer is working on something and it turns out that some design changes are needed. Hopefully bigger things have been figured out during sketching and prototyping before the actual development work but it can still be almost anything. Maybe an example pops into your head while reading this.
Consider the 2 options:
A: The perfect solution for this problem, but sacrifices some UI consistency
B: Less than ideal solution for this problem, but maintains UI consistency
Very rarely, if ever, is the user of the software only using one particular feature. A more realistic situation is that they spend most of their time doing other things. They get used to a certain kind of logic. Too many “A” solutions to feature requests and this logic would be lost. It is actually easier for the user if the solution is consistent to the way they are used to, even if it is less than perfect for this specific situation.
3. Often it doesn’t even make sense to try to figure out every detail beforehand, you learn by doing.
The specs suck. Or, what specs? Often there might be some room for improvement to be honest. It is impossible to take everything into account beforehand. Just as design is an iterative process, so is development. Reflecting on the first version, it becomes clear what you should’ve done. It is a constant balancing act where you need to leave some room for the technical aspects to affect the design but give enough direction that the development work doesn’t become painful. Preliminary designs are an excellent way to facilitate and provoke discussion. It is easier to point out things that don’t work when you have something to look at. Which then leads to a more finalized solution.
4. Voting within teams is rarely the correct way to decide anything meaningful in design.
It might seem like wisdom is in the crowd. Ask enough people and you’ll get a consensus decision that surely can’t be too wrong. Whilst this may be true, the end result will just be something safe that works.
There are those design decisions that look like no decision was made at all (see point 1). Everything is designed, but not everything can, or should, stand out. Some things though need to stand out and those are the ones that can’t be voted on. Sometimes people need to be guided in the right direction. There are many examples where people initially disliked something that was new and weird. Those things went against people’s expectations and they needed some time to adjust.
The first AirPods looked like toothbrushes sticking out of people’s ears and they were ridiculed for that. But that is a bit of a bad example since they really looked like the previous generation of headphones, just without wires. So I don’t really know what the issue was. Anyway, lots of branding changes are initially disliked too. Then, after enough time has passed, they grow on people and when the next branding change comes along people are up in arms again because their old beloved logo, livery or whatever is changed. These kinds of designs are intended to evoke feelings so people become attached to them. If nobody hates it, nobody loves it either.
5. The better thought out the UI is, the harder it is to just add or remove things without doing some additional changes as well.
This is an interesting one and kind of a test of how good the design is. If something looks like a mess and there are lots of things that don’t really make sense (maybe they even make sense, it doesn’t matter) nobody will notice or care if you add one more button or remove something.
However, when something is really thought out it becomes trickier. I don’t want to use the word “uncompromising” because basically all software is made up of compromises. Art is uncompromising. Opinionated is a better word. You know what you want to achieve and get rid of the extra crap. It is like one of those stylish but cosy living rooms you see in magazines. You can’t just add an additional lounge chair without moving the sofa and table a bit. Otherwise you are blocking the hallway or making the proportions of the room feel wrong. If you already have too big a sofa placed in a weird spot in an unusually shaped and inconvenient living room, who gives a damn if you add two more chairs. It can’t be that much worse.
Then there are those special cases like wearables where the screen real-estate is limited. Everything on the screen needs to be really well thought out.
Design is just thousands of decisions. Getting a couple of them wrong doesn’t matter. It is unavoidable. Getting enough of them right is hard work and doesn’t happen by accident.
Obviously, not all of these apply to every developer out there. More like some of these apply to some developers at some point in their careers. And not just developers but product owners, project managers and others. Designers, I’m pretty sure you were nodding along while reading though.
This article is written by Senior Designer Tommi Moilanen.