This week I was doing work on LimeLM that involved virtual machines. In particular preventing piracy in an environment where the whole PC can be duplicated bit-for-bit. As you can imagine this meant installing and using many virtual machines; VMware, Virtual PC, Virtual Box, Hyper-V, Parallels, and every other obscure VM.
You’re seeing this right – 4 windows stacked on top of one another. They’re even polite enough to welcome me twice.
No one reads dialogs.
The worst part is that I still haven’t read what the dialogs say – and this is even after I cropped & arranged the dialogs in Photoshop, proof-read this article 3 times, and written this very sentence. They could say some pretty vulgar things and I wouldn’t even know.
If a dialog has more than 3 words I just look at the buttons and guess what the dialog says. Here’s what I read:
I clicked OK on the last dialog, and a new dialog popped up:
Oh God, they’re breeding. I’m sure “Copyright Notice” is real page-turner, but I have better things to do.
What can you learn from Parallels’ Mistakes?
By this point I’ve forgotten what Parallels Workstation is. I think it’s a dialog generating machine.
What can we learn from Parallels’ horrific design?
- Their developers haven’t read The Elements of Style. Rule 17: Omit needless words.
- The Parallels developers don’t do clean installs of their programs.
- They haven’t sat a user down and had them use Parallels from start to finish (from setup to the first virtual machine).
“Ok, but what can I apply to my own work?”
Parallels’ first-run faults seem easy to apply for web & desktop developers alike. But if you clear the front door – let users actually use your program – will you convert more trial users to paying users? What if you clutter the first run – do users care?
Yes, they do.
In wyBuild’s early betas (back when it was still called InstantUpdate Designer) I ran a split test comparing how long a person used wyBuild. Group A had a version of wyBuild with crap similar to Parallels Workstation; the user had to dismiss a couple of “useful” dialogs before they could use wyBuild. Group B had an experience similar to what we use today; a dead-simple first screen:
I foolishly thought the first-run dialog boxes would give users a better understanding of our product.
In retrospect the results aren’t surprising. Group B, the group that wasn’t interrupted, used wyBuild more than twice as long as Group A. More than that, the people in Group B were around 2 times as likely to save their project and build their first update.
So, the group that was bothered by a bunch of pointless dialogs often quit before they’d created their first update. (And this was back when wyBuild was free. The only measure of success was if the user actually used the product).
Because this data was collected remotely (it was opt-in, of course; I’m not a sleaze), we couldn’t ask the people in Group A why they gave up. If I were to guess I’d say their thoughts ranged from “It’s too confusing” to “I’ll do it later, when I have some free time” (i.e. never).
Anticlimactic lesson: Don’t waste your users’ time.
You almost certainly have a competitor that is faster, cheaper, better, or all of the above. So, the next time you add just one more dialog or just one more field to your order webpage, think about how many potential customers you’re losing.
Scratch that. Test to see how many users you’re losing.
Subscribe to Wyatt Says...
Subscribe to the 'Wyatt Says...' RSS Feed and keep up to date on on my articles on updaters, usability, open source C# components, and software licensing.