Lessons from the Classic Mac
We all do tons of user interface design, both in games and in business software. One of my favorite books on usability design is “Macintosh Human Interface Design”. It’s a classic; I’ve been reading it off and on since as long as I can remember. Much of it is woefully out of date. But, as with all visionary products, it has lessons to teach us to this day.
So, what can we learn from a user interface three decades old?
Design for the worst case scenario
In the era of the original Macintosh, they spent a lot of time designing their applications to handle the worst-case scenario smoothly. For them, the worst-case graphics meant two colors – quite a stretch when we nowadays think in floating point 32-bit color. The Macintosh team solved this by requiring each icon to be designed in black and white first, and converted to color later. This ensured that all the icons had a consistent, striking shape that was easily recognizable, regardless of your monitor’s color depth.
Nowadays, you need to identify your user interface’s worst case scenario. Your user interface will display information and receive information – which things will change? You may design it for a small number of columns now, but need to support more later. You may design a graph to work great with three lines, but when fifty lines are added it may be unreadable. What growth will cause your interface to break?
The lesson is, even if your designs works now, what will happen if your assumptions change?
Have a reason for everything
The Mac design book is full of lots of interesting little explanations: The little “…” that appears on a menu item tells you that clicking it will open a dialog box. All controls related to each other should be inside a rectangular line called a group box to indicate that their functions overlap. Text labels should be evenly aligned because it makes reading faster. Any menu selection should be flashed so the user knows what they clicked.
Having an explanations is important, more so than the quality of the explanation. When you’re designing, you need to have a reason for everything, even if you have to make one up! A bad reason - even if it’s really lame - allows your colleagues to debate constructively. Someone who can make a better argument can help improve your design, and improved design is what we want.
Have standards, and stick to them!
Way back when, the Macintosh had a standard that said that the “Save” button was on the bottom right hand corner of a dialog box, and the “Cancel” button was immediately to its left. They had a reason for doing that, because they said the default action should be in the bottom right corner. When Microsoft came out with Windows, they swapped places. They also had a reason: they wanted the default choice to be harmless, so if a user clicked without paying attention no damage would be done.
Which standard is right? It doesn’t matter! The important lesson is to be consistent. If you make a nifty decision in one part of your application, go look at the rest of the application and see if you can apply that lesson elsewhere.
Keep thinking
Keep reading, and discussing, and debating your design. If you cultivate an atmosphere of appreciating suggestions, you’ll wind up with a better result.
Happy designing!
