Every standard framework we adopt in our work is chosen to offer a new perspective on an old problem and, in some cases, better enable us to meet the challenges of the future. But in overcoming the blind spots of our old mental frameworks we often forget that we've introduced new ones.
In the 1990s the increased popularity of multimedia and hyperlinked systems - especially the World Wide Web in late 1994 - placed a growing strain on traditional, functional models of application design and user interface engineering. The fields of information architecture, human-computer interaction and usability began to transform software design into a much more human, or user-, centred design activity.
This was a reaction to a framework that focused on functions - what can be done - with little to no thought often given to the ease or otherwise with which it happens. (This mental framework is still dominant in many corporate IT groups and is one contributor to the high rate of failure of large IT projects to deliver value.)
A new framework was needed. One which would allow for functions and features to be prioritised according to user need. One in which language is the language of the users, not software engineers (or marketers). One in which the person using the system is explicitly catered for (as a person, not with functions).
The confluence of usability, HCI and Information Architecture gave rise to the new, unified framework of User Experience (UX). In this new model the focus of the design is the experience a person has with the thing we're designing.
As a reaction to the functionalism that preceded it, UX offered a great deal.
In an emerging and dynamic space like the Web it offered a structured approach to structure through the theory and practice of IA. A focus on the emotional response of the user allowed designers to highlight and address issues of frustration and confusion. Convoluted flows; obscure error messages; dead ends; blind alleys; lack of visibility and feedback - all of the things that never make it onto the Functional Requirement list because there is no "Don't frustrate the user" function, and no way to test for it in the code.
New methods of research, evaluation and testing were needed, and were created (or adopted & adapted) by the pioneers of UX. Personas, wireframes, design research, and many more, brought into alignment with the new, user-centred paradigm.
The results have been impressive. The general user-friendliness of most new apps and Web services has improved significantly over the past decade. User research routinely informs strategy, and user testing helps ensure not only a bug-free system, but a far more friendly and less frustrating one.
The UX framework has worked so well that we see "Experience" now paired with other qualifiers as it is more broadly applied. 'Customer experience', for example, is a popular application of this perspective today. Designers who successfully work in this way have begun shifting into product management, strategy and innovation, service design and more. A focus on the experience of use is becoming more and more prevalent.
And with good reason. Apple - one of the most successful corporations on the planet - has a clear focus on the experience of the product rather than the features or specifications of the product itself.
At the same time UX as a framework is itself coming under pressure, and that pressure is coming from many directions.
The complexity of how we as humans experience any situation has caused some to question whether we can meaningfully design another's experience. So much impacts the quality of the experience it's difficult to see how we can orchestrate such control.
In many corporate, commercial contexts, it has been shown that a better user experience will lead to increased organisational value, and yet the impact of such an indirect lever can be hard to quantity and, therefore, difficult to justify.
This is particularly the case in transactional environments where the desired outcome can be described and measured in very concrete terms: order volume, conversion rates etc. There is a natural tendency in such context to fall back on old patterns and focus on functional efficiency. And that is then to the detriment of the experience of use. In other words, by placing the ultimate goal - some specific behaviour - as a secondary outcome, we have undermined the argument for the approach in the first place.
Another factor impacting the suitability of UX as the dominant framework is the increasingly broad, complex problem spaces within which these same designers are now operating. Over the past decade we've seen interaction designers branch away from the stock in trade of UX - the interface and the model of request-response architectures - and begin to look at the behaviour of the person; the behaviour of people on both sides of the interaction, and more and more, at the aggregate behaviour of the entire system within which the product or service resides.
In this endeavour they are joined - often in large, multi-disciplinary teams - by urban planners, architects, organisational psychologists and change managers, behaviours psychologists and more.
For the UX worldview it is difficult to apply the same perspective across scales in such contexts. The experience of the 'crowd' or the community or society become increasingly meaningless. Not only can they barely be described, but they cannot be designed with any real intent.
And it is the case that, despite the rhetoric of UX design, much of the focus of UX practice can be described in terms of behaviours first and foremost. This is not something the community particularly wishes to admit, but much of the discussion around UX is on user actions and activity; little is to do with designing intentionally towards specific emotions or feelings.
Of all of these pressures I think the most critical (and the most relevant to the work that occupies me) is the difficulty with which the UX framework scales and helps the designer tackle issues of system dynamics and system-level behaviours.
In my own work I resolve this tension by focusing my attention on the behaviours I wish to see and the factors influencing, blocking and shaping that behaviour.
I recognise that a key factor in shaping a person's behaviour is the experience they're having. And so I intentionally take it into account and design an explicit experience. Sometimes that experience creates 'friction' for the user to make them more aware in the moment, and creating a point of leverage at which behaviour change might occur.
Behaviour represents an important target state at all scales of the service, from the micro interactions of the 'interface' elements through to the large-scale, systemic behaviours that influence national economies, education and healthcare. At larger scales, 'experience' becomes non-sensical.
Behaviour, at all scales, is much easier to measure and subsequently can be aligned much more readily with organisational goals.
To think about the design for behaviour it is useful to pick a scale and look at the component skills necessary.
At a high level, the behaviour of the system is driven by system dynamics - cause and effect, feedback loops, dampening effects and delays. An appreciation for Open Systems theory is also beneficial as large-scale design challenges rarely operate at the simple level of closed systems.
Depending on the type of challenge the design team might draw on urban planning, architecture, place-making, public policy frameworks, political and social ideology, economics (macro & micro) - even biology & emergence.
The next meaningful step down in scale might be to the individual or group, and the challenge of aligning the individual behaviours to beget the system behaviours desired. In this context we might look to behavioural economics, cognitive and behavioural psychology, ergonomics, persuasion, credibility & trust, and more.
We may also want to understand environmental and contextual influence over behaviour such as cultural identity, religion, technical capability (and access), and socio-economic status.
We need to understand group dynamics, architectures of choice, and social interactions; mental models, language and labels will also surface.
At still lower levels of interaction, the behaviours we see are direct attempts at manipulating information/data, objects, and/or people through discrete controls. These low-level interactions "bubble up" to drive the higher-level behaviours.
These interactions are the domain of disciplines such as industrial design, graphic design, information architecture, HCI, interaction design and usability. We may as well include copy-writing and content governance since these, too, are levels that help shape specific behaviours.
And, of course, we need to understand how people are feeling throughout, what they'll remember afterwards and what they'll forget. These are some of the more experiential components of the design.
A focus on behaviour has disadvantages as well; its own blind spots. It can lead unwittingly into a slavish focus on numbers and indicators, becoming more and more short-sighted, and more narrow in its thinking.
It also runs the risk of slipping into 'tricks' - gimmicks aimed at gaming the system; so-called "black hat" techniques geared towards behaviours not in the best interests of the person using it.
These risks can be mitigated, however, and the focus on behaviour not necessarily be a problem.
Increasingly I believe a singular focus on the individual's experience is limiting our work and narrowing our scope of exploration. It is less and less appropriate to the projects undertaken beyond the digital realm, and particularly those in the service domain.
I also believe that each framework can act as a 'lens' through which we assess the problem, opportunities, and potential solutions. And, more and more, the use of multiple lenses in the same project will become the norm.
For designers currently fixated on the user's experience above all else, a framework centred on behaviour could be a valuable alternative to bring to bear.