Stack OverflowWhy is good UI design so hard for some Developers?
[+206] [65] Chris Ballance
[2009-02-05 00:54:16]
[ user-interface ]
[ ]

Some of us just have a hard time with the softer aspects of UI design (myself especially). Are "back-end coders" doomed to only design business logic and data layers? Is there something we can do to retrain our brain to be more effective at designing pleasing and useful presentation layers?

Colleagues have recommended a few books me including The Design of Sites, Don't make me think and Why Software sucks , but I am wondering what others have done to remove their deficiencies in this area?

(1) For myself (I suffer the same problem) I know a good UI when I use one. And I definitely know a UI that annoys me. But I have a very difficult time trying to design one myself. It's like the critical eye I have when I'm using someone else's UI doesn't work on my own designs. - JMD
(1) I hate the term "back-end coder" and was trying to keep it out of the title - Chris Ballance
(1) About books, go back to basic, 'The Design of Everyday Things' is probably the classic way to start grasping the actual goal in UI design ^^ - Oskar Duveborn
What makes you think there are people who don't suck at UI? Some people just aren't aware that they suck at it. ;) - jalf
This should be marked community wiki. - raven
In every developer lies a dormant graphic designer...just be careful not to wake them up! - thinkbeforecoding
(20) Graphic design != UI design. The former is about making things pretty. The latter is about making things useful and usable. - Esko Luontola
(2) +1 @Esko. Often 'pretty' means totally UN-usable. But the two CAN co-exist if handled with care and thought. - Dhaust
I can design good UIs, but i cannot design good websites. Your question should be rephrashed/another question opened asking how designers can improve their graphic/website design skills - Ali
(1) I don't even understand why you can ask a bounty on a discussion question, much less ask it. The very premise of the question is questionable. - Mark Rogers
(1) How in the world are you going to decide to award the bounty on a subjective question? - matt b
(12) Why is developing software so hard for UI designers? - Greg Hurlman
This is a great question. Many developers (including myself) probably ask themselves this :) - Aishwar
[+359] [2009-02-05 14:42:35] Thorsten79 [ACCEPTED]

Let me say it directly:

Improving on this does not begin with guidelines. It begins with reframing how you think about software.

Most hardcore developers have practically zero empathy with users of their software. They have no clue how users think, how users build models of software they use and how they use a computer in general.

It is a typical problem when an expert collides with a laymen: How on earth could a normal person be so dumb not to understand what the expert understood 10 years ago?

One of the first facts to acknowledge that is unbelievably difficult to grasp for almost all experienced developers is this:

Normal people have a vastly different concept of software than you have. They have no clue whatsoever of programming. None. Zero. And they don't even care. They don't even think they have to care. If you force them to, they will delete your program.

Now that's unbelievably harsh for a developer. He is proud of the software he produces. He loves every single feature. He can tell you exactly how the code behind it works. Maybe he even invented an unbelievable clever algorithm that made it work 50% faster than before.

And the user doesn't care.

What an idiot.

Many developers can't stand working with normal users. They get depressed by their non-existing knowledge of technology. And that's why most developers shy away and think users must be idiots.

They are not.

If a software developer buys a car, he expects it to run smoothly. He usually does not care about tire pressures, the mechanical fine-tuning that was important to make it run that way. Here he is not the expert. And if he buys a car that does not have the fine-tuning, he gives it back and buys one that does what he wants.

Many software developers like movies. Well-done movies that spark their imagination. But they are not experts in producing movies, in producing visual effects or in writing good movie scripts. Most nerds are very, very, very bad at acting because it is all about displaying complex emotions and little about analytics. If a developer watches a bad film, he just notices that it is bad as a whole. Nerds have even built up IMDB to collect information about good and bad movies so they know which ones to watch and which to avoid. But they are not experts in creating movies. If a movie is bad, they'll not go to the movies (or not download it from BitTorrent ;)

So it boils down to: Shunning normal users as an expert is ignorance. Because in those areas (and there are so many) where they are not experts, they expect the experts of other areas to have already thought about normal people who use their products or services.

What can you do to remedy it? The more hardcore you are as a programmer, the less open you will be to normal user thinking. It will be alien and clueless to you. You will think: I can't imagine how people could ever use a computer with this lack of knowledge. But they can. For every UI element, think about: Is it necessary? Does it fit to the concept a user has of my tool? How can I make him understand? Please read up on usability for this, there are many good books. It's a whole area of science, too.

Ah and before you say it, yes, I'm an Apple fan ;)

(8) Excellent comment! You've nailed one of the most fundamental hurdles in software design. A hard fact to swallow for hardened developers (like me), but the truth often is. - user34411
Your comment reminded me of someone I worked with that was always apologising for not knowing something or other about computers. Her basic computer skills were fine, but when we got into techie stuff it went over her head. In the end I pointed out... - Evan
...that this was my area of specialisation, and I would be totally useless trying to do her job, so stop apologising! - Evan
Find me one adult who doesn't know what the motor in a car does, or what the steering wheel does, or what seatbelts are for. - TraumaPony
(12) +1. I recommend reading "The Inmates are Running the Asylum", it goes into good detail about the differences in user/dev mindsets, as well as some remedies. - Richard Levasseur
(9) +1 To be honest, any developer that doesn't care about the user is a poor developer! - Gary Willoughby
(3) Damn I wish I could vote for this more than once. You.Are.Right. .FullStop - CAD bloke
+1 - Very well said. Apple obviously puts a lot of time into user experience. VERY important and often left out component of development. Computers & software on them are to make life easier, not trying to guess the programmer's brain. - Bill Martin
Seinfeld portrayed this very concept, except that it was Jerry's auto mechanic having the perspective deficit: The mechanic's ultimate solution to Jerry's cluelessness is hilarious. - Chris Noe
(7) Very valid points, and I think that this mentality is also part of the reason that a number of developer-run projects (e.g. open source or what-have-you) have come across as difficult to use -- by and large, most developers write for themselves as the user, not for the "real" end user. - Cloudy
(1) +1. Most developers will never care about users. It simply does not interest them. I like the empathy point. There is at least anedotal evidence that people with aspergers gravitate to programmer positions - Mitch Wheat
+1-Fantastic! I program and do UI. Hardcores need to be OPEN to users. My business is to transalate "geek speek to plain talk". In iRobot, Will Smith confused at womans job desc. she said, "I make the robots seem more human". He said, "Know wasn't that easier." She said "Not really". Ouch - SnapJag
(25) +1 This is THE reason Linux still isn't ready for the average user's desktop. - Bryan Anderson
+1: You hardcore usability nerds always think we should care about usability, when our primary goal is just to make cool algorithms. Shunning normal developers like that is just ignorance. - Alex Lyman
(1) @TraumaPony: The #1 thing about user interface design is to do it the same way everyone else has done it. Which is why it is easy for people to move from one car to another. Unfortunately, most devs just throw crap all over the UI without putting thought into how others are doing it. - NotMe
(1) The inclusion of stereotypes only distracts from the meaning and purpose in this answer. - Bernard Igiri
Man, you're answer for me could be a poem. Excellent thougth. - Nelson Miranda
(1) I greatly with the car analogy. Anybody who drives around with the oil light on for 2 months is an idiot and deserves to have their car break down. In the same way, I don't think it's all the fault of the developer when many users fail to grasp even the most basic concepts of computers. - Kibbee
(1) I think that if a person drives around with the oil light on for 2 months, it's a problem with the design of the oil light. - Breton
(2) i totally agree with all the points except for apple admiration. we are not "dumb" end-users after all, are we? :) - rpr
I must completely agree and completely disagree at the same time. Because although we are not script writers (in the sense of a movie script) or mechanics ... all developers are also users, so we sit on both sides of the fence. +1 for apple users :) - Nippysaurus
(1) the car example was the best comparison i ever read about UI design for developers - Chris
(2) +1 Same problem with API Design. Most developers design APIs having only themselves in mind, not the API's clients. This results in bloated, inconsistent, totally unusable APIs. - helpermethod
(2) I personally think that most programmers/hardcore tech people are not only not willing to step into the user's shoes, most are simply unable to. It's pretty hard to have a lot of knowledge on a subject (programming) and then look at a thing (a program) while not using all that knowledge you have. Compare it to a person who's been driving a car for years to suddenly be asked to start acting as if he didn't. - Niels Bom
I disagree - there are developers who care about users but can't get their minds thinking about designing great UIs. See Karl Fast's excellent answer - he actually addresses the point that good developers might find UI designing "hard". - AbdullahC
The car analogy and the comment about Linux later on totally reminded me of the car dealership analogy from "In The Beginning Was The Command Line" -- one of the best essays ever written. If you haven't read this essay, I'd highly recommend it. The section I'm talking about can be found here‌​/… (but read the whole thing if you haven't already) - Ben Lee
Re-reading it now, I came across the intro to the Linux analogy: "With one exception, that is: Linux, which is right next door, and which is not a business at all. It's a bunch of RVs, yurts, tepees, and geodesic domes set up in a field and organized by consensus.". My first thought was "Burning Man". - Ben Lee
I would like to suggest a good analogy here, web apps are like magic shows. UX/UI/Design people act as magicians, they are good at showmanship and in presenting the magic. On the other hand Engineers/"Backend People" act as scientists who are working it all out to make it happen. - Kapil
[+215] [2009-02-11 16:05:01] Karl Fast

UI design is hard

To the question:

why is UI design so hard for most developers?

Try asking the inverse question:

why is programming so hard for most UI designers?

Coding a UI and designing a UI require different skills and a different mindset. UI design is hard for most developers, not some developers, just as writing code is hard for most designers, not some designers.

Coding is hard. Design is hard too. Few people do both well. Good UI designers rarely write code. They may not even know how, yet they are still good designers. So why do good developers feel responsible for UI design?

Knowing more about UI design will make you a better developer, but that doesn't mean you should be responsible for UI design. The reverse is true for designers: knowing how to write code will make them better designers, but that doesn't mean they should be responsible for coding the UI.

How to get better at UI design

For developers wanting to get better at UI design I have 3 basic pieces of advice:

  1. Recognize design as a separate skill. Coding and design are separate but related. UI design is not a subset of coding. It requires a different mindset, knowledge base, and skill group. There are people out there who focus on UI design.
  2. Learn about design. At least a little bit. Try to learn a few of the design concepts and techniques from the long list below. If you are more ambitious, read some books, attend a conference, take a class, get a degree. There are lot of ways to learn about design. Joel Spolky's book on UI design [1] is a good primer for developers, but there's a lot more to it and that's where designers come into the picture.
  3. Work with designers. Good designers, if you can. People who do this work go by various titles. Today, the most common titles are User Experience Designer (UXD), Information Architect (IA), Interaction Designer(ID), and Usability Engineer. They think about design as much as you think about code. You can learn a lot from them, and they from you. Work with them however you can. Find people with these skills in your company. Maybe you need to hire someone. Or go to some conferences, attend webinars, and spend time in the UXD/IA/ID world.

Here are some specific things you can learn. Don't try to learn everything. If you knew everything below you could call yourself an interaction designer or an information architect. Start with things near the top of the list. Focus on specific concepts and skills. Then move down and branch out. If you really like this stuff, consider it as a career path. Many developers move into managements, but UX design is another option.

Why UI design is hard

Good UI design is hard because it involves 2 vastly different skills:

  • A deep understanding of the machine. People in this group worry about code first, people second. They have deep technological knowledge and skill. We call them developers, programmers, engineers, and so forth.
  • A deep understanding of people and design: People in this group worry about people first, code second. They have deep knowledge of how people interact with information, computers, and the world around them. We call them user experience designers, information architects, interaction designers, usability engineers, and so forth.

This is the essential difference between these 2 groups—between developers and designers:

  • Developers make it work. They implement the functionality on your TiVo, your iPhone, your favorite website, etc. They make sure it actually does what it is supposed to do. Their highest priority is making it work.
  • Designers make people love it. They figure out how to interact with it, how it should look, and how it should feel. They design the experience of using the application, the web site, the device. Their highest priority is making you fall in love with what developers make. This is what is meant by user experience, and it's not the same as brand experience.

Moreover, programming and design require different mindsets, not just different knowledge and different skills. Good UI design requires both mindsets, both knowledge bases, both skill groups. And it takes years to master either one.

Developers should expect to find UI design hard, just as UI designers should expect to find writing code hard.


(8) This is the best answer here. Great links BTW! - Bernard Igiri
Excellent overview of UI design! I've also observed your notion of different mindsets. I do both UI design and programming, and it's best that I concentrate on only one of them at a time. [...] - Esko Luontola
If you make UI design decisions while programming, you think that what is the simplest way to implement, which often leads to poor UI design. And if you think about implementation while doing UI design, you might choose UI design patterns which are easier to implement, but not as good for the user. - Esko Luontola
Excellent booklist, every developer should at least read 5 of the books you listed. - Murmelschlurmel
+1 for linking to "How to be a UX team of one" by Leah Buley. That is a phenomenal presentation! - Dubs
What a comprehensive list of links! This must have been a huge work to put all this together. Hats off, Sir! - Slauma
(2) Why isn't this marked as the best answer? It seems far better than Thorsten79's answer. - AbdullahC
(1) Wish I could favorite this answer directly. :) - Dan J
[+70] [2009-02-05 00:59:16] Kevin

What really helps me improve my design is to grab a fellow developer, one the QA guys, the PM, or anyone who happens to walk by and have them try out a particular widget or screen.

Its amazing what you will realize when you watch someone else use your software for the first time

I've tried this approach a lot and found it to be very effective. Occasionally I have a non-technical friend use it to see what causes them pain when trying to use it. - Chris Ballance
This is the same approach that I take. - Ed Swangren
Could this approach be called "usability testing" perchance? ;) Yes, it's the approach you should take prior, during and after. - Ates Goral
This would be almost my exact answer. QA and tech support are awesome. Developers suck at UI Design, iterate and have others test it out often. - Bill K
(7) I believe its called the "hallway usability test" - Kevin
I do that too. It's very effective and usually makes me cry, because in 2s I have to scrap some feature I spent a few days perfecting thinking that it would immensely enhance the page when in fact it is just plain wrong for the user... - yu_ominae
[+32] [2009-02-05 01:05:53] Jacob Mattison

Ultimately, it's really about empathy -- can you put yourself in the shoes of your user?

One thing that helps, of course, is "eating your own dogfood" -- using your applications as a real user yourself, and seeing what's annoying.

Another good idea is to find a way to watch a real user using your application, which may be as complicated as a usability lab with one-way mirrors, screen video capture, video cameras on the users, etc., or can be as simple as paper prototyping using the next person who happens to walk down the hall.

If all else fails, remember that it's almost always better for the UI to be too simple than too complicated. It's very very easy to say "oh, I know how to solve that, I'll just add a checkbox so the user can decide which mode they prefer". Soon your UI is too complicated. Pick a default mode and make the preference setting an advanced configuration option. Or just leave it out.

If you read a lot about design you can easily get hung up on dropped shadows and rounded corners and so forth. That's not the important stuff. Simplicity and discoverability are the important stuff.

well put. Most often, attempts to add flexibility just result in clutter. Simpler == better. - SquareCog
Can you put yourself in the shoes of your user if they are on the other side of the planet, in a culture you've never experienced before? Internationalization is a major consideration in solid UI design. Lets not assume that everyone lives in the USA. - user34411
Absolutely; my current project is in fact targeted at users all over the planet (basically in every country other than the US, where I am). It makes empathy harder, no question -- and all the more important to attempt it seriously and vigorously. - Jacob Mattison
Also, I'd add that the vast majority of usability problems are shockingly obvious once you get a real user to look at it. Yes, there will be subtle ones that are culture-specific, but you can make tremendous improvements using the next guy walking down the hall. - Jacob Mattison
+1, only because I can't +100 myself! I'll add that gaining experience using vastly different applications as they were intended helps you grow as a UI developer. Only using tools like Visual Studio or other dev tools will hamper this ability... - BQ.
I've found that past experience with things as diverse as Photoshop, some 3D design packages, AutoCAD, MS Office, and even various point-of-sale order entry applications helps me immensely building and maintaining empathy for users of software I'm developing. Notice how each has it's own paradigm. - BQ.
[+26] [2009-02-05 14:49:40] Vlad Gudim

Contrary to popular myth there are literally no soft aspects in UI design, at least no more than needed to design a good back end.

Consider the following; good back end design is based upon fairly solid principles and elements any good developer is familiar with:

  • low coupling

  • high cohesion

  • architectural patterns

  • industry best practices

  • etc

Good back end design is usually born through a number of interactions, where based on the measurable feedback obtained during tests or actual use the initial blueprint is gradually improved. Sometimes you need to prototype smaller aspects of back end and trial them in isolation etc.

Good UI design is based on the sound principles of:

  • visibility

  • affordance

  • feedback

  • tolerance

  • simplicity

  • consistency

  • structure

UI is also born through test and trial, through iterations but not with compiler + automated test suit, but people. Similarly to back end there are industry best practises, measurement and evaluation techniques, ways to think of UI and set goals in terms of user model, system image, designer model, structural model, functional model etc.

The skill set needed for designing UI is quite different from designing back-end and hence don’t expect to be able to do good UI without doing some learning first. However that both these activities have in common is the process of design. I believe that anyone who can design good software is capable of designing good UI as long as they spend some time learning how.

I recommend taking a course in Human Computer Interaction, check MIT and Yale site for example for online materials:

Structural vs Functional Model in Understanding and Usage

The excellent earlier post by Thorsten79 [2] brings up the topic of software development experts vs users and how their understanding of software differ. Human learning experts distinguish between functional and structural mental models. Finding way to your friend's house can be an excellent example of the difference between the two:

  • First approach includes a set of detailed instructions: take the first exit of the motorway, then after 100 yards turn left etc. This is an example of functional model: list of concrete steps necessary to achieve a certain goal. Functional models are easy to use, they do not require much thinking just a straight forward execution. Obviously there is a penalty for the simplicity: it might not be the most efficient route and any any exceptional situation (i.e. a traffic diversion) can easilly lead to a complete failure.

  • A different way to cope with the task is to build a structural mental model. In our example that would be a map that conveyes a lot of information about the internal structure of the "task object". From understanding the map and relative locations of our and friend's house we can deduct the functional model (the route). Obviously it's requires more effort, but much more reliable way of completing the task in spite of the possible deviations.

The choice between conveying functional or structural model through UI (for example, wizard vs advanced mode) is not that straight forward as it might seem from Thorsten79's post. Advanced and frequent users might well prefer the structural model, whereas occassional or less expirienced users — functional.

Google maps is a great example: they include both functional and structural model, so do many sat navs.

Another dimension of the problem is that the structural model presented through UI must not map to the structure of software, but rather naturally map to structure of the user task at hand or task object involved.

The difficulty here is that many developers will have a good structural model of their software internals, but only functional model of the user task the software aims to assist at. To build good UI one needs to understand the task/task object structure and map UI to that structure.

Anyway, I still can't recommend taking a formal HCI course strongly enough. There's a lot of stuff involved such as heuristics [3], principles derived from Gestalt phychology [4], ways humans learn etc.


+1 for the MIT OCW link :) Those lectures notes are invaluable - Debajit
You're right, users can become experts of a software themselves, and they like it when somebody carved a way for them through the "nice" UI to be faster. That's where all the key shortcuts are for, for example. usability is a very interesting subject! - Thorsten79
[+25] [2009-02-07 18:53:55] Hoffmann

I suggest you start by doing all your UI in the same way as you are doing now, with no focus on usability and stuff.

alt text [1]

Now think of this:

A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away. — Saint-Exupéry

And apply this in your design.


This is why I far, far prefer Office 2007! - Richard Ev
If someone is wondering from which grave I dug that quote, I heard it from civilization 4. Great game. I have no idea who the author is, but he sure as hell could write a better UI than the designers from word. - Hoffmann
There's another similar good quote from A. Einstein: "Make everything as simple as possible, but not simpler." I've found these ideas also applicable to UI design: ...and +1 - Pyry Jahkola
Saint-Exupery was much more than a pilot and aircraft designer; +1 for quoting him. His children's book ("The Little Prince") is well worth reading, but I'm getting off-topic here. - David Thornley
This is why the ribbon UI is better, unfortunately too many are already used to the this terrible pattern. The younger generation however, remains unspoiled. They can still be spared. - Bernard Igiri
You like that quote? Up vote this:… (its wiki, so I don't 'profit' from this...) - Aardvark
I'd say the solution to this problem is the same as with any programming problem; Just throw more hardware at the it. In this case, buy a bigger monitor :-) - Tom Lokhorst
(5) You should've selected the print view...can't see the rulers now. - Mussnoon
Thus the creation of the Ribbon UI. :) - netrox
[+16] [2009-02-05 01:05:20] thursdaysgeek

A lot of developers think that because they can write code, they can do it all. Designing an interface is a completely different skill, and it was not taught at all when I attended college. It's not just something that just comes naturally.

Another good book is The Design of Everyday Things [1] by Donald Norman.


Thanks, "The Design of Everyday Thinks" is on my Amazon WishList - Chris Ballance
+1. "The Design of everyday things" is also on the Coding Horror list of recommended reading (good list of books for developers). Recently finished reading it, and can also highly recommend it. - Mun
I'm reading "The Design of Everyday things" at the moment - it's certainly very good, but as mentioned in comments on another answer, Alan Cooper's "The Inmates are running the Asylum" addresses exactly this topic. As a developer, the book was "life changing"! - Stuart Helwig
My peeve: a lot of developers (and designers, and others) think that because I can code, I can't design the user interface. I don't know Photoshop very well, but I think I have a good eye for what works and what doesn't. (The Design of Everyday things was my first UI bible.) - Barry Brown
[+14] [2009-02-05 02:23:25] Uri

There's a huge difference between design and aesthetics, and they are often confused.

A beautiful UI requires artistic or at least aesthetic skills that many, including myself, are incapable of producing. Unfortunately, it is not enough and does not make the UI usable, as we can see in many heavyweight flash-based APIs.

Producing usable UIs requires an understanding of how humans interact with computers, some issues in psychology (e.g., Fitt's law, Hick's law), and other topics. Very few CS programs train for this. Very few developers that I know will pick a user-testing book over a JUnit book, etc.

Many of us are also "core programmers", tending to think of UIs as the facade rather than as a factor that could make or break the success of our project.

In addition, most UI development experience is extremely frustrating. We can either use toy GUI builders like old VB and have to deal with ugly glue code, or we use APIs that frustrate us to no end, like trying to sort out layouts in Swing.

"We can either use toy GUI builders like old VB and have to deal with ugly glue code, or we use APIs that frustrate us to no end, like trying to sort out layouts in Swing." You really boiled down my experiences with GUI building. If I may add: "or crazy DOM and CSS combination" - Hoffmann
I'm sure everyone is familiar with Totally Gridbag? "" - Uri
[+12] [2009-02-05 15:22:53] David Thornley

Go over to Slashdot, and read the comments on any article dealing with Apple. You'll find a large number of people talking about how Apple products are nothing special, and ascribing the success of the iPod and iPhone to people trying to be trendy or hip. They will typically go through feature lists, and point out that they do nothing earlier MP3 players or smart phones didn't do.

Then there are people who like the iPod and iPhone because they do what the users want simply and easily, without reference to manuals. The interfaces are about as intuitive as interfaces get, memorable, and discoverable. I'm not as fond of the UI on MacOSX as I was on earlier versions, I think they've given up some usefulness in favor of glitz, but the iPod and iPhone are examples of superb design.

If you are in the first camp, you don't think the way the average person does, and therefore you are likely to make bad user interfaces because you can't tell them from good ones. This doesn't mean you're hopeless, but rather that you have to explicitly learn good interface design principles, and how to recognize a good UI (much as somebody with Asperger's might need to learn social skills explicitly). Obviously, just having a sense of a good UI doesn't mean you can make one; my appreciation for literature, for example, doesn't seem to extend to the ability (currently) to write publishable stories.

So, try to develop a sense for good UI design. This extends to more than just software. Don Norman's "The Design of Everyday Things" is a classic, and there's other books out there. Get examples of successful UI designs, and play with them enough to get a feel for the difference. Recognize that you may be having to learn a new way of thinking abou things, and enjoy it.

+1 for suggestion The Design of Everyday Things - Oskar Duveborn
+1 for a very good answer. I think it's telling that you are still hovering at 1 up-vote (now 2); those that fit your description will probably not think they do, or simply dismiss the very idea :-( - mghie
This is a blanket statement. Not every anti-Apple comment on Slashdot is a criticism of its UI, or verification of a lack of UI understanding. Apple has good UI and so do many of their competitors. - Bernard Igiri
Another thought: an Apple isn't for everyone; for example, it doesn't provide the phenomenal awesome power that a CLI does. - J. Polfer
Almost the first thing I did with my new MacOSX machine was move the Terminal program to the Dock. It made it easy to run it like a Unix machine should be run. Anyway, I wasn't referring to all anti-Apple remarks, but a certain specific group. - David Thornley
(2) I personally find Apple products to be extremely unintuitive to use. I imagine I am not the only person who was frustrated when their first iPod would start shuffling songs every time I started jogging, or why the iPhone screen is continually inverting itself. I think things should only occur from direct, unambiguous user actions. - Lotus Notes
[+10] [2009-02-05 00:57:31] James B

The main rule of thumb I hold to, is never try to do both at once. If I'm working on back-end code, I'll finish up doing that, take a break, and return with my UI hat on. If you try to work it in whilst you're doing code, you'll approach it with the wrong mindset, and end up with some horrible interfaces as a result.

I think it's definitely possible to be both a good back-end developer and a good UI designer, you just have to work at it, do some reading and research on the topic (everything from Miller's #7, to Nielsen's archives), and make sure you understand why UI design is of the utmost importance.

I don't think it's a case of needing to be creative but rather, like back-end development, it is a very methodical, very structured thing that needs to be learned. It's people getting 'creative' with UIs that creates some of the biggest usability monstrosities... I mean, take a look at 100% Flash websites, for a start...

Edit: Krug's book is really good... do take a read of it, especially if you're going to be designing for the Web.

and what is the title of this krug's book - defau1t
@refhat It was prominently linked in the top post, so I didn't link it at the time, but it's this one: - James B
[+8] [2010-06-15 05:10:50] george kyaw naing

There are many reasons for this.

(1) Developer fails to see things from the point of view of the user. This is the usual suspect: lack of empathy. But it is not usually true since developers are not as alien as people make them out to be.

(2) Another, more common reason is that the developer being so close to his own stuff, having stayed with his stuff for so long, fails to realize that his stuff may not be so familiar(a term better than intuitive) to other people.

(3) Still another reason is the developer lacks techniques.

MY BIG CLAIM: read any UI, human interection design, prototyping book. e.g. Designing the Obvious: A Common Sense Approach to Web Application Design, Don't Make Me Think: A Common Sense Approach to Web Usability, Designing the moment, whatever.

How do they discuss task flows? How do they describe decision points? That is, in any use case, there are at least 3 paths: success, failure/exception, alternative.

Thus, from point A, you can go to A.1, A.2, A.3. From point A.1, you can get to A.1.1, A.1.2, A.1.3, and so on.

How do they show such drill-down task flow? They don't. They just gloss over it.

Since even UI experst don't have a technique, developers have no chance. He thinks it is clear in his head. But it is not even clear on paper, let alone clear in software implementation.

I have to use my own hand-made techniques for this.

[+7] [2009-02-05 00:58:21] Edwin Jarvis

I try to keep in touch with design-specific websites and texts. I found also the excellent Robin Williams book The Non-Designer's Design Book [1] to be very interesting in these studies.

I believe that design and usability is a very important part of software engineering and we should learn it more and stop giving excuses that we are not supposed to do design.

Everyone can be a designer once in a while, as also everyone can be a programmer.


I don't agree that everyone can be a programmer. Some aspects of the trade cannot be taught, you can either hack it or you can't (no pun intended.) - Chris Ballance
(2) I mean, once in a while, that doesn't mean that the guy will be a good programmer or will be it forever. - Edwin Jarvis
[+7] [2009-02-05 01:28:34] Rex M

When approaching UI design, here are a few of the things I keep in mind throughout (by far not a complete list):

  • Communicating a model. The UI is a narrative that explains a mental model to the user. This model may be a business object, a set of relationships, what have you. The visual prominence, spatial placement, and workflow ordering all play a part in communicating this model to the user. For example, a certain kind of list vs another implies different things, as well as the relationship of what's in the list to the rest of the model. In general I find it best to make sure only one model is communicated at a time. Programmers frequently try to communicate more than one model, or parts of several, in the same UI space.

  • Consistency. Re-using popular UI metaphors helps a lot. Internal consistency is also very important.

  • Grouping of tasks. Users should not have to move the mouse all the way across the screen to verify or complete a related sequence of commands. Modal dialogs and flyout-menus can be especially bad in this area.

  • Knowing your audience. If your users will be doing the same activities over and over, they will quickly become power users at those tasks and be frustrated by attempts to lower the initial entry barrier. If your users do many different kinds of activities infrequently, it's best to ensure the UI holds their hand the whole time.

You bring out a good point with Knowing your audience ... I also like "You are not your user" (Platt) and "Know thy user."(Platt) This cannot be emphasized enough - Chris Ballance
[+7] [2009-02-07 18:11:22] Marco Luglio

Read Apple Human Interface Guidelines [1].


You mean the guidelines that Apple themselves no longer follow? - Gregor Brandt
"They're more like guidelines anyway" ^_^ - Marco Luglio
[+5] [2009-02-05 02:24:19] user34411

I find the best tool in UI design is to watch a first-time User attempt to use the software. Take loads of notes and ask them some questions. Never direct them or attempt to explain how the software works. This is the job of the UI (and well written documentation).

We consistently adopt this approach in all projects. It is always fascinating to watch a User deal with software in a manner that you never considered before.

Why is UI design so hard? Well generally because the Developer and User never meet.

Absolutely agreed, but it's quite possible for a developer to apply solid basic UI principles. - nailitdown
Solid Basic UI principles do not work in every country. We deploy software in many regions and there is a vast difference in UI design for different parts of the globe. Try sending your US-centric app to China sometime... - user34411
[+5] [2009-02-05 03:02:32] nailitdown

duffymo just reminded me why: Many Programmers think "*Design" == "Art".

Good UI design is absolutely not artistic. It follows solid principles, that can be backed up with data if you've got the time to do the research.

I think all programmers need to do is take the time to learn the principles. I think it's in our nature to apply best practice whenever we can, be it in code or in layout. All we need to do is make ourselves aware of what the best practices are for this aspect of our job.

I think that you can't discount aesthetics completely. Perhaps an ugly UI can be just as useable as a pretty one, but that isn't all that a UI is for. After all, the UI is the face of your program, much like a book's cover: people are much more likely to pick up a program with a pretty UI. - Tikhon Jelvis
Absolutely, aesthetics are important, but that's Graphic Design, not UI design. - nailitdown
[+5] [2009-02-06 04:12:37] Dhaust

What have I done to become better at UI design?
Pay attention to it!

It's like how ever time you see a chart on the news or an electronic bus sign and you wonder 'How did they get that data? Did they do that with raw sql or are they using LINQ?' (or insert your own common geek curiosity here).

You need to start doing that but with visual elements of all kinds.

But just like learning a new language, if you don't really throw yourself into it, you won't ever learn it.

Taken from another answer [1] I wrote:

Learn to look, really look, at the world around you. Why do I like that UI but hate this one? Why is it so hard to find the noodle dishes in this restaurant menu? Wow, I knew what that sign meant before I even read the words. Why was that? How come that book cover looks so wrong? Learn to take the time to think about why you react the way you do to visual elements of all kinds, and then apply this to your work.


+1 for the zen advice on learning to look, and think. Very few people question what meets the eye. - Debajit
[+5] [2010-07-15 19:51:43] exoboy

However you do it (and there are some great points above), it really helped me once I accepted that there is NO SUCH THING AS INTUITIVE....

I can hear the arguments rumbling on the horizon... so let me explain a little.

Intuitive: using what one feels to be right or true based on an unconscious method or feeling.

If (as Carl Sagan postulated) you accept that you cannot comprehend things that are absolutely unlike anything you have ever encountered then how could you possibly "know" how to use something if you have never used anything remotely like it?

Think about it: kids try to open doors not because they "know" how a doorknob works, but because they have seen someone else do it... often they turn the knob in the wrong direction, or pull too soon. They have to LEARN how a doorknob works. This knowledge then gets applied in different but similar instances: opening a window, opening a drawer, opening almost anything big with a big, knob-looking handle.

Even simple things that seem intuitive to us will not be intuitive at all to people from other cultures. If someone held their arm out in front of them and waived their hand up-and-down at the wrist while keeping the arm still.... are they waiving you away? Probably, unless you are in Japan. There, this hand signal can mean "come here". So who is right? Both, of course, in their own context. But if you travel to both, you need to know both... UI design.

I try to find the things that are already "familiar" to the potential users of my project and then build the UI around them: user-centric design.

Take a look at Apple's iPhone. Even if you hate it, you have to respect the amount of thought that went into it. Is it perfect? Of course not. Over time an object's perceived "intuitiveness" can grow or even fade away completely.

For example. Most everyone knows that a strip of black with two rows of holes along the top and bottom looks like a film strip... or do they?

Ask your average 9 or 10 year old what they think it is. You may be surprised how many kids right now will have a hard time identifying it as a film strip, even though it is something that is still used to represent Hollywood, or anything film (movie) related. Most movies for the past 20 years have been digitally shot. And when was the last time any of us held a piece of film of ANY kind, photos or film?

So, what it all boils down to for me is: Know your audience and constantly research to keep up with trends and changes in things that are "intuitive", target your main users and try not to do things that punish the inexperienced in favor of the advanced users or slow down the advanced users in order to hand-hold the novices.

Ultimately, every program will require a certain amount of training on the user's part to use it. How much training and for which level of user is part of the decisions that need to be made.

Some things are more or less familiar based on your target user's past experience level as a human being, or computer user, or student, or whatever.

I just shoot for the fattest part of the bell curve and try to get as many people as I can but realizing that I will never please everyone....

[+4] [2009-02-05 02:54:35] David Anderson

I know that Microsoft is rather inconsistent with their own guidelines, but I have found that reading their Windows design guidelines have really helped me. I have a copy on my website here [1], just scroll down a little the the Vista UX Guide. It has helped me with things such as colors, spacing, layouts, and more.


+1 reading the platform's design guidelines is definitely something one should do (and discover how often Microsoft breaks their own rules ;) - Oskar Duveborn
And in addition read the Apple ones (Human Interface Guidelines). They have more basics and principles in them. That makes you understand what should be universal and what is platform specific - Stephan Eggermont
And while you are at it, read the GNOME HIG as well. Between those three it starts to become visible what is just a specific thing of a single platform, and what seems to be a good idea in general. - mghie
Most of these are based on IBMs, but that is pretty out of date now. For example, the standard cut and paste commands were Shift+Del and Shift+Ins (they still work, btw). - Simon Buchan
[+4] [2009-02-05 14:34:49] Michael Borgwardt

I believe the main problem has nothing to do with different talents or skillsets. The main problem is that as a developer, you know too much about what the application does and how it does it, and you automatically design your UI from the point of view of someone who has that knowledge.

Whereas a user typically starts out knowing absolutely nothing about the application and should never need to learn anything about its inner workings.

It is very hard, almost impossible, to not use knowledge that you have - and that's why an UI should not be designed by someone who's developing the app behind it.

[+4] [2009-02-05 20:14:33] MSN

"Designing from both sides of the screen" presents a very simple but profound reason as to why programmers find UI design hard: programmers are trained to think in terms of edge cases while UI designers are trained to think in terms of common cases or usage.

So going from one world to the other is certainly difficult if the default traning in either is the exact opposite of the other.

[+3] [2009-02-07 18:38:04] jwendl

To say that programms suck at UI design is to miss the point. The point of the problem is that the formal training that most developers get go indepth with the technology. Human - Computer Interaction is not a simple topic. It is not something that I can "mind-meld" to you by providing a simple one line statement that makes you realize "oh the users will use this application more effectively if I do x instead of y."

This is because there is one part of UI design that you are missing. The human brain. In order to understand how to design a UI, you have to understand how the human mind interacts with machinery. There is an excellent course I took at the University of Minnesota on this topic taught by a professor of Psychology. It is named "Human - Machine Interaction". This describes many of the reasons of why UI design is so complicated.

Since Psychology is based on Correlations and not Causality you can never prove that a method of UI design will always work in any given situation. You can correlate that many users will find a particular UI design appealing or efficient, but you cannot prove that it will always generalize.

Additionally, there are two parts to UI design that many people seem to miss. There is the aesthetical appeal, and the functional workflow. If you go for a 100% aesthetical appeal, sure people will but your product. I highly doubt that aesthetics will ever reduce user frustration though.

There are several good books on this topic and course to take (like Bill Buxton's Sketching User Experiences [1], and Cognition in the Wild [2] by Edwin Hutchins). There are graduate programs on Human - Computer Interaction at many universities.

The overall answer to this question though lies in how individuals are taught computer science. It is all math based, logic based and not based on the user experience. To get that, you need more than a generic 4 year computer science degree (unless your 4 year computer science degree had a minor in psychology and was emphasized in Human - Computer Interaction).


I disagree: computers are math and logic based, by their nature. Any teaching of computer programming must be math and logic based. - Paul Nathan
(1) Yes, you are right Paul. Computers are math and logic. UI design involves a human element though, which has proven in history to be far less math and logic based. - jwendl
It's not so much that they are less math and logic based, it's that the math and logic behind them is much more complex, mostly beyond anyone today. That said, I bet good UI designs are all, to some extent, based on geometry. - Tikhon Jelvis
[+2] [2009-02-05 20:15:27] Sean Taylor

You mentioned the Don't make me think [1] book. I highly recommend reading this.


[+2] [2009-02-07 19:04:18] igouy

Let's turn your question around -

Are "ui designers" doomed to only design information architecture and presentation layers? Is there something they can do to retrain their brains to be more effective at designing pleasing and efficient system layers?

Seems like them "ui designers" would have to take a completely different perspective - they'd have to look from the inside of the box outwards; instead of looking in from outside the box.

Alan Cooper's "The Inmates are Running the Asylum" [1] opinion is that we can't successfully take both perspectives - we can learn to wear one hat well but we can't just switch hats.


[+2] [2009-02-10 23:30:52] Gregor Brandt

I think its because a good UI is not logical. A good UI is intuitive.

Software developers typically do bad on 'intuitive'

Excellent point, requires the other side of the brain - Chris Ballance
There's no such thing as intuitive for UI. There is similar to what I already know, but that is somewhat different. - Stephan Eggermont
Nothing is "intuitive" everything is learned. Intuitive is a word thrown around by business people to make programmers sweat. - Bernard Igiri
spoken like a true programmer....and that then is the root of the issue. - Gregor Brandt
@gbrandt Intuitive is some combination "familiar" and "simple". It's still a goal to strive for though. The hard thing about usability is that what is intuitive to some is not necessarily intuitive for others. @Stephan is right that "intuitive" is not some hard "fact", it's relative to the user. - TM.
[+2] [2009-02-10 23:54:42] chaos

A useful framing is to actively consider what you're doing as designing a process of communication. In a very real sense, your interface is a language that the user must use to tell the computer what to do. This leads to considering a number of points:

  1. Does the user already speak this language? Using a highly idiosyncratic interface is like communicating in a language you've never spoken before. So if your interface must be idiosyncratic at all, it had best introduce itself with the simplest of terms and few distractions. On the other hand, if your interface uses idioms that the user is accustomed to, they'll gain confidence from the start.
  2. The enemy of communication is noise. Auditory noise interferes with spoken communication; visual noise interferes with visual communication. The more noise you can cut out of your interface, the easier communicating with it will be.
  3. As in human conversation, it's often not what you say, it's how you say it. The way most software communicates is rude to a degree that would get it punched in the face if it were a person. How would you feel if you asked someone a question and they sat there and stared at you for several minutes, refusing to respond in any other way, before answering? Many interface elements, like progress bars and automatic focus selection, have the fundamental function of politeness. Ask yourself how you can make the user's day a little more pleasant.

Really, it's somewhat hard to determine what programmers think of interface interaction as being, other than a process of communication, but maybe the problem is that it doesn't get thought of as being anything at all.

[+2] [2009-02-11 10:42:03] Mihai Nita

There are a lot o good comments already, so I am not sure there is much I can add. But still...

  • Why would a developer expect to be able to design good UI?
  • How much training did he had in that field?
  • How many books did he read?
  • How many things did he designed over how many years?
  • Did he had the opportunity to see the reaction of it's users?

We don't expect that a random "Joe the plumber" to be able to write good code. So why would we expect the random "Joe the programmer" to design good UI?

Empathy helps. Separating the UI design and the programming helps. Usability testing helps.

But UI design is a craft that has to be learned, and practiced, like any other.

Exactly what I was thinking, How does "developer" relate to "User Interface Designer"?? - Jorge Córdoba
@Jorge here's now it relates: a lot of developers have to design UIs for their employers, even if they aren't designers. At my company, we don't have ANY artists. Our apps don't look too bad. In this case, you've got to have group reviews and stuff to make sure the design is nice. - TM.
@TM: Design is not necessarily UI/UX Design. Sure it might look good but that doesn't mean it works good. - Kevin Peno
[+2] [2009-02-11 18:19:37] alchemical

I think they are very different skill-sets. Good designers know about human behaviour, the psychology of colors and fonts, etc. I think it's like trying to be a marketing person and a developer at the same time. Very challenging but not necessarily impossible.

I'd try to find some UI experts and see what their study recommendations would be. Unless you are designing something very minimalist like google, if it is a significant project it is probably best to hire someone who has studied the art of UI as their main thing.

That said, if you are designing a very practical app, I think you could try to focus on simplicity and clarity in the interface -- I think this is at least half the key to google's success (and stack-overflow) -- i.e. it is intuitive and a pleasure to use.

[+2] [2009-02-11 20:00:20] MattBelanger

Developers are not (necessarily) good at UI design for the same reason they aren't (necessarily) good at knitting; it's hard, it takes practice, and it doesn't hurt to have someone show you how in the first place.

Most developers (me included) started "designing" UIs because it was a necessary part of writing software. Until a developer puts in the effort to get good at it, s/he won't be.

[+2] [2009-02-11 20:04:20] Rob Wells

To improve just look around at existing sites. In addition to the books already suggested, you might like to have a look at Robin Williams's excellent book "The Non-designers Design Book" ( sanitised Amazon link [1])

Have a look at what's possible in visual design by taking a look at the various submissions over at The Zen Garden [2] as well.

UI design is definitely an art though, like pointers in C, some people get it and some people don't.

But at least we can have a chuckle at their attempts [3]. BTW Thanks OK/Cancel for a funny comic and thanks Joel for putting it in your book "The Best Software Writing I" ( sanitised Amazon link [4]).


[+2] [2009-02-12 03:29:42] Breton

User interface isn't something that can be applied after the fact, like a thin coat of paint. It is something that needs to be there at the start, and based on real research. There's tons of Usability research available of course. It needs to not just be there at the start, it needs to form the core of the very reason you're making the software in the first place: There's some gap in the world out there, some problem, and it needs to be made more usable and more efficient.

Software is not there for its own sake. The reason for a peice of software to exist is FOR PEOPLE. It's absolutely ludicrous to even try to come up with an idea for a new peice of software, without understanding why anyone would need it. Yet this happens all the time.

Before a single line of code is written, you should go through paper versions of the interface, and test it on real people. This is kind of weird and silly, it works best with kids, and someone entertaining acting as "the computer".

The interface needs to take advantage of our natural cognitive facilities. How would a caveman use your program? For instance, we've evolved to be really good at tracking moving objects. That's why interfaces that use physics simulations, like the iphone, work better than interfaces where changes occur instantaneously.

We are good at certain kinds of abstraction, but not others. As programmers, we're trained to do mental gymnastics and backflips to understand some of the weirdest abstractions. For instance, we understand that a sequence of arcane text can represent and be translated into a pattern of electromagnetic state on a metal platter, which when encountered by a carefully designed device, leads to a sequence of invisible events that occur at lightspeed on an electronic circuit, and these events can be directed to produce a useful outcome. This is an incredibly unnatural thing to have to understand. Understand that while it's got a perfectly rational explanation to us, to the outside world, it looks like we're writing incomprehensible incantations to summon invisible sentient spirits to do our bidding.

The sorts of abstractions that normal humans understand are things like maps, diagrams, and symbols. Beware of symbols, because symbols are a very fragile human concept that take conscious mental effort to decode, until the symbol is learned.

The trick with symbols is that there has to be a clear relationship between the symbol, and the thing it represents. The thing it represents either has to be a noun, in which case the symbol should look VERY MUCH like the thing it represents. If a symbol is representing a more abstract concept, that has to be explained IN ADVANCE. See the inscrutable unlabled icons in msword's, or photoshop's toolbar, and the abstract concepts they represent. It has to be LEARNED that the crop tool icon in photoshop means CROP TOOL. it has to be understood what CROP even means. These are prerequisites to correctly using that software. Which brings up an important point, beware of ASSUMED knowledge.

We only gain the ability to understand maps around the age of 4. I think I read somewhere once that chimpanzees gain the ability to understand maps around the age of 6 or 7.

The reason that guis have been so successful to begin with, is that they changed a landscape of mostly textual interfaces to computers, to something that mapped the computer concepts to something that resembled a physical place. Where guis fail in terms of usability, is where they stop resembling something you'd see in real life. There are invisible, unpredictable, incomprehensible things that happen in a computer that bare no resemblance to anything you'd ever see in the physical world. Some of this is necessary, since there'd be no point in just making a reality simulator- The idea is to save work, so there has to be a bit of magic. But that magic has to make sense, and be grounded in an abstraction that human beings are well adapted to understanding. It's when our abstractions start getting deep, and layered, and mismatched with the task at hand that things break down. In other words, the interface doesn't function as a good map for the underlying software.

There are lots of books. The two I've read, and can therefore reccomend, are "The Design of Everyday Things" by donald norman, and "The Human Interface" by Jef Raskin.

I also reccomend a course in psychology. "The Design of Every day Things" talks about this a bit. A lot of interfaces break down because of a developer's "folk understanding" of psychology. This is similar to "folk physics". An object in motion stays in motion doesn't make any sense to most people. "You have to keep pushing it to keep it in motion!" thinks the physics novice. User testing doesn't make sense to most developers. "You can just ask the users what they want, and that should be good enough!" thinks the psychology novice.

I reccomend Discovering Psychology, a PBS documentary series, hosted by Philip Zimbardo. Failing that, try and find a good physics textbook. The expensive kind. Not the pulp fiction self help crap that you find in Borders, but the thick hardbound stuff you can only find in a university library. This is a necesesary foundation. You can do good design without it, but you'll only have an intuitive understanding of what's going on. Reading some good books will give you a good perspective.

[+2] [2009-02-13 17:05:56] dotmad

If you read the book "Why software sucks" you would have seen Platt's answer, which is a simple one:

  1. Developers prefere control over user-friendliness
  2. Average people prefere user-friendliness over control

But another another answer to your question would be "why is dentistry so hard for some developers?" - UI design is best done by a UI designer.

[+2] [2010-11-16 04:02:00] Nada Aldahleh

UX Design and software development are by no means mutually exclusive skills. On the contrary, they both require common sense and logic, attention to detail and being able to see the big picture. So, if you are a good developer chances are you can become a good UX designer!

They might appear mutually exclusive because many developers don't have experience in UX Design and vice versa. Also, if you start thinking of the architecture, framework or language before you think of the UX Design it might steer you in the wrong direction.

[+1] [2009-02-05 00:58:51] duffymo

Left brain versus right brain. Some people don't have an artistic sense.

I would bet that anyone could get better at designing interfaces by study and diligence. That doesn't mean you'll become a first-rank artist or designer.

I think it's always possible to improve.

Good UI design is not an artistic discipline. Good UI design follows rules just the same as programming does. A Good UI need have absolutely zero artistic elements. - nailitdown
UI design is not about artistic design. Think usability - Tim
[+1] [2009-02-07 18:47:40] Richard Ev

UI design is more art than science, and requires an understanding of your users and an ability to empathise with them.

This is very different to talking to a computer all day.

I don't think that people always realise this.

Here's a little self-test: Have a look at the FamFamFam silk icons [1]. Think about which icon you'd choose to represent various functions in the last application you wrote. If spending more than ten minutes doing this makes you eyes start to glaze over then UI design probably isn't for you.


Indeed, I also think that is the main distinction. It's more of an art than science. Developers think too 'logical' most of the time, to create astounding UI's... - Tom Deleu
[+1] [2009-02-07 19:28:35] Stephan Eggermont

It is all about practice, a bit of training and retrospective. But most back-end developers work in an environment where good UI-design is not really valued by management.

Organize a few coding dojo's around UI design after you've read a bit of literature on it.

[+1] [2009-02-07 21:09:45] TM.

I know that when I produce a crappy UI, it's almost always because I get too "zoned in" on particular parts of it.

During developing and testing a given feature, I'll almost always be using it lots of times.

After I've checked it out a dozen times, I'm in a frame of mind where I know exactly what I am trying to do and exactly what I need to do to make the program do what I want. I also and viewing this particular piece functionality all by itself, over and over until it's "done". I quickly blast past the rest of the app/menus/workflow/whatever while I am testing.

The user is not in the same situation at all. They are are not viewing this piece of the software as an independent "chunk". They are not always doing it lots of times, and when they are doing it often, they certainly aren't doing it by ITSELF often. They are not "skipping" the rest of the process and focusing on this piece the way the developer does.

It's important to try to look at a UI, then think "what am I supposed to do with this?". If it's not clear, you're doing it wrong. We are in a situation where we KNOW what input the software wants, and we just figure out a way to get that input. The user is in a situation where they want some result, and they want to know what they have to do it to get that result.

[+1] [2009-02-07 21:50:37] Arjan Einbu

users think top-down, while programmers often think bottom-up when they get to the step of creating the UI.

We (programmers) are thinking so hard about creating a datamodel that will do the job, that will hold the needed data etc. We create the UI to map neatly to the underlying model. So much that we often we forget to look at how our users aproach the same task, and not getting into their flow and way of thinking.

It comes natural to us to expect the users of our system to think about the problem in the same way as us, how we store and process their data, and so also understand how the UI is expected to work.

This is often a mismatch to their view of (and expectations for) the task.

How to solve it? I think one way is to actually ask a (potential) user how they expect the program to work before ever showing anything to them. Never give them any hints on how we'd implement a feature. Prototype the UI on paper with them, let them tell you what they expect and need every step of the way. Never take anything for granted.

The palm pilot was designed in a more top-down way:

Before starting development of the Pilot, Hawkins is said to have carried a block of wood, the size of the potential pilot, in his pocket for a week. ( From this article [1])

He'd simulate what to do on the piece of wood, not thinking about how it needed to be implemented as code. Every time a new idea came along, he would "try" it out on is piece of wood.

Of course you'll need some guidelines on how to deal with some of the ideas you come up with, and maybe not all of it needs to be addressed, even if we technically can...

See bulletpoint 1 (Eliminate options) and 3 (Underpromise, overdeliver) here. [2]


[+1] [2009-02-11 15:04:06] JacobE

A decade ago, I really sucked at UI design... I guess what helped me become better with the years was a healthy combination of humility and striving for perfection.

Bottom line: Never become too satisfied with your past or present achievements. Learn from your own and others' mistakes.

[+1] [2009-02-11 18:12:56] Paul Nathan

I use what I call the Grandmaw test.

  • If your dear old Grandmaw can't use it, there's a problem.
  • Presupposing she knows what the program's about, e.g., knows how to do taxes and is trying to use Quicken.

[+1] [2009-02-11 18:30:48] User

Just like with music: Sometimes people can be technically great musicians, but not be artists. My rule of thumb is always present the user with only the UI they need at the time. I notice a lot of back end developers flooding the screen with every option imaginable when they do a UI. While those type minds like to have all the details first and slowly ignore what they don't need, that doesnt work for most end users.

[+1] [2009-02-11 21:24:47] J. Polfer

A good book that provides lots of thoughts on user interface and its importance is In the Beginning was the Commandline [1] by Neal Stephenson. Not everyone needs a GUI, just a lot of people who don't program. It's like the difference between DisneyWorld's Animal Kingdom and the actual Amazon.


[+1] [2009-02-13 14:46:47] oberhamsi

"good ui design" is actually two problems [1]:

  1. getting the right design
  2. getting the design right

both are hard problems. in my experience the two things should be explored in parallel, as to not get ugly surprises late in the project ("why is our sexy drag&droping ultra-slow in IE8?? what do you mean it's not fixable???")

to get the right design you will have to explore posibilites. books can guide you towards trying out things that make most sense for your cicumstance - experience is even better, of course. also you absolutly need feedback from real users - how else would you find out that the design is already right? (you certainly can't tell.. read on!)

"getting the design right" then is the next problem, as it means the design you found appropriate must be implemented.

those "user experience / gui" things are so hard, because finding the right answer involves understanding what humans want - which they can't objectivly tell you and you on the other hand can't find out from "the outside". this means an (experience-) guided trial&error approach is the only way to go.

to more clearly answer your question:

why is good ui design so hard for some devels

for hardcore developers a big problem is, that their understanding of how the software works is so very different from how the users think it works (for example the URL "" should be written as "", if you know anything about how DNS works. but try selling a browser that expects URLs it like that :)).

as a sidenote: I would suggest you look into "experience design" rather then "user interface design", but that's another story.


I think you meant "com.stackoverflow.www" in your second-last paragraph, line 3? - Darkwoof
[+1] [2009-02-13 21:24:05] RS Conley

Eating your own dogfood is actually not quite the best way. The lack of focus on user concerns while true is not the whole story either. The same with growing distant from normal user concerns as your expertise grows. Most developers I know want to do a good job in creating software that solves problems.

Where the disconnect occurs is in failure of imagination. The inability for us as human being to think of all the possibilities and combination. Sure we try to overcome this with "better" methodologies.

The only way I found that works is putting myself in line of fire in receiving user feedback. This way I LEARN about the problem I am solving, not just once but on a continuing basis as users use my software.

This is not easy solution. You have to not only be a good programmer but also good at X with X being whatever problem you are trying to solve. By being good at X you can the needed experience to understand the possibilities and limitations. You can start accounting for that in your code resulting in more polished software both in the features you offer and the in the design of the UI.

It not about retraining your brain but gaining the experience needed to effectively solve the problem. This especially true if you going something brand new like Stack Overflow where the experience can only be gained if you are the line of user feedback.

[+1] [2009-04-20 07:56:32] Assembler

Design it for your Mother.

[+1] [2009-06-01 04:11:00] Steve Weller

Part of the answer is that UI design is much harder than it looks, just as coding is much harder than it looks to designers. The two worry to very different degrees about very different things, and this, apart from the obvious differences in approach and skills needed, causes them to focus on problems that are invisible to each other.

I've found that it helps to describe my app and how to use it to someone without any visual tools whatsoever. It helps focus on what is actually necessary and important and feeds back what can be comprehended quickly by another person. I can do this even before I have a line of code, so it's very cheap to do and doesn't require any artistic skills. The other advantage is that verbalizing the app gets parts of my brain working that otherwise would remain dormant while coding and I can start to "see" the app work (or not work) as I talk.

[+1] [2009-10-30 14:56:34] Will

"Is there something we can do to retrain our brain to be more effective at designing pleasing and useful presentation layers?"

Yes - use an interface driven architecture. First design a user flow from your business requirements --- then design your programming logic and databases based on your user flow. If you structure the mid-tiers and back-end as something designed to serve the front-end, then you'll have a user-centered app.

[0] [2009-02-05 20:09:28] Syntax

Programmers in general suck at UI design. There are designers that specialize in usability and UI design and they should be respected when it comes time to developing commercial software/websites/entertainment etc.

The problem most programmers have is that they can not look past their own noses and realize what makes things easier to understand and digest.

One of the best UI design principles is to always have an interface designed to be simple and accessible to your target.

A great and simple example is an elevator. Generally you press buttons to open/close the doors as well as traverse the floors of the building. Could you imagine if instead you had knobs and switches you had to flip to get from floor 1 to say floor 2? What if you had to slide a panel back to access three key switches with three colored keys you have to turn in a certain order to get to a certain floor?

You can quickly see how difficult a bad interface can be and how simple and usable a good interface is.

[0] [2009-02-06 03:33:08] Lee Treveil

I believe that all CS programmers have the ability to produce good usable designs, because Usability Design requires developers to think along certain paths and rules. Whereas developing a good 'attractive' design can be near impossible for a some programmers. This does not mean that both are inexorably linked. Its like Mozart being able to write a beautiful piece of music and not being very good at football.

[0] [2009-02-07 21:59:50] Jarin Udom

On the note of user feedback, Silverback ( ) is a great tool if you're on a Mac. I suggest creating a list of things to do (find this film, watch the trailer, find this film with this actor, purchase it, etc) and having the users sit there and go down the list.

The most important thing is to not tell them HOW to do it but to see how they accomplish the tasks (for the second scene, do they browse by actor or do they find the scene alphabetically?). You can start with non-tech-savvy people at your company and then get on Craigslist or hit the street and pay random people to test it.

[0] [2009-02-10 16:23:19] Andrew Cowenhoven

I'll start by saying that I have similar deficiencies to those voiced by the question. Nevertheless, I think the only reason anyone would suck at doing anything is because:

  • They didn't understand it and had never studied theory of how and why to do it
  • They never practiced it enough to become an expert

So my advice is to first get the books and web pages you need that describe the subject and study them. Lots of good answers here on these, I would add Tog On Interface [1] to the list. Also look at those UIs that are considered great [2] like the Mac, IPhone and Google.

The second step is to just start creating UIs. This sounds easy, but if this is not part of your job description you may need to do this on your own time. Get involved in a web development project as the UI developer. Maybe its your own project or someone else's but getting good at creating web pages can give you the experience you need and should not be to hard to do. Good luck!


[0] [2009-02-10 22:07:06] leeand00

"What others have done to remove their deficiencies in this area?"
— Chris Ballance

  1. Work with the least computer-savy-end-user you can find.
    (A fresh one, that's never seen your software).
  2. Get feedback from them about what makes it suck for them.
  3. fix those problems, take it to another computer-unsavy-user,
  4. Repeat the process again..

When enough fresh-unsavy-users can use your product, you know you've done your job.

(Also your software will probably look alot like Microsoft's, and you'll probably not enjoy using it...)

But that isn't the point! The point is that the end-users can use it, and enjoy using it!

Not the developers!

Also read this post [1] I found it helpful in this arena. It basically states that you should give in to what the users seem to be wanting.

To put it another way...

You have to look at what the users are already trying to do...

The Sidewalk and the Students

There was a trail that was created by students walking to and from class on the campus where I went to college. When the school noticed the trail, they put up a fence where the people already walked. The school did the wrong thing. You want to put up a sidewalk where the students already walk instead!

Video Stores and Netflix

To give another example, think about recent video store history: A long time ago there were alot of video stores: Block Buster Video, etc...what did people not like about those video stores? Late Fees of course. So Netflix came along and removed late fees, since it was more of what the client/end-user wanted.

Now Block Buster is busting for bankrupcy along with all the other fee charing video stores.

Is it more difficult to do this? To turn your brain off and give the people what they want? Of course it's bending your will to theirs...that's always more difficult, but in the end it's reaching the goal of giving the end-users what they want.


It's difficult to begin with, but it does get easier. I started writing software in the form of scientific analytical programs and later got into GUI development. It's only when you hand your software to a few non-techy people and watch them that, you start to see how they approach your code :-) - Jon Cage
[0] [2009-02-10 23:20:46] Andy Brice

Is there something we can do to retrain our brain to be more effective at designing pleasing and useful presentation layers?

Yes. Watch users trying to use your software and don't help them. Also known as usability testing.

The basic idea of usability testing is that you take someone with a similar background to your target audience, who hasn’t seen your software before and ask them to perform a typical series of tasks. Ideally they should try to speak out loud what they are thinking to give you more insight into their thought processes. You then watch what they do. Critically, you do not assist them, no matter how irresistible the urge. The results can be quite surprising and highly revealing. Usability testing can be very fancy with one way mirrors, video cameras etc, but that really isn’t necessary to get most of the benefits. There is a good description of how to carry out usability tests in Krug’s excellent book Don’t make me think: a common sense guide to web usability [1]. Most of his advice is equally applicable to testing desktop applications.


[0] [2009-02-10 23:28:10] BBetances

I think the reason we can't design UIs is because we are perfectionists and just cant decide when good enough is good enough. I know I personally can't stand designing UI because I am always doubting myself and saying, "no, that's not good enough."

[0] [2009-02-11 18:00:24] HLGEM

Something no one else has suggested but which help you immensely is to take a course (usually graduate level) in Human factors engineering. If you don't want to take the course at least go find the textbooks and read them.

[0] [2009-02-11 19:40:42] dtc

I think part of it is because UI design and program design often have conflicting goals. When I program I often think "What is the easiest way to do this?". When designing a UI the easiest way is not always the most user friendly. If you do both you might have a tendency to choose the easiest implementation which negatively affects user friendliness.

I also believe programmers are too close to the product to see it from a user's perspective. What seems very easy and intuitive to the person programming the application may not be to a user. It's necessary to get a user's input.

UI design is also not something that is always right or wrong. Different people will evaluate a UI differently. For example some people hate the new "Ribbon" UI in Office, some people love it. Some people think Apple's OSX UI is great, others don't care for it and find it difficult to use. No matter what UI you come up with you will have people who don't like it.

and sometimes programmers just chose what is easiest to code which usually makes for a terrible UI. - Bernard Igiri
[0] [2009-02-11 19:47:41] Mike B


Developers aren't designers. They haven't trained or attempted to learn about design, so why should they be good at something like UI design? It's almost the same as saying "why is accounting so hard for some developers?"

UI Design is essentially Design and Design is a visual representation of rules. Being good at design means that you understand why something should look, act and behave in a certain way (e.g. why links should be highlighted or why a header should be at the top of a page).

Design and Development are two entirely different beasts, but both require background knowledge and practical work. If you're not willing to put in time with one of these subjects then you simply won't be very good at it, no matter how well you fluked one of your programs/websites into looking good.

[0] [2009-02-11 20:17:44] Rik

Why is UI design so hard for some Developers?

That's a bit like asking why basketball is hard for footballplayers.

[0] [2009-02-12 09:04:06] Jérôme

When developers think UI, they usually think the perfect widget they could use for this or this task (by widget I mean text area, combo box, so interactive Ajax search field...). UI, and more especially HCI, should be thought at a lower level. It is interesting to split the reflexion about the UI into 4 steps:

  • Task and concept model: this is the most difficult to understand at a developer point of view. You must abstract from your reflexion all the idea you could have about the future platform, the language you could use. [ Paterno, 97 [1]] is the reference in this domain. You define your tasks as a tree, where tasks have sub tasks. Here an example for an export task.

  • Then you define the abstract UI: this is about group tasks and subtasks into workspaces.
  • Concrete UI: you can now decide which interactors use. You should now think about the platform (large screen, PDA, mobile phone...). Here is the key. Your task model and abstract UI can be factorized among several platforms.
  • And the final UI, implemented in a chosen programming language.

[0] [2009-02-12 23:01:10] Avram

Maybe because some developer start from Dos, and continue to partially work on command line OS.
Or because some of us writing software, because computer have some normal logic, not like human been. :-)

[0] [2009-02-12 23:14:45] Klelky

Because generally they are not UI Designers. Its a different skill. Thats it.

[0] [2009-02-13 00:55:52] RWendi

Because Its a different set of skill. Skills required to be a Web designer IS NOT the same as skills required to be a programmer. Yes few skills might overlap, like HTML, CSS, Javascript, but by nature Programmers know nothing of what makes a web design a good web design, and vice versa.


[0] [2009-02-13 01:10:31] user13276

UI design is a completely different skill. It is one closely related to visual art - being able to appreciate and create visual symmetry and beauty. And for WHATEVER reason, typically coders are NOT good with visual arts. I know there are exceptions - but as a general rule - it holds.

So really (unless you are the exception to this odd rule) - it should be dealt with like any other area where you are not naturally talented. You should evaluate if you can get along well enough with the chops ya' got - or maybe even spend a little energy improving, when you have a chance. However, you'd be better served developing the areas where you have ability and maybe seeking to work with people that are strong in the area where you do not..

A good book covering this idea is: Now, Discover Your Strengths by Marcus Buckingham ... it's an easy read.

[0] [2009-02-13 14:40:31] theman_on_vista

ui design and software development work on two different sides of the brain. it isnt that a designer sucks at developing and vice versa, its just that they are trying to do it with the wrong side of the brain. no serious person would disagree.

ok who is the not serious person that disagrees? - theman_on_vista
[0] [2009-11-26 07:12:19] 200found

I designed a program for people outside my social circle and observed their behavior. In doing this, I was no longer subject to the bias of my friends, and my own pride and ego. In improving the app, I became more humble and sensitive to the design issues. I learned the importance of task-oriented design, of simplicity. I learned the cost of having too many features. With experience, so will you.

Some references I highly recommend:

  • joelonsoftware jef raskin's "the humane interface"
  • robin william's "a non-designer's guide to design"
  • most of the ui articles on alistapart
  • jwz's blog on programming
  • the apple human interface guidelines

Some references and philosophy I highly advise you to ignore:

  • "themes"
  • desktop applications in general, unless you need driver/filesystem access
  • the idea that "more is better"