An artist is designer’s worst enemy

Preamble

Although I generally dislike the Construction Metaphor applied to Software Development, I am going to use one to illustrate my point. After all, rules are only good for breaking them :)

Imagine that you are building a house. It is obvious, that you have some kind of more or less strict budget assigned for this. Construction workers have done a wonderful job building it up from the basement till the rooftop, installed all the wires and tubes and left you with empty rooms, which are yet just to be arranged. Talking in some software project terms: designs have to be applied. Your living room is totally empty and only one lonely bulb is hanging down from the ceiling. The construction workers have put it there as a temporary solution, so that you don’t injure yourself in the dark.

Let’s say, you invite a interior designer (a very artistic friend of yours), who takes a look at your situation, goes away and returns in a week with a design solution for your living room. Among others, one of the suggested details is a posh ceiling chandelier, which would definitely impress all of your friends, point out your artistic nature and correspond well with your social status. And yeah, it looks like this:

 

Finally you are totally persuaded by your designer in the necessity of this piece of luxury. You make some budgeting calculations on your own and decide to let the construction workers do it. (Imaginary examples are not obliged to be too accurate, so let’s say those are the same construction workers that have built the house in the first place).
The engineers take a look at design sketches and get a priceless WTF-moment. They call you back and tell you, that:

• the ceiling was not designed for that heavy weight, and they will need to install additional supports for it not to break;
• electric wiring is not strong enough for that amount of bulbs, so this has to be redone too;
• and, by the way, this kind of chandelier would actually touch the floor, if installed in real conditions.

“So you say it’s not doable?”, you ask them.
“Sure it is. But it will cost much more than the initial budget. And knowing that your budget is tight, we would not recommend you to do it.”, they say.
In real world you would probably just count your money and realize that you simply cannot afford this kind of stuff and abandon the (stupid) idea for good.

But it seems it does not work that way in IT. For non-IT specialists, who often end up to be project managers, the stuff they see on the screen seems to be so lightweight and easy, that they tend to do the cost estimations on their own, and still try to squeeze the fancy chandelier into the existing budget. Often they try to convince you to give more optimistic estimate. This eventually puts the entire project under failure danger.

 

The traps

There are several traps and mistakes, that people tend to fall into and do when thinking about UI-design and UI-designers especially.

 

1. Designer is not an artist

Many people tend to think about UI-designers as very artistic personalities. Not to mention, that our perception of an artist is very stereotypical. You know, this bohemian type of a person who is totally out of this world and probably always high ;) That is why people tend to think that a designer should be allowed to let his or her imagination flow, should be given the freedom of creation and should have no external limitations.

The important thing to realize here is, that a designer is not actually an artist, but rather an engineer with a definite set of creative skills and tools. The main goal and purpose of a designer is to solve a problem, not to create an artwork. Also, the designer should know, what are the tools and technologies, that will be used to implement his design idea. I believe this counts for all kinds of design. It doesn’t matter, if you design interiors, new iPhones, or a website with a responsive-UI (here goes the buzz-word). Implementation effort, costs and technical limitations should always be taken into consideration.

We witness bad designers’ works on everyday basis. We often see objects, which look somewhat nice from the first sight, but are actually very uncomfortable to use in practice. In one of our previous offices we had expensive designer bar stools, that sure looked fancy, but had to get a tighten-the-screw maintenance on a monthly basis, just to keep them usable.

If a chair suits the room interior (or looks unusual, if you like) and is comfortable to sit on — it has good design. Moreover, if a chair is comfortable to sit on — it most likely has a good design. But if a chair is impossible to sit on — it has bad design, no matter how it looks like.

 

2. What is the problem we try to solve now?

The goal is not just to solve a problem, but also solve the correct problem. I realize that this trap does not only apply to UI-designers, but to any other role in the project. But as I am in this mood already, let’s talk about it.

I have observed numerous times a problem solving pattern, when the initially chosen concept is driving the process. The reality is such, that the more we work on the solution, the more new details will always keep coming up. Those will be constantly questioning the relevance of your initial plan. At some point one might notice, that keeping the initial concept causes you to solve problems, which were not there initially. You are not solving The Problem anymore, but dealing instead with problems of your concept. And this is the good old ego vs. project value game. You should be able to realize and accept that the chosen plan is causing more problems, than bringing value to the project.

 

3. “Now let’s apply design”

On the World Usability Day Tallinn conference, which me and my colleagues attended last week, Pedro Custodio pointed out a common mistake — good usability and design is not something, what can be “applied” to the project on some latter phase. It is not a band-aid, that you put to a wound. He made an example of a car interiors design — it is really not about making the engine start-up button red (or any other color).

By now, everybody is already kinda used to the fact (I hope at least) that Quality has to be built in into your project starting from Day 1. But so does Usability. If designs are applied too late, then odds are high that the end result will either lack usability, or a large piece of “ready” stuff will have to be redone.

Another guy, who was also presenting on the conference, has stated that he has a team of ~13 UI and UX-designers and that they apply agile methodologies in their daily work. I got excited about it. He mentioned, that they work in iterations, have weekly demo sessions on Friday, and even showed a photo of their Kanban wall. “And then pass the ready designs on to the developers for implementation”, he said. Suddenly all my excitement was gone.

If designs are fixed and finalized before the actual implementation has even started, you can bet that developers will suffer implementing wild designer ideas, which did not pass a reality check. A short feedback cycle for your designs is a crucial part of the process. Design sketches and layout pictures lack the feedback, they are not interactive. But your system is.

Make your designers collaborate with the developers on day-to-day basis to work out best suiting solutions (both, usability and cost wise).

 

Short summary

A good UI-designer is worth some gold, as these species are hard to find. A good designer is probably not just a friend of yours who you know can draw well. Good UI-design is so little about nice drawings, but rather about allowing the user to quickly and painlessly access information and functions, that are provided by your system. A UI-specialist who does not know usability is rather an ambitious artist, than a good professional. However, even if you find one, do not completely rely on his or her professionalism. I believe, that only in tight collaboration with all parties involved in the project one can achieve best results. Designers often do freelance, but nothing can replace an in-team designer.

 

Some good references

• Bret Victor “Inventing on Principle”. Awesome highlights on short feedback-cycles in UI-design process.
• Яна Франк “Дневник дизайнера-маньяка”. A good book about artists, designers and essential differences between those. Written by an artist and designer Yana Frank. Unfortunately I don’t know, if this book was ever issued in English.