I fight for the users. -- Tron
At work, I'm a computer programmer; my job involves software and interface design. At home, I play M:TG, and enjoy reading Mark Rosewater's articles on game design. Every now and then, the two cross over and influence each other; one such example came up this week, so it's a good excuse to write something up (or write something down - isn't English a weird language) on the subject.
First, the Magic part. This is an article from late last year, discussing one of the mechanics from the then-new Scars of Mirrodin expansion set; and in discussing Metalcraft, the article explains many things about the nature of "threshold mechanics". But that's not the point of what I'm saying here. For that, read down as far as Lesson #2: There's A Sweet Spot.
If the ability had been written as "Metalcraft 3", then additional design space would have been opened up for cards with "Metalcraft 4" or "Metalcraft 2" or "Metalcraft 17" if R&D so desired. More flexibility is a good thing, right? Mark puts it better than I could: "We don't add a number, because there's no reason to open up future design space that we won't use."
In any design, be it a collectible card game, a web site, an automatic toaster, or a novel, this issue will always come up. We could number the pages of a book as "1+1", "2+1", "3+1", "4+1", etc, thus allowing ourselves to write books in the future where the page numbers increment by some other number. But this would be a bad decision, because we'll never want to do that, and it adds a completely unnecessary cost - complexity and mindspace. Every element that the user must grok takes up space in his/her mind.
With user-interface design, I have adopted the assumptions that the user:
- Starts out knowing nothing about our system
- Does not read the documentation
- Won't click the crucial button that would have explained everything
- Is in a hurry, and
- Has a very specific goal.
- Make our system similar to everyone else's. People can handle "log in by entering username and password", and "sign up with an email address, then click the link in the email we send you".
- Ensure that the interface is itself intuitive, at least for straight-forward actions.
- Make normal actions easy (and unusual actions possible). Don't force the user to click twenty different links to find the one that does what most people will want first off anyway.
- Keep the screen uncluttered.
- What color do you want your paper to be?
- What font would you like the acknowledgements page to use?
- By what number should the page numbers increase?
- Should the text color alternate on left/right pages?
Are these questions you need to answer before you see your document? No. They're just clutter; and even if they're pushed off to a "Document Options" screen, #3 and #4 should not even be asked. When you design a communication protocol, don't make every single element capable of having multiple values, just because someone might maybe want to put a second source port into his TCP packet. When you design a device for humans to use, don't go to great lengths to ensure that it can be used by someone who stands five meters high.
Everyone wants to make powerful software. Hey look, not only can you do this, but you can do this and this and this too! In every design discussion, somebody needs to fight for the users. Yes, that means dumbing it down. It's the right thing to do.