When I first used this particular Brita pitcher, I discovered that it has a major design flaw.  There is this section where the hollow handle connects to the reservoir, thereby permitting unfiltered water to flow down and mix with the freshly filtered water, obviously defeating the point of filtering your water! (See image below.)

It seems to me that some basic user testing would have revealed this very obvious design flaw.

This is just a small example of how easy it is to make users of any product unhappy.  As a User Experience designer, my goal is to give users the best experience possible.  Doing so requires user testing throughout the product development cycle in order to identify both the big and small issues so that they can be corrected before going live. I seriously wonder if this is something Brita did before rolling out this product.

I think the final result came out pretty nice. See the screenshot below for a test I ran on Responsinator. You can also check out the final result by resizing this browser or viewing this site on a mobile device! I realize the CSS structure isn’t perfect, but it’s a work in progress.

Below is the app’s original welcome screen (with and without the launch screen’s instructions), noting the problems I identified in my initial user assessment:

Review comments on iTunes yielded similar complaints about the lack of NASA branding and the overall structure of the app.

Step 2: Redesign of Application Architecture

I redesigned the application architecture to make a few changes that would hopefully address the issues that I identified during user testing (see below). With the new architecture, the home page gives users option to search by date, keyword, or category.

Below are the initial mock-ups (home screen, search results listing, and a single event screen) that would implement the new architecture while also addressing the other issues identified.

Home Screen:

Search results listing:

Single event screen:

View the interface design phase of the application.

The forms I’m working on have overwhelming and somewhat tedious user requirements. Here is an example:

This portion of the web form is just one of many, many fields the user is required to complete. In this particular instance, the user must evaluate and count characters they enter into the input box. Not exactly user friendly. The “help” item tells the user that he/she must use “about 40 characters” when creating their organization’s short name, but this can become a guessing game because the user can only see their final result once they submit the form and check the front-end of the website. Limiting characters is important for avoiding line breaks, but clearly the instructions and method for avoiding this are less-than-ideal.

Solution:

Using what I learned from reading Web Form Design: Filling in the Blanks by Luke Wroblewski, I eliminated the less-than-useful “help” text and user guessing game.  Instead,  using Javascript, I changed the form to provide a live preview, enabling the user to see exactly what their input will look like on the front-end of the website. I also included the critical instruction pertaining to the width of the text above the blue line. This prevents the user from having to click on any “help” items, hopefully saving time.

A simple solution that (hopefully) makes the user experience less frustrating.
Out of curiosity, how have others resolved similar issues?

Download iPhone Camera Icon PSD file

Download Staples PSD file

In iOS 5, “Location Services” lived under “Settings” as one of the top menu items on the screen. With two taps I could easily turn it off:

However, in iOS6, the “Location Services” has been moved under “Privacy,” which is the ninth item on the main “Settings” page. To turn off “Location Services” now, I need to scroll down, tap on the “Privacy” menu item, tap on “Location Services,” and tap to turn it off:

That means four steps to turn “Location Services” off instead of only two. This is a big difference considering I and other users likely turn Location Services on or off more than once a day. It makes me wonder what Apple’s User Experience designers were thinking.

Here is a little story illustrating how important it is to create a well-designed form: Not long ago, I wanted to donate $15 to a non-profit animal welfare organization. After completing the form, it failed to submit, and notified me that a $15 donation option did not exist. What a shame! Think about all those who wanted to donate, but could not because the amount they desired to donate did not exist on the form. Because the design was bad, the form could not complete a crucial interaction.

In my current position, part of improving our back-end forms is to integrate help files. Our forms have the tendency to be a bit overwhelming in requirements because of the nature of the subject we deal with (science and exploration). The information we request often needs clarification and/or explanation, so a good help sections is a necessity. However, I was concerned that adding help items would clutter our forms and deter users from utilizing the form itself.

Considering our situation, we had to develop a solution that was both easy for users to access and provided flexibility in terms of content length and format. We also tried to minimize the need for help items by improving labeling and reorganizing the forms.

We ended up with three different solutions:

1. A link to a central help section with all the help content, which is the first paragraph users see when logging in:
   
2. Small, gray inline “help” text under the input labeling. This provides immediate help to the user for understanding the label. No additional clicks are needed:
   
3. A tooltip revealed by a mouse hover interaction over the question mark. This takes up minimal space and presets a satisfying amount of content if needed:

My next task will be to create a style guide on how to implement future help items.

How have you added the “help” function to your online forms? I am interested in hearing what others are doing out there!

Some quick user testing, however, revealed that my design was encouraging the user to delete a section, rather than create a new one, which was not our intent.  It appeared that having the “DELETE” button centered and within a darker background resulted in users gravitating to it, even when it wasn’t the function they wanted.  Conversely, the “ADD NEW” button (no background, flush to the left) seemed harder for users to locate.

To resolve this issue, we made a few changes:

These changes made the “ADD NEW” button the main action, and downgraded the “DELETE” button to a secondary action.  Small change, very different user experience.

In the beginning, all was well. The web developers and I knew what functionality would be required. The design was simple in an effort to prevent user confusion. We never discussed user testing because we all assumed the application would be easy to use. In addition, user testing just wasn’t part of the process.

The image below is the first iteration of the design mock-up.

After I developed this first mock-up, there were additional meetings with the project managers and with each meeting we received additional requirements.  The addition of these requirements resulted in a design that began looking cramped and confusing:

As a designer, I quickly became unnerved with the lack of attention to the user experience.   But time was of the essence and things were moving so quickly that any discussion of “user experience” was overshadowed by the necessity of getting the project completed on time.  In addition, due to a limited budget, formal user testing was not an option.

Around this time, I happened to be reading, Undercover User Experience Design (Voices that Matter) and had just reached the chapter titled “Testing with Users.”  Serendipity!  In this chapter, the author emphasizes simple solutions for conducting user testing when it is not a formal part of your design and development process.

So, taking this advice, I simply walked across the hall from my office and asked one of the potential users of this application to help me test it.  She happily agreed to be my guinea pig and a time was set up for the testing.  I invited one of the project managers to this first user-testing event and we were both in awe of what occurred.

User testing results:

The project manager and I subsequently concluded that functionality and design changes were needed. Using the information obtained during this brief user testing experience, I was able to improve upon our initial design, incorporating new user interaction features in the application. See below images for improvements.

Designers must always understand how potential users will interact with the design and underlying application. Understanding this is integral to the design process. Unfortunately, it’s an easy thing to leave out during project planning, either because of budget or time constraints or both. When this happens, it is up to the designer to advocate for some form of user testing. User testing does not have to be expensive; it can involve nothing more than simply walking out of your office and finding a couple of volunteers. It also doesn’t have to be time-consuming; our user testing experience took less than an hour from start to finish. Even if you’re a designer working with a small budget on a tight deadline, user testing can happen.