A former community discussing the business of software, from the smallest shareware operation to Microsoft. A part of Joel on Software.
We're closed, folks!
Doug Nebeker ("Doug")
I just receive an email from a customer, that got me thinking, is my software really that complicated. Customers says:
1. My software is too difficult to use and that the software should look like X & Y (which are my competitors).
2. That he can use other software's (X & Y) without reading the user guide and can set them up in hours but mine requires that he reads the user guide and takes days to setup.
I then went ahead to reply the customer that we cannot look like X & Y because if we do we will not be different and that we designed the software to the best of our abilities.
Do you think all software's without user guide are really that user friendly and usable?
A lot of products don't have very good documentation.
Most users don't read documentation because they assume it will be confusing and useless.
It's better to write software that doesn't need a manual for most things. This reduces support costs.
Writing such software is difficult and takes a long time, with much dogfooding and iterations.
Such software is generally considered good software.
User friendly is often taken to mean that the user doesn't have to think about how to use your software, and that seems to be the way your customer sees it as well. This definition of user friendly doesn't benefit the user or the developer/vendor.
If the user doesn't have to think about how to operate software, then the software isn't providing anything to the user that s/he wasn't already getting without using the software. It's like eating for the sake of eating.
For software developers and vendors, if your customers don't have to think about how to operate your software, then why should they buy your software? Simply consuming software without any mental engagement is pointless, and if your software is so similar to "X & Y" that the user doesn't have to consider differences in the operation of that software, you don't have anything of value to offer to the user.
"without user guide are ... usable"
If your software is different enough from "X & Y" to be worth using, then the user has to learn how to use your software. The user can a) experiment, b) learn from some type of user guide or c) get the vendor to teach him/her. Somehow, that learning has to be accomplished with minimal cost (in terms of time and money) to both the user and the vendor. If that learning doesn't take place, your software isn't usable.
Every customer is different, but this customer appears to be having problems learning how to use your software. Fix that problem and you probably fix your problem with this customer. What the customer says is the problem may not be exactly the same as what the customer's problem actually is. So, providing your software without a user guide isn't the solution, but providing a better user guide probably is.
The customer also said that he has also tried the X& Y but don't like them either that's why he ordered our software, which means we did somethings better.
The customer wanted us to look like X & Y yet the customer does not like X & Y.
@Howard Ness You may be right. when you stated:
"What the customer says is the problem may not be exactly the same as what the customer's problem actually is."
I also have a very broad definition of user guide in mind. As in "anything that guides the user." Your menus, tooltips, static text, help system, command structure, even the graphic layout of the program itself can help guide a user. Unless your users are programmers, accountants or engineers, they don't read stand alone user manuals, and even in those specific user groups, the number who eagerly read manuals is very small.
A long time ago... let's say 25-40 years ago, I really enjoyed reading user manuals for software and hardware and would read them cover to cover. Nearly all were well written, often by people who were experts in the field. Many manuals were tutorials and introductions to the subject matter. Hardware came with schematics and descriptions of how various sub modules worked, in case you needed to fix it.
Wow, those days are over. Manuals these days are obviously thrown together over the years by random different people who have no idea what the device does.
For hardware, you have a 360 page manual consisting of 20 repeated pages in 12 different languages. The first 10 pages consist of government mandated safety warnings, the next 6 are descriptions on how to unpack the box and plug it in, the last 4 are a list of service centers in various countries.
For software you have a 360 page manual consisting of 20 repeated pages in 12 different languages. The first 18 pages consist of legal disclaimers and binding contract agreements, the next 2 are descriptions on insert the CD and double click on the installer, and the last sentence says if you need more information visit their web site.
Who in their right mind would read such manuals?
It has nothing to do with the user being lazy, it's that 99% of manuals are shit. Mine, Howards, everybody here, I'll give the benefit of the doubt and say we are all the 1% with a fantastic manual. So? The user doesn't care to find out since there's a 99% chance it isn't.
> My software is too difficult to use and that the software should look like X & Y (which are my competitors).
I do not believe a user manual has much to do with it.
This is about UX and being intuitively clear what to do on each step of using the software.
Non-intuitive software has a much lower trial-to-purchase ratio, so I believe it worth it to let a UX expert to take a look and suggest some improvements.
Sunday, August 25, 2013
This is a common problem.
A software that is usable without guide usually is very simple. Can give a first "good impression" but falls short.
On the other side once user chose a simpler solution (she will not initially understand it is limited) you lost the sale. Hardly she will reconsider and possibly keep the impression that whatever the choice the software would not match her needs.
The best solution is to have a minimal set of functions that are intuitive and that the user can explore with no guide. Once the user asks for support simply point the user guide.
Sunday, August 25, 2013
"let a UX expert to take a look and suggest some improvements"
Usability specialists, whether calling themselves HF, HUI, UI, UX, etc, can do usability testing with actual users to see where there are problems during real use of the product. Such testing is not difficult and if you have more time than money you can easily do it yourself. But a specialist can do a competent job as well.
However, listen carefully. Under no circumstances should you ever put one of these specialists in control of deciding how to fix things. They are always wrong. If you don't believe me, look at software and web sites designed by usability experts themselves.
Here is a comprehensive list of the people who are actual usability experts regarding the usability of your product:
1. The Users of your Product
a. first time users with a problem to solve that the program addresses
b. habitual users with ongoing problems to solve
Notice that professional usability specialists are not among these. They have a problem to solve - getting you to pay them - which is not among the problems your program should be designed to address.
To find out about usability problems:
You as user:
1. Dogfood the program yourself and observe the problems through your own use.
2. Demonstrate it publicly and see where it is clunky.
3. Write tutorials and notice where you have too many steps, or ones that require thinking that isn't an essential part of the problem to be solved - like if you make the user do arithmetic because your rescaling tool is only in pixels and doesn't allow percentages, or vice versa.
4. Think about workflow for tasks and what would be needed to simplify things. Doesn't matter how much engineering work is involved - ask what would make it easier for users first, not what is easiest for you.
1. Notice where you get a lot of user requests for help. Workflow problems are there.
2. Notice where you never receive any feedback at all, good or bad, those are sections that are so complicated or unintuitive that no one even knows what it does.
3. Observe what people are trying to do in real life.
You do not need to add every feature request. You shouldn't. In fact you should probably ignore feature requests completely unless you get the exact same one over and over from many different people. Instead you should notice the questions and confusion, and address that using your own design sense. Not that of the users.
I don't know who design things at gmail. Is it a known HF designer?
Obviously there are also non-HUI specialists who are just as lousy at design as specialists are.
Their criticism of UI is good, as is their ability to test. But they are not designers.
Tell me, what is your average rating of films where Roger Ebert was the producer or director? Is it similar to the rating of films made by other random people? How does it compare to your ratings of producers like Kurosawa who have made known good films?
One might argue this is a poster example of hypocrisy, but nevertheless here is what Microsoft has to say on UX:
Tuesday, August 27, 2013
> For software you have a 360 page manual consisting of 20
> repeated pages in 12 different languages. The first
> 18 pages consist of legal disclaimers and binding contract
> agreements, the next 2 are descriptions on insert the CD
> and double click on the installer, and the last sentence
> says if you need more information visit their web site.
+100! You're absolutely right, Scott! I agree with every word.
Thursday, August 29, 2013
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz