UX is not UI

Many people seem to confuse UX (User Experience) with UI (User Interface).  These are very different things and confusing the two are likely to result in unhappy users. 

Many people who “design UX” seem to spend the bulk of their time focusing on the screen layout, controls and behavior of various elements on the screen. Many weeks can be spent conducting user studies, analyzing feedback and reviewing various fonts and color schemes in an attempt to provide the most aesthetically pleasing user experience.  These are important things to focus on but something obvious usually goes missing – what about the data?  Where is the data coming from?  How must the data be transformed or manipulated prior to displaying it to the user?  These critical questions are frequently an afterthought as design engineers focus instead upon the look and feel of a given screen.  Focusing on the look, layout and behavior of individual controls on the screen is UI, not UX.  UX should require that designers consider potential latencies due to data retrieval, security and other background processes that impact the overall performance of the user experience.  A beautifully designed screen that performs poorly always results in a poor user experience. 

So how should one design a great UX?  I’m not a UX expert but I’d suggest you start by understanding the data that the screen is to display or work with.  List all of the fields or data elements that the screen must display or accept from the user.  Try to answer the following questions:

• Where is the data coming from?
• How long will it take to retrieve the data to display to the user?
• What relationships (if any) are inherent in the data to be displayed or processed?
• Is the data in a format that is presentable to the user or must it be transformed?
• For data entry try to invoke the validation rules as close as possible the actual data entry experience
• Is it possible to retrieve the data proactively via a background process?
• How can we “distract” the user while their data is being retrieved/transformed/validated or otherwise processed?

Avoid blocking, especially if the data must be retrieved or processed by a slow/remote network location or an underperforming back end system.  Users have become accustomed to asynchronous experiences - blocking users with an hourglass, spinner or some other form of “dancing monkey” is insufficient. 

Design engineers should work closely with architects or developers to become intimately familiar with the data and its associated service level expectations (SLEs).  Understanding data behaviors can help design engineers avoid designing a Ferrari that performs like a Yugo.