Our audience is full of fellow UI designers so please feel free to leave a comment about topics you would like to learn regarding: Usability, UI Design, Interaction Design, Various Design Patterns, Application Design, etc..

I look forward to hearing from you.

Usability is nothing new. What is new is the use of the term usability by anyone and everyone. It has become the de-facto buzzword across the design world. There are so many definitions and differences of opinion across the web on what usability actually means. Let’s take a look at the dictionary definition:

Websters defines usable as the following:

1. capable of being used
2. convenient and practicable for use

As UI designers, we draw upon a few more concepts to define this idea further. My personal definition takes into account the following:

• Learn-ability
• Memorability
• Performance
• Expected Interactions
• Consistency
• Repeatability 

Yes, I know that’s a lot of “abilities”.  I will discuss this in future articles,but right now let’s just focus on what falls into the category of usability from an application standpoint and how it can directly impact adoption of our application.

Here’s A Feature, There’s A Feature, Every where’s A Feature

Many notable UI Designers, Interaction Designers, and User Experience Designers have talked about the problems of “featuritis.” The term simply refers to the rapid increase of features beyond either application need or user desire. This can occur to almost any product you can think of.  The goal is to minimize and avoid user frustration by understanding what it is the users really need. After you have identified what is needed it’s important to categorize your features, functions, etc into primary and secondary interactions ( I will talk more about this in a future article.)

Even The Best Applications Have Skeletons In The Closet.

Let’s examine some existing products on the market and identify some problems with these applications. Im sure many of us have used Illustrator, Photoshop, 3dsMax, or Bryce. These applications have a high user competency. You may need classes, formal training, and many years of experience to produce professional results. That is not to say these companies have “driven usability off the cliff.” In fact, many follow the same “menu” toolbar structure seen in 100’s of applications. Each application may have their own slight twist and or added access to complex functions. Regardless, there is no doubt a very important process has taken place at some point during the development of these applications to priortize the location of menu features. Hopefully, this process involved usability groups to actually figure out what the priorty was.

Take 3Ds Max for example. 3DS max is aimed at highly competent designers with modeling, mathematical, computational, and visual skills.  One version of 3DS Max I’ve used contained many complex context menus with alternating functions to complete as expected complex design modeling tasks. Personally, I’m glad I’m not a 3D modeler working with Max or Maya. The interfaces may be some of the most difficult UI’s I have ever encountered. Multi-Tiered cascading menus, complex keystrokes, and alternating views of wire-frames.

Let’s take a look at Photoshop. Pretty much every designer I know has used this behemoth of an application. The sheer power of the tool led to a lot of acceptance of any short comings. Yet, with the creation of CS 3 Adobe redesigned many core menu structures. One simple example is the tool bar that can now be set to a single strip along the side. This was one of my pet peeves. I would frequently run into the tool bar constantly being in the way. This small change (to the user interface) has saved me many minutes of productivity, and eliminated a major annoyance.

We The Users Will Not Stand For UI Mediocrity

Alan Cooper’s Book “The Inmates Are Running the Asylum“-(published in 1999)  talks about the complaceny users of software faced when working with web applications. of course, it is now 2008 and a more recent study by Jakob Nielsen points out that users have lost thier patience. No longer will users stand idly by and wait for that 30 second flash splash screen to load. Poor UI designs and convoluted interfaces, face a growing demand to be made better. It’s our job as UI designers to improve and invent new and easier methods of interaction. If any feature proposed as a usability enhancement fails it is much easier for users to swich prdoucts.

There was a time in the past when humans were pleased by simply improving complex processes with the use of a computer and software. The novelty has worn off, and now users expect much more out of the software they buy. 

Think back to the last time you waited for a web page to load. Did you wait patiently? Maybe you tried to click faster in hopes the page would load faster. If you are like me, you simply go to one of the billion other web sites.  It’s reasonable to assume loyalties will shift and applications that fall to the road-side and allow usability to suffer will ultimely loose users.

The Dreams That Dreamweaver Dashed

For many years I was an avid Dreamweaver user. The tool allowed me to code faster than notepad, and did not overwrite my code. Adobe became comfortable with it’s lead on the market and the tool never really pushed the bounds of innovation.

Each subsquent upgrade lead to more features, but what I really needed now was a tool that could read my complex CSS style sheets and visually give me a good in program rendering engine. This would allow me to not have to constantly switch back and forth to my browser to check my designs.

So after years and years of program use I switched to Expressions Web. The CSS rendering engine was  amazing. Sure, it was an entirely new interface to learn not to mention Microsoft’s insistence this was not a FRONTPAGE tool but instead was directly aimed at professional designers. I hesitated making the final switch, but haven’t looked back. That being said now Expressions is falling behind on delivering the best software experience. I may have to take a look back at Macromedia.

Don’t let your software and usability become a fat pig. Conduct usability groups and determine where to go next with your application. When you have your list of features be cautious.

All Features Are Not Created or Treated Equally

Imagine you are in the market for a new luxury car. The list of features reads something like this:

• Power Steering
• Anti-Lock Brakes
• Rear View Mirror Camera
• Internal GPS
• IPOD Connection
• Stereo CD Controls
• Cruise Control
• Defogger
• Air Conditioning
• USB Ports
• Extra Outlets
• Block Heater
• Light Panel
• Spare Tires
• Microwave Oven

This is a top of the line luxury car. It has items you may never need. The engineers believed it was best to have two spare tires. One attached to the roof, and one in the trunk. They reasoned with the manufacturer that because of all the extra features the tires are not the best quality, but we did get all the features in. Occasionally, the operator of the vehicle may turn on the brights when adjusting the radio. They may short out the battery if too many items are plugged in to the outlets. They may burn fuses, but “everything” asked by the car manufacturer was included. Some pieces are less reliable then others, some have some major bugs, some even may cause system failure.

You may laugh at this example, but sadly it is very true. So many times features are the prized cow at the fair. They are the desired outcome of a super speed, fuel injected, development cycle.

Now let’s fast-forward a week later to the purchaser of this vehicle. His initial reaction was WOW it offers me all of these things? That’s a lot of stuff. Sure I may not use many of them, but oh well. I may need them some day! (just what the engineers, and developers wanted them to think). In The past they would have drank the kool-aid! OH YEA! Today that car is going right back and guess who just lost a sale and millions in investmetns?

The next time you want to jam that feature or expand that application. Stop! Think a moment about what the cause and effect will be.  Not to just the current implementation but future expected implementations. You may just prevent your application from careening off a cliff!

*Author’s Note - Due to the size of this article I was a bit late in publishing.

Thanks again!

You can either use the forum to dscuss articles posted here in more depth or bring up completely new discussions. Perhaps you want to have an article written on some UI design topics that are important to you.

You must sign up on the forums in order to post and comment. This is mainly to reduce spam. I want this to be productive and valuable information and discussion. Spammers will be banned. All accounts must be approved!

UI Design Guide Discussion Forums

I will add a link on the site navigation to the design forums later when I know everything is working as expected. As always you are encouraged to sign up on UIDESIGNGUIDE and comment on the articles. I want your feedback to improve the articles and the topics covered. I have many articles in the writing process. I hope to cover lots of topics ranging from (ajax proto-typing, to more example web application wire frames, mocks, etc).

Thanks for being a loyal UIDESIGNGUIDE reader!

What are the benefits of Hybrid Prototyping & Mocking?

• More reliable layouts that fit expected content layouts (better predictability)
• Quickly create complex and realistic widgets
• Rapidly develop new HTML controls
• Use each tool (expressions, notepad, Photoshop, illustrator, acrobat) to its strength

Step 1: Build Your Design Library?

When building a new web application, or widget I usually fall back on my base CSS styles for initial mocks. If you do not have a base set of styles. I suggest you build a CSS library. With only a few lines of code you can quickly create many different application widgets and their look. This is especially true if you have a standard corporate or company brand you need to follow. Here is just a quick sample of the table code I use when doing table structures.

/* Used by the other data grids */
TABLE.grid {
 border-collapse: collapse;
 font-size: 13px;
}
TABLE.grid caption {
 font-size: 13px;
 font-weight: bold;
 color: #F6F18D;
 vertical-align: middle;
 text-align: left;
 padding: 5px 0 5px 3px;
 margin-top: 20px;
 background: url(images/header_background.gif) no-repeat center left;
}
TABLE.grid TBODY TR {
 vertical-align: top;
}
TABLE.grid TBODY TR TH {
 font-size: 11px;
 font-weight: bold;
 vertical-align: top;
 text-align: left;
 border: 0px 0px 0px 0px;
 border-style: dotted;
 border-color: #B8660B;
 padding-top: 10px;
}
TABLE.grid TBODY TD.alternate {
 background-color: #EEEEEE;
 padding: 2px;
 height: 14px;
}
TABLE.grid TBODY TR TD {
 font-size: 11px;
 padding: 4px;
 height: 18px;
 text-align: left;
 border: 0px 0px 0px 0px;
 border-style: dotted;
 border-color: #B8660B;
}

 The above code is just a small example. The goal is to build out the code enough so you can simply class/id at the top of your table and then let the cascade ripple through the table elements. If I simply removed the <tfoot> or other elements I can quickly make my table look twenty different ways with only the simple class /id  at the top.  Using this same process I would build out divs, legends, fieldsets, and form elements.

I can mock up a drop down in Photoshop in about 10 minutes, or using this method I can do it in about 10 seconds. If I put more widgets to use In this way I can build out custom screens very rapid. Even more to the point I am using my actual library so I may be coding real world code that could easily be used in the final web application.

Step 2: Screen Print Is Your Friend and So is Screen Capture

Now that I have some custom widgets built and displaying on the screen I can capture the screen and begin building out my widget folders in Photoshop. I usually would create new Groups (folders) inside my Photoshop work space.  An example folders structure: Data Examples, Search Bars, Buttons, Grids, etc..
Using our little friend cut and paste I’ll start placing my pieces into the appropriate folders.

The goal is to get frameworks of your widgets. You can then use Photoshop to “spice em up,” or change them into other designs. You could even create some text examples to lay on top of your various frame-worked widgets. I usually end up creating my containers, and supporting images in Photoshop / Illustrator since that is the best tool for this job.

 Step 3: Build It Out and Tie It All Together.

Start building out your new application interface. I’ve found that using both an HTML design tool and Photoshop in tandem I can quickly pull together a design in a matter of hours. The quick benefit of this is that your design nows uses actual sizes and even actual (potentially production) code.

When you have some screens you like save them out as JPG’s. Next your are going to open up your JPG’s inside of Adobe Acrobat. Merge all of your related screens into a new PDF. Now go ahead and go to your first page and look for the interaction point you are looking to simulate. For example clicking a link pulls up an AJAX edit screen. Select the “ARTICLE” tool and draw an area around your interaction destination. Be sure to name it something you will remember. Now you want to go ahead and select the “LINK TOOL” and draw a link area around where you want your interaction to occur. You should see a popup.  Choose the following “CUSTOM LINK > ACTIONS > READ AN ARTICLE > Your named article area. Repeat this process and you now have an Interactive PDF MOCK.

Summary

In this article we looked at why Hybrid prototyping can get you to a visual interactive mock faster. We learned about creating a CSS library to speed up the process of creating these mocks. We learned how to create an interactive PDF.

I’ve been wanting to get back to the core of this blog for some time. I think I finally have made some time to do this. For anyone that has missed out the original core of this blog is to examine the brainstorming, creation, and execution of an application. This can easily be a process that any company or individual can follow when creating a web application. Size of the application has no bearing on whether these principles can be applied.

In our sample application we will begin working through the brainstorming, feature set creation, and mock layouts of new Cthinker App. The application I will be building in this example is a social aggregation tool. We will take a look at several social aggregation web sites as well as walk through the process of designing one from scratch.

Where’s The Vision

Not a lot of people talk about the vision when it comes to application design. It’s especially important though if you are looking to build an application better than your competitors. Without vision and a way to distinguish your product it makes it extremely difficult to truly produce the best software. It’s also important to make sure you have a large scale vision of where you may want to go with your product. Vision is something that should change and adapt to the times. Vision should keep up with both technology and trends.

What’s The Value?

Besides the obvious monetary ROI. It’s always important to come up with reasons that a particular application is valuable. This helps you to flesh out the cost or investment in the application and also helps isolate what potential profit can be made by launching a new application. Listed below are a few more items you should look at before considering the total value of the proposed application design.

1. Do other similar applications exist? If so can I do it better?
2. Is the target market so small that the potential for profit or usage by clients is marginal?
3. Will the cost of maintaining the application outweigh the cost of producing and running the application?
4. When do you expect a return on your investment?
5. How can the application design be kept simple, teachable, and learn-able?
6. Will there need to be training to use the tool? (Just because something is usable doesn’t mean everyone will understand the usage).
7. Are you going to build out the application in phases? If so make sure each phase is independent and contains your MOST important features while being highly usable.

Later we will explore how vision and value help you to build a successful brand. Branding is another aspect extremely important if you are constructing a suite of applications and are trying to create a overall consistent user experience.

The House that Jack Built…Is Crumbling Down

Let’s say you are a contractor building a new home for an unknown family. Looking at your deadline you realize you aren’t going to make it on time. It’s time to do something to solve the problems. What can be cut first?

Perhaps you get cheaper wiring, maybe the concrete on your house didn’t dry before the rest of the foundation had set. Because you are behind schedule you feel the only way for you to “catch up” is to cut corners. Cut one corner and you have opened up Pandora’s Box. It’s so easy to cut more and more. You begin a process of jamming things in just to meet the deadline. One year later the house catches fire and you are sued because you cut those corners.

Elevate Your UI Design To Another Level

The same holds true in UI design and in the UI design process. Frequently you can get rushed to put an unfinished design to the test with real users, even though you are aware of other issues with the design. It may be slow, it isn’t usable, lacks cohesiveness, tries to do too much, is hard to understand, is missing key features of a process. All of these are symptoms of a rushed and hurried design. You can see this in pretty much any application.  Your goal is to minimize this but how?

Give Your UI Time To Mature

This is one of the big concern designers have with an Agile development process. The same can also hold true in a Waterfall management process. The rate of development and design is fast and it’s extremely tricky for the UI designers to stay ahead of the development cycle. What’s even scarier is if the business fails to understand the importance of re-factoring and retesting a design. Rarely, is a UI design perfect the first time. It should and must be tested preferably by the people, person, that are going to be using the application. The problem is getting those that have direct interest in the application to buy-in( I’ll cover more about this later).

Dress your UI Design For Success or Send it Back to the Orphanage

It’s important to somehow let the client know that the first impression of an application is the most important. This is your adoption point (your such a cute design yes you are). If your customers don’t like the product at this point you have to work three times as hard just to gain them back!

Please Come Back I’ll Do Better Next Time I Swear!

Think about the last time you purchased a product and were dissatisfied with the outcome. You probably returned the software, car, clothing, food, etc.. and refused to ever purchase that product again. You probably even refused to purchase a different product made by the same company. This is especially important to your web application and UI design. Yes, features are important, but if my car has 3 steering wheels, 5 extra tires attached, and everything is labeled in Japanese are you going to think it’s usable?

Act Like The Customer Think Like the User

A customer tries to answer two quick questions about your software before purchasing, or using it.

1. Does it do what I need it to do?
2. Can it do it easily?

These are simple core concepts, yet look how many UI designs struggle with this. Look how many Interaction Designers wrestle with these ideas. Think back to the last piece of software, or product you have used. Do you have it in your head? Now think back to the reason you purchased it.

For myself the last item purchased was a tennis racket. These were the thoughts going through my head.

1. Can it hit a tennis ball? - Question Answered - [FEATURE]
2. Is it lightweight, balanced, and does it feel right to use? - [USABILITY]

If I was able to answer the above questions and after repeated use (learn-ability, memorability) could continue to perform and even excel then the design was in essence “great for me.” Why did I put this in quotes? Well as UI designers we have to find that common ground to support the vast majority of users. Are you really really going to find a UI Design that supports 99.9% of your users. You may find a a design that meets all the goals of your (persona’s -fake users), but even that is a rarity.

So What Makes a Design Great?

It’s the combination of a great feature set that has a high level of usability and has an aesthetically pleasing design. It’s about a design that delivers direct answers to the questions.

Does it do what I need it to do?
Can I get it done easily?

So the next time someone says just jam that feature in to the design. Feel free to send them to this post so they can see what really happens and how many aspects of the software you effect because of quickly rushing a design. Your adoption point or the first release of your application is your first impression. Fail at making a good one and what was the point of even producing the software?

Part of this comes from knowing what the common design pattern is for a particular widget. Another part is knowing how and when to stretch the limits of what is considered to be “common usage.” Any time you do something outside of the user expects is when your usability can start to plummet.

The Naked Anatomy of a Check box

Let’s take a look at a simple example our beloved friend the check box. There are two states to this standard check box that are considered common.

• If an item is checked it can indicate either something was accomplished.
• If the box is unchecked you are undoing or indicating you do not want to follow through on an action.

Generally you will find a check box in an unchecked state. Suppose for an instance that we reversed the common usage. A check box when checked now indicates to the user they are NOT SUPPOSE TO DO SOMETHING.  Applying this to the example below we see that because the current state is checked I would un-check to save my selections. Not only is this conter-intuitive but see how hard it was to explain that. You may have to read what I wrote twice to figure out what we are trying to accomplish.

Save Selections:

The same holds true for the most minute details in your application design and ultimately in the widget you choose to use. Going against the common accepted practice has already introduced unneeded complication and confusion.

In future stories we will be looking at a number of controls and how they should be used effectively.  Soon I will have a forum setup (next few weeks) to continue on the discussions outside of the articles written here.

Why Use Icons?

First a brief synopsis of why you may want to use icons.

• Icons are meant to increase the speed of visual scanning
• Icons should be the same size and used consistently across your application.
• Some icons are so recognizable: print, save, it becomes common sense. Frequently though when building a new application you will find the need to develop your own icons based on new functionality.

So how do you know when to break out the design tools and create some new icons? Here are some common indicators that let you know it’s time to possibly look at branding icons across your application.

When To Use Icons

• The functions you are representing are common and existing mental models. Icons that fall in to this category include print, save, pdf etc.. Pretty much everyone on the web can identify a print icon and understands that something is going to get printed when clicked.
• If space is tight in your application and future implementations may make this problem worse. In this case you really need to look at the application as a whole (we will be doing this in later examples) and identify similar functions idea for icons.
• If using an icon would help spatially an visually with
  learn ability. An example of this would be if there are many secondary
  functions in your application in the same area. In this instance too much
  text even if the text clearly states the function can hinder the visual
  recognition.

Studies have proven humans can recognize pictures faster then text.

Things You Should Do With Your Icons

• Do make all your icons similar across your application or brand
• Do make all your icons adhere to the same size when in proximity to other icons.
• Do use size in order to emphasize function prominence or importance
• Do use standard icon sizes 12 x 12 16 x 16
• Do make sure icons mean something
• Do test your icons & icon sets to make sure users can quickly identify the function

Things You Should Never Do With Icons

• Do not make icons blatantly different in the same applications or brands
• Do not over use  icons purely for decoration
• Do not use icons if you are unable to visually depict the function
• Do not change functions of an icon across your application or brand.

Are You Convinced

Hopefully you have a quick idea about when you should use icons. There is no cut and dry path, but the guidelines above will help you to identify icon requiring situations or solutions. We will examine icons a lot more in the series on web application design. I hope you will check back to learn more. If you have questions or comments feel free to leave them.