Flyosity: Mac & iPhone Interface Design Blog by Mike Rundle

To make things easier:

- The more tools you know the more options you allow yourself in creating user interfaces.
- However, the great designers know how to show restraint with these tools.
- I think Lukas has a problem with people who know how to code everything and because they do figure it's okay to use everything which isn't the case. This is where many designers fails. They use something just because they can or think that it is cool. This is not design, this is picking crayons out of the box and just throwing colors on a page.

Thanks for helping me reach my quota on reading this week.

Great post, totally agree with you on this! Designers that create posters and book covers and such don't really have to know how the cover end up on the book, but for UI-designers that do web-related work, knowing how stuff works backstage is always a plus since it helps you pick the right tools and techniques for the right reasons. It also helps you as a designer b/c you know the potential problems that might develop with certain types of designs (as your example with the "Designer A hands HTML & CSS developer B a..." clearly shows).

Right on. I think the essential debate is where to draw that knowledge line: does a designer need to know how to program an operating system? Of course not. But I would expect a competent web designer to know CSS, because without that knowledge their designs are not taking advantage of the unique capabilities of the web. Knowing jquery adds another dimension to what they can do. Add SQL and they begin to grasp the overall structure of how their app will look and work. Conversely, your average print designer will not understand resizable pages or scrolling, let alone UI design. The best workflow will include designers who are knowledgeable in programming as well as programmers who understand the principles of design.

Excellent article. Well constructed, educational, and you stated your points in a clear concise manner.

Thank you for sharing this information.

(Note that I use interaction designer, user experience designer and designer pretty much interchangeably in this post; I'm talking about the person who designs what the programmer has to do, regardless of the specifics. Also note that I apologize for the long comment, perhaps I'll write a follow-up blog post. Finally note that I apologize for my original blog post; I will probably have to rewrite it as I don't think I make my point well and concise enough; discussing this with you has helped me come up with a clearer picture of what I actually intended to say :-)

I guess I should start out by reiterating the problems I see with interaction designers who know how to code.

First, if the interaction designers implements his own designs, he is beholden to two different goals: Clean code and great user interaction design. These two goals contradict each other. If you have to implement your own designs, you're bound to compromise for the sake of code quality, which is bad for your interaction design.

Second, if the interaction designer designs for a programmer, but knows about the code, he will make decisions too early. Instead of designing the best possible user experience and letting the programmer implement it, he will cut features which may have been possible, but which he did not know were possible (say, typographic decisions on web sites), and he will make decisions which are technically wrong (say, decide to use Ajax when all the data could have been loaded when the page was loaded).

In the first case, the user interaction designer is compromised because he has two contradicting goals. In the second case, he is compromised because he makes decisions which should have been made by the programmer, who has the full picture of the code base and better knowledge of the technology.

Thus my conclusion that interaction designers should not be forced to learn how to code, and that interaction designers who know how to code need to learn to put aside their knowledge and concentrate on the users when working on interaction design.

>As I pointed out in my next tweet, what Lukas said is actually
>not true — in many circumstances an Ajax request is literally
>faster to execute than a full page refresh.

I'm not sure how this contradicts what I said :-)

I did not say that an Ajax request was slower from the user's point of view, I said that it was harder to implement from a programmer's point of view. The end result of this is that people who do both interaction design and implementation have contradicting incentives: Do I want to implement the feature that is best for the user, or the feature that is easier to write and results in a cleaner code base?

From what you write, I'm going to guess that you mainly do user interaction design, and that somebody else writes the code. However, you also write that you "decide to use Ajax." How can you make that choice without knowing the code base and data layout? The user interaction designer's job is to define the user interaction - i.e. that something should change without a full page request. The programmers can then figure out whether they want to use Ajax, or a reloading iframe, or whether they can load all the necessary data when the page loads and simply switch out DOM elements as needed, or whether they have a different mechanism to implement your design.

And if they use Ajax, they can decide whether to let the server send XML, JSON, an HTML string or a plain old string. The user interaction designer should not tell the programmer to use Ajax, just as he should not tell him whether to use JSON. He should tell the programmer how the user interaction will play out, and the programmer should decide on the best possible technology.

Whether to use Ajax is simply not the interaction designer's job. The interaction designer's job is to design the interaction; the programmer's job is to find the perfect technology to implement that interaction.

In other words, your decision to use Ajax is a decision made without full knowledge of the consequences; precisely the thing you don't want to make.

A little knowledge is a dangerous thing; you can never make useful educated decisions when you only have half the picture. So let the people who have the full picture make the decisions.

>If they don't know HTML & CSS, then they're not really
>designing for the web because they're not designing for
>the constraints of the medium.

Which is a good thing. In my experience when working with (visual) designers, the people who know how HTML and CSS work will give me blocky designs which are easy to implement. I love that. But at the same time, I end up with average to good results.

The people who *don't* know how the web really works give me designs with drop shadows on complex backgrounds, round corners, interesting typography. And sometimes there's no way to implement this in a standards-compliant, efficient way (which is okay, because we can iterate). But more often than not, after a good night's sleep, I come with a solution for their ideas, and the end result is all the much better for it. This is when people end up with lush, awesome results; the friction between the designer and the programmer, the divergent goals which combine into the best possible solution.

Visual designers who know how the web works are constricted by that knowledge. They're easier to work with, of course, but in nine times out of ten, the end result is better if the designer did not give a rat's ass about what was possible, thus pushing the programmer to do things he did not think were possible.

>You also have to be knowledgeable about how an impaired
>person uses the web and how to make a drag-and-drop
>experience still usable for them. You have to know how
>to handle a situation where a user has Javascript turned
>off.

The interaction designer will design the user interaction for impaired people and for people who don't have JS enabled (which admittedly requires that the interaction designer has some rudimentary knowledge of which parts of his designs will not work without JS - if he does not have this knowledge, the programmer will explain which features will not work without JS). The programmer will figure out how to implement the designs in a way which is workable. If he can't, he will iterate with the interaction designer.

The interaction designer never has the full picture of the code base; code decisions (such as "we will use Ajax") made by the person who does the interaction design will never be as good as code decisions made by the person who writes the actual code.

Awesome post. While Scrivs may mock the length, it's all completely true; and you definitely said it better than I ever could.

Hi,this article is very useful,and it benefits me a lot.Thank you! Then I want share it with my parteners,may I have your permission to translate this article into a Chinese version?

>I thought more about our differences
>of opinion and I think it has a lot
>to do with the caliber people we've
>worked with on projects. (...) Nearly
>every designer I know is a CSS expert,
>and most of them are also very
>competent at writing Javascript.

So our differences may also be due to the fact that you've never really experienced how somebody who doesn't think in CSS and JavaScript will come up with fresh ideas, while people who are CSS and JS experts will tend to fall back to the same design archetypes ;-)

But I actually don't dispute your point. In fact, I agree that it is possible to overcome the inhibitions caused by knowledge of the code. Which is one of the two reasons why I wrote the essay: To get designers who know code to be conscious of the fact that knowing the code may influence their designs in a negative way.

I agree that the best designers won't have the issues I describe. However, 90% of all designers are not the best designers, which is the second reason why I wrote the article: If you take any designer and teach him to program, there's a chance that he may eventually become a better designer. But it's more likely that his new knowledge will hinder him, rather than help him, because only a small percentage of designers will become competent enough at programming to actually gain something from the knowledge.

So your article may apply to the top 10% of all designers, but I believe mine applies to the rest :-)

>I don't think you can be a world-class
>user experience designer without knowing
>how the full user experience works —
>which means how users interact with your
>interfaces, which means Javascript. How
>can you design interaction if you have
>no idea how it works?

But the code is not how interaction "works," the code is how interaction is *implemented.* The *human* is how interaction "works." A world-class user experience designer is probably neither mainly a programmer nor mainly a designer, but mainly a psychologist :-)

The user interaction's designer's job is to find the best possible user interaction (taking into account human psychology, the target audience's preexisting knowledge, target platform interface guidelines, the interaction design of similar applications, the results of usability tests and so on). The programmer's job is to implement this model using whatever technology best suits the requirements. The code is executed on the machine, but the interaction design is executed on a human. You can get the machine to do whatever you want, but the human has a mind of his own; you thus have to optimize for humans, not for machines.

Knowledge of CSS (as an example) won't help the interaction designer create a better interaction design (or at least I can't see any way it possibly could); it will merely push him towards making premature decisions based on his (probably even in the best case limited, compared to the programmer's) knowledge. For example, he may - consciously or unconsciously - discard designs because he believes that they can't be implemented in CSS.

If the interaction designer is both a world-class interaction designer as well as a world-class CSS coder, *and* if he is consciously aware of these two areas and does not let his knowledge of CSS prematurely influence his work on the interaction design, *then* the knowledge of CSS may be helpful. I just don't think such a combination of skills applies to very many people.

The next time you work on, say a visual design, ask yourself whether you made all of your choices because they were the best possible choices, or if you made them because you knew you could implement them in CSS.

As a self-proclaimed Designer&Developer this really hits home with me. I think the more knowledge you have about the entire process helps you understand application and web design better. But you have to use perspective, discretion, and wisdom any time you wear multiple hats.

I'll use a fairly complicated analogy to explain my position. In a basketball game, you've got a coach, a player, and a referee (who enforces the rules). They each have different viewpoints. The coach wants to execute a carefully planned strategy to win the game, the player wants to score as many points as possible to win the game, and the referee wants to make sure the game is played fair.

The coach stands for the interaction designer, the player is the developer, the referee is web browsers, and the rules of the game are web standards (or should be at least).

Now, all the perspectives are different, but one thing remains the same. In order to play the game, you have to understand all the rules and be able to work within those rules to be successful. Sometimes you bend the rules just a bit. Sometimes you go too far and break them and get called for a foul.

If you didn't have rules, you could be as "creative" and "innovative" as you want to achieve the desired result, winning the game. However, rules are applied in all phases of life, especially when it comes to designing and developing applications. You can never discount the value of knowing the "rules." They're what keep you and your designs honest.

I think having a deep knowledge and understanding of every part of the design process can only help. As long as you remember where the focus is: creating the best possible result for the end user. What are their goals and how can you help solve their problems through design?

LKM, it sounds like you have never worked with a world-class hybrid designer/developer. If you had, you would have never posted what you did.

The great web designers must possess a solid understanding of the technologies involved. I completely agree.

However, where I often run into the most problems with designers is when they have an understanding of coding and design and limit their designs because of this knowledge. Designers should always come to the table with options, knowing full well that some options may not be feasible. Too often I have seen designers artificially handicap the user experience because of a false belief that was not validated.

Understand that this problem is not just limited to designers nor is it only a problem when thinking about code. However, it is something to be considered and understood.

John
http://johnfmoore.wordpress.com

Touché!

Couldn't agree with you more Mike! Great article!

"From the comments on your blog entry where you said, essentially, that designers who think about the code while they're designing tend to produce blocky, inelegant designs says to me that you never worked with really talented folks — people who are fantastic designers and equally fantastic CSS and Javascript coders."

I think that this is a perfectly valid point. A great designer will understand that a website/app can provide a great experience and still have an aura of visual elegance about it. In fact, I would say, that the more subtle the elegance the better the user experience... but that's just my opinion.

Great article. Agree with you about user experiences and the accompanying knowledge that augments a designer's final product.

Thank you.

Thanks for this excellent article!

I believe the discussion between you and my namesake Lukas is showing two entirely different working styles in general.

Your approach (the one I symphatize with because it's my way of working) I'd call the "craftsman" or even "artist" approach. The motivation for that way of working lies in creating a piece as complete and finished as possible, and creating it with a deep knowledge of everthing that belongs to it, including the tools and the way they are used to form the final result of the work. A craftsman needs to be a generalist, and is eager to learn new skills and topics that help improve creating his or her piece.

This approach has it's clear limits - many projects are bigger or (more limiting) need to be completed in a shorter time frame than what a "craftsman" (or a small team with deep personal mutual understanding) can manage. So large projects needs to be broken down into specialised tasks, and these tasks assigned to efficient specialists. This is also a powerful approach, but requires clear separation and defined formal communication methods between the different specialist's expertises, as Lukas suggests. So the coders may not have authority to influence the UI design, and the UI designers shouldn't try to understand coding aspects.

I think that the "craftsman" approach has much better chance to create products that feel complete, simply because they are an expression of a real person's attitude to work, life, the universe and everything. Which of course also means that many of these products can feel completely wrong, if your attitude is different. However, I like nothing more than products that give that feeling of completeness, because they are an expression of someone working from an bare idea to reality, and make the product speak for the person.

I was just thinking about this topic myself. I've always more of a "technical" person. I felt this would hinder my ability very quickly. It's actually turned out to help me in many ways.

Artistic talent would be nice but I don't think it's necessary to become a web designer.

Hey - I just want to drop a thanks for this - nothing big just thanks.. Keep up the good work - hope to see next :)