During the development of v2.0, almost everything went according to plan. Almost.

What didn’t go right, at least not entirely, was scheduling. In fact, the usability testing for scheduling went absolutely horribly. Embarrassingly so. And it wasn’t just isolated to a single tester: in fact, only one user in the test group managed to figure it out at all.

The question is, of course, what happened? We should know this stuff cold, shouldn’t we?

Looking back, it’s pretty easy to tell where things flew off the tracks, and it started with a simple thing: there wasn’t enough room in the main window to fit the Copy Now button.

SuperDuper!’s main window isn’t “narrow”, and we didn’t want to widen it. A small issue, easily understandable, that snowballed into something fundamentally wrong. Here’s how.

It’s very difficult, when you’re going through a months-long development process, to stay focused on usability. You become so familiar with the concepts you’ve designed that it’s difficult to remember that users—the users you’re trying to serve—don’t necessarily approach the feature set the same way you do.

So, we’d added a “Saved Settings” feature to SuperDuper! as one of the very first changes on the roadmap that would eventually bring us to full scheduling. This was a way to save a whole SuperDuper! setup—from the drives and script to the options—and had been part of SuperDuper! for a very long time. We rarely got any questions about it—usually a good thing.

The initial design of scheduling basically used these documents “behind the scenes”: the user clicked Copy Later, the settings were saved for them, a scheduled copy “job” was created and appeared in a Scheduled Copies window, all automatically. That copy then ran at an interval selected by the user. All pretty straightforward.

But, as I said, Copy Later didn’t fit: a definite problem.

Well, since we knew that we were basing our scheduling around these “settings”—in essence, a SuperDuper! document—we decided that we’d just make the scheduling part of the document itself! After all, that’s sort of what was going on anyway, and obviously people were familiar with these saved settings documents, they’d been in the product for a year! (Plus, this resolved the whole issue of managing “hidden” documents behind the scenes, something that didn’t feel entirely right.)

The design I came up with was this: rather than a Copy Later button, I did what I thought was the next best thing. I moved scheduling to a tab in Options called, of all things, Scheduling. You’d just switch to that, check a box that said “Automatically copy (source) to (destination)”, set the schedule, save the document, and bingo—scheduled document! And all without any changes to the main window.

Problem solved. Looked nice, too! And there was much rejoicing: perfect!

Design settled, Bruce expended much effort implementing it exactly that way.

But during that process, there were some warning signs that should have told me something was wrong. Bruce would come back with questions like “When exactly does the document get scheduled? When it’s saved? Do we force a save when the check the box?” There were intermediate builds with little quirks and small issues that needed to be worked on. These were all problems with solutions, but the fact that they were coming up at all—questions about basic operation that didn’t fall immediately out of the design—should have raised a lot of flags. A whole United Nations of them.

But they didn’t. Or, if they did, I aggressively ignored them. Big mistake.

This was totally my fault: although I wasn’t doing the implementation, the developer in me was thinking about implementation details from a developer’s perspective—never a good thing. Because I knew what was going on behind the scenes, I let it influence the way I framed the UI, and totally lost the light—my “user” perspective—thinking something like:

  • We have documents.
  • User, of course, knows we have documents.
  • Scheduling uses documents.
  • Therefore user will know that documents are the way that scheduling works.

It’s so obvious!

Nothing quite like a usability test to toss cold water on that kind of crap thinking. And we’ll pick up that sad saga in the next entry.