Applied Logic Engineering, Inc.

Technology and Management Solutions

User Interface Design : The Solution (Part 2)

Copyright 2009

Kelly Nehowig, Applied Logic Engineering, Inc.

 

Overview

In the first article in this series, I discussed the unfortunate state of user interfaces in a lot of the devices and software that we use every day.   In a lot of cases, very little attention is given to the quality of the user experience, especially in embedded system (consumer electronic) devices.  I attribute this to primarily two major reasons – the first is a lack of consideration for the user interface until the design is almost complete (and therefore too late) and the second is the growing complexity of the devices and software we use every day, which typically results in correspondingly complicated interfaces.

 

In this second article in this series, I will offer some general suggestions to keep in mind when designing the UI for your product.

 

The Five Main Rules for User Interface Design

While there are many specific rules that one can apply to the design of user interfaces for embedded systems and for software, I always apply the following five principles to every project that I’m involved with:

 

Simplify!

Frequently, our systems and software contain more functionality than is reasonable.  “Because we can” is not a good answer to the question “Why is this feature in the product?”.   Remember my landscaping irrigation controller example in the first article – all I needed (and I would venture to say that what most people needed) was to turn the water on at the same time each day for the same number of minutes per day.  In analyzing that problem, I would expect that there would have been three user inputs – 1) the current time of day (set once when installing the device), 2) the time of day to start the water and 3) the length of time (in minutes) to run the water.  That’s all I needed.  Unfortunately, the device I purchased complicated this simple need into extraneous items (i.e. delay time, cycle ABC, days to water, etc.) that resulted in a multi-step, multi-key stroke setup that was not necessary.  By simplifying and/or eliminating the features in the product that are extra baggage, you can simplify the UI.  Will you leave a few users behind because you don’t have every feature under the sun?  Maybe.  But make sure you balance this off with the frustration (re: product returns, tech support calls, etc.)  the majority of your users will experience if things are too complicated.

 

Use Defaults

Take advantage of “default” (or commonly used) settings for your user interface.   Imagine how frustrating it would be if you needed to input the paper size parameters into Microsoft Word every time you wanted to print a page on your printer – thankfully Microsoft assumed that most people will use a 8 ½” x 11” sheet of paper (at least in the U.S.) in their printer and went ahead and preset Word accordingly.  Sure, the user can change the paper size to whatever they want, but most users probably will never change that setting.   Apply the same thinking to your product – what are some defaults that can be assumed in the UI?  If the majority of users will expect certain operating parameters, go ahead and set them as defaults.  You may not be right 100% of the time, but the vast majority of your users will appreciate not having to configure these settings.

 

Use established standards if they exist

I’m always amazed by the number of developers that ignore standard conventions when designing the UI for their products.  Probably the best example of this is ignoring the icons that Microsoft has established for common UI items like “File Open”, “File Save”, “Print”, “Copy/Cut/Paste”,  etc. in their user interfaces.   While one could argue that aesthetically these icons may not be the most visually pleasing, they do have the advantage of being instantly recognized by the end user, even if they have little knowledge of the specific features of your particular product.  The same thing applied to menuing systems in Windows applications – most users will know that the PRINT function will appear under the FILE menu.  While this does not make analytical sense (What does printing have to do with files?), it does represent a common experience that most (if not all) major software developers for Windows applications have adapted.  So look for the same types of opportunities in your products – what standards exist that you can take advantage of in your design?  Are there industry-standards that can be implemented in your UI?

 

Give high-use items priority in your user interface

Remember – not all features are created equal.  There are always some features in your embedded or software products that are going to be utilized the majority of the time by your end users, while others are necessary but used much less frequently.  Make sure that common, frequently used features are extremely easy to access.  And conversely move less frequently used items in the user interface to menus or other indexing systems in your UI. Think of a TV remote control – poorly designed devices simply have rows and rows of buttons that are the same size, appearing in no functional groupings to help the user find the correct button for the desired function.   A well designed remote controller  would enlarge the channel up/down buttons and the volume up/down buttons (which are used the majority of the time) and place them near the physical center of the device where the users can find them easily.

 

Lastly, test your UI with real users

This sounds obvious, but again I am amazed how many companies ignore any kind of user feedback until after their product is mostly designed and ready for market (at which point the resistance to changing anything is extremely high).   Test your UI concepts early and often with end users.   I’m a big believer in using story boards at the initial concept stage of the design.  It is not as good as sitting the user down in front of the actual product, but the feedback obtained in this early stage can validate or invalidate your basic UI concepts prior to going to the expense of implementation.  Once coding starts,  continuously test your UI with users during the development iterations.  Make sure you properly “hear” this feedback – you will never get 100% consensus from each and every user, but you can draw on the aggregate.   In other words, if many of the users in your sampling complain about the same issue, chances are that customers that buy your finished product will also have the same issue as well.

 

 Clearly, you will need to apply the specific design rules based on your device or software product that will be appropriate for your project – but whether your product is a consumer electronic device, a shrink-wrap software product, a web site, or even a watering controller, the application of these basic guidelines will put your product on the right track from the user’s perspective.

______________________________________________

 

Kelly Nehowig is President/CTO of Applied Logic Engineering, Inc., a Minneapolis-based consulting company specializing in software development, products, and services.  A 27-year veteran of the software industry, he has worked with companies from startups to large corporate clients.  Kelly holds a MS degree in Software Engineering from the University of St. Thomas and a BS degree in Electronic Engineering from Minnesota State University – Mankato.  He can be reached at kellyn@appliedlogiceng.com.