Don’t design like a programmer

I sometimes say that UI looks like it was “designed by a programmer.” This isn’t some arbitrary remark—rather this is my cute way of describing a class of UI design mistakes that programmers are particularly prone to make. Contrary to claims made by Alan Cooper, I don’t think this style of UI is the result of some programmer conspiracy to inflict their ill will over hapless users. Rather, these designs happen because programmers find them easier to develop, don’t notice their usability problems, and often aren’t aware that there are better solutions.

New! By popular demand, I have posts that show what a good design looks like and how to get it. Please check Don’t design like a programmer, part 2 for a design process and Don’t design like a programmer, part 3 for the new design.

These designs usually stem from directly mapping a data structure into a UI and expecting the result to be usable. To see what I mean, let’s assume that we have a data structure like this:

     struct UserOptions {
          bool        Option1;
          bool        Option2;
          String      Option3:
          String      Option4:

It’s natural to assume that a good UI might look something like this:

Now all you have to do is present this UI to the user, have the user provide all the information, and continue. Pretty straightforward, right?

While sometimes this approach works just fine, all too often it leads to a poor experience. Here are some of the reasons:

Data structure issues

  • Using variable or technology names as control labels The variable names work fine for the code, so why not use the same or similar names in the UI? The problem is that these names, often based on technology, may not be all that meaningful to users. Devices properties and settings are full of examples. For example, how many users know that “duplex printing” means print on both sides of the paper?
    Warning sign: Control labels based on technology rather than purpose.
  • Letting variable types determine control types The common data types of strings, integers, and Booleans readily map into text boxes, radio buttons, and check boxes. The problem is text boxes, being the most unconstrained control, require the most knowledge and effort for users. Mapping to richer, more constrained controls takes more effort for programmers.
    Warning sign: Overuse of text boxes and check boxes.
  • Exposing raw, unformatted data It’s much easier to expose raw data than to translate it into a format that is more meaningful or natural to users. For example, it’s easier to expose a raw date than a properly formatted date for the user’s locale. It’s easier to display a plain date than the useful, relevant information behind the date (such as days until deadline, age when an event occurred, etc.) Likewise, raw data like “1KNG 1BDRM EVO STE NSM” is easier to display than the more comprehensible “Evolution Suite with 1 King Bed (non-smoking).”
  • Warning sign: Controls display raw, unformatted data that requires users to translate.
  • Exposing representation invariants In object-oriented programming, a representation invariant is a set of constraints that a concrete data type must uphold to correctly represent an abstract data type. Simply mapping a data structure to a UI would expose the invariant and put the burden of enforcing the invariant on users instead of the code. A typical example is having to enter a phone or part number in a specific format instead of the program handling any reasonable input.
    Warning sign: Users required to enter data using a specific format.
  • Exposing special values A common programming practice is to assign special meanings to a special value, so, for example, a value of -1 might mean “not available” or “unassigned”. Simply mapping a data structure to a UI exposes these special values (typically through the control label), requiring users to know and enter them.
    Warning sign: Control labels that explain special values.
  • Overusing error messages A related problem is display error messages for the slightest input problem, regardless of how clear the user’s intent or easy the problem is to correct.
    Warning sign: Use of error messages for easy-to-correct input problems.

Simplicity issues

  • Not optimizing for the probable While from the code’s point of view any input is possible, from the user’s point of view not all input is equally likely. For example, while users could select any font, most likely users are going to select the last font, a recently chosen font, or a font chosen in the past.
    Warning sign: Not optimizing for the most likely input.
  • Over generalizing (the 0, 1, n problem) Programmers handle the absence or presence of something with a simple if statement, but handling 2 or more things requires a for loop. Exposing this generalization often leads to unnecessary complexity. From the programmer’s point of view, if you are going to design code to support a family, you might as well support a commune too. From the UX perspective, it’s far better to optimize for the common cases.
    Warning sign: Not optimizing for the most common number of objects.
  • Asking for what the code needs vs. what the user knows What the code needs and what the user knows might not be the same. For example, the program might want an airport code, but the user might know the city. Or the program might want the telephone exchange code, but the user might not know what that is (it’s the three digits after the area code). While it’s easier to present what the program needs directly, it’s better to ask for input that users can provide easily and confidently.
    Warning sign: Users have to look up information or need to use help to provide input.

Life cycle issues

  • Having baffling initialization Have you ever seen a large form where everything was initially blank and you had no clue what to do to get started? While zeroing out everything is a fine way to initialize a data structure, sometimes users need more than a blank form to get going.
    Warning sign: Initial UI state is blank and difficult to figure out.
  • Going all in Data structures reflect data types and hierarchies, but they reflect little else—they don’t reflect dependencies between members, or important vs. unimportant or required vs. optional values. Mapping a data structure directly to a UI would present all the data at once, without showing dependencies or optional values, or using progressive disclosure to hide infrequently used settings.
    Warning sign: All input is always displayed and always required, even if unimportant, optional, or dependent on other settings.
  • Having all or nothing Similarly, while all elements might belong together in a data structure, they don’t necessarily have to be provided by the user all at the same time. Mapping a data structure directly to a UI would require the user to provide all the information before proceeding, whereas a better experience would be to let the user proceed with the task with only the minimum amount of information, and gathering the remainder only when needed.
    Warning sign: Input is requested well before it is necessary.

Efficiency issues

  • Having a privacy hurdle If the data structure needs personal information or information that is difficult to obtain (such as having an account, finding an account name or password), users might be unwilling to provide such information—especially if such information shouldn’t be required to perform (or at least initiate) the task.
    Warning sign: Users are required to have accounts, log on, or provide personal information unnecessarily.
  • Avoiding excise Even if all the other factors work out, the UI could be annoying if displayed every time a frequent action is performed. Frequent actions should be designed to reduce or eliminate any hurdles, typically by assuming reasonable default values.
    Warning sign: Frequently performed tasks present an unnecessary dialog box instead of assuming defaults.
  • Handling scale Mapping a data structure directly to a UI might work well for a few variables, but the resulting UI can be a nightmare for dozens.
    Warning sign: Way too many controls displayed on a single screen.
  • Handling unexpected input Just because you don’t expect input in a certain format or find that format inconvenient doesn’t mean it’s wrong. If the user believes the input is valid, it almost certainly is. Check We cannot accept that behavior for an unpleasant but all-too-common example.
    Warning sign: Unnecessary restrictions on input formats.

If you do only one thing: Think about UI as a means for users to achieve their goals and perform their tasks, not as a means to fill in data structures or make code happy. Poorly designed UI requires users to translate their goals into what the UI needs, whereas well designed UI does this translation for them. What at first appears to be easy and obvious UI design may prove to be a poor experience from the user’s point of view.

A challenge

How many of the above problems can you spot below?

Yup—this looks like it was designed by a programmer. For starters, notice how nearly all the controls are text boxes and check boxes because they map directly to the underlying data structure. While this UI has problems outside of those mentioned in this post (such as poor communication, task flow, and layout), fixing the core problems first will make other problems easier to solve.

Want to see how to do it right? Check out Don’t design like a programmer, part 3.

A bonus challenge

The User Options example has 6 minor guideline compliance problems. Can you find them?

Want to learn more? Check out UX Design Essentials and UX Design Basics

If you would like to learn how design UIs the right way, please consider taking my UX Design Essentials course or my online UX Design Basics course. I’ve designed both of these courses to help non-designers get started in UX design.  I’ve only scratched the surface here.

Leave a Comment / What do you think?

43 Responses

  • elboru - May 31, 2011 at 11:54 am #
  • I guess I’m able to find three problems with the User Options example.
    1. The labels from the check buttons and the textboxes aren’t align, so aren’t the inputs.
    2. The Three button’s order, the cancel button is between the ok and apply buttons.
    3. The user will find difficult to difference between ok and apply buttons’ functionality.

  • Everett McKay - May 31, 2011 at 5:38 pm #
  • Elboru, I’ll give you full credit for #3 (most likely the Apply button isn’t necessary), but the other problems are still out there. Hint: Check the labeling carefully. BTW: The controls are aligned, but it’s not especially obvious with the hand-drawn look.

  • waldo - May 31, 2011 at 1:53 pm #
  • I enjoyed the recommendations given but would have liked to see some examples. How would you have designed the User Options interface or reworked the challenge presented?

  • Stan - May 31, 2011 at 3:22 pm #
  • Show us a solution to wGet UI that you posted! I am curious how professional UI designed would structure it!

  • Everett McKay - May 31, 2011 at 5:33 pm #
  • Stan, thanks for your comment. I’m up for the challenge, but to improve this UI I’ll need to understand what users do with it. While I easily infer the underlying data structure that the UI is trying to fill out, I can’t infer the tool’s purpose. If you can provide me with a few top scenarios, I’ll give it a shot.

  • Iain Collins - May 31, 2011 at 4:44 pm #
  • I find the attitude in this article tired and frustrating. In my view it’s long been true that the meme that it’s okay to suck as user interface design because your a programmer (and that programmers innately do suck at UI design) needs to die already.

    Many developers do suck at UI design. Many suck at being developers too. Some decent developers have been convinced they suck a UI design, but are not as bad as the assumptions of others would have them believe (they are told they suck, and repeat that notion to others, but actually they are not that bad). Many of us, however, are pretty good at it thanks, and don’t appreciate a presumed lack of ability.

    In complex applications, good developers are best able to come up with better UI’s because those who have the fullest understanding of the software can also be the best placed to know how and what to simplify or abstract (and what not to), in a way that someone who doesn’t understand exactly how the underlying code works would not have the knowledge to be able to do.

    In the case of the wget example above, there is an understandable reason why the UI apparently sucks – it was designed as a direct port of the command line GNU application wget (hence the name) and the author has tried to copy these options verbatim, rather than removing more of the 100 odd options – thus limiting the useful functionality – or by abstracting options to a degree whereby the command line flags to which they map is no longer recognisable.

    If you did abstract the options for wget you’d no longer in fact have a GUI version of wget for Windows, you’d have an entirely different application that just performs a similar function (of which there are many more user friendly, but not functionally identical, implementations). This doesn’t completely excuse the example above (there is some odd stuff in there and I’m certainly not defending it as whole) but it goes a long way to explaining for the most part why it’s like that.

    I’d note the command line implementation is hugely popular and has been around for 15 years, it’s not like it no one has rationalised the options (in fact curl – the BSD licensed alternative – has even more switches!). Lots of ports of old CLI GNU and BSD apps for Windows work this way. They make for horrible looking Windows applications, but they do have a specific purpose for specific set of power users (such as sysadmins).

    So, in this case, if you changed the UI radically by nesting options and abstracting them it would make such a port entirely useless to much of the target user base. What irks me most on the surface of it, frankly, is that it doesn’t show the flags each of the options map to.

    A better example of a crummy UI (that manages the worst of both worlds) would, IMO, be putty.

    A better title for this article would be: “Don’t design UIs like a programmer who sucks at designing UIs”.

  • Everett McKay - May 31, 2011 at 6:00 pm #
  • Iain, thanks for your feedback. I agree with you, and if you check the rest of my site you’ll see that my entire business is based on helping non-designers (especially programmers) improve their UX design skills. My goal wasn’t to mock, but to sympathize.

    Contrary to others (Alan Cooper especially), I believe that programmers can design good UI–but only if they make an effort to develop those skills. This post explains the trap developers fall into and show why it’s so easy to fall into it. The first step is to recognize the problem, and start to develop your design thinking by looking at the UI from the user’s point of view and not the code’s.

  • carlo - May 31, 2011 at 5:06 pm #
  • For a general ui like the simple first one we see in post,which ui would you propose for a better ‘user exp..’?

  • Everett McKay - May 31, 2011 at 5:49 pm #
  • Carlo, thanks for your question. The article explains how a good UX requires more than simply mapping a data structure to a UI, which is what the simple screenshot shows. Many people have been asking what a well designed UI should do instead. The difference boils down to the purpose of the UI and what the target users are going to do with it. Note that the example uses generic labels, so the purpose is undefined.

    To do a better job, you’d have to know about your target users, what they know, what their goals are, etc. So, for example, if this were a travel reservation site and Option 3 were the departure location and Option 4 were the destination, a good UI would help users select the right locations in a way that is natural to them. By contrast, a poorly designed site would just use text boxes and help users make selections only through the error messages generated. This specific problem falls under “Asking for what the code needs vs. what the user knows.”

  • Jim Abbott - May 31, 2011 at 7:02 pm #
  • Just FORGET about the alignment, labeling, control choice, etc.

    Until the problem of having both an “Apply” button and a “Cancel” button is resolved, everything else is a secondary issue.

    THAT problem can DROP USER DATA ON THE FLOOR–the usability equivalent of ‘meltdown imminent’!

    In case it is not clear to anyone why that’s a huge problem:

    1) In programmer’s terms: what are the transactional semantics of committing 1 to N changes via the Apply button, and then making a Cancel request (i.e., what is the net result after the applies plus the cancel)?

    2) In lay-person’s terms: ‘Hey, I clicked on Apply to make some changes, and then I changed my mind and clicked on Cancel but it didn’t remove the changes–your system’s [stupid/broken/made me feel stupid/is hard to understand/I hate you/I want my money back/my lawyer will be contacting you/…]’

  • Everett McKay - May 31, 2011 at 7:30 pm #
  • @Jim Yes, having an Apply button here is one of the six problems. There’s nothing here that suggests that an Apply button is needed.

    Apply is basically a poor-man’s preview. (That is, make some changes, click Apply, see what happens, continue making changes.) People sort of get it, but after clicking Apply they aren’t really sure what OK and Cancel mean at that point. I’ve seen in many times in usability studies.

    One way in which this confusion shows up is that people put Apply buttons on UIs that don’t need them.

  • Eddie Van Helsing - June 1, 2011 at 5:54 am #
  • Instead of asking programmers to not think like programmers when designing a UI, you might be better off having somebody *else* design the UI and then having the programmer connect it to the underlying business logic.

  • Everett McKay - June 1, 2011 at 6:45 am #
  • I agree that UX design is best done by the experts, so having experienced designers create your designs is the best Plan A. But in practice we need a Plan B. Here’s why:

    Staffing Most development teams are focused on the technology and simply don’t have the budget to hire designers. Those teams that do are usually understaffed.
    Teamwork Having designers on the team accomplishes little without effective teamwork. Managers and developers need to appreciate what those designers are contributing, and facilitate great design rather than hinder it.
    Culture Organizations ship their culture and that culture determines who gets hired and rewarded, what efforts get funded, what bugs get fixed, and ultimately what goes in the product. A culture that doesn’t appreciate great design is incapable of creating it.

    Great design requires having everybody’s head in the game, even if designers own the design.

  • Henu - June 1, 2011 at 7:23 am #
  • It’s a good article. But, if the example of the better design for produced for the challenging design.. it would’ve been better..

  • Frank - June 1, 2011 at 7:29 am #
  • My personal favorite is the alphabetic country dropdown.

    I’m as “one world” as the next guy but am I supposed to believe there are more users in Angora than the United States?

  • Everett McKay - June 1, 2011 at 8:48 am #
  • @Frank. Yes, that’s a good one. Context is an important part of scenarios, so it’s totally appropriate to put the probable locations of the target user at the top of the list. To do otherwise assumes that all choices are equally likely. Doing so isn’t a slight against Uganda.

  • Stefan - June 1, 2011 at 8:12 am #
  • Two more problems you haven’t mentioned, but which are so common especially on web sites that some people might not even consider the possibility of an alternative:

    1. forms that clear all entries when you made an error, forcing you to reenter everything from scratch!

    2. forms that require you to check a box that indicates you’re good with some special regulations.

    I shouldn’t need to explain the first. The second is a problem for at least two reasons. First, the regulations are often a convoluted mess of legalize that noone but an attorney can even understand, so forcing a client to acknowledge it is like asking him to issue a blank check. Second, if there is an actual need for such a checkbox then this implies that some sort of contract is concluded, in which case it should already be obvious to the client that he has to abide by the usual regulations. Forcing him to acknowledge that is redundant.

    This is similar as ‘Asking what the code needs’, in that the provider wants to ensure his legal rights are being observed, whereas the user couldn’t care less, to the point of being annoyed (I know I am!).

  • Everett McKay - June 1, 2011 at 9:03 am #
  • @Stefan, good points. I especially dislike #1 when entering user names and passwords. Doubly true when using a touch screen. I plan to address this problem in a future post.

  • Buddha Dude - June 1, 2011 at 8:33 am #
  • I admit it, I am a programmer and I, like 99% of the other programmers I have ever met, suck at UI design; we build them functional, not pretty, not optimally friendly. In my journeys as a contractor, I have seen many different ways companies do development and IMHO, the best way, in the Web Development world anyways, is to build the page with divs around everything and not care what it looks like, then check in the page, let the Art department know the page is done and let them make it look pretty. Another way is the exact opposite, you email the Art department the specs of the page (I need the following inputs), then they send you the basic pages in HTML mark-up and you code against that template. Either way, it lets the developers do what they do best and the art and marketing departments do what they do best; we are too logical for atheistic, art peeps are to abstract to do the code, but when we work together as a team we create something functional and something that the users like.

  • Everett McKay - June 1, 2011 at 8:58 am #
  • Budda Dude, thanks for your feedback. I think it’s important to separate visual design from interaction design. I accept that most developers aren’t and will never be good at visual design, but interaction design is a whole different story. I believe that devs working on UI code can and should have a strong understanding of interaction design. Please check out my UX Design Basics course to see the UX skills I believe developers need to have. Most of UX design isn’t about subjective art–it’s about objective communication.

    While you proposed two practical solutions, note that they also have challenges. Specifically, the pages that you are throwing over the wall to your designers in fact imply a UX by what goes on the page and their order. So your designers are designing the pages, but your developers are designing the task flows. And as my article suggests, those task flows are likely to be based on the needs of the code instead of the needs of your users.

  • Jaime Bula - June 1, 2011 at 8:41 am #
  • Please post the solution.

  • Everett McKay - June 1, 2011 at 8:49 am #
  • @Jaime. OK, I’ll propose a solution next week.

  • Divyan - June 1, 2011 at 9:52 am #
  • This article would be a first-class example for a series to be titled: “Don’t write technical articles like a UX designer.”

    The premise is flawed: most commercial software user interfaces are not direct “mappings” of data structures to visual elements, with the glaring exception of configuration/settings interfaces.

    The example shown is trivial, and the author does not put “his money where his mouth is” by showing how he would design a “UI” for some plausible scenario in which a few text boxes and check-boxes would require user input.

    In real-world software development, “context,” is everything, and it is context which determines when an Apply button is appropriate.

    Stressing the importance of context, however, does not leave the author of an article purporting to advise a hypothetically design-challenged group (programmers) “off the hook” of giving an example of design he or she feels is an excellent match of interface to context.

    It’s easy to take the lamest interface you can sketch out and then use it as a soapbox.


  • Everett McKay - June 1, 2011 at 10:14 am #
  • @Divyan, the goal of my article was to show a single common trap that programmers easily fall into that leads to a poor UX–without even realizing that they have fallen into it. Of course I chose the simplest example I could think of to illustrate that point. I’m sure you will find many programmers admit that what I described is pretty much what they do sometimes.

  • Buddha Dude - June 1, 2011 at 9:53 am #
  • Everett, OK, I see what you mean now. But to tell you the truth, I guess I never really thought about it until you mentioned it.

    About 15 years ago, I took some Windows architecture courses (Win Arc I & II and Windows Architecture I & II for those that remember the MCSD days) so I generally build my GUI’s based on these teachings, if you build your GUI’s based on industry standards then there really is not a problem. Those books thought me to design as if I was going to submit my application to Microsoft to get Logo certified even though it was in-house use only, for example:

    • No custom fonts
    • No custom colors (custom fonts and colors will override a persons custom settings and they will not like that, plus… if the person is visually impaired they might not be able to use your app)
    • File Edit View to the left in that order, Help to the far right of the menu bar
    • Standard short keys (Toad could learn from this, LOL)
    • OK Cancel View in that order for buttons.
    • Tab indexes!!! Drives me nuts when developers do not set the tab indexes properly and every time you tab it bounces all over the form

    In general, every Microsoft application has a certain look and feel, if you build your GUI to follow these standards, your users will feel comfortable with your application from the first time they use it and the learning curve for your app will be lower. I read somewhere that a user will accept an application that feels intuitive but has a few bugs in it, compared to a 100% bug free app that is designed well… like a programmer designed it 🙂

  • micron_rt - June 1, 2011 at 10:28 am #
  • I’ve thought about this subject some time ago and I’m glad that I found someone that I can share it with. Here is a functional model for do/abort pair of buttons that I’ve come up in the end. I hope that you/your readers might consider it. … BTW, I’m a developer, too!

    initial stage (“-” is a hidden/disabled “do” button):
    – [exit]

    after (0) with occurring changes in the form:
    [apply] [cancel]

    after (1) and “apply”:
    [confirm (OK)] [undo]

    after (1) and “cancel” -> reverse to (0)
    after (2) and “undo” -> reverse to (0)

    The form is closed either on “exit” in (0), or on “confirm (OK)” in (2). I believe that the technical details/effort of managing the states is not unacceptable, giving the fact that this model doesn’t leave the (careless) user to guess what happened, like the second case pointed by Jim Abbott.

  • Shawn Mclean - June 1, 2011 at 10:45 am #
  • Could you rework the challenge into a better interface? That would be a great example of what you are talking about.

  • Alex McKay - June 1, 2011 at 10:52 am #
  • Good Article Mr. McKay.

    It will prove to be a helpful cheat sheet to print out and check while developing!

  • Stefan - June 1, 2011 at 11:47 am #
  • While there are lots of ‘DON’T’s that you have covered, there are a few ‘DO’s that are worth mentionning. Here are a few guidelines I’ve learned that users care about:

    1. Sensible TAB navigation, i. e. using lets you navigate the input fields (and only the active input fields) from top to bottom and left to right, not some random order.

    2. Activate (or show) only those input fields that make sense at any given point. Don’t activate (or show) those that require input elsewhere, until that input is present and validated.

    This includes controls, such as the ok button: don’t activate it until all mandatory input fields are filled.

    3. Visibly mark mandatory fields. It might also be good to change that marking after input, so the user can easier spot missing entries.

    4. Validate input immediately upon entering. Don’t wait until the user tries to commit the data.

    5. Use appropriate input controls to keep invalid input to a minimum. E. g. Use a calendar control to input a date, a slider to input a value in a given range, a listbox for a selection of 1 of N possibilities, etc..

  • Everett McKay - June 1, 2011 at 4:58 pm #
  • @Stefan: all good points. Be careful how you use disabled controls though, because they have the potential to be extremely unintuitive. So while it’s good to disabled a commit button when the reason it’s disabled is clear and unambiguous from inspection, it not good otherwise. Better to give a helpful error message than force users to figure out the problem the hard way.

  • TS - June 1, 2011 at 8:25 pm #
  • I wonder why there are so many bad-designed UIs out there since I´d expect that in most cases the implementer of the UI is not only the first but also one of the more frequent users (read. testing and end-level support) of it. Thus, shouldn´t it be more natural that proper UIs are actually driven by its programmers rather than ignored?

    I guess the main reasons are:

    -lack of time: If the job has to be done as fast as possible the quickest way to do it will win, no chance for more useability here. Note that this is a short-sighted behaviour since in the long term a user-friendly, self-describing and error-avoiding UI will pay off better due to less time wasted for documentation and support (“it just works”), let aside that a happier customer is a major advantage anyway.

    -lack of interest: Might be a result of the first reason, caused by programmers who are command-line maniacs (which aren´t the right ones to create UIs anyway and might show their skills better in other parts of the software) or due to overspecialization: If the specification (which is quite often created by people which are neither designers nor regular users or programmers) hardly leaves options for optimization (e.g. replacing textboxes by something more sophisticated) one shouldn´t expect more than a generic solution. Good UIs are an iterative result of tight cooperation between the client, users (including testers) and developers (both back-end providers as well as UI creators), and an overegulated environment prevents that from happening.

    Some design principles which I found helpful:

    -don´t try to be overly creative: Keeping to standard conventions based on everyday experience, the common design of the OS or the UI library used helps guiding the users. And it allows using special features like accessibility helpers, multi-language text, or speech/text recognition by default rather than breaking it. Common example to avoid: Many textboxes fail by not doing something useful after pressing “return”.

    -accept everything: Assume that everything that can be entered actually is useful data. Not beeing able of doing so indicates that there are either badly-designed data structures limiting the range of useful values, or that the UI is less optimal and should be modified so that such invalid data cannot be entered at all

    -assume nothing: do not expect that all users will first enter A, then B and afterwards C using a 3 button mouse on a bright 21″ color tft in a well-lit rom. They might also cancel B by a touchscreen tip to get back to A, reproceed by pressing enter after deciding that A already was fine and remains unchanged, and cancel everything at C by pressing escape or saying “cancel that”, all happening on a small mobile device held by a colorblind user.
    In other words: Whatever state the UI might be in, make sure that any action can be handled properly, no matter how it is done.

    -instant feedback: input validation, auto-showing hints or status indicators (e.g. url valid and retrievable), enabling preview or submit buttons only if the previous input is sufficient reduces frustration on both sides

  • Everett McKay - June 1, 2011 at 10:23 pm #
  • @TS My theory: engineering is ultimately about problem solving, but there’s a lot more to UX design. The engineering process boils down to: discover a problem, find a solution, verify that solution really solves the problem, done! In UX design, mechanically solving the problem isn’t the end—it’s only the beginning! Great solutions require thinking about the target users, their goals, their context, using good task flows, choosing the right controls, communicating tasks effectively, making tasks efficient, etc.

    Note how the typical “designed by a programmer” UI enables users to perform the task just fine mechanically. Realizing that there’s more to it—developing “design thinking”—is the first step.

  • Ken - June 1, 2011 at 10:23 pm #
  • “For example, how many users know that “full duplex” means print on both sides of the paper?”
    I stopped reading at that point because I’m one of those users who doesn’t think that’s what it means.

    I come from an age where 300 baud terminals were top of the line communication tools. I always set it at half duplex because I was communicating with a mainframe running at half duplex by default.

    As I typed the terminal also immediately typed what I did on the thermal paper. If I switched the terminal to full, nothing I typed showed up. If I also switched the mainframe to full, an agonizing second after I typed, the character would show up. Trying to type quickly was impossible because there was buzzing and clicking noises being made as the thermal paper was being heated to provide the character image totally out of sync with what you typed.

    In “full duplex” the computer confirmed every character you typed was the one it received by transmitting it back to you. DUPLICATING the character is where duplex comes from.

    The error rate wasn’t high enough to deal with the headache of using full duplex.

    PS 300 baud meant 30 characters a second. Reality was more like 40-50 baud. That’s much faster than I can type, about matches the typing speed of the fastest typist I’ve ever seen. One of the reasons I don’t believe claims of 100 wpm or a line of code every 6-8 seconds. That’s about as fast as a 1200 baud terminal could write a line. (It should be able to write a line in 2/3 of a second.)

  • Everett McKay - June 1, 2011 at 10:33 pm #
  • @Ken. I wrote this from memory, as modern UIs thankfully use “Print on both sides” now. “Duplex” is definitely used, but perhaps “full” shouldn’t be there. “Manual duplex” means single sided printing. Check for the gory details.

    Update: searched on “full duplex printing” and got plenty of matches, so that’s in fact a technical term being used.

  • Ken - June 1, 2011 at 11:48 pm #
  • Ok, I lied, I went back to reading…
    “The problem is text boxes, being the most unconstrained control, require the most knowledge and effort to use. Mapping to richer, more constrained controls takes more effort for programmers.”

    HUH???? Since text boxes require the most knowledge and effort to use, wouldn’t mapping to richer, more constrained controls take less effort? I personally find that text boxes require the least knowledge and effort to use, and because I’m lazy, I tend to use them more than I probably should.

    Stefan: TAB navigation is important, but I don’t think you really mean from top to bottom and left to right. I accidently did that, by swapping indexes to my text box array. It was rather comical hitting the tab key, watching it go down, down, up top and next right, etc. It feels much better going from left to right from top to bottom.

    Everett: OK, your article doesn’t deserve my ripping into it, like I just did. You are making good points, both in the article and in your comments. You made a slight gaff. And terms like duplex will shift with technology. (Went I started, printers only printed on one side and your printout could be 100’s of feet long. The paper was perforated so they could be easily divided for each individual’s printout and dyed on only one side of the page so you could read across long lines of output with empty spaces, but they lined up with the dye marks so your lines of text were aligned easily. The concept of “manual duplex” just couldn’t be comprehended with these printers.)

    I’ve got one UI, I’m not proud of. I built it to test the app design, not create a real UI. I found and fixed plenty of bugs in the app, so it did what I wanted. If the app was commercially viable, I’d put the effort into making the UI better and fixing the one bug I found in it.

  • Vahag - June 2, 2011 at 3:04 am #
  • I think, that the biggest problem in user options UI is that option labels are incorrect “Option 1”, “Option 2” :D:D. They must be something understandably :))


  • Ken - June 3, 2011 at 11:11 pm #
  • Here I go, nitpicking again: “Avoiding excise”
    Why!!! If I can force a user to pay me a tax every time they open a program, that would be great!
    You did mean “Avoiding excess”, right?

    I love it! elboru gives you the first comment and it exactly matches the design review for the programmer you say shouldn’t be designing UI programs. I don’t know if he/she intended to be humorous, but I cracked up with that response.
    Even though your list is good, I’m going to ignore your list and give just general feedback on the form.
    1. Knowing what version of the application being run may be critical for support situations, but put it in the help menu, not the title.
    2. Where is the help menu? I have no clue what the application does in the form. This can be as complex as the msdn library or as simple as “This application will help you install Widget 1.9 on active servers on the network you have admin access to.”
    3. What does the URL do? What’s the “-” button following it for?
    4. Why do you give the option to list both the hosts you want and the hosts you don’t want? What in the world would you do with the host listed in both lists? Giving the option to exclude hosts implies you have the technical ability to scan the network for the list of hosts that can be included. Set up a radio button option to include or exclude hosts in the list, keep one of the multiline text fields, but leave it hidden and read only. Add a new button whose text changes based on condition “Add/Modify” + ” list of hosts to ” + “exclude/include”, that, when exeucuted brings up a modal window with the list of servers. How you design that is up to you, but I would tend to a multi-select tree-view that dynamically alters the level of detail shown based on the number of hosts in the list. (No level shows more than 20 lines, listing high/low host names if above 20. (If 2000 hosts, you would have 20 picks with 100 hosts in each, expand that, you have five picks, expand that you get 20. Clicking on a summary would pick all host names in the list to (un?)select. It would be nice if you could determine if the action you are planning to do can be done by the user doing it.
    5. Looking at Retrieval Options, I’m back to 2. These list values may be fine, but more information is needed on what they do. Use a multi checklist to reduce menu space needed for all these options. Why do I feel like Quota is an optional/dependent piece of information? If it is, hide the label and text box. Would it make sense to have Quota values in a pull-down list?
    6. Continuing Retrieval Options, Hide a button that says “FIND” followed by a hidden label “custom dir” and the hidden text box. All of this made visable when the Save to custom dir in the list box is selected. Hitting FIND would come up with a modal window letting you pick the dir from a dynamic list to fill in the textbox when selected. Ditto for Depth when Recursive Retrieval. This definitely feels like a good place to put in a list box over the text box.
    7. Ditto 5. for Accept/Reject except leave in the radio buttons. The custom list label box and button should only show up if it is selected in the list.
    8. Ditto 5. for Special and Running Options including hiding labels and boxes until needed.
    9. Replace all the buttons at the bottom of the screen with a label “Execution Options:” followed by a pull-down menu that is more descriptive than the button labels you are using because you will have a lot more room to be descriptive. Picking the option would be the same as clicking on the option except you would clear the selection as it’s made. Whoops, there’s the help I was complaining about earlier. (About)
    10. What exactly does the “Exit” button do that the little “X” at the top of the screen doesn’t?
    11. Putting in a function “E” option is so 1990s, are there still people who do that? I’d leave the functionality of it in for the curmudgins still using your code, but I’d take “Exit” out of the option list unless it does something else. (The curmudgin will be really pissed you removed the functionality, but then be pleased as punch that it still exists when he tries it out of pure cussedness.)

  • Everett McKay - June 3, 2011 at 11:44 pm #
  • @Ken, in fact I did mean “avoiding excise,” although in retrospect I should have stated it more plainly with “avoiding unnecessary interaction.” “Excise” is often used to describe an interaction or effort (such as waiting) that shouldn’t be necessary, making it feel like a tax.

  • Ken - June 3, 2011 at 11:20 pm #
  • Whoops, I meant to put this in too:
    If your application is dependent on a version update in a dll, don’t put it in the title. Start the app, determine the version of the dll, bring up a modal window describing the problem and what they can do to get the current version of the code, make all your newer versions backwards compatible and when they close that window, close the app because it can’t run properly with this version of the dll.

Links to this article

For more information, please contact

All Content Copyright © UX Design Edge