Fog Creek Software
Discussion Board

Getting the UI right

I manage software development for which making a very friendly user interface is extremely important. I'm not an experienced manager because I am in fact a developer promoted to this position, and I don't have management studies.

There is a problem I keep getting, and which I don't know how to solve:

The developers who work for me are smart, and get things done. They develop the internals of the applications very well. They solve difficult algorithm and systems programming problems very well, etc. I'm very pleased with the progress of my team from this point of view.

However, if I let them design the interface themselves, a very bad UI results. One that programmers can use, but not end-users.

I tried to teach them good UI design skills. They have improved somewhat, but are still not getting it. They don't understand the psychology of the user.. what goes on in the user's head when he or she uses the application.

I understand the psychology of the users because I have done some technical support for non-technical users, and I know how they think, what they think when they see a program interface, etc. Unfortunately I can't have my developers do some tech support because of the way the firm is organized. We deliver the app, and the tech support is done by the tech support department.

I have tried designing every detail of the user interface for them when I write the specification.

Unfortunately, while they write the software, the interface usually has to be changed because of some technical things we find out while developing (for example "we can't have a checkbox to backup some data, because under Windows this operation is impossible or very hard to implement"). There is maybe a 15% change because of technical reasons we only find out while developing.

Also.. they sometimes simply don't write some parts of the interface according to the spec - let's say there is a 5% difference.

So, the app has a 20% difference from the specification (that means that 20% of the app's controls are different from the specification). The end result is still a bad interface.

When the app is ready, many times I have to do a complete interface redesign, because the resulting UI is simply not acceptable from the point of view of the non-technical users which must understand and use the app without problem, and must simply like the app, enjoy using it.

Lots of development time is wasted because of this final redesign.

Is there anything I can do in order to shorten the redesign time, or to eliminate it completely?

What is your suggestion?

Is there a book, or some articles, on organizing software development so that the end result has an UI which is very good for non-technical users?

I want to develop outstanding UIs. By this I mean user interfaces which are easy to understand, are well designed, are usable, look good, and which users enjoy using.

Is there any book about how to organize the software development process so it results in outstanding UIs?

Are there any articles about how to do this efficiently, without redesigning the whole app again?

I've been thinking about doing some prototying on paper. Any advice on this?

Are there any other methods for getting outstanding UIs?

Thank you very much for your time and advice!

Manager in Germany
Friday, May 28, 2004

Well, Greasing to the host of the forum, Joel's "User Interface Design For Programmers" might be a good start. It's a sensible set of comments for programmers. Then there's the absolute classic "Tog on Interface" by  Bruce Tognazzini. I'd totally recommend anything by Edward Tufte that even sounds relevant: "Visual Display of Quantitive Information" is fantastic if you have to provide feedback of any sort to the user, and "Visual Explanations" has a wonderful section which I paraphrase as "the space shuttle blew up because some engineers couldn't draw graphs". It might be the sort of smack round the head that your engineers need to realise they really don't think the same as the average user.

And I think that's quite possibly the point: your engineers need to be led to the point where they realise that they simply think differently from the average software user. Then they might make the leap to accepting that someone else might be able to present the user's point of view.

I used to have endless arguments with a friend of mine on this sort of topic. We'd develop interactive websites together. I'd do the tricky coding, and he'd tell me that the sort of interface I wanted just wasn't adequate for the user. We never quite came to blows, but I learnt a huge amount from him. I used to think (actually, I still do) that 'if the user thinks like that then the user is an ass'. I'm right (in some ways), but that doesn't alter the fact that the user _does_ think like that, and _I_ need to get over _my_ prejudices and work in the real world.

I'd go further than this, and suggest that maybe, you should push harder so that the 15% that's too hard gets reduced to 5%. With enough effort, (and the right tools) you can do some fantastic things with software UIs. Just because something is how the tool lets you work, it doesn't mean it's right. Witness the insane placingof the three buttons at the top right of any Windows app: putting the 'I've had enough and do't want to do any more work on this' button right next to the 'I'm really interested in what I'm doing and want to see more' button is _DUMB_. Battle for the last 15%.

bah humbug
Friday, May 28, 2004

Check this:

Matthew Lock
Friday, May 28, 2004

Pay a professional to do the UI design. That's what they are for, and there is a reason that they exist (specifically, the point that you quoted - developers suck at designing UIs). Don't lok at me, I'm just a UI developer, which is not the same thing at all.

Friday, May 28, 2004

My tip: Spend the next year fostering a culture of excellent UI design in your team.

I took a few years out of my IT career and worked in a completely unrelated field. All around me were typical software users - heck, I even became one when doing administrative tasks. This helped significantly in changing my outlook on what makes software UI's good. You touched on a similar theme too, when you mentioned your time in tech support. It's a great way to get to understand the problems of regular users. say that your developers don't have the opportunity to do tech support. So, what about a "Constant Improvement" technique? Today 20% of the UI gets screwed. Aim to reduce this to 15% over the next 6 months...then to 10%...then...etc.

Of course your developers will never be perfect, none of us are! Give them Joel's book to read. Give them copies of Tog's articles to read. Give them "The Design of Everyday Things" to read - or even better, just a pertinent chapter. After a while one or two things may sink in. In your weekly or monthly meetings make a two minute mention of a good UI improvement or good UI design text.

A couple of years back I asked each member of my team to read Joel's book. I gave it to them, then discussed it afterwards. The online version can be read on the train home from work, or in an hour-long break from development. I was quite impressed at the immediate improvement some of them showed in understanding UI design.

You say you are in Germany...Germans have a proud history of excellent design, such as those excellent German cars, or Birkenstock sandals, or ... I don't know what else. I am a foreigner living in Germany, and I see a culture of appreciation for good design not present in my homeland. Maybe discuss why a Mercedes car feels so good when you are sitting in it or driving it - and it certainly wasn't designed for engineers! But it was designed BY engineers, I guess.

Herr Herr
Friday, May 28, 2004

Maybe your design sucks, and you don't know it.  Your developers sit around at night jabbering after you've left, "What the heck are we going to do about this UI specification?  Man this feature really sucks.  Maybe if we change this he won't notice." 

This happens all the time.  Tonight was one of those nights for me.

Friday, May 28, 2004

If your developers don't understand the requirements or thought processes of users you telling them isn't going to make that much difference.

Peel them off one by one and have them sit with some of your target users and have them watch/participate in the job they have to do.

If, though, it isn't so much that they don't understand what the users want and need but its a complete misunderstanding as to what the interface is for then have them inspect and analyse well made and well crafted applications and get them to tell you why they do and don't work.

I don't agree particularly that you need to separate UI design into its own ghetto, if someone has to place widgets on a form and get them to behave they need to know what they're doing.

Simon Lucy
Friday, May 28, 2004

The book to read is "The Inmates are running the asylum" by Alan Cooper.

You should start of with the design, and not let the coders code a single piece of code until you have decided on the UI, and most important of all the process.

I'll repeat that: - the process. UI design is not about getting some neat widgets on the screen. It is having a process that flows with the way your users think.

This should start at the beginning. What do you have in your requirements document? If there's a single technical word or acronym there, then it's probably a specification and not a requirement. A requirements document says things like, "tutors ought to be able to see all their students' timetables" or "users ought to be able to search for all messages sent to an unlimited number of email addresses" (Outlook 2000 sucks there).

Steve McConnell in Code Complete 2 covers this in the early chapters.

Stephen Jones
Friday, May 28, 2004

Have your developers participated in the analysis and design stages of the project? Have they met the users? I guess not. 

Nowdays new development methodologies encourage user participation in the process.  Developers could learn more about users needs if they are closer to them.

If you have a group of systems analysts separte from the developers, is the group analysts how has to design the UI as they have been in contact with users... actually the analysts must also have some knowledge on programming so their designs can be implemented by developers (that is there shouldn't be any technical problem to implement the design).

Cecilia Loureiro
Friday, May 28, 2004

If Bruce Tognazzini ( is to be believed, one simple, fundamental thing you should do is: user testing. That is, sit some end users in front of your software, give them little or no instruction about how to use the software, give them some common tasks to perform, and let them at it. Observe and take notes. You will see what areas of the program are confusing, where they are making assumptions that your program doesn't match, etc. You should get plenty of information and feedback to know how to make your UI less confusing and more intuitive.

Friday, May 28, 2004

You better get used to it. Most general purpose software engineers are TERRIBLE at UI design; so bad, in fact, that we've coined a phrase for engineer-designed UI: "Medusa UI". Turns normal people to stone. :-p

We've just hired a human factors person to help us improve the UI of our app, and it's actually already pretty good. So even when you think it's good, it's worth talking to a real pro about making it better.

Brad Wilson (
Friday, May 28, 2004

There's a fine line between UI design and graphic design. And there's a fine line between graphic design and art.

It takes artistic skill to develop really top-notch user interfaces. It's not something most programmers should be expected to do well. If you think you can teach UI design to a team of software developers, then I think you'll get frustrated pretty quickly.

The basic principles of graphic design (line, color, shape, texture, value, form, space) and an understanding of the psychology of human visual perception (unity, emphasis, balance, variety, pattern, proportion, figure & ground) are essential to creating harmonic user interfaces.

Programmers shouldn't be expected to have these skills, and they shouldn't be expected to acquire them.

I say, leave UI design to UI designers.

Just like you shouldn't ask managers to write code. It's not their job.

Benji Smith
Friday, May 28, 2004

Makes me think about the lotus notes UI. Did they even test it? I mean the learning curve is just to high. I can use Office 2000 then Openoffice and then firefox followed by IE, with no real problems at all.

Friday, May 28, 2004

If you are cheap just tell you developers to make it look and feel like an MS product.

Friday, May 28, 2004

I believe in heavy standardization. Just take Microsoft Business Solutions - Navision for example. It has hundreds and hundreds of forms. They thought it over and divided in into form types: card, list, document, journal, ledger. All types are standardized: on all document, the first menu is the document name, the next is Line, the next is Functions, and finally Posting. And so on.  You also should standardize the UI to a few basic types, define the basic types clearly, and force using them.

If you have every form designed as the developer, or you, or a professional UI designer sees fit, the result is chaos. Make 3-4 basic standards, enforce them to every situation, and the result will be coherence and ease of use.

Wild Wild East
Friday, May 28, 2004

Get an Apple iBook.

Vestal Virgin
Saturday, May 29, 2004

"If you have every form designed as the developer, or you, or a professional UI designer sees fit, the result is chaos. Make 3-4 basic standards, enforce them to every situation, and the result will be coherence and ease of use. "

Unless, of course, your standards sucked to begin with.

Benji Smith
Saturday, May 29, 2004


I find that UI development is very ITERATIVE.  I get an idea, slap it up on the screen, see how it looks, etc.  Sometimes there isn't room on the screen for a optimal solution.

I.e., there are constraints that become apparent only on actual implementation.

Then, once I have a design that makes sense, I need to iterate again: show it to a non-technical user.

Doing all of this through a developer is EXTREMELY PAINFUL.  It's slow, it takes 3x the effort (now you have to explain it to someone, then verify that they did what you explained and THEN you're ready to actually test the results).  This slowness also interferes with the FLOW of my thought process.

And, then,  I often end up having to "persuade" the developer to do it my way, so now it takes 6x the effort.

Mr. Analogy
Sunday, May 30, 2004

*  Recent Topics

*  Fog Creek Home