There are a lot of things that can sink an app but none more visible, yet often overlooked, than a poor user experience.

User Experience Matters

Duh, of course! Something we all know, right? But do we take care of the UI with the same passion as we do with code? In order to ensure the user experience remains relevant and a pleasant experience requires refactoring as well. Like code that can erode over time, the user experience can suffer the same fate.

The Eroding UI Example

Our team has worked on an application that’s used throughout the organization to enter requests for budget. The application has gone through several heavy revisions over the past few budget cycles and each time we have had a very tight timeline. It’s always been a mad rush to make the modifications necessary to accommodate the changes in the process.

Over time, the UI slowly began to mismatch how the users worked. The UI grew into a large form and required all the fields to be filled in before a user could save any work. The nature of how the user worked was very different.

The user process is highly iterative and collaborative within business units who are developing requests. They often work on one section’s wording over and over until they have it just right and then move to the next section.

Unfortunately, the UI didn’t handle this well. Fields that required a lot of text (several paragraphs) were forced into a small text area that had to be scrolled to read. Users would just print a report to see all the text to get around this. With all fields being required, users entered garbage/placeholder information into fields in order to save their work.

New ideas were introduced into the process and the application grew. A few more forms were added. The flow was changed so that the user was required to enter this information and save it as a separate step from the main form. The items were required but very much felt like a bolt on and not as important.

An Aside…

Who’s fault is this? Mine. It’s the job of the team leader to remove barriers to success and help foster and create situations that lead to success. It took me a few tries to get us to the point where the team could work their magic properly instead of being hamstrung by constraints that could have been better managed by yours truly.

Redesign

This year we took the time to give the application some tender loving care. The vision was to create logical sections of information. Maximize space utilization for the sections and move away from strict validation to a routine that would allow saving work anytime while quickly showing what is left to be completed.

The team took the vision and ran with it.

Navigation

The team created a new navigation section that is very pleasing on the eyes and more visible. The team nearly eliminated the need to scroll vertically on the page. When scrolling does occur the team floated the navigation so that it will always be at the top of the screen. The save and cancel operation work on the entire record, versus several forms that required saving separately. Additionally, the user can save at anytime and reduced the number of absolutely required fields down to two.

Layout

The team created tabs to group similar information into sections. The tabs have an icon representing if that section has been completed or not.

Additional information is in each tab to help the user. When a tab has a green check mark the tab includes a message stating it’s complete.

If the tab is incomplete, represented by the yellow warning sign, a message is shown stating what is needed and each element on the form that needs attention has the same warning icon and it’s own message.

With “softer” validation in place the user is able to work on a request in whatever order they need to and with a glance see what is incomplete. They can also save their work in whatever state they want. This lends itself well to the iterative drafting process of the initial budget development cycle.

Handling large text needs was simplified by giving them their very own tab.

More obtrusive (yet nice) messaging was added to the system to help ensure the user doesn’t accidently/inadvertently do something.

The real test - What are the users saying?

In the users tests we’ve conducted we received rave reviews. We have a few weeks to go to finalize the application and go live with the entire user community. It’s exciting!

It’s coming along great and I am extremely pleased with the team’s redesign and the large undertaking to replace the strict validation with a softer/gentler validation technique to serve the users better. Kudos to the team!

Conclusion

The UI is not immune to change and requires the same level of care that code does. The need to develop changes can erode the UI just like code. The UI requires our attention and needs refactoring as well to stay relevant.

Normally forms don’t have much of a visual queue to the end user showing them where they are on a page.

Wouldn’t it be nice though?

That just seems like a step in the right direction. Making this happen is a lot easier than I thought. Most browsers can handle this with the css pseudo-class selector. The css to make this happen for all your inputs would look like this:

I have done all my targeting with the input element. You can just as easily have done this with classes for your elements. In my case, the application is already well underway and it seemed an easier approach to select the input types I wanted. You could also add your textareas easily this way.