A DZone Zone Leader discusses the importance of UX and UI to the usability and popularity of an application, and how it’s just as important as development.
The electronic age has certainly made life simpler.
Even before we found the need to be connected, electronic devices have become a supplement to our daily lives. The simple word processor and spreadsheet on the way-overpriced home computers helped make communication easier to read and reduced errors with pencil and paper computations.
With our connected world, just about everything we used to do can be completed (in one way or another) using an electronic device. Earlier this week, our family searched the web-sites of a couple grocery stores (and Amazon, of course) to see who had a particular type of icing that was going to be used on a cookie cake. Performing the search from home saved us the time and money (gasoline mostly) of driving around to reach our goal. With a newborn baby in the house, both time and money savings are always appreciated.
The success of being able to provide a need or service electronically requires some type of user-interface. In modern Information Technology (IT) applications, this is often referred to as user interface (UI) or user experience (UX) design. While it might be hard to believe for some, the UI/UX design is equally as important as the actual need being met. Some argue the UI/UX design might even be more important.
Below are three scenarios I have encountered of cases where the UI/UX design probably wasn’t the highest priority in the overall goal of meeting the application.
Growing up a fan of playing electronic games, I was super excited when the idea of PC-based games started to gain momentum. I had invested in a pretty nice computer that I was using for school and could not wait to allocate some of my entertainment budget toward playing games. At this point of my life, I was still enjoying a round of golf — both for the time outside and the challenge of doing my best at the game. So being able to golf virtually (especially during the winter months in the midwest) was something I was looking forward to evaluating.
The original Links game series was called «Links: The Challenge of Golf» (you can play it using your browser here) and the game was incredible (for the time). Since this was before computers had dedicated video cards, the CPU was used to handle every aspect of the game. So, it took several seconds for those picturesque golf scenes to render on computers back in those days. Players didn’t really care about the lag, since this was awesome… and compared to nothing else available at the time.
However, one thing that always bothered me was UI decisions within the game. When you bought the game, it came with only one course: Torrey Pines — South. Each time you started a new round, the game would always prompt you to select a course, as shown in the screenshot below:
When this screen arrived, it was common to jokingly ask, «which course do you want to play? Torrey Pines… or err … Torrey Pines.»
What I never understood is why the development team wouldn’t put in a feature to check to see if any other courses existed, before making the user select from a single select list. Especially since the game only shipped with one course and other courses were provided at a later date… for an additional cost.
I have seen this same type of logic years later, where a dynamically generated pick-list has only one option and an option is required to continue. If the field is required and there is only one option, why not go ahead and preselect that option? The savings the development team would save on making this default selection not only saves the end-user time but also provides a more positive UI/UX experience.
A great deal of projects are using web frameworks (like Bootstrap) to supplement the design of a web application that can provide a responsive application across multiple end-user devices. A core aspect of the responsiveness is the CSS Grid Layout technique, which divides the into as many as 12 equally spaced columns. Within each another set of 12 can be added (and so on) with a goal to meet the needs of a majority of user interfaces.
Below, is a simple example of a basic grid row.
Grid systems have been a part of nearly every web-based client interface I have worked on since 2013.
The one challenge I have seen is with the UI/UX team not recognizing our decision to use a CSS Grid Layout. Instead, the UI/UX team provides 2D screen mockups using their preferred graphic design tool. For the most part, the elements depicted in the 2D screen sample can be rendered into the grid system without any issues. However, there are times when quirky CSS is required to meet the design — which can be a challenge to support across multiple screen resolutions or devices.
Most of the time, accommodations can be made to update screen designs to represent reality. However, it would be nice if the UI/UX team had a clear understanding of CSS Grid Layouts and it would be even nicer if their tooling allowed them to mock up the screens using the same frameworks that were ultimately utilized by developers. Otherwise, the disconnect will often require re-work costing the project team unexpected expenditures and potential timing delays in meeting their goal.
Mobile devices have certainly seen their share of great and not-so-great UI/UX experiences. I believe a good portion of the bad UI/UX designs are due to the fact that the work was completed by an individual without much experience in front-end design. This could probably be traced back (in most cases) to the boom of mobile applications and a flooded market of individuals attempting to cash in on the wave.
However, I have seen a couple applications that have been developed by major corporations which lack one major feature: the ability to easily quit the application. Two applications that come to mind for me are the UnitedHealthcare (UHC) Motion application and the iHeartRadio application.
I initially downloaded the iHeartRadio application so that I could continue listening to an over-the-air program while I worked on the lawn after my drive home. What I noticed at the time was that there was no way to quit the application. I could stop the broadcast from playing, but the application remained open and at the taskbar on the top of my screen. To close that version of the iHeartRadio application I had to force quit the application — which was crazy!
Currently, the iHeartRadio app includes an Exit App option, buried inside the Settings screen:
I use the UHC Motion application about twice a month to sync my daily steps for Health Savings Account purposes.
