in User Interface, UX Practice

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.

  1. Hi Anders – I didn’t spot your reply for a while. It’s disappointing if the idea of separability is living on amongst UX designers.

    Do you think that designers who think this way do so because they don’t know any better, or do they have some theoretical and academic underpinning?

    Something that surprised me was the amount of heavyweight academic work that went into trying to justify it in the 80s and 90s. Do you feel that this work, by the likes of Edmonds, Hartson & Hix, and Green still has credibility? Or is it simply a matter of designers being reluctant to move on from a mental model with which they feel comfortable, and not having been exposed to more effective approaches?

  2. Hi James – I wish it were true that the UI and the underlying functionality no longer are seen as separate. In my experience, I have found the opposite to be true. Too designers are focusing solely on the surface layer, thinking of what is happening under the hood as some black box best left for developers to think about. So, in my opinion, the fallacy of separateness is alive and well in the UX design community, very much to its detriment IMO.

    Hi Ulf – would love to hear how things go if you should happen to apply some of the ideas above, which btw really are not my original ideas, but rather a common practice among Agile teams, in which the focus tends to be much more on the underlying code and less on the UI, and starting with a command line version is not uncommon, at least in my experience.

  3. I really like the idea to transcribe user experience requirements and system processes into a simple command-line interface. Not sure how practicable/helpful it actually is, but will give it a go as about I’m about to start with a process-heavy application project.

  4. Interesting post. I wrote a Master’s dissertation a couple of years ago that, amongst other things, looked at why UX professionals had been so ineffective at getting their ideas across to software engineers.

    One of the points I argued was the same one you made; that too often they’d focussed on the surface and ignored the guts of the application. I rubbished the notion that the interface was “separable” from the functionality, and argued that this illusion had marginalised UX.

    I thought the idea of separability had been discredited. It’s interesting to see you feel the need to argue against it still. All too often ideas take root in academia then get ditched over time as people gain a deeper, or more sophisticated, understanding of the subject. Meanwhile they’ve taken root in the outside world and the academics can lose sight of the fact that outdated ideas are still guiding practitioners. Is this another case?

Comments are closed.