8 ms·

Don’t design like a programmer (2010)

113 points by panic 11y ago

ralusek 11y ago
This is actually pretty well thought out here. I feel like the most important one is the one that I consider to be the most difficult: Optimizing for the most probable. To me, it's always a struggle between probability, predictability, and shortest possible paths between states. Probability being that at any given point, the path to what the user is most likely trying to do is as short as possible. Predictability means that from any given state, there is a consistent and predictable way that the user can know how to get to any other state. And finally, that from any state, the ability to switch to any other state in the application is as short as possible (which obviously conflicts with probability). In my mind, almost every UX should be the equivalent of tabbed, nested folders. This takes care of predictability and short paths between all application states. The area this falls behind is in probability, in that there is no effort made to guess what the user wants. Given that your average user in a large application is unlikely to care about anything outside of the given task they're trying to accomplish, I feel like it's arguably more important than the things I traditionally prioritize for, and therefore something that I have to work on the most.
elcapitan 11y ago
I think there is an interesting pattern that every larger software interface that is designed mostly by the developers converges against the IDE in which it was developed. But then on the other hand, superficial designers often just adjust towards the look and feel of their preferred environment as well (e.g. tendency towards the old iPhone look back then, then suddenly switch towards the flat new look of iOS, etc. And even in non-mobile applications like web applications).
- wodenokoto 11y ago
  The flat look of ios was a catch-up design. But you are right that there are very strong trends in at least visual UI
simula67 11y ago
This is a very good article. We should generalize this to quote Steve Jobs : 'We have to start with the user experience and work backwards to the technology'[1]. A lot of companies try to get around this by hiring external design teams who decide the user experience first and then asks engineers to implement the experience. Of course then problem is then if they are not technical enough they might not take into account how hard something could be ( http://xkcd.com/1425 http://xkcd.com/1425 ) [1] https://www.youtube.com/watch?v=1SIeTmORl0E https://www.youtube.com/watch?v=1SIeTmORl0E
greggman 11y ago
> 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. This one drives me nuts. Soooooo many forms say "enter your phone number no spaces or dashes or parens" or cc number. Please just remove the dashes, spaces, parens when checking validation and maybe after submit. Don't force the user to have to do this. They might be copying and pasting Also don't make some 4 field 16 digit custom form that ruins backspace behavior and makes it impossible to copy and paste. That also means don't limit the field to 16 characters. If a users pastes in "xxxx-yyyy-zzzz-wwww" and only get "xxxx-yyyy-zzzz-w" you're only going to frustrate them. This is also an issue with many phone apps. Some you can't paste a number in. Try copying a number from Safari iOS into Google Hangouts Phone dialer. There's no paste option so I'm forced to write down the number on paper so I can manaully type it back in. Even the built in iOS phone dialer sucks. While you can paste you can't edit. So if you copy something off a webpage and because of the crappy smartphone copy/paste issues you get something like "dial:123-4556" there's no way to remove the "dial:" part. At best you have to paste into some other app that will let you edit, edit, then copy and paste again. Sheesh, does no one ever use this stuff?
- arethuza 11y ago
  Is there any reason at all for not allowing spaces in CC numbers or other long strings of digits?
  - dfox 11y ago
    I tend to write applications such that spaces and dashes are removed on input from long strings of digits and then optionally re-added on display. But I've come across case where dashes and spaces (in this case in product's serial number) were significant.
- 1_player 11y ago
viperscape 11y ago
> "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." Just about every app, service, and site does this now. It's ridiculous that this is the case, but everyone wants a slice of the pie so to speak.
collyw 11y ago
As a 'programmer' I find I often have a better idea than end users about what should be implemented. I sit in front of the system I am building all day, and I notice if performing certain actions is too slow or frustrating. I take an interest in UX concepts and will read articles on them, as opposed to "can we get a new button here to do X" without any real thought going into the process.
- dfox 11y ago
  That assumes that you as a programmer actually use the thing you are building for something else than testing. I've seen many LoB applications that get optimized by this process for programmer testing instead of normal user workflow. Yesterday's example (the application is desktop thick client for REST web service): (mostly developmen only) UI for manually creating test data is readily available on application's toolbar, while button for reloading form/view state from server has different placement on each form and in some parts of the application is completely absent (obviously, UI programmers restart the thing often enough that they essentially don't need that button).
- dagw 11y ago
  That only works if you work on apps that you actually use, and more importantly use in the same way that your end users use it. Having worked on specialized engineering applications where I'm not the end user, I'll admit to on more than one occasion making some really stupid UX decisions since it turns out that the engineers actually working with the app on real projects where using it very differently than I was when testing it on a tiny made up toy project. Spending just 20 minutes sitting next to someone trying to get real work done can be a real eye opener some times.
  - collyw 11y ago
    I watched the users of my last app cut and paste data from the application into excel, mess with the data in excel, upload the excel back to the database and ask me what was causing the errors when the unvalidated data in excel would not go back in to the DB. It was eye opening how they accept such a crap system. I tried to change it, but it was never given high enough priority.
collyw 11y ago
As a 'programmer' I find I often have a better idea than end users about what should be implemented. I sit in front of the system I am building all day, and i notice if performing certain actions is too slow or frustrating. I take an interest in UX concepts and will read articles on them as opposed to "can we get a new button here to do X" without any real thought going into the process.
EdiX 11y ago
There's also a follow up where the wget UI is redesigned [0]. It's important to also read this because that's where the argument falls completely apart: most of the features have been sacrificed to the altar of "simplicity": the redesigned application is essentially useless. Not only that, the design includes a really nice looking progress bar that is, unfortunately, impossible to implement. [0] http://www.uxdesignedge.com/2011/11/don%E2%80%99t-design-like-a-programmer-part-3/ http://www.uxdesignedge.com/2011/11/don%E2%80%99t-design-lik...
- 1_player 11y ago
  I do not agree. He explained the thought process two times: 1) "The target users for SiteNabber are intermediate computer users. They have enough knowledge about computers and the Internet to want to copy a website’s files, but they aren’t so advanced that they would prefer using a more complex existing solution. Experts who want to control every detail aren’t target users!" I agree with that. If you need a GUI you're not comfortable playing with wget from the command line and/or spending time reading the wget documentation. But you're advanced enough to know it is possible to download whole websites (!) 2) "Step 12: Test with real users, so there’s a good chance that I have some details wrong. This is normal and expected." Design, like programming, is a never ending process. Last 20% take 80% of the time, yadda yadda. I am a programmer, and I desperately want to learn what is wrong with my designs. This article explained very clearly what is wrong in my (and most programmers) thought process when designing an UI: Programmer flow: Write code -> Design UI around code -> Change code -> Apply changes to UI -> Rinse & Repeat Correct, designer flow: Think long and hard about your target users and why they'll use your product -> Design the UI around their goals -> Write code -> Test with humans -> Adapt design to better suit their needs -> Rinse & Repeat In the "Programmer's flow", code changes drive UI changes. When the code is feature complete and bug free the app is done. The correct way is to have end users drive your UI changes. And till users aren't satisfied you are not done, even if the code is perfect.
  - wpietri 11y ago
    > The correct way is to have end users drive your UI changes. And till users aren't satisfied you are not done, even if the code is perfect. Yes! If we make an app for other people, we must actually make it for other people.
Murk 11y ago
I've seen several applications that look like wget UI. They often are internal engineering applications, and, in the main work fairly well for the target audience. I think programmers know exactly what a good UI might look like, but (a) they don't always have to time to make such a thing. (b) it's not cost or time effective to produce one. Personally I've done both sort of user interfaces, the quick crowded ones, and the task Centeric ones, where time is spent on design and redesign. I don't really necessarily think that programmers are inherently bad screen design, but it requires the time/effort and inclination; where often, one or more of those are in short supply.
- Roboprog 11y ago
  That was my thought: First, a text box to make entry POSSIBLE, then, if time allows, a select/option list to constrain to meaningful answers, then, the "other-with-text" option to allow the long tail of never before seen but valid answers. And so on, as time allows.
Raphmedia 11y ago
This reminds me how much I miss those old clusterfuck interfaces of early windows day. I find them much more easy to play with and learn them in details.
- Kenji 11y ago
  Windows 95 to 2000 and the respective Microsoft software during this time had the best interfaces, hands down. Minimalistic, grey, fast.
  - bitwize 11y ago
    I miss those and their Unix counterparts, the old Motif apps. We should bring Motif back. Heck, with flat design being a thing, we should bring Xaw back.
makecheck 11y ago
This misses some crucial observations. One, good UI takes time, even for experts. UI redesigns that are easily described can be hard to reprogram (e.g. “replace those dialog elements with a table!” may mean switching to entirely different programming interfaces, there may be no sane data model that matches both without rework, and the new method may have new bugs). If your manager is asking you to finish something and move on, you need to make trade-offs. Two, historically there had been no serious shell in Windows environments for a very long time. When you have no other way to easily set a bunch of options, a crappy dialog that maps GUI elements directly to all possible options would have been a quick and practical way to expose all functions. I am not saying that these GUIs are good in any way but it makes perfect sense why they were created this way. Third, low-level interfaces such as the command line are an EQUALLY important part of all UI. A “design” should not just focus on how to rearrange some buttons. Low-level options for tweaking a program can help immensely to edit down what belongs in the GUI. On Mac OS X for example, it is really cool that one can use "defaults write" for a bunch of stuff because you can implement a lot of options without cramming them into your GUI. On a web site, a thoughtful layout for service URLs and JSON data formatting is far better than something that seems hastily-constructed and full of structural problems and other inconveniences. And also, this post is not showing convincing counter-examples. That “SiteNabber” redesign from part 3 is not really fixing the real issue. If you’re going to create a graphical replacement for a tool that deals with web sites, exposing “site url” to users is still broken. Why not make it a browser plug-in where you can simply view the web site you want, and click a toolbar button to save what you are looking at (or long-press that button for a menu that exposes a dialog version of the save with a few common options)?
Nutmog 11y ago
I disagree with the date comment "it’s easier to expose a raw date than a properly formatted date for the user’s locale". I'm constantly fighting software that tries to localize dates. Paypal thinks I live in country A and uses that format. My web host is in country B and uses their own format. I actually live in country C which has yet another format. It's no fun reconciling this in a spreadsheet which I have to keep changing the date formats in. Just use YYYY-MM-DD everywhere. Everyone knows what it means.
BorgHunter 11y ago
Another take on the same theme: http://www.howtospotapsychopath.com/2009/05/21/a-surprisingly-un-awful-interface/ http://www.howtospotapsychopath.com/2009/05/21/a-surprisingl...
strictfp 11y ago
Not a other critizism of the wget UI! We know it's bad, but it's simply because it's a 1:1 mapping to the command-line options. And command-line options is a flattened representation of all options. They are quite often not even combineable. A well-designed options class hierarchy with all constraints in place would map quite nicely to a GUI wizard.

113 points by panic 11y ago

This is actually pretty well thought out here. I feel like the most important one is the one that I consider to be the most difficult: Optimizing for the most probable. To me, it's always a struggle between probability, predictability, and shortest possible paths between states. Probability being that at any given point, the path to what the user is most likely trying to do is as short as possible. Predictability means that from any given state, there is a consistent and predictable way that the user can know how to get to any other state. And finally, that from any state, the ability to switch to any other state in the application is as short as possible (which obviously conflicts with probability). In my mind, almost every UX should be the equivalent of tabbed, nested folders. This takes care of predictability and short paths between all application states. The area this falls behind is in probability, in that there is no effort made to guess what the user wants. Given that your average user in a large application is unlikely to care about anything outside of the given task they're trying to accomplish, I feel like it's arguably more important than the things I traditionally prioritize for, and therefore something that I have to work on the most.

elcapitan 11y ago

I think there is an interesting pattern that every larger software interface that is designed mostly by the developers converges against the IDE in which it was developed. But then on the other hand, superficial designers often just adjust towards the look and feel of their preferred environment as well (e.g. tendency towards the old iPhone look back then, then suddenly switch towards the flat new look of iOS, etc. And even in non-mobile applications like web applications).

wodenokoto 11y ago
The flat look of ios was a catch-up design. But you are right that there are very strong trends in at least visual UI

simula67 11y ago

This is a very good article. We should generalize this to quote Steve Jobs : 'We have to start with the user experience and work backwards to the technology'[1]. A lot of companies try to get around this by hiring external design teams who decide the user experience first and then asks engineers to implement the experience. Of course then problem is then if they are not technical enough they might not take into account how hard something could be ( http://xkcd.com/1425 http://xkcd.com/1425 ) [1] https://www.youtube.com/watch?v=1SIeTmORl0E https://www.youtube.com/watch?v=1SIeTmORl0E

greggman 11y ago

> 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. This one drives me nuts. Soooooo many forms say "enter your phone number no spaces or dashes or parens" or cc number. Please just remove the dashes, spaces, parens when checking validation and maybe after submit. Don't force the user to have to do this. They might be copying and pasting Also don't make some 4 field 16 digit custom form that ruins backspace behavior and makes it impossible to copy and paste. That also means don't limit the field to 16 characters. If a users pastes in "xxxx-yyyy-zzzz-wwww" and only get "xxxx-yyyy-zzzz-w" you're only going to frustrate them. This is also an issue with many phone apps. Some you can't paste a number in. Try copying a number from Safari iOS into Google Hangouts Phone dialer. There's no paste option so I'm forced to write down the number on paper so I can manaully type it back in. Even the built in iOS phone dialer sucks. While you can paste you can't edit. So if you copy something off a webpage and because of the crappy smartphone copy/paste issues you get something like "dial:123-4556" there's no way to remove the "dial:" part. At best you have to paste into some other app that will let you edit, edit, then copy and paste again. Sheesh, does no one ever use this stuff?

arethuza 11y ago
Is there any reason at all for not allowing spaces in CC numbers or other long strings of digits?
- dfox 11y ago
  I tend to write applications such that spaces and dashes are removed on input from long strings of digits and then optionally re-added on display. But I've come across case where dashes and spaces (in this case in product's serial number) were significant.
1_player 11y ago

viperscape 11y ago

> "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." Just about every app, service, and site does this now. It's ridiculous that this is the case, but everyone wants a slice of the pie so to speak.

collyw 11y ago

As a 'programmer' I find I often have a better idea than end users about what should be implemented. I sit in front of the system I am building all day, and I notice if performing certain actions is too slow or frustrating. I take an interest in UX concepts and will read articles on them, as opposed to "can we get a new button here to do X" without any real thought going into the process.

dfox 11y ago
That assumes that you as a programmer actually use the thing you are building for something else than testing. I've seen many LoB applications that get optimized by this process for programmer testing instead of normal user workflow. Yesterday's example (the application is desktop thick client for REST web service): (mostly developmen only) UI for manually creating test data is readily available on application's toolbar, while button for reloading form/view state from server has different placement on each form and in some parts of the application is completely absent (obviously, UI programmers restart the thing often enough that they essentially don't need that button).
dagw 11y ago
That only works if you work on apps that you actually use, and more importantly use in the same way that your end users use it. Having worked on specialized engineering applications where I'm not the end user, I'll admit to on more than one occasion making some really stupid UX decisions since it turns out that the engineers actually working with the app on real projects where using it very differently than I was when testing it on a tiny made up toy project. Spending just 20 minutes sitting next to someone trying to get real work done can be a real eye opener some times.
- collyw 11y ago
  I watched the users of my last app cut and paste data from the application into excel, mess with the data in excel, upload the excel back to the database and ask me what was causing the errors when the unvalidated data in excel would not go back in to the DB. It was eye opening how they accept such a crap system. I tried to change it, but it was never given high enough priority.

collyw 11y ago

As a 'programmer' I find I often have a better idea than end users about what should be implemented. I sit in front of the system I am building all day, and i notice if performing certain actions is too slow or frustrating. I take an interest in UX concepts and will read articles on them as opposed to "can we get a new button here to do X" without any real thought going into the process.

EdiX 11y ago

There's also a follow up where the wget UI is redesigned [0]. It's important to also read this because that's where the argument falls completely apart: most of the features have been sacrificed to the altar of "simplicity": the redesigned application is essentially useless. Not only that, the design includes a really nice looking progress bar that is, unfortunately, impossible to implement. [0] http://www.uxdesignedge.com/2011/11/don%E2%80%99t-design-like-a-programmer-part-3/ http://www.uxdesignedge.com/2011/11/don%E2%80%99t-design-lik...

1_player 11y ago
I do not agree. He explained the thought process two times: 1) "The target users for SiteNabber are intermediate computer users. They have enough knowledge about computers and the Internet to want to copy a website’s files, but they aren’t so advanced that they would prefer using a more complex existing solution. Experts who want to control every detail aren’t target users!" I agree with that. If you need a GUI you're not comfortable playing with wget from the command line and/or spending time reading the wget documentation. But you're advanced enough to know it is possible to download whole websites (!) 2) "Step 12: Test with real users, so there’s a good chance that I have some details wrong. This is normal and expected." Design, like programming, is a never ending process. Last 20% take 80% of the time, yadda yadda. I am a programmer, and I desperately want to learn what is wrong with my designs. This article explained very clearly what is wrong in my (and most programmers) thought process when designing an UI: Programmer flow: Write code -> Design UI around code -> Change code -> Apply changes to UI -> Rinse & Repeat Correct, designer flow: Think long and hard about your target users and why they'll use your product -> Design the UI around their goals -> Write code -> Test with humans -> Adapt design to better suit their needs -> Rinse & Repeat In the "Programmer's flow", code changes drive UI changes. When the code is feature complete and bug free the app is done. The correct way is to have end users drive your UI changes. And till users aren't satisfied you are not done, even if the code is perfect.
- wpietri 11y ago
  > The correct way is to have end users drive your UI changes. And till users aren't satisfied you are not done, even if the code is perfect. Yes! If we make an app for other people, we must actually make it for other people.

Murk 11y ago

I've seen several applications that look like wget UI. They often are internal engineering applications, and, in the main work fairly well for the target audience. I think programmers know exactly what a good UI might look like, but (a) they don't always have to time to make such a thing. (b) it's not cost or time effective to produce one. Personally I've done both sort of user interfaces, the quick crowded ones, and the task Centeric ones, where time is spent on design and redesign. I don't really necessarily think that programmers are inherently bad screen design, but it requires the time/effort and inclination; where often, one or more of those are in short supply.

Roboprog 11y ago
That was my thought: First, a text box to make entry POSSIBLE, then, if time allows, a select/option list to constrain to meaningful answers, then, the "other-with-text" option to allow the long tail of never before seen but valid answers. And so on, as time allows.

Raphmedia 11y ago

This reminds me how much I miss those old clusterfuck interfaces of early windows day. I find them much more easy to play with and learn them in details.

Kenji 11y ago
Windows 95 to 2000 and the respective Microsoft software during this time had the best interfaces, hands down. Minimalistic, grey, fast.
- bitwize 11y ago
  I miss those and their Unix counterparts, the old Motif apps. We should bring Motif back. Heck, with flat design being a thing, we should bring Xaw back.

makecheck 11y ago

This misses some crucial observations. One, good UI takes time, even for experts. UI redesigns that are easily described can be hard to reprogram (e.g. “replace those dialog elements with a table!” may mean switching to entirely different programming interfaces, there may be no sane data model that matches both without rework, and the new method may have new bugs). If your manager is asking you to finish something and move on, you need to make trade-offs. Two, historically there had been no serious shell in Windows environments for a very long time. When you have no other way to easily set a bunch of options, a crappy dialog that maps GUI elements directly to all possible options would have been a quick and practical way to expose all functions. I am not saying that these GUIs are good in any way but it makes perfect sense why they were created this way. Third, low-level interfaces such as the command line are an EQUALLY important part of all UI. A “design” should not just focus on how to rearrange some buttons. Low-level options for tweaking a program can help immensely to edit down what belongs in the GUI. On Mac OS X for example, it is really cool that one can use "defaults write" for a bunch of stuff because you can implement a lot of options without cramming them into your GUI. On a web site, a thoughtful layout for service URLs and JSON data formatting is far better than something that seems hastily-constructed and full of structural problems and other inconveniences. And also, this post is not showing convincing counter-examples. That “SiteNabber” redesign from part 3 is not really fixing the real issue. If you’re going to create a graphical replacement for a tool that deals with web sites, exposing “site url” to users is still broken. Why not make it a browser plug-in where you can simply view the web site you want, and click a toolbar button to save what you are looking at (or long-press that button for a menu that exposes a dialog version of the save with a few common options)?

Nutmog 11y ago

I disagree with the date comment "it’s easier to expose a raw date than a properly formatted date for the user’s locale". I'm constantly fighting software that tries to localize dates. Paypal thinks I live in country A and uses that format. My web host is in country B and uses their own format. I actually live in country C which has yet another format. It's no fun reconciling this in a spreadsheet which I have to keep changing the date formats in. Just use YYYY-MM-DD everywhere. Everyone knows what it means.

BorgHunter 11y ago

Another take on the same theme: http://www.howtospotapsychopath.com/2009/05/21/a-surprisingly-un-awful-interface/ http://www.howtospotapsychopath.com/2009/05/21/a-surprisingl...

strictfp 11y ago

Not a other critizism of the wget UI! We know it's bad, but it's simply because it's a 1:1 mapping to the command-line options. And command-line options is a flattened representation of all options. They are quite often not even combineable. A well-designed options class hierarchy with all constraints in place would map quite nicely to a GUI wizard.