Monthly Archives: July 2009

Designing beyond the surface layer

Designing a user experience is usually considered synonymous with the work of designing the part of a system users will directly interact with.  While that is all good and well, a general problem I see in the UX practice is that this then becomes the place where the UX work not only begins, but also where it ends.  In other words, the underlying functionality, the components that actually allow for the interaction being designed to function is either completely ignored or only given cursory consideration from a UX perspective.

This lack of attention to the impact of the non-visible aspects of a system on the user experience is, in my opinion, a major reason for a lot of bad user experiences.  If you think about it, if your page is slow to load, if you try typing into a text field but nothing happens, if some seemingly simple action in the UI in fact initiates connections to a bunch of data sources and causes whole interface to become sluggish, who cares how perfect your UI design is?

I think a lot of UX designers shrug their shoulders at issues like this.  Hey, that’s the developer’s problem not mine, right?  Yup, definitely the developer’s problem, just like the proverbial leak on his side of the boat is his problem and not yours.

The issue here is not one of who is responsible, rather one of an awareness that it may critically impact the user experience, and therefore the User Experience design process should be one that allows for surfacing the issue and addressing it.  Current conventional methods of UX design, i.e. focusing solely on the user interface first, then waiting to deal with pesky issues such as load time later is only likely to ensure that those issues get relegated to the revolving “Phase 2″ version of the application.  A better way to address this is to rethink the relationship between UX design and development, and a great example of that is to evolve the GUI in tandem with the software build.

An Agile UX Method: Functionality First, GUI Second

The idea of designing the user interface in tandem with the build is a good example of applying Agile thinking to UX.  Here, instead of first creating some fully formed interface concept before starting to actually implement it, we take a step back and look at what underlying functionality needs to be developed.  In cases where it makes sense, such as a piece of  functionality that may be simple at the user interface level  but where there may be some heavy lifting on the back end, rather than spend a lot of time at the outset trying to come up with the perfectly user-friendly UI, we instead abstract out what inputs the user will provide and what outputs the system must return and then create a minimal user interface, of which the most standard is the command line interface.

Example of a minimal user interface, showing only user inputs and outputs

Example of a minimal user interface, showing only inputs and outputs

Here is an example of an auto parts search, in which we know that actually connecting to the various parts warehouses and then executing the search is going to be highly complex.  Therefore, before spending a bunch of time designing a GUI, which will need to make assumptions, for example, about the amount of time that will be required to complete a search, we instead start by building a first iteration of the search functionality and use a skeleton user interface.  With the knowledge of the actual average time of completing a search, as well as issues related to connecting to the warehouses, we are in a much better position to build a graphical user interface around this, in which we can clearly set user expectations, as well as determine much more effectively what forms of dynamic features in the UI we can support, such as how much flexibility we can allow for in terms of user inputs. (I.e. maybe we discover that Name needs to be a separate field from ID or whatever.)

This can be an incredibly powerful way of working, since it actively and organically involves developers into the design process, allowing you to collaborate much more closely in evolving the user interface.