IT Employment

How intuitive should developers make software?

If a user can't figure out how to use software, the blame often falls on the software developer. Justin James espouses that the expectation that developers must create intuitive software is unrealistic.

Would you want your brakes installed by someone who is on their first day on the job with no training and expects fixing brakes to be intuitive? I didn't think so. But this is essentially the expectation that we have been perpetrating in this industry for years now.

Somewhere along the way we lost track of the fact that software is often used to accomplish some very complex tasks. As a result, this expectation has turned into a curse. Users now feel entitled to sit in front of any given piece of software and instantly understand its every nook and cranny. And if they can't, it's the software developer's fault for not making intuitive software. This is an unrealistic expectation, and it's time to start reversing the trend. Below I present what I perceive to be the problems that have perpetuated the myth of intuitive software, as well some potential solutions.

The problems

The first part of the problem is the idea that users who have no experience or understanding of the field of knowledge the software addresses should be able to use the software. If I sat in the cockpit of a 747, I would not expect to be able to fly it after glancing at the controls (even if I did put in countless hours of Wing Commander), yet this is the first mistake users make when blaming the software developer. "I don't know what it means when it asks me to enter my IP address, so this software is hard to use." Would users prefer for the software to ask for their system administrator's e-mail address, and then automatically e-mail that person and ask them to reply with the IP address? Or, would the user want the software to provide a short tutorial on networking? If the user does not understand what an IP address is, no application should be teaching it to them; the software should be looking for a way to get the information without the user's help.

The next part of the problem is that even users who are knowledgeable in the problem domain are not necessarily going to "get" a piece of software if the domain is sufficiently complex. Word processors are a great example. A word processor is a piece of software designed to do hundreds of tasks -- everything from writing grocery lists to legal briefs to screenplays, all of which have different workflow requirements, formatting needs, and so on. Needless to say, any piece of software designed to do not just one complex task but hundreds of complex tasks is going to be complex. Given the complexity of these pieces of software, why would we expect someone who is good at writing essays out by hand to instantly "get" a word processor right away?

ERP and CRM applications are some of the favorite punching bags in the industry. It is common knowledge that a huge number (some studies show the majority) of licenses sold for applications like SAP go unused. These projects have an astoundingly high failure rate, and when you consider their sticker price, that is really unacceptable. One of the typical causes for a project to be declared a failure is that it is "dustware." That is, after a year-long integration and millions of dollars in consulting fees and license costs, the users fire it up, stare at the screen for five minutes, shut it down, and it sits on the shelf for eternity. Well, not to give these enterprise-class vendors a free pass, but I do not think that plopping a user in front of a complex piece of software untrained and with no documentation is a good way to get them to use it. If I expect a crane operator to be trained in that piece of equipment before using it to lift 10 tons of steel, I think it's reasonable to think that someone should be trained before using a piece of complex software.

What is most frustrating to me is that things were not always this way (at least, that's my recollection). WordPerfect 5.1, which is often remembered with a mixture of fondness and disdain, required you to purchase a keyboard overlay, a 100 - 200 page Quick Reference guide, and have a 500 page in-depth manual on your desk to be well-equipped to use it. But the simple fact was, you really needed to read a few hundred pages of text to get the gist of what was happening before you could sit down and do real work. That was also an era when there were local users' groups for users to get together and help each other out. In addition, companies also sent their employees to computer training.

Now employers are looking for computer savvy and computer literate employees, which seem to mean, "I can use Google to find Gmail." Instead of teaching true computing skills, such as how to form effective search queries, how to discern which Web sites are credible, and how to maintain security of private data, schools are letting students play on Facebook and LiveJournal, and saying, "Oh, the kids are learning how to use a computer." Nonsense. The students are learning, at best, how to use a particular Web site that will be different by the time they graduate.

Proposed solutions

Our industry needs to do more about this issue. Sure, we occasionally throw our hands in the air and spew forth a loud "RTFM!" Which would help if "TFM" wasn't often so useless. After all, why bother writing good documentation when the only people who care to read it are those who can figure it out on their own? It's a catch-22. So first up is the documentation. If your application is addressing complex tasks, you can't count on an intuitive interface.

A complex task will require either a ton of walk-through style wizards (which power users hate and even beginners eventually outgrow); or an interface like a command line; or a toolbar crammed with buttons, lots of keyboard shortcuts, or some other way of packing a lot of functionality into a small screen space. And with interfaces like that, the documentation needs to be better. Unlike a wizard-driven interface, you do not have a paragraph to explain each choice; at best, you have a tooltip to explain what function the icon represents. Users in these situations need to be able to rely upon the documentation to give them in-depth information.

A fallacy is that in order for software to be intuitive, it needs to be different from the "hard to use" products on the market. Networking devices are a good example. If I were to market a networking device, I would do my best to emulate the Cisco IOS to the most minor detail. Even though the Cisco IOS is not intuitive (in fact, it is one of the most consistently miserable pieces of software I have ever dealt with), nearly every network administrator has spent a lot of time learning the intricacies of IOS. By emulating a really obnoxious system, you are actually working with existing user knowledge. You see this a lot in the *Nix world. Because so much of *Nix counts on pipes and redirects, applications tend to implement the I/O patterns of existing applications in order to be a drop-in replacement, even if they support their own (and probably better) I/O as well. If you are trying to break into an existing market, you will want to provide a UI that looks like the current king, even if you have a better one as an alternative. If possible, try to use both, with an easy way of switching between the two.

We also need to stop counting on the community to provide support for us. A huge temptation, particularly in the current economic climate, is to put some freeware wiki or forum software on a server, link to it from the Support section of the Web site, and expect that users will train each other. I am not saying this doesn't happen or telling you not to set up a wiki or a forum. I'm saying that even with these tools, your staff will need to spend a lot of time on the wiki or forum and provide many (if not most) of the answers -- at least until you get a number of MVPs on board and editing the wiki.

Also, I would like to see more new user and experienced user modes for software, particularly in super-complex applications. It would be even better if the software could seamlessly transition on a feature-by-feature basis. For example, once a user does Task A a few times without too much help, the software stops using wizards, but the first time a user does Task B, the software still has him in training wheels mode. I think this would be a great way to combine the promises of agent-based systems with the guidance of wizards and hands-on tutorials.

Finally, let's get honest and drop the "easy to use" bullet point in our marketing materials when possible. Instead, we need to start putting in good tutorials and have our sales reps offer free (or highly discounted) training. What do you think costs your company more money: sending a trainer on site for a week to get new users up to speed, or not having a customer renew its license because no one ever used the system and then bad-mouth your software to boot? In the long run, it makes more sense to give free (or highly discounted) on-site training to big accounts and free online training to smaller accounts than it does to lose the upgrade fees.

In conclusion, software does not need to be intuitive to users who don't know the field; and even for users who understand the work, complex tasks are going to have complex software. But, software developers need to keep finding ways to make sure that users get up to speed and can fly on their own.

J.Ja

Disclosure of Justin's industry affiliations: Justin James has a working arrangement with Microsoft to write an article for MSDN Magazine. He also has a contract with Spiceworks to write product buying guides.

---------------------------------------------------------------------------------------------------------------

Get weekly development tips in your inbox Keep your developer skills sharp by signing up for TechRepublic's free Web Developer newsletter, delivered each Tuesday. Automatically subscribe today!

About

Justin James is the Lead Architect for Conigent.

204 comments
mnorth0666
mnorth0666

I held on to most of my support jobs in the tech world having been one of the few in any of the companies I worked for to have read the manuals to the software I was supporting. I worked in chip design and setup and ran the compiliers, simulators etc...The designers never had the time to RTFM ... if they had my work week would have been much less hectic ... Working now in a web design/development capacity I find I'm still the one people come to for answers on how the software works, how to do this etc...I'm still reading manuals, seems most others still aren't.

mikifinaz1
mikifinaz1

As with writing, the audience and the goals of the stateholders will determine more than anything the "useability" built into software. If the program is a game and the stakeholders want to sell it to everyone and his brother, you have to make the software so useable that your dog can work it. If you are creating a program for 12 senior computer specialists not so much. Now you get into the balancing act of cost versus effort for profit. You have to make the program easy enough to use so that time is not wasted by the user driving up ROI etc.so they will buy the product, but still profitable enough to be worth making and selling.

BALTHOR
BALTHOR

One that ignores virus.Any doctor in computer science should be able to write an OS.

stevenjs
stevenjs

The problem with all software development, indeed all consumer technology, is that design and development is controlled, that is to say dictated, by technologists, which is to say, programmer/developers. They dominate all decision making. As documentation writer for a software development company, and as consumer, I see the same "technologist syndrome" over and over and over. They're narcissistically enamoured of the means, and outright contempt for the end, and end user, is hardly an exception. This disgusting state of affairs, of course, keeps me well employed, but even the biggest and some of the oldest software out there is fundamentally unusable because of developer narcissism, and no other reason. The solution is to absolutely and unequivocally BAN developers from all decision making in the DESIGN of software. Designers, which is to say usability experts who are NOT developers, should tell developers what to develop and how to manage the interface, not the other way around, which is the grim state of affairs today, a legacy of the "gee, wow, look how smart I am to code this" and "screw the user if they can't appreciate it." Here at work, the developers rule supreme, as they do most everywhere. This is bane of usability, period. The PC (and Mac) are model-T's that have learned nothing from 100 years of auto design, for example. The PC itself is a perfect example of techno-narcissim. What a piece of junk I am typing this on, no matter if it were the hottest PC in existence today. I could spend a decade enumerating the deficiencies in OS and hardware, and another decade with the deficiencies in "celebrated" and "version 12.0" softwares.

glassangel
glassangel

I practically made a career out of cleaning up stupid Access database mistakes. If you don't know anything about data modeling, you have absolutely no business using a relational database application. People think because they can use the silly Access GUI, they can create a "database", when what they're really doing is creating a flat file beneath an application layer that works like a Data Processor set on "puree". They need to use a spreadsheet instead, and hire someone who knows what they're doing to do the actual database. In short, GUIs ought to reflect this potential for disaster by making the GUI as forbidding as possible for novice users.

ron.e.wolf
ron.e.wolf

Intuitive and ease-of-use are similar, but distinct, concepts. A complex application can have a complex yet intuitive interface. That is, the interface supports a trained expert at a virtuoso level. Apple's music creation application Logic is an application example (with a modern cockpit and WoW as other examples) of a complex application that is accessed and controlled via intuitive interfaces. Each of these 'applications' has interface elements that match an 'intuitive' (expected) sense of action. In your column you confound intuitive to mean ease-of-use. As you point out ease-of-use addresses an applications usability by an untrained novice. However, your column talks only to ease-of-use and does not discuss intuitive interfaces. You repeatedly make the observation that complex applications can not also be easy to use. Of course you are right that mastering a complex application takes time and effort. But you are not right that a complex application can not be intuitive. BTW, Apple's Garage Band application is a great example of how to down function the complexity found in logic in a way that the resulting application is both intuitive and easy to use.

Jaqui
Jaqui

The person who has never even used a computer will not see ANY application as intuitive. After they have used one, enough to be able to find what they want on it, which application will do what they need, those DEFAULT applications are what is intuitive for them. If that first system is a Windows system, then the MS app design is it. If it is a Mac system, then Apple's app design is intuitive. If it is a GNU-Linux system running GNOME, then that is intuitive. Pity the company that has to write an app that is intuitive, for the person whose first system had Enlightenment WINDOW MANAGER for a desktop.

DHCDBD
DHCDBD

The software needs to be intuitive enough that a person that is familiar with the field can use the basic functions and can understand the books or manuals to learn the more advanced functions. Maple v. Mathematica is a good example of this. With Maple I can sit down and use the program from simple math up to differential regression, once I reach matrix operations I have to RTFM. Mathematica, on the other hand, I could not use at all with out reading the help manuals, this is despite having six semesters of advanced math. Why, because it is not intuitive within the branch of mathematics, only within its own logic. But the problem is not just in how intuitive the software is, the problem is also in how intuitive the base code is. I have an ongoing project in which the code is a mess. The code is almost entirely undocumented as is the program itself. Meaningful identifiers are not used, the code is full of i, j, k, & l's instead of an identifier that tells me why the code is looping. Variables are calculated each iteration of the loops but only used once and are not in arrays or lists, so that the variable only need be determined once. After staring at the code for a week or so and after cleaning some of the most obvious problems, I put the code in a debugger to trace how the functions are used. Looking at the second example; now comes along some poor tech writer who barely knows what a loop is and who needs to write the manual. How? It is uncommented, and undocumented. The variables that the user manipulates have no meaning except to the original programmer and do not have meaningful identifiers to anyone but the original programmer. As an example, there are three user controlled variables "SF, SN, Trig." Just what do they do. I had to trace the source to find out that they stand for "Sample Frequency," "Sample Number," and "Trigger." The sample frequency is not the sample frequency, but rather the speed of the samples collected from an audio card. The sample number appears to be the buffer size, I don't know for certain - yet. The trigger is not really the trigger level as it is normally understood, rather it is the decay factor from the original input signal. This is by the way a software oscilloscope. How can you write a meaningful manual when the program is not intuitive nor properly written, even if it works. Intuitive needs to be on both sides.

BALTHOR
BALTHOR

Software needs to be very intuitive.You download a program and you figure it out.How good your end product is would be directly related to the amount of time that you spent with the program.Writing hit songs in a few minutes is what you run into.Help sections are the greatest.

t-techr
t-techr

developers are the problem their rogue, i know better attitude, results in this type of difficult software

wmjas.shaw
wmjas.shaw

Maybe you're using "developer" in a broad sense, but it has always seemed obvious to me that developers should be UI implementers, not designers. Ten years ago we already had experts in UI and the importance of architecture (setting standards and principles for new system development) was already understood. By the time a developer starts work there should be clear guidelines on how the UI is to be implemented for the software: the use of tool bars, tool tips, help, tutorials, wizards, nav bars and plain old screen navigation should not be something that the developer has to be concerned with. And the UI design / architecture should have been developed cooperatively by experts in the application knowledge domain and experts in UI to match the target users' typical skill level, the conditions under which the application will be used, and the level of expected training. Especially with large apps, we don't expect the developers to be the data modellers or the technology architects. Since the UI is so critical to the success of the application it needs far more attention than developers can devote when they're under pressure to deliver high quality software components within the tight deadlines that they are typically expected to meet.

fidlrjiffy
fidlrjiffy

First the compliment; I always find Justin's articles interesting and thought out, even if I don't always agree. Such is the case here. In my opinion based on over 20 years of software interface design is that software that you can more quickly understand how to use is better than not. All things being equal software that requires the least amount of training is better software. The easier it is for a user with domain knowledge to "get it" the more likely the software will be used and used successfully. The less a user has to use the manual or help the better. Training and documentation is no substitute for software that is difficult to understand and navigate. None of this means that documentation and support are not required, or can be less than excellent. It does mean that the documentation and support can be about the software and not about the domain, ie: if your product is PhotoShop you don't have to train someone to be an artist. A couple of examples: I architected and designed laboratory management software in a very competitive market. While we didn't always get the sale we always got to round two because everybody viewing the software "got it". We competed feature for feature with the top products but our software was easier to understand and use. We had a comprehensive manual, help system, and offered training but hardly ever needed to train anyone. Competing products offered up to a week of required training. More recently I managed a project to implement a third-party and very domain specialized billing product. It looked like Windows circa 1987, our domain people took 8 months to get it to work and to figure out what the heck the software was talking about, and the company had bought and paid for it before anyone had ever set eyes on it. So, yes, it is an example of bad management but also an example of bad software that got shoved down our throats. There are no standards for interface design; everyone gets to roll their own, probably something akin to automobiles somewhere around 1910 (but even cars have some ergonomic requirements; software can be anything). Microsoft Office and Windows software in general has set some standard, and, yes, Office 2007 breaks that standard and I find it frustrating to find things that I don't use that often which were easy find previously. Going to the "design" people for wireframes and such doesn't do a thing for me; it's still what they think best (they are the "experts" after all) and they're less likely to talk to the people who'll actually use the software. Software interface design is difficult because it can be anything and much software solves complex problem. Hardly anything else compares. The interface to a car can be pretty simple because, at least to the user, it's pretty simple; go forward, go back, turn, start the car, brake, turn on the radio. The most off-putting thing is Saab with the key in the console (I don't know if they still do that). I can't tell you how long I looked for the darn thing and what was the point of doing that? Just to be different. Probably designed by an interface expert. You name it; power saws, lawn mowers, dishwashers. Pretty much any software we have is several magnitudes more complex than anything else we come into contact with. It's therefore not trivial to make it easy and understandable. The interface to software should work like in the movies with that big ACCESS DENIED flashing on the screen. Now that's easy to use!

gsveeb
gsveeb

This has to be one of the best user interfaces I've come across. Intuitive, functional, even a baby could use it. At the same time it is performing some relatively complex tasks in the background. This is my idea of great software. And by the way ... it has never crashed!

TuesdayNews
TuesdayNews

Apparently, the purpose of this article is to enable the author to vent his frustrations. The "problems" it addresses are purely emotional. The author provides no evidence of any financial or other impact that the supposed user "expectations" create.

mikifinaz1
mikifinaz1

People have to use your software. If it is hard to use they will get someone else's software. So, if you are in the market to sell stuff, you had better make it easy to use.

rami
rami

Justin, Well written article. I am in complete agreement with you here. I used Windows for about 9 years prior to switching to Linux for 3 years while studying computer science at Oregon State. After starting a creative web firm, I switched to OS X. Having used a wide array of operating systems I obviously noticed a variety in UI methodologies. Without a doubt, OS X is the best step in the right direction for UI. While designing a robust UI does aid in the overall usability of applications (whether web or software based) it will never eliminated the need for proper documentation and training. One thing I would like to see is some innovation in documentation delivery. The way help and support are offered to a user while directly interacting with an application. Screencasting has come a long way. I often prefer to see what I need to do rather than read 3 pages about it. I believe that video has the ability to deliver a message quicker. Nonetheless, I myself am a visual learner. There are those who prefer to read... but we need both. Nonetheless, the moral of what I'm trying to say is that there are many tasks that can be significantly simplified with proper UI but even new user interfaces require documentation on, well, the user interface :) Great article on an important topic. Thanks!

read
read

I think one aspect you have missed is that a public wiki or forum serves to reduce traffic that might otherwise go directly to support. The reason we implemented a forum at my company is precisely for this reason. We are not saving any time answering questions that have not been answered before, however, once those answers are public anyone can view them and support is also able to direct people to them (if the user did not bother searching first). We do also have quite a few end users helping each other because of the nature of our product. It is very customizable, to the point that you can literally get it to do things we could not possibly predict anyone ever doing. The majority of our users do not do massive customization, but there are still many that do (often larger clients with very specific needs). Often the types of questions that are asked are best answered by other users working in the real world trying to create similar solutions and a forum is a great place to share these ideas. I see a similar sharing of ideas (though perhaps more mundane) with some of Microsoft's products in their new help portal system where end users can suggest tips and tricks and ask questions of other users.

Duggeek
Duggeek

Think about that subject I put there. The plain-English version would be, "Intuitive is not Easy". In both ways, it is a concise statement. In both ways, it is speaking to a certain group. For the most part, I am in agreement with Mr. James... for the most part. Some responders here have touched on a sense that the article is predominantly blame-shifting away from developers. I have to agree that this seems to be the case. Does that mean developers deserve all blame? I have to say "no" to that. After all, with a user-base, there is always enough blame to go around. As many have stated here, in one way or another, a good piece of software is more than just programming, more than UI design, more than marketing, and more than documentation. It is all of these things combined! If you want to make a good pizza, you start with quality dough. Does the need for quality end there? Of course not! All of the ingredients make the end-product... not just one. I've been reading the stories in this discussion, some of which I remember myself, but each one seems to accuse a different part of the process for the shortfalls. It's not any-one-part, it's all of them. An undocumented feature is a future support call, no matter how well implemented it may be. An over-documented feature is hype marketing, whether it is well implemented or not, and also leads to support calls of a different sort. A feature that is documented and implemented just right is intuitive, which eliminates irrelevant support calls. Put *that* on your ROI. A human's intuition is what guides a human when it meets a challenge it has not faced before. It's part intelligence, part experience. The challenge of making intuitive software is not about making the user's choice more obvious, but about showing how that choice makes a difference in the end result. This debate may go on for generations, what makes a difference is how long we allow ourselves to think that blame is the important thing.

john3347
john3347

All too often, developers lose sense of the intended target of their developments. It seems that quite frequently (even usually) the developer is using their product as a public proclamation of their expertise, not as a tool for the end user. YES, an application should be designed as intuitive as can be made, whether a complicated 3D modeling program or a CD burning application. (I define "intuitive" here as having one step LOGICALLY lead to the next.) If the developer would concentrate more on how simple their product is to use, rather than to showcase how smart and highly trained they (the developer) are, this issue would not even exist. Having made this rant for "the masses", I do also realize that it takes a complicated program to perform many complicated tasks. The goal still should be to make the program INTUITIVE even when it is not a program designed for a novice. Still intuitiveness is imperative and simplicity should be the guideline so long as the intent of the software is not compromised. That's my story, and I'm stickin' to it. (edited to correct a typing error)

cook.sandy
cook.sandy

I am not surprised that the author writes for Microsoft. I have been a full-time computer user (not a technical type) since the days of CP/M and "dot" text editors; an original user of VisiCalc and WordStar. As we all grew together, Microsoft established a paradigm of organization and commands that we all learned over time. We have spent 30 years learning, and then comes VISTA. Microsoft decided that 30 years worth of learning wasn't important. The developers had the only "right" idea about how we should use their applications. Now I am learning again at the age of 73, and it isn't easy. Commands have had their names changed, which is bad enough, but the most important change, and a nearly disastrous one, is that the relationships and grouping of commands have been changed, and unnecessarily. The author may be right that many users want to work with no problems, but I am one user that wants to work (and I do every day) with out developer-imposed problems. Why can't we work together to grow capabilities? That's what we non-technical systems engineers do when we build non-standard systems for corporate or government users. Guess what? It usually works to both side's satisfaction. S Cook - born again VISTA-hater

Tony Hopkinson
Tony Hopkinson

They assume a level of knowledge, admittedly a vastly inaccurate assumption in the main for Access. I could say the same about code gen add ons for popular IDEs, VB6. Case tools.... This foolish assumption that a simpler approach to the discipline, makes the discipline simple. The reason for that is so they can avoid paying big bucks to people who know what they are doing, and some poor clueless numpty a lot less. If you think cleaning up access is bad, wait till you get a 'spreadsheet database'. :( :( :( If you are vain get lots of hair colour in just in case you have any left.

Tony Hopkinson
Tony Hopkinson

between ease of use and intuitive then ? Both concepts are subjective to the user and if you find one that makes the distinction, that isn't a developer/UI specialist I'll give you two medals. Intuitive in software is 'obvious' to someone trained in the domain. Ease of use matches their pattern of use within that domain. How do you define what SHOULD be intuitive to someone else. Developer, analyst or UI expert. This will be easy for you to use says Tony. Why?. Because it was easy for me. Unrealistic expectations...... You tell me what you think is intuitive. Ron Junior tells me what is easy. I do it, are you both happy with the result. More to the point is Fred, who I'd really like to sell it to as well? JJ said it can't be intuitive to everybody, so it's likely to be intuitive to no one....

Sterling chip Camden
Sterling chip Camden

... when Windows 3 was the new interface, we got a lot of pushback from users against porting to Windows, because "icons and mouse clicks are not an intuitive interface". They were used to staying on the keyboard (which upon years of reflection isn't all that bad an idea).

Justin James
Justin James

Jaqui - Great points. "Intuitive" is in the eye of the beholder. I can't remember seeing an app that satisfies new users and power users at the same time, for example. They have different experiences and expectations. J.Ja

programmeroo
programmeroo

Just a few points: 1. If your company makes medical equipment they are no going to hire Joe Developer to design the UI. Likewise, You would not hire a device driver developer to create iPhone Apps. The talent on this forum seems to span many levels. 2. Companies like Oracle, Microsoft, and Cisco make tons of money on training, not on intuitive interfaces. 3. Look at the affect Vista & Office 2007 have had on the PC business. Apple is doing quite well with its new market share. I will not install Vista or Windows 8. I am ready to make the switch. 4. Justin is a very sharp guy and I enjoy his articels, but quite frankly this article and most of the comments don't address a common problem we have in this industry. If you don't make it intuitive, someone else will. We loose business to global companies that look at software interfaces on a global level. 5. Not all users are technical. I hired an admin assistant 5 years out of college. She is an awesome, dedicated worker and has great skills. She is struggling with Office 2007. I can't afford to send everyone to MS Office training.

Justin James
Justin James

I agree completely that UI is overwhelmingly desgined by people who are not qualified to do it! Do I think that every project needs a UI designer? Nah. I think that many apps are simple enough that one is not needed. In other cases, a developer with an eye for design *and* knowledge and training in usability engineering should be sufficient. But for big projects, absolutely. There is no reason why a project with a zillion people on it can't add one or two more to ensure a good UI. J.Ja

seanferd
seanferd

and has a very narrow and focused purpose, running on the exact hardware it was optimized for.

Justin James
Justin James

If you don't think that frustrated users, or unfulfilled expectations are a problem, there is a major disconnect here! For the last 20 years or so, a small fraction of applications have actually done new things, and the rest of them have been promising to be easier to use than their predecessor or competitors. Clearly, we're not there yet, since "easy to use" still sells software. At the same time, we have huge numbers of users trying to operate software that they clearly have no business using, simply because they expect it to be "easy to use". The lost productivity and wasted money by all parties is astronomical. J.Ja

Justin James
Justin James

One of the things that recent developments have unlocked, is new ways to train and assist users (you mentioned screencasting, for example). The flip side is, all too many vendors rely on whichever innovation they find easiest/cheapest to deliver training and documentation in, and ignore users who are not well served like that. How many vendors *only* provide a forum or a wiki or a PDF and call it a day? So yes, I too would love to see more things like screencasts and such... so long as other things like the manual are not ignored! J.Ja

Justin James
Justin James

Yeah, I did overlook them, somewhat intentionally. The trick to using wikis and forums to provide support, is that the company needs to be involved with them. You can't just kick back and think, "gee, we have our forum, looks like support is being handled!" You really need to have some folks looking at those forums, seeing if questions are going unanswered, and so on. At the same time, it is a great way to "take the temperature" of your users and find out what the pain points are, and what might fix them. Even on a forum with some highly motivated users, it helps to establish something like the MVP program to encourage top flight contributors. After all, few people will want to make supporting your application their hobby! J.Ja

read
read

I agree exactly. Well said. [Too bad there isn't a rating system implemented here. If there was I'd simply have pressed the +1 button to say I liked this post.]

Justin James
Justin James

... is that they are *much* more usable and intuitive than their predecessors... assuming you never used the predeccessors. That was Microsoft's big mistake, they underestimated (big time) the difficulty of people having to relearn their systems. The fact of the matter is, Vista and Office 2007 took the existing features, reordered them to be much more logical than the way the feature sets had organically developed over time. But nonetheless, for existing users, they might as well have been moving to a Mac or Linux, in terms of how different the UIs were. So while I *personally* appreciate the changes, and I took the time to learn the new UIs, and I like them now (especially Windows Server 2008), I sympathize 100% with folks who can't stand them. It stuff like this, for example, that keeps me driving Ford products. My first car was a Mercury Sable. As a result, Ford products "feel right" to me, no matter how long or often I drive cars from other manufacturers. J.Ja

chris
chris

another says it's workflow

Sterling chip Camden
Sterling chip Camden

Back when I managed the development of tax preparation software, we started out with an old system that had what seemed like a very strange data entry interface. The operator would type in a code that corresponded to a line item on a tax form, and then enter the amount. These codes were printed on the input sheets, so a tax preparer had to fill out the input sheet by hand and then give it to the operator. We decided to implement a WYSIWYG interface, where the questions on each form were shown on the screen, and you just filled in the blanks. It demoed very well, and many accountants thought it would save them time and money. But the operators hated it, because they had to navigate from one form to another to fill out all the information. So, for the small preparer (and for demos) we kept the WYSIWYG, but we resurrected the high speed code=>data interface for the benefit of the data entry operators.

Jaqui
Jaqui

is follow a standard design model for the ui. When the app in question will be cross platform, the different operating systems / desktops impact the user interface heavily. This is something that it seems the developers of wxwidgets thought about, their widget set is a wrapper for the NATIVE widgets of the target os. That means the Mac user will get an app that is natively cocoa framework, windows user will get an MFC based app, unix and unix-like users get the option of GTK or QT widgets, whichever is default for their install. [ GTK = Gnome, QT = KDE usually ] The other benefit, if shipping binaries rather than sources, wxwidgets is not needed to install the binary, unless you purposely built the app to require them to be installed.

chris
chris

that if you don't say it's intuitive someone else will. too many management types get sold too many bad things from too many "sales people"....and they're all sales people.

Tony Hopkinson
Tony Hopkinson

hers, mine, my dogs ? If what was intuitive was common never mind obvious we wouldn't be having this discussion. You look at this site there's a Discussions tab, and a questions tab. New arrivals regularly mess this up. Is the layout unintuitive, certainly to some. How would you change it to make it more intuitive? I'm all ears.....

Sterling chip Camden
Sterling chip Camden

... are doomed to fail under their own weight. But there's no reason why a six person team can't include a UI designer.

TuesdayNews
TuesdayNews

First, I don't buy your premise. People take graduate courses in applying complex software (e.g. ArcGIS, NASTRAN). I've never heard a single complaint that the software required college training or was not "intuitive enough". It was understood that the software could yield inaccurate results without knowledge of its underlying principles. It appears the problem, as you see it, is that some developers outsell their competitors by claiming their product is "easy to use". So one company's loss is another's gain. Neither is the claim of lost productivity apparent. What's a user's alternative...hiring a specialist to use the software, developing their own in-house solution, cranking the numbers with a calculator? Regardless, I don't see the financial downside to your industry. Your software gets purchased and you make your money. If you want to advocate the interests of end users, you might start with an article about software written by developers who don't have a proper background in the field their product is used in.

john3347
john3347

Mr James, I respect your opinion, but I think your statement is simply not correct. I have an example to back up this statement. I met a person recently who was a proof reader by profession and had used Mac computers on the job for several years. He had a home computer with Windows 3.11, also for several years. He bought a new computer with Vista and got familiar with that. It was a few months into his Vista experience when I met him. I asked him if he preferred Vista to other previous OS's. His response was I never used anything between 3.11 and Vista except Mac. I invited him to my home to sample both Windows 2000 Pro and Windows XP Pro. To make a long story short, he gave his son the Vista machine and bought a system with Vista Business and "upgraded" it to XP before even using it. This is based on no more than 1 hour familiarity with the two previous OS's. This is testament to the lack of intuitiveness of Vista.

Sterling chip Camden
Sterling chip Camden

Funny story: I was on a tight schedule to catch a ferry, but I was waiting for my wife to get home with the VW Eurovan so I could go. She screeched to a halt in front of the house, and as we passed she said "you've got to get gas, we're almost empty." "Oh shit," I thought, "I'm going to either miss the ferry or run out of gas." I sped off to the gas station as fast as I could go. Luckily, before I got there, I noticed that the gauge did not read empty -- it was full. The VW engineers wanted to make the dial internationally intelligible, so instead of "E" and "F", they used fractions: "0/1" and "1/1", with a "1/2" in the middle. For some reason, my wife assumed that the needle leaning all the way to "1/1" meant that we were empty instead of full (I guess that makes her a pessimist).

Sterling chip Camden
Sterling chip Camden

Sometimes, the pre-automated workflow is determined by the constraints of the system -- and those constraints can often be lifted through automation. So it may make sense *not* to stick to the "inuitive" workflow -- but you have to be careful to balance productivity against user comfort.

Justin James
Justin James

Sorry for that confusion then! I probably should ahve made that more clear. Yup, I have tons of sympathy for the developer (hey, I *am* one, after all!), but the end result scenario stinks... the user/customer wastes time and money, the developer gets dumped on (even when the fault lay in management or systems design), no one is happy in these situations. :( J.Ja

Tony Hopkinson
Tony Hopkinson

Don't even have to take your mittens off to count those who don't. So blaming an industry wide malaise on a relatively small number of inexpereienced incompetents isn't all that useful. Even less so when even those that fall into this category were specifically employed because they are cheap. Pick a piece of software, pick a small but broad selection of users, try and get them to agree on at would be intuitive, that's te real problem. Intuition in UI definition is mainly learned behaviours. The button with the printer on it prints, at it's simplest. If you come from a paperless environment you might expect a save as pdf, even email it. Effectively the same operation, produce a copy of the document for distribution, but software designed for one isn't going to do the other. To satisfy both, you could be talking two to three functions, relearning the UI, different shortcuts. A default save as folder, a new printer setup and MRU list... Or do you change the operation? Only have save as, leave distribution as an extra? This is all very simple with a minimal impact on the existing architecture. Where do you go when an 'obvious' usability change mkes a complete arse out of your design which you are successfully selling it to people who use it a different way. Anyone who starts selling off the shelf software as intuitive, has a marketing background not a technical one.

TuesdayNews
TuesdayNews

"... in-house software often fails to be intuitive as well. I doubt a calculator would be much use, .... They usually are not intuitive to use, simple to make changes, or easy to fix when they get corrupted. Definitely less efficient than well-written software." That's the point I was making. When evaluating lost productivity/money, your baseline should be the complete absence of the software. When you look at the costs versus doing the job with pencil & paper, with a specialist, etc. then I think you'll agree that an uneducated user fumbling around with the software isn't as expensive as it seems. I think the problem's being exaggerated. Most users are going to buy the software, support, etc. given the alternatives are even less productive. Unquestionably, the ideal would be that users have realistic expectations, get the proper training, and never complain about anything to the author so he doesn't have to dwell on his "frustrations".

TuesdayNews
TuesdayNews

If you're not an expert in say, orbital mechanics, then you'd better have someone who is check your work. Granted, most developers do this, but some don't.

TuesdayNews
TuesdayNews

I don't disagree that it's a waste of money for the users. However, your original article clearly is advocating the interests of developers, not users. Seems like a switcheroo to me. You start off by complaining about unrealistic user expectations and then switch to sympathy for the user's financial loss. I guess that's where I get confused.

Glenn from Iowa
Glenn from Iowa

"What's a user's alternative...hiring a specialist to use the software, developing their own in-house solution, cranking the numbers with a calculator?" While I doubt someone would actually hire a specialist (perhaps a consultant?), the author clearly pointed out that if the software is not easy to use, people will stop using it. See below for financial ramifications for this. Developing their own in-house software (or purchased custom software) is definitely a possibility, although in-house software often fails to be intuitive as well. I doubt a calculator would be much use, but you'd be surprised how many complex spreadsheets are used to track and calculate data. They usually are not intuitive to use, simple to make changes, or easy to fix when they get corrupted. Definitely less efficient than well-written software. "Regardless, I don't see the financial downside to your industry. Your software gets purchased and you make your money." The downside for the company that purchased the software is wasted money for software purchased, but not used (possibly millions of $) and then doing the task in a less efficient way than the purchased software presumably would do it. The downside for the developing company is that most complex software has ongoing support, maintenance, upgrades, etc. that the purchasing company will not renew or purchase. The author's premise is that perhaps some complex software is impossible to make completely intuitive, even for users with domain knowledge. The primary premise of the author is that some software (he mentions ERP and CRM specifically, and I would presume that your examples of ArcGIS and NASTRAN would fall into that category also) is sufficiently complex that it cannot be used "intuitively" out of the box. Perhaps the conclusion would be that, yes, some software is too complex to be completely intuitive. Therefore, even users with domain knowledge need, let me repeat, need to have some training to use it effectively. As I have stated in other posts, I believe that an intuitive interface and user training are inextricably linked and that when you have less of one, you need to have more of the other. Many problems have shown up when companies, who have often spent thousands or millions of dollars on the software, believe they shouldn't have train users for the complex and extremely costly software. Software setup is another issue, but it usually doesn't apply quite as often for moderately complex software such as word processing software.

fidlrjiffy
fidlrjiffy

The proper background for a developer is development. The idea that a software developer should be, say, a finance person and a developer is as wrong headed as expecting a finance person to be a developer (we would sure get a lot of Excel spreadsheets, wouldn't we?). A software developer designing a user facing product needs to be an expert in doing exactly that and I do advocate that the easier it is to use, even by perception, the better. The other skill needed, which is often lacking, is the ability to understand the needs of the users of the software and to translate that into usable software. You may not find that in one person but that is the goal of the software. When you're dealing with a custom product there is really no excuse, unless the customer doesn't want to pay for it, a common occurrence, for the software not doing what the customer needs and still being difficult to use. It's clearly a balancing act. One of the common frustrations of developers is the unrealistic expectations of users in terms of what software, and especially customer software, costs. If a proper background is that a developer knows your job and the developer job that is worth two salaries, no? There's that old cartoon of the swing and what the customer wanted, what engineering designed, yada, yada, yada, and they really wanted a tire on a rope. To develop good software one really does need to have expertise beyond programming. That's why it takes more than one person, takes time, and takes money.

Justin James
Justin James

You talk about some pretty advanced stuff, I am actually pretty surprised that you are missing the point here. I think maybe your experiences are exactly the stumbling block here. I am not talking about trying to put, say, ArcGIS, SAS, Mathematica, or Autodesk in front of the receptionist. I agree, those are packages which are intimately tied to years of learning. What I am talking about are people purchasing systems and applications that they assume should be "intuitive" to users, but really aren't and can't be. Things like ERP and CRM. Image editing. Word processing (sure, you can use Word to crank out basic items with little knowledge, but it takes a lot of learning to be able to do the more complex tasks). Etc. If you can't see how it is a huge waste of money, time, and other financial resources to keep trying to put these kinds of packages in front of users who lack the knowledge to really leverage them... well, I don't know what to say. J.Ja

Tony Hopkinson
Tony Hopkinson

Who's background. Your's a competitors, a related domain? If they are getting that, when do they learn how to develop? Where do things like outsourcing, and subcontracting which throw away domain knowledge fit in? Are you prepared to pay for exacty what you want. Is what you think you want, what you really want. Does the guy sat next to agree that waht you want is what he wants? Given even two users in the same business using the same software want different things, how is a software developer meant to meet both those needs at the cost of one of them? Intuitive, user friendly is too subjective for a one size fits all approach, yet customerss and softwareware devlopers want the cost savings that model engenders. The basics are doable, this is in a top level menu, that's a button, this is a list box. Jargon, process, layout, if you aren't prepared to pay, software devlopers aren't prepared to do, it's that simple. Don't even go near vendor lock in, How many MS consumers wanted the ribbon interface?

Justin James
Justin James

I don't dispute what you're saying. The fact is, computers are (largely) personal devices. I find my particular cell phone a cinch to use, but I know other people who are baffled by it. Ditto for my super ergonomic keyboard and my vertical mouse. On the flip side, if you take Vista and XP, and compare them from a neutral stance, it would be hard to say that XP is more intuitive or usable than Vista. The devil is in the details. Vista is significantly more consistent in terms of how things work, where they are located, and so on than XP. Where it makes life miserable, is if you are used to the pre-Vista way of doing things. In terms of your friend who had trouble with Vista... the fact is, it is an extremely complex system. Any modern OS is. Last weekend, I noticed that my local Best Buy had some Macs on display. The last time I used a Mac, it was OS 8 or OS 9 (a VERY long time ago!). Did I find it "intuitive"? No way. My brain is "trained" to do things the Windows Way. At the same time, taking a step back and honestly evaluating it, I can definitely see why people who are new to computers find them easy to use. Great example of this: I bought my wife an iPod Touch for Christmas. She wanted a laptop, but all she really wanted, was to be able to get on the Internet for mild Web usage from the living room. Indeed, the iPod Touch meets her needs better than a laptop would have, overall. But I tell you, it took her TWO WEEKS to figure out how to turn it off! I had to show her how to scroll, which I thought was "intuitive", especially since every ad for iPod Touch and the iPhone show off that functionality. At the end of the day, these systems are complex, no matter how you cut it. If you look at the number of "moving parts" in a modern OS, it is probably about as complex as an aircraft carrier, and took just as man man-hours to engineer. When I said that Vista is "more usable and intuitive", I meant just that: a comparative statement. When evaluated from the field of usability engineering, it is a true statement. Does it mean that anyone and everyone is going to be able to "get" Vista, even if they aren't used to XP? Nope. I used to date a girl who took over 10 years to learn to drive. At the same time, there are tons of people out there operating computers who don't actually know how to use them, let alone use them to their utmost. Think of the people at the office with the "cheat sheet" explaining to them exactly how to start their Web browser, or how to open a document. Every office I have worked in had one of those. :) J.Ja

Sterling chip Camden
Sterling chip Camden

... your ability to showcase XP's strengths. I agree with you that MS gummed up a few things in Vista, but I wouldn't be too certain that your friend's newfound opinion is entirely objective and informed.

Editor's Picks