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.

When I was saying (translated)

An interesting blog post that I have decided to translate into English. Quite many fair points there. Special thanks to Stan and Heiti for help and support :)

Habrahabr.ru 404 page design

 

When I was saying...  

A collective image, all similarities are coincidental 

When I was saying, that you have to invest into community and User Groups, you were investing into table football instead. Now we have a lot of average football players and absolutely no community.

When I was saying, that you can not lure IT-guys into conferences with chocolate chip cookies, you were still buying pizzas, giving away t-shirts and iPads. Now every other event starts with a quest for free load and ends there.

When I was saying, that you should invest into employee education, you were still giving away money for endorsements and references. Now no one works, but everyone recommends.

When I was saying, that you can’t pay thousands of dollars to people who do not know the difference between an abstract class and an interface, you still kept on paying. Now everyone gets thousands of dollars, but f%ck knows what is the difference between an abstract class and an interface.

When I was saying, that you have to publish technical articles, you continued to hang around on Slashdot* and build up IT-company benchmarks. Now Slashdot is awesome, but still no technical articles there.

When I was saying, that you cannot call everybody “seniors”, you kept on doing that. Now we have hordes of 23-year-old seniors everywhere, but still f%ck knows what is the difference between an abstract class and an interface.

When I was referring to people-over-processes principle, you were still organizing agile hangouts and installing scrum-boards all around the place. Now everybody does “scrum”, but to be honest, the projects are still done as shitty as ever.

When I was saying, that you shouldn’t crack puzzles on job interviews, you kept on asking why are all the manhole covers round. Now everybody knows why manhole covers are round, but the abstract class and interface dilemma... well, you got my point.

Now when you say, that developers became too picky, you are absolutely right. Because you did everything right.
______________________
* Originally refers to russian-speaking community habrahabr.ru


P.S.
By the way, we at Ignite do ask about the abstract class and interface stuff ;) So beware.

Few minutes ago

What is your favorite timezone? Years back I used to have a school record book with a timezone map printed on it. And since then my absolute favorite is Kathmandu (UTC/GMT +5:45 hours). No, seriously: +5:45.

I guess, every company that plans to go international, faces the infamous timezone-problem. Not to mention, that just supporting different timezones in your application is just a part of the problem. There is also this fancy thing called daylight saving time.

In a project I used to work in we ended up having a daylight-saving-approximation-table to deduct the presence of daylight saving shift in one or another timezone. Just for your reference: timezones don't have daylight saving shifts, but specific countries do. So what will you do, if you don't know the country?.. We also had a fancy unit test, which would fail twice a year, and only on weekends. You probably know why.

However, this silly note is not about us traveling through different time shifts etc. I wanted to highlight one brilliant example of requirement handling. I don't know, who was first to introduce this, Facebook or Twitter, but they have this amazing timestamp presentation feature. The posts are being timestamped as "just now", "about a minute ago", "about an hour ago", "1 day ago".

This features two amazing mind shifts at once. It makes the timezone-problem obsolete — people just want to know, when the update was posted. They don't want to define their timezone in profile or anything and this is not required from them. This is what makes FB/Twitter adequate to the growing world of mobile. The other mind shift is the loss of precision, which could be considered as a drawback, but actually just keeps things simpler. I don't care if something was posted at 13:51 or 13:52... it happened a few minutes ago.

Agile Schmagile — ScanAgile 2012 trip-report

I always get easily confused when conferences have too many tracks going on. No, seriously. At first it gives you an illusion of choice but in the end you just realize that you missed most talks on the conference. In the end of the day you can never be sure if you have made all the right decisions when choosing one talk over another.

A fancy sticker I've got from the conference organizers. Self-irony is really one of the most valuable worldly skills :)

ScanAgile 2012 conference, which was held on 8th of March at Marina Congress Center in Helsinki, had three lecture tracks and one track reserved for workshops. Although the temptation to spend the beginning of the day playing Lego was very big, I decided to stick to the Human Touch track. It opened with a talk about complexity based approaches to project management by Dave Snowden, who has seriously challenged my English language skills. I got totally lost when Dave started to oppose “complex” to “complicated” and “effective” to “efficient”, which as I believed would mean pretty much the same thing regardless of the context.

The coffee break discussion on these things lead to The Quote of the Day by my friend Justus Karekallas, who explained to me the difference between something being complex or complicated with a philosophical statement: “Women are complex, so life is complicated.”

Luckily enough, Joseph Pelrine’s talk about Cynefin turned out to be a continuation of the topic, therefore many of these conceptual differences started to be much clearer.

According to Joseph Pelrine, agile is a good tool for making a transition from complex to complicated.

After lunch we decided to visit the Software Craftsmanship track, where Daniel Knott from Germany was giving an overview of automated mobile testing challenges and solutions. The automated mobile cloud testing (such as TestDroid Cloud, for example) seems to be something worth looking into, if you are dealing with mobile app development.

Next, back to the Human Touch track — Laura Snellman-Junna talking about “Mechanics of Empathy”. Generally an interesting psychological topic turned out to be even more exciting by following Dave Snowden’s twitter-criticism on almost every of Laura’s statements. However, one should definitely try to be aware of the effects of empathy on everyday life, regardless of the neuro-mechanical details behind it.

Laura used fragments from the Blade Runner movie, featuring the use of Voight-Kampff machine to detect androids based on their inability to feel empathy.

The rest of the conference was totally screwed up by one of the conference sponsor quests for getting the MacBook Air. We barely have seen The Unseen shown by Marko Taipale and the “aivobic” training by Reidar Wasenius was also left aside. And, sadly enough, we still didn’t manage to solve all the challenging puzzles. Anyhow, all the sponsors were generally very generous giving away tons of free after-party-drink tickets to sweeten the bitter pill of our failure.

This was not a bad conference all in all. Maybe it’s just me who visited one too many agile conferences last year and therefore did not find any exciting eye-opener talks on this years ScanAgile. But after all, it’s all about the community. Meeting new people, who are inspired by what they do cannot be underrated.

Does Construction metaphor harm Software Development?

For some time already I was thinking to myself, that construction metaphor, applied to software development field so frequently, doesn’t serve its best purpose. We design and build our software, and we even have Architects in our projects. You can often hear people referring to construction experience, saying “You wouldn’t start building your house from the roof, wouldn’t you?” or “How would you build a house without an architect?”

It seems to make a good sense to refer to Google, before writing your first blog post. Not at all surprising that my dumbest web search quickly ended up in me reading an article, criticizing the famous “Code Complete” book by Steve McConnell for exact same reason: Software Development isn’t like Construction.

To me the cornerstone difference is the building process. In construction, building means, roughly speaking, putting bricks together. Well, also digging the basement and assembling concrete panels together, but all that doesn’t really matter. What matters is, that this process takes a considerable amount of time and effort. And, having a wild assumption that the engineers did not screw up the blueprints, the building process is supposed to happen only once. That is when your house is actually complete -- when you have built it!

Now, what’s the analogy for this process in software development? I wouldn’t say that it is the actual coding. Because this is more similar to what construction engineers do -- design blueprints, according to which the physical thing is built. As I see it, the building process in construction corresponds to compilation and deployment processes in software development. That’s the thing your build script usually does, isn’t it? :) Your code together with the build scripts are your specs and blueprints, which make the actual building happen.

But there is one significant difference between building a house and building your software project. Compilation and deployment do not take as much time, as putting the bricks together on a construction site. It is very much automated and doesn’t take as much effort at all. And it’s repeatable. Building your software is so easy compared to construction, that you even do it frequently. Frankly, it’s the fastest way to verify, what exactly you just did. And hey, most likely your software is not complete after the build process.

In fact, I don’t even know when that point is exactly. When is your software complete? There’s always room for adding configurable and resizable windows to your software walls, and all kinds of other stuff. The smells you get from applying the construction metaphor to software development are something like:

• the famous “If it works, don’t touch it!” engineering principle;
• the widely used Feature Freeze concept.

Software Development is not like Construction. You deal with abstractions, not concrete blocks. You change your thinking and even the idea of the entire project during the time it’s being developed. The thing you actually build is Knowledge. Let’s just not drag thousands of years of construction experience into the software industry. Wild idea -- maybe it should happen vice-versa even? :)

.