On the acceptance of UX concepts in the development process.

Brave new web

The dawn of the Web 2.0 era has seen the uprise of many new and highly interactive elements of what make today's internet: rich internet applications, user generated content and social networks just to name a few. Along with these came a higher sensitivity to the users needs. This led to UX Design entering the realm of the web as the response to the increased demand to professionally tackle the issue of shaping customer and user experience.

In the first decade of the browser based internet (1993-2003) professional UX Design was only rarely a part of the standard commission and development process.

Introducing UX design to projects has brought along a shift in focus. Ever since UX experts have been involved in the development of sites and applications they saw themselves confronted with the problem of not being integrated well in the development process. The traditional participants of the process seem to tenaciously ignore their points of view and all the explaining of the importance of UX concepts for the success of a project doesn't seem to change that. However it would be negligent to reduce this to the lack of knowledge about UX or even to the lacking will by the participants to learn about UX.

Every project is a process that extensively involves decision making. In order to be successful this presupposes mutual acceptance of the participants, an acceptance that is heavily depending on expressing and meeting expectations.

This paper shows the dynamics of collaborative design as a process of extensive decision making  and defines criteria that are relevant for the acceptance of UX in a development process.

From Collaboration to Collaborative Design

In short collaboration is the successful sharing of a working environment in a joint effort to accomplish a task. Good collaboration allows the free flow of information and an awareness of when and how the stakeholders participate in the collaboration.

Collaborative design expands this concept. It is distinct because it points at the creation of an artefact as a more complex form of accomplishing a task:

Collaborative Design takes place whenever an artefact is planned and/or implemented by two or more participants.

The term design is not restricted to graphic representations, but has to be understood in a wider sense: as the act of giving form to a structure or object. In some typical collaborative design areas like architecture, software development or movie making the creation of the artefact involves the design of high variety of interdependent elements and the contribution of different departments that have to agree on a single design.

Collaborative design is the inevitable process that emerges when something is built by a team. It is not a consciously chosen process like User Centred Design or Test Driven Development. Collaborative design is an inherent part of a project, it just happens. Even if the project is between a one-person company and a one-person client it involves collaborative design.

The Structure of Collaborative Design

The process of collaborative design involves a network of participants and is shaped by the interactions of these participants. Each participant is able to propose solutions for design issues. The goal of any collaborative design is a product with an optimum of utility:

Some designs are better than others. We can in principle assign a utility value to each design and thereby define a utility function that represents the utility for every point in the design space (though in practice we may only be able to assess comparative as opposed to absolute utility values)[…]

The goal of the design process can thus be viewed as trying to find the design with the optimal (maximal) utility value, though often optimality is abandoned in favor of ‘good enough'. (Klein et al. p. 203)

Each project typically has participants in different concurring entities or divisions with very distinct tasks. In order to fulfil these tasks decisions have to be taken, some of which may have a negative effect on the fulfilment of an other participant's tasks: Every participant is driven by self-interest that bears the risk of favouring the fulfilment of the personal task over the achievement of a common goal.

A simple example with three participants: a customer, a developer and a designer. As a customer I want the product to be affordable and yet magic. As a developer I want the product to be solid, stable and performing. As a designer I want the product to be highly functional and visually appealing. So each of these participants has a very distinguished personal task that determines self-interest. Fulfilling this self-interest means being good at the task assigned within the project. This however does not mean serving the project in the best of possible ways. Fulfilling the self-interest means reaching a local optimum of utility, an optimum thus only valid in the realm of the task assigned.

The decisions that may be made by each participant for the fulfilment of tasks in a project are highly inter-dependent. Typical inter-dependencies may involve access to shared data, research results or infrastructure. These inter-dependencies make the radical pursuit of the fulfilment of self-interest both harmful to the achievement of the common goal and almost impossible to accomplish. It is harmful because ignoring the dependency of a participant leads to the failure of the other participant. It is difficult to accomplish because inter-dependencies are mutual: no participant is completely independent from others. Hence: Participants must be willing to compromise their self-interest for the sake of a global optimum.

Adding Complexity

The larger the projects the higher the level of complexity. With a high number of participants the system can become non-transparent because it is hard to keep track of the interactions and design decisions.

Further complexity is added when not only the number of participants but also the number of companies involved increases. This additional layer is especially complex due to the variety of possible constellations between companies. Companies involved can be competitors, subcontractors, partner-companies.

An increased number of participants can favour the emersion of subsystems consisting of a few participants with similar tasks. These subsystems also have a local optimum utility plus their participants are loyal to each other.

Every new participant brings a different set of expertise to tackle a task and therefore establishes an own local optimum and a specific self-interest. This brings along a shift in the overall utility. The project however could fail if old participants refuse to accept a new participant. If the old participants are unwilling to compromise their self-interest in order to allow the new participant to contribute to the project, the overall utility will not be reached.

Acceptance

Before UX experts were engaged in the creation of applications and sites, developers took themselves as users and modelled processes according to their needs instead of the user's.

UX expertise brought and is still bringing a paradigm shift by putting the user in the centre of development efforts. This means that there is a shift of what the optimum utility is made of, not only as far as a single project is concerned. This applies to a whole industry. This change is not happening without considerable problems, the main effect being that UX concepts are not implemented and become paper waste on the moment they are put into the hands of the developers.

Both contracting developers and executing participants involved on the client's side (e.g. system engineers, data-administrators) show only little or hesitant acceptance towards the new paradigm.

In addition before UX engagement the responsibility for the utility of a design was not clearly assigned but diffused among the participants. UX experts took up this responsibility explicitly.

The key to acceptance is understanding. In order to build truly active commitment overcoming passive tolerance or even rejection, it is important to raise awareness of the dynamics mentioned before. However is also important to understand why the developers are so reluctant to reject idea of them as users and why they hesitate in embracing the paradigm of user centricity. Two aspects seem worth exploring: the role of measurability and objectivity and the role of expectation management.

Measurability and Objectivity

Since an application's utility was not anyone's explicit responsibility prior to UX experts being involved, utility did not figure as a criteria for quality assertion. If quality assertions for utility would happen at all, they only did in the context of usability tests after the main development phase, but not as a part of the conceptual phase.

A list of elements for quality assertion includes:

  • Performance (computing speed, interface response)
  • Drain on resources (bandwidth, disk-space, file-size)
  • Implementation standards (normalisation, unit/functional testing, validation)
  • Deficiency (incomplete or faulty implementation)
  • Duration, cost (on time, on budget)
  • Utility (relevance of information, ease of task completion)

There is an important difference between utility and all the other elements of the list: The assertions of the other elements can be done by the participants themselves. The measurability is higher because scale is not an issue: it is not difficult to measure response time or bandwidth consumption. The scales are based on absolute figures, easy to read and interpret. Utility, on the other hand, needs a process involving users to be asserted. It's findings are hard to read and difficult to interpret. Patterns arising from the findings are obscure to participants alien to UX.

Another reasoning that is important in respect to the false assumption that developers are apt to assert utility, is that in the case of utility the user is the only valid measuring instrument. Evidently it is bad advice being tester and testee (or, to be accurate, the measuring instrument) at the same time.  Simultaneously being tester and testee deprives the developer from objectivity. Objectivity is only possible if the results do not depend on the tester, which in the case of the developer being the tester   is not possible. Only measurements based on objectivity lead to reliability and validity.

Expectation Management

One aspect of tackling the lack of acceptance is expectation management. Unexperienced participants know little of what they can expect from UX experts and what expectations these experts have. Expectation management is an essential task both of project management and participants alike. “[…] it is important to continuously manage stakeholder expectations. In other words, regularly communicate and meet with these parties to understand their expectations, candidly identify what each stakeholder can and cannot do.” (Spafford, 2009)

Despite the very heterogenous expectations there are two obvious demands that UX experts have to answer to in order to maintain credibility: device proficiency and completeness of information.

UX experts must be aware and proficient of the device they conceive an interaction-concept for. They must be familiar with the conventions of use on the device as well as its limitations. This is especially true for internet applications due to the fact that the interpreting “devices” are the variety of very heterogenous browsers, be they for desktop or mobile platforms.

One example for this is how printing is handled in the browser. Printing can be triggered in several ways and not all can be intercepted by the page's javascript in order to do optimization form printing. If printing is a key element for task completion, developers expect that the interaction patterns proposed by the UX expert take this in consideration.

One further demand is for completeness and consistency of the information architecture proposed by UX experts. There is a clear division between who determines the architecture and who implements it. Incomplete concepts pave the way for arbitrariness. Missing information that has to be assumed by the developer means asserted utility that is lost.

This means that developers to some extent need methodological guidance. As Rönkkö points out developers become highly engaged in design tasks during implementations, a fact that lead to the appearance the concept of Personas:

[…] developers became heavily engaged in design tasks and often had strong opinions and made suggestions for changes in initial design. Arguments arose between developers and interaction designers concerning the best way to present functionality in the interface. The Interaction designers often had to confront developers with such questions as – from whose perspective do you put forwards claims? Is your opinion a fair representation of the user's opinions? (Interaction designer) The fact that their opinions might not be the same as the target groups was raised. The ID team wanted to remain faithful to the developers' good intentions, their creativity and questioning, but direct it towards a shared user understanding outside their own personal opinions.  (Rönkkö, p. 195)

Raising Acceptance

Successful Collaborative Design is based on the commitment of each participants to achieve an optimum of overall utility. Successful acceptance is based on reciprocal understanding of each others standards and expectations. This understanding can be reached through clear negotiation and can heavily benefit from alliances established by shared experiences and common achievements.  It is essential to make an effort to overcome barriers that separate companies in order to enhance the forming of interdisciplinary teams. Common workflows based on high iteration with frequent synchronisation should be stressed as well as the elaboration of interdisciplinary patterns. These patterns can include project based interface and interaction conventions but also address general collaboration issues like workflow definitions, role assignments or documentation patterns.

                        __

Watch the Slides

Read the most important points of this essay summarized as a slideshow.

Embracing Collaborative Design

References

Klein, Mark , Peyman Faratin, Yaneer Bar-Yam and Hiroki Sayama. “The Dynamics of Collaborative Design: Insights From Complex Systems and Negotiation Research” Concurrent Engineering, Vol. 11, No. 3, 201-209, 2003. Print.

Spafford, George . “Active Expectation Management” Web. 29. Nov 2009 http://itmanagement.earthweb.com/columns/article.php/2246881

Rönkko, Kari . “Making Methods Work in Software Engineering Method Deployment – as a Social Achievement”. Karlskrona, Sweden: Blekinge Institute of Technology,  2005.  Doctoral Dissertation Series No. 2005:04. Print.