A 12-year-old MSDN article still rings true -- and provides excellent guidance when JavaScript may be giving us too much to play with
Note: This week Iβm stepping aside to allow my colleague, Jonathan Freeman, to post this killer piece on UI design. He has been a UI developer for my company, Open Software Integrators, since 2011. β Andy
One of the best articles Iβve ever read on user interface design is this 12-year-old classic β written by Microsoft, no less. Published long before smartphones and modern tablets emerged, it fully explains the essence of good UI design. Amazingly, it criticizes Microsoftβs own UIs and explains why they are bad, though it was written at a time when Microsoft was not known for its humility.
Because my company has a mobile application division β and increasingly does full application development in our enterprise open source division β I often have to explain what makes a good or bad UI to customers. Iβve frequently referred to this article by way of explanation.
[ Learn how to work smarter, not harder with InfoWorldβs roundup of all the tips and trends programmers need to know in the Developersβ Survival Guide. Download the PDF today! | Keep up with the latest developer news with InfoWorldβs Developer World newsletter. ]
See, Microsoft decided it wanted to solve a big problem with software: Itβs hard to use. So it conducted research on how its customers use and learn software and guessed the reasons why it was so hard for users. Microsoft realized users werenβt understanding the conceptual model of the product, werenβt learning common tasks after repetition, and found it hard to figure out what each screen was supposed to do. Deductive user interfaces, as Microsoft called them, were the culprit.
The deductive user interface
The basic concept of a deductive user interface is that a user is presented with a pile of possible actions on a single screen. Then the user has to go through bit by bit figuring out (or deducing) what does what, whatβs related, and what actions can be taken. Power users might breeze through this introductory period and get to work because that sort of exploration is comfortable for them. Unfortunately, the majority of your user base doesnβt fall in that category. A deductive interface is just a pain for the average user.
Two great examples of deductive interfaces come immediately to mind. The first, given that tax season just ended, is the almighty IRS 1040 U.S. Individual Income Tax Return form. This form has instructions, but in general, you have to figure out what to do and what the terms mean. The form comes close to assuming you are an accountant familiar with tax law. This obscurity has created a whole industry of tax preparation experts who not only know the form but everything behind it.
The second example is Windows Explorer. When Microsoft originally came up with this UI motif in Windows 95, it suggested everyone use it. There were controls for Visual Basic that helped you apply the Explorer interface to your custom applications.
Windows Explorer is almost intuitive if youβve grown up in the paper world. You have data, which you think of as documents that go in folders β except folders and documents are a sort of deductive user interface in themselves. You had to know how the filing system worked, what to find, and what to do with what you found. You see a bunch of stuff, but what can you do with it? Right-click it and find out. How did you know to right-click, let alone alter folder or filename attributes? Someone showed you or you took the tutorial at least once.
A user interface shouldnβt leave users with questions like βwhat am I supposed to do?β or βwhat is this icon for?β or βwhy/how did I get here?β The UI should answer those questions and guide users through the process.
The inductive user interface
Microsoft coined the term IUI (inductive user interface) to describe a type of interface that solved the problems described above. It fit Web design naturally, years before AJAX as we know it: A workflow was broken out into separate pages, each with the sole purpose of completing a simple, well-defined task. After each task was completed, information would be sent to the server and the next page would be loaded. The one-to-one ratio between a task and a screen became the cornerstone of IUI.
Microsoftβs guidelines document spells out specific steps to take when designing using IUI, but the core concepts can be distilled down to a single idea: Each screen should have a single, clear purpose, with everything on the screen supporting that purpose β including the title of the screen. The only items allowed on the screen that donβt directly support the purpose are closely related tasks. This exercise in simplicity is actually difficult, but worth it. Simplicity means happy users.
If the 1040 tax form is a deductive UI, then TurboTax is an IUI. TurboTax breaks down the tax filing workflow into small, very clear tasks. Each task has a dedicated screen that is clearly labeled, with a short description of what information is needed and why, and often asks the user a direct question. Instead of forcing the user to jump around worksheets and add line 18b on page 2 to line 42c on page 3, the user is guided through the process in a logical, linear way. User interfaces that embrace these guidelines are easy and enjoyable to use, even for doing something like filing your taxes.
That was then⦠A decade or so is an eternity when it comes to technology. So how pertinent is IUI today? The limitations of the Internet 12 years ago were informing Web design decisions, and those decisions drew heavily upon the concepts of IUI. IUI fit naturally with slow Internet connections.
The Internet isnβt slow anymore, and single-page Web applications are springing up left and right thanks to advances in browser technology and the widespread adoption of JavaScript for more than just frilly enhancements. Now that the limitations have dissolved, is IUI even worth practicing anymore?
Absolutely. For those developing desktop software, IUI is just as pertinent as it was when the article was released. For Web developers, IUI is crucial to remember. Now that Web technology has progressed so much, the distinction between βit can happenβ and βit should happenβ can easily be forgotten.
IUI is particularly relevant for mobile developers because real estate is precious on smaller screens. The purpose of each screen on a mobile device needs to be very concise β clearly labeled, and often inline with a single navigation button (if needed) and a maximum of one supporting action button.
Although IUI is still pertinent today, itβs not a complete solution. It provides a great foundation for design, but problems arise when you want to give users more power. Take Photoshop as an example of one of the most deductive interfaces in widespread use. Itβs filled with toolbars that contain countless unlabeled icons, and itβs notoriously arduous to learn. Users of Photoshop have accepted interface struggles in return for eventual speed and power.
What if the learning process were smoother? A screen-by-screen interface walking a user through customizing a color gradient would be great for beginning users. That same βgradient wizardβ would just get in the way of that same user once the workflow had been mastered. The ultimate solution is a user interface that adapts, gauging user experience and adjusting the interface and user experience accordingly. Some preliminary attempts at this, such as progressive reduction, will help to advance our understanding of how to measure user experience (and experience decay) and how to adapt our interfaces to account for it.
Regardless of whether IUI is right for the current project, your whole team should be familiar with it. It embodies basic UX principles that help everyone from project managers to developers make better decisions. Even though βMicrosoft Inductive User Interface Guidelinesβ was published more than a decade ago, spend the time to go through it. Understand the problems identified and the approaches to solve those problems. Your users will thank you.
Jonathan Freeman is an associate developer at Open Software Integrators. He joined OSI in 2011 and specializes in font-end development and UI design.
This article, βWho nailed the principles of great UI design? Microsoft, thatβs who,β was originally published at InfoWorld.com. Keep up on the latest developments in application development and read more of Andrew Oliverβs Strategic Developer blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.


