Software and the languages used to write them change over time, but the principles behind software design often remains intact. This is proven out when looking at any guidelines written in the 80’s. The languages and technology are all outdated, but the basic problems of design are easy to relate to. If, for example, you read Apple’s design guide for the Apple II, you could be convinced that it was a design guide written for the modern audience.
Here are some notes I’ve taken from the guide:
There are two primary functions of a good human interface design: make the product easy to learn, and make it easy to use. We all know that our customers can learn to use our programs faster if they look and act like other programs with which the customer is already familiar.
This design pattern is more about reigning in experimental design people who want to innovate rather than follow convention. It’s usually better to use interfaces that people are already used to using to lower the barrier of entry.
Human interface design should come into play from the very beginning. A good design is no mean task: expect to expend a great deal of design and programming effort toward a smooth interface. For most programs with a good human interface, the design of that interface consumes more design time, is more prone to bugs, and is harder to test than any other part.
This point still holds today. Human interface design includes both UX research and UI design. Those respective feilds have steps that start out at creating user stories and end at A/B testing designs till you get a perfect fit. Due to the nature of the process, a better design can be had if design is handled at the beginning of development so that designers don’t have to work around tools that have already been built by developers.
Human interface testing is quite different from the kind of exhaustive “boundary condition” testing used to uncover bugs. You should begin testing as early as possible, using drafted friends, relatives, and new employees, to uncover the really big holes in your design. As you get closer to a finished product, try it out on larger groups drawn from the target population.
It is imperative that the designers actually watch people use the program. Do not just send off copies of the program and expect written responses. Get the users and designers in a quiet room together.
It can be very tempting to limit usability research to surveys, but designers and users should be able to have a two way communication that allows for immediate feedback. UX researchers can even gauge a user’s impressions of a design simply by looking at a user’s body language, information that cannot be extracted from text.
User interaction should be simple and easy to remember. Spend the necessary time to design a user interface that presents the best trade off between alternate design issues.
Once the user has become basically familiar with the human interface, if she guesses at an unknown response, she should be correct 95% of the time.
This point is the most obvious, but one of the hardest to implement. Different people have different learning curves, and overall simplicity depends on the type of application. For example, a classical book web app(Libbri) that I partially designed attempts to simplify online reading by grouping chapters into an accordion menu. Interacting with the menu is simple and the plus UI is familiar to anyone that has interacted with a similar interface.
However, enterprise apps may deal with farm more complex interactions that are completely unique to a company. Simplicity for that app may mean something completely different. It may simply mean automating a tedious task.
Here are some bonus points to take away from Apple’s design guide:
Consistency: All programs written for a given computer should have as great a commonality as is practical.
Efficiency: The user should be able to perform a desired task in as little perceived time as possible.
Speed: Actual speed of operations is important, but perceived speed is even more important. React to user’s input immediately. A user will interpret any delay of more than a few tenths of a second after he has pressed RETURN to mean that either the program or the user has made an error. If you need to make a computation, first acknowledge that you have accepted the input.