The 7 signs your UI was created by a programmer

Do you suspect a programmer may have put together the terrible user interface on that “enterprise” software you’re forced to use every day? There are some give-away indicators. Look out for them in your software, hunt down the developer and force them to read a book about user interface design. If you’re suitably senior, force them to a) improve it, or even better b) get someone with real UI experience to fix it.

1. Exclamation marks in dialog box messages
Look, it’s probably the 50th time I’ve seen this message today. The fact that this application “Cannot connect to database!” is no longer a surprise. You may have noticed that most professional software uses a neutral tone for its communication with the user. Try that. Also:
1a. Double negatives in confirmation dialogs
“Are you sure you don’t want to lose your changes?” Err… what? No. I mean YES. Oh sh*t. Any dialog that requires you to stop and try to parse the question in order to work out if you’re about to destroy several hours of work is not doing its job. It’s getting in the way of you doing your job. In fact, convoluted messages are such a serious issue that Microsoft even tried to help developers to help their users by introducing a whole new kind of dialog box in Vista: the question/task dialog. Good luck with that.

2. No tab ordering defined\mouse only navigation
Because no-one’s ever going to use the keyboard to navigate the zillion controls in your data entry app, are they? This one actually surprises me, because I’d have thought that developers would’ve needed to navigate quickly through the application while they’re writing it. Well, that doesn’t seem to be the case. Pretty much all commercial apps are good counter examples. I don’t mean to hold up Microsoft Office as a paragon of UI virtue, but they definitely do the “alternate way of navigating everything” thing well. Everything you need can be reached by both keyboard and mouse. Unplug your mouse and try that with your favourite piece of in-house software and see how you get on.

groups3. Group boxes around everything
This is a bit of a WinForms specific one. The clue is in the name: group boxes are for grouping logically related controls, not for providing a kewl recessed border around every single one of the controls in your dialog. Don’t kid yourself that this is doing anything other than using up some valuable screen real estate. (See if you can spot another pet peeve in the example dialog, too).

icon_editor4. Icons created in the IDE
Look, Visual Studio’s a really good integrated development environment, but it ain’t no Photoshop. Don’t try and use it to create icons. And while you’re at it, please don’t make icons consisting solely of the name of your application (inevitably an acronym) in pixel font and primary colours. Oh, and don’t just steal various icons from another application, unless you’re going to steal the whole lot; one of the key visual aspects of a good UI is consistency. Mixing your hand-drawn 4-bit icons with the glorious 32-bit shiny ones you borrowed is going to be jarring. In fact, why not go the whole way and get someone who can actually draw to create your icons for you? After all, you wouldn’t have someone who wasn’t a programmer writing the code, would you…?

5. Data grids
Otherwise known as the “Excel is the pinnacle of user interface design” disease. Break the habit. Generally, the more types of controls that are embedded in your grid, the less likely that it’s the right kind of interface paradigm. Yeah, I’m looking at you, person embedding a calendar control, drop down box, graph, slider and checkbox in each row of a data grid. And whatever your 3rd-party grid provider of choice says, it’s not going to do screen redraw performance any good, either.

6. Not implemented message boxes
Ahh, the GUI equivalent of source code TODO comments. Of course, it’s an in-house software give-away; no commercial (desktop) software would be brazen enough to ship with bits of functionality dangling from the stumps of buttons and menu items. Would it? Feel free to provide counter-examples if you have them.

dialog_dialog7. Excessive use of dialog boxes
Warning: dialog boxes are considered harmful (to usability). They’re the equivalent of restraining your user by force and preventing her from moving until she answers your question. That might be OK for matters of life or death (i.e. data loss), but not otherwise. Every time you find yourself about to add a new message box, stop, take a deep breath and consider whether it’s really necessary.

So, if you’re a victim or one, many, or all of these user interface faux pas, all I can say is: sorry. I’ve been responsible for doing at least one of these things myself over the years. Consider this post repentance for my user interface sins.

  • Pingback: Tweets that mention The 7 signs your UI was created by a programmer --

  • Callie

    I agree with you, and would even go one step farther on the dialog interference. Even for data loss, just make the deletion undo-able, instead of asking for confirmation. Most users just click “yes” or “okay” in confirmation dialogs – it’s after the three-second task completion time that they consciously think “wait – did I want to do that?” One author I read postulated that happens because when the confirmation dialog appears, the user is still focused on the task at hand (deleting their valuable data, for instance).

  • Juan Valdez

    Whoever those people were that did those things above, they weren’t programmers. There’s a lot of people in the business pretending to be what they are not.

    Anyway, a good list. I also have noticed the pattern of whenever I see an exclamation point in an error message, the rest of the code is usually crap. Full of bugs. The rest of your list also speaks to a uninvolved mentality. If you see any of those items in a program there are certainly far more other problems that you are not seeing.

  • Ben Smith

    Flip side of dialog boxes…

    I can’t explain the number of times that I’ve had to field a call about somebody doing something completely, utterly stupid, but occasionally necessary. It’s a juggling act!

    I write software for schools, so I’ll start with an example: taking attendance in class.

    On one hand, you want to allow teachers to correct a mistake. But on the other hand, administrators really want to know, months later, what the attendance was for the class on that day.

    Teachers are all-too-prone to delete records they no longer consider “relevant”. After they “claim” for the first week, they are very likely to want to “clear the deck” so that they don’t have to worry about the first week.

    So when a teacher goes to delete attendance in your attendance system, do you:

    1) Just do what they want, with happy green check marks and/or smiley face icons,

    2) Kick up a dialog box and make them click “OK”,

    3) Make them type something like “If I do this, I know I’ll probably be hung by my toenails in a dark, damp cave by my boss” before letting them do this, or

    4) Tell them to screw off and pound sand for pleasure.

    In many cases, the right answer falls somewhere between #3 and #4, despite all our desires to the contrary. People don’t *think* about what they are doing. I’ve had to take calls where people ACTUALLY TYPED “I want to delete this” only to complain later that our system “lost data”!

    Much, perhaps most, of annoying “bad design” comes from ignorant users, and engineers who somehow have to make it work, anyway.

    Yes, I want our stuff to be easy to use. But I have to deal with the results when I succeed, too.

  • Pingback: Pitfalls in User Interface Design « Orion Spur()

  • doug

    My favorite was an interface (designed by a CS PhD) for entering in a bunch of values that had an “apply” button next to EVERY entry field. iiiiiick. I made him change it so that when you left the field it automatically applied the value.

  • kabdib

    @Juan Valdez: [on code containing exclamation marks being crap]

    There’s a high correlation between exclamation marks and garbage code; not only dialog boxes, but debug code and comments as well.

    I have a sinking feeling when Iopen up a source file and see something like:

    /* enter for-loop !!! */

    … because I know that I’ll either be living with crap, or re-writing it.

  • what I *love* are the inconsistent warning dialogs (when closing a dialog for example).
    Dialog 1: Do you want to save your changes?
    Dialog 2: Your data hasn’t been saved, are you sure you want to exit?

    Besides the annoyance of the dialog, this forces you to read “every single” dialog to make sure “Yes” is the appropriate response.

  • „Much, perhaps most, of annoying “bad design” comes from ignorant users, and engineers who somehow have to make it work, anyway.“

    Must of the bad design comes from programmers thinking this way. I did not completely understand your problem, but there should be much better ways to deal with it: some kind of archive function, which keeps records, but hides them from teachers, delete function only marking records as deleted, but still keeping them, and of course “undo”.

  • euromix

    well i don’t fully agree. I do write interfaces, my users beg me for everything excel like, and fight hard to have useless warning message all around.
    and you know what ? they pay me to get what they want. so it’s perfectly fine.

    if you pay someone to build your house and this person answer that your requests are stupid, how will you feel ? my bet: you will fire him…

    This being said, i agree about neutral tone and clear messages.

  • Dave Spillett

    @Ben: One method that mitigates this is to never really delete anything, and make sure the users know. Mark “deleted” information as such so it doesn’t show by default, or move it to an archive area, and audit the delete operation. The same with data updates: keep the old record somewhere in an archive/audit table and record which user made the change. And the most important bit: make sure the user can see their audit trail so they know what any admin “missing” data is reported too can see.

    If your app is web based, make sure you keep web server logs for a decent amount of time (this will help by providing useful extra evidence for/against when someone disputes the audit trail or reports a genuine fault (“I did X and it seems to have not recorded it”).

    If people can not really delete data then they can’t delete data you want kept. And if they know that an admin you can see their actions they are much less likely to waste your time with “I didn’t do anything, but all this info has gone” when they did actually do something. Likewise, the audit trail, logs and archived copies will support genuine reports of the system being at fault and allow restoration of lost/damaged data.

    Of course you need procedures in place for when things genuinely need deleting (at user/customer request, for instance, under the data protection act or your local equivalent).

    FYI: I work on software that is used in a certain high-profile regulated industry where not keeping accurate records can break a business if the regulator sends in the auditors or the company faces customer or public complaints, and there is sometimes great temptation for users to massage recorded information (to disguise a mistake for instance), so this sort of data management is essential to some of our clients.

  • Well to say that these kind of mistakes are made by ‘programmers’ is a truely understatement. I’d rather say its made my newbies. What you imply is that programmers are dumb coding machines and actual UX and all that is given by someone else? I doubt. You say yourself that professional applications tend to be more consistent – well those applications were never developed by someone who is ‘not’ a programmer – just a better ‘programmer’. So someone with incomplete knowledge of CS would do that.

  • Michael


    Don’t agree on the grid 5. On the current row selected better on the current cell selected it makes sense to provide a control. I agree a the wohle grid filled with edits makes no sense at all.

    Some people like this. I usually try to have a sepreated group for the detail in the same tab sequence as the column of the grid are arranged. Think this fists, no one complained.

    Editors in the grids are helpful when applying quick changes/corrections, especially status changes of records… or when reslution is low…


  • “Signs your UI was created by an inexperienced programmer” maybe. Most educated IT and CS people have had usability classes. Most passionate developers, regardless of education, have read relevant works, be they blogs or books. I’m an engineer and a CTO, but I’ve known Norman, Nielsen and Tog since 1997. Lame title for an otherwise generally good piece on basic UI principles and gaffs.

    Will also disagree with grids — depends on the nature of the application. Some applications are very data-centric and/or large dataset-centric. Like anything else, you need to select the right tools for any given job. If you shy away from data grids as a rule, it’s probably because you’ve never dealt with heavier duty data-centric programming, particularly against disparate backends like legacy mainframes.

  • Pingback: REVUE DE PRESSE DU 2009-09-20 | Humour Publicite Humour Buzz Insolite()

  • Hmm, I agree that passionate programmers – craftspeople, as I like to think of them – are likely to consider these issues. The problem is that the vast majority of “Joe programmers”, those working in a large corporation perhaps, pay absolutely no attention to, and have no interest in these kind of issues. They have a kind of UI blindness. The problem with a good UI is that you never notice it; so unless you’re actively looking, a good UI can pass many people by.

    I’ve got nothing against grids as such. A lean and mean grid can be a good way of editing lots of homogeneous data. I take issue with them being used as the sole means of interacting with the application.

  • On the contrary, I think there’s a negative correlation between programming skill and ability to create polished UX. Anyone who’s an expert in one area, like programming, probably got there by focusing on it to the exclusion of other things. And user interface design is more aligned to creative disciplines like graphic design than it is to programming, so there isn’t even a natural overlap.

  • Bassel Samman

    OK, most of the people that responded are clearly not programmers. Guys, if you don’t get it, no need to comment on it. Exclamation marks, for example, are not signs of bad code. It’s just that when we went to school to get our “Programming” degrees, most examples we saw had exclamation marks in them in the text books or on the blackboard. Here is a good one you may have to implement quite often, or when learning a new language, it’s called “Hello World!!!”. We just tend to put exclamation marks at the end of all of our printed lines. “This is an example!!!”. As for all the other signs, they come from a programmers logical thinking. If the program is logical working correctly, we don’t really care if it looks nice or not. Because logically speaking it’s working as we want it to work. It’s hard for us to really care about the visual stuff because we see it as makeup and is always the last of our worries. If anything it may tell you is that you have a good programmer on your hand because he cares more about the integrity of the application then the visual candy(in my logical programmer opinion 😛 ). All kidding aside though, we always strive to care about makeup, but our clear lack of interest in putting on makeup sometimes slips through and you get things like bad confirmation boxes or a not so fancy icon.

  • Bassel Samman

    Just so I don’t get attacked, I do agree that those are rookie mistakes in a professional application. It just happens from time to time that something will sneak by the sales guys and the designers and even the customer, and something we put in for testing actually goes to production and you might see a bad icon or a bad error message. Trust me, be happy that they caught all the other ugliness because if developers were allowed to do design, your virtual world would not be nearly as pretty.

  • Pingback: Christians dagbok – 2009-09-20 | En sur karamell()

  • I’m a UI designer and am sometimes called in to critique existing UIs. In the course of my work, I’ve seen a bunch of other signs that the UI was created by a programmer (inexperienced or not):

    1) Organization of the main screen of the program around something that looks vaguely like the Windows file manager, with a hierarchical folder list on the left, and either controls or form elements on the right. I can’t blame programmers for doing this because after all, it’s what they are most familiar with and use for programming apps themselves (it’s how most IDEs are designed). Unfortunately, not all programs have a hierarchy (the underlying metaphor behind them may be a graphic editor, or a book, or a chat application, etc. To make matters worse, a lot of programs that didn’t necessarily need to use this setup have embraced it as well: iPhoto and iTunes, several twitter clients, just about every FTP application, Powerpoint and even a bunch of text editors. I’m not against this layout, but the fact that its become so pervasive means that developers don’t necessarily think about whether or not there’s a need for it, or whether a hierarchy even exists in their application. Like this one: or perhaps this one:, or this one: (boy, that last one is a doozy).

    In short, after a while, every UI uses that same layout, with large scale navigation at the left and then one or more panes at the right. Pretty soon, all apps look nearly identical, not matter what they do or need to manage. I think it shows a knee-jerk approach to application design where the task is forced into the layout, rather than the layout following the task.

    2) Putting many small icons in the taskbar or ribbon with no text associated with them and having them do vastly different things. Microsoft is responsible for a lot of these, particularly in the Office apps. There are so many toolbar icons, each with different kinds of behaviour (the alignment icons act like radio buttons, the table icon is a drop down menu for inserting a table, others invoke new windows).

    3) Many small dialog windows for preferences(or worse, preference dialogs nested 2 or 3 levels down). Rather than group things together logically, you get a discrete dialog for each preferences.

    4) Lack of progress indicators. Showing meaningful progress (with an estimate on the time left before finishing) on a lengthy task takes time and effort. Most programmers will merely resort to the hourglass/spinning ball/watch cursor.

    5) Input fields that are too short, even for typical data input. I can’t tell you how often I’ve seen that one.

    6) Menus with jargon in them (like ‘Turn on Verbose Logging” or “Clear Memory Cache’), which are certainly useful, but their functions should probably be put either on an ‘Advanced’ dialog box .

    7) Forms that have checkboxes acting like radio buttons. Believe it or not, I’ve seen that one quite a few times.

    I’ve probably got a bunch more, but these are a few that came to mind immediately.

  • Pingback: Tweets that mention The 7 signs your UI was created by a programmer --

  • “And whatever your 3rd-party grid provider of choice says, it’s not going to do screen redraw performance any good, either.”

    Ah snap, I had great reasons for why your statement is wrong about screen redraw performance, but no matter what I say… I guess the case is closed!

  • There’s a big difference between UI design and programming – hence the fact that the two are generally regarded as separate disciplines these days. Programmers (well, the good ones) tend to approach things from the point of view of performance and maintenance – this is not necessarily the same as delivering a great user experience.

    Perhaps there should be a counter article – “7 signs your UX knows sweet diddly-squat about implementation issues”. My first item would certainly be “throws everything but the kitchen sink into a wire-frame”…

  • Pingback: UX is making me dumb | Doug McCune()

  • Except that not all programmers are the same. Some of us pay attention to details; some of us are UE engineers. Some of us care about design.

    Some of us can architect software AND possess design skills.

    Some of us pay attention to the domain experts for the software we create *and* we bring to the table the ability to provide things those domain experts don’t know are possible and we do it in a way that follows good UI/UE principles.

    1 sign your article was created by a UI designer? He/she is dissing the engineers.

    And for the record, there’s a difference between a programmer and an engineer.

    And maybe you should have had a writer write your article for you. Designers can’t write and it shows–yes, that was tongue in cheek. Mostly. There *are* errors. Can you spot them? I can, and I’m just an engineer.

  • As a programmer, I’ve had all but #2 and #6 pushed on me over the years by designers. Each time, I’ve ignored the designer and delivered something usable instead.

    Although, frankly, I consider the pages of missing information a good substitute for #6.

    Don’t kid yourself. This isn’t a programmer vs. designer thing. This is people who have good taste vs. those who don’t.

    And I have to disagree with Bassel Samman. In my code I have not a single exclamation point. And I like it that way, thankyouverymuch. I take pride in my work, and the design of it is right up there with data integrity as the most important part of that.

  • Pingback: workspace » UI Problems()

  • Paul Clark

    I find a lot of messages boxes from Excel confusing. They have a paragraph or two of text and Yes/No buttons at the bottom. They require your full understanding of the text before you click the button. I shouldn’t have to fully understand the text, just the gist of what they are saying.

    To overcome this kind of problem I try to get rid of the Yes/No buttons and use buttons with descriptions. So even with with a paragraph or two of text and two buttons “Save”/”Don’t Save” it is clear what to do, even if I don’t read all the text.

  • Pingback:

  • Pingback: QA Hates You » Blog Archive » You say “ArmageddON”, I Say “ArmageddEN”()

  • Very nice! I think that, “Group boxes around everything” and “Excessive use of dialog boxes” are really true.

  • Pingback: Destillat KW39-2009 | - GNU/Linux, Open Source, Softwareentwicklung, Selbstmanagement, Vim ...()

  • Hi there,
    I have been burned as a user enough times to not trust dialog boxes. Programmers do not think from user’s perspective.

    For an e.g. please look at this thread :-!#fa507ae8ba40a2b9

  • Is this a “no dissent allowed” blog?

    You promised that my email is never published or shared, but I guess my comments aren’t either.

    Not only are all engineers devoid of UI/UE sensibilities, there are a whole class of engineers whose specialization involves User Interface issues.

    If a dialog box whose text was a question to which the answer was “Yes” or “No” that appeared in buttons at the bottom, I’d sooner rewrite the copy that let it go out the door with “Yes” and “No” buttons under almost any circumstance. Those responses are too general and pull the user out of the tight contextual focus he/she is in when deciding the proper way to dismiss the dialog.

    For example.

    But what do I know? I’m just a programmer.

  • Thanks for taking the time to reply. I finally got around to approving your first comment (not at all related to your remarks in this one, of course)…

    I don’t know if you’ve realised – I didn’t think you had based on your other comment – but I am a programmer first and foremost, and a UX tinkerer second, so this post wasn’t intended as a sleight on programmers. Just on sloppy programmers who think “hey, UIs are easy, there’s nothing to ’em”.

    And I found your “ooh, there are some mistakes” thing in your previous comment a bit tedious. I had enough “fun” with reddit commenters pointing out my misuse of apostrophes to want to spend any more time worrying about grammar. I’m not a professional writer or blogger… I’m a programmer.


  • Mick

    Great article and guilty as charged!

  • Pingback: Dew Drop – November 3, 2009 | Alvin Ashcraft's Morning Dew()

  • Pingback: Indicios de que tu interfaz de usuario fue creado por un programador | Spargo.Net()

  • patrick91

    8) No progress bar on long processes 🙂

  • A lot of people should read Alan Cooper’s “About face”!

  • Pingback: Top posts 2009 en Variable Not Found - Variable not found en

  • Pingback: 10 Resources for Design-Challenged Programmers()

  • bob

    Lol, you said to force the programmer to not be a programmer. If the organization is need of something better, why not hire a UI designer? That kind of makes sense to me.

  • Rp10001

    Wow. This is a really funny article, and the responses were even better! Yep, we sure know ourselves well (programmers) we’re the ones feed life into your beautiful ui layout. You’re welcome.

  • Adam


  • Karven Ferandez

    I really hate wiggle box UIs. For me, the wiggle box system is very hard to use.