"Users don't always want things to work faster"?

I was skeptical of this premise when I read a Fast Company article on the subject. While I recognized that this is a real thing companies do, and I acknowledged that the article accurately described it, I still didn't believe it as a principle of design. "The quicker, the better," was my motto.

Well... not so fast!

Another technological generalization, "a bigger screen means a better user experience", left us with 'smart' phones that can't fit in our pockets. Analogously, I've discovered there is at least one usage case where you may want things pokier than they could be.

I've spent more time than I care to admit playing 'games' that were broadly similar to my dice game. In the old system, I would pick a number of contestants, build a spreadsheet (or text file) with the tournament playoff chart, figure out the differences in team strengths, and then roll through the matches, one at a time, one roll for each side, and do any necessary modifications to the sums in my head to get the proper results for a game, and eventually the series, and sometime even later, the tournament. It could take 10 minutes or more to go through all these steps, and although it was entertaining, in recent years I've always felt like reconsidering my life choices at the end of a session.

I was excited to make an automated version, partly because I thought it would be an interesting programming exercise and challenge, and perhaps partly for other reasons (like getting more people to look at my site), but in no less part because I thought it'd be fun, and that automating this process would keep all of the thrills of the old random-number games without their downsides.

In the current automatic system, I have built it to load all the (pre-configured) contestants, randomize playoff seeds, match them up against each other, run all the matches, match up the winners of those matches, and so on, to the end. The calculations are done virtually instantly, and you can have as many tournaments as you want, one for each refresh of the page.

What I didn't foresee is that the generator works too well. The trouble is this: by having no delays or human involvement, there is no dramatic tension.

The final outcome of every match is known not only to the computer, but to the user, virtually from the beginning. This is roughly the same difference as there is between keeping up with a live sports event, and looking at a complete listing of the results two years after it happened. I suppose it's still theoretically possible to get excited about that, if you're a real history or stats buff, but most people don't have that good of an imagination.

As a mathematical puzzle, there's nothing that needs to be added to it, although I may do so anyway, for the sake of variety and keeping things interesting. But as a spectator event, it is paltry, and its efficiency is primarily to blame for this.

I've concluded from this exercise that 1) there should probably be some kind of user interactive component, even if it's just clicking a button to run one or two contests at a time, and 2) the Fast Company, as I should have guessed from the name, has a little more experience with speed than I do: enough to know that it isn't always best.