The user interface (UI)

An important cluster of relationships within the innovation games is that of the user interface (UI).

Although designers design objects, the building of them is left to the engineers.

Designers create representations of an object in which they make sense of the compositional, sensual, emotional and spatio-temporal aspects of the object (Wright et al., 2003). These representational artefacts describe the object and may consist of user journey maps, wireframes, mockups, or interactive prototypes. Much detail goes into the representation of the user interface (UI), which describes the relation between body, object, and action (Bonsiepe, 1994, p. 29):

“The interface is the central domain on which the designer focuses attention. The design of the interface determines the scope for action by the user of products. The interface reveals the character of objects as tools and the information contained in data.

It makes objects into products, it makes data into comprehensible information and - to use Heidegger's terminology - it makes ready-to-hand (Zuhandenheit) as opposed to present-at-hand (Vorhandenheit).” (Bonsiepe, 1994, p. 29)

Because of the level of detail that goes into the description of objects, as illustrated in the previous section, the collaboration between the designers and the engineers is close and often tense, because so much is at stake (Cooper et al., 2007, pp. 21-23)*. In the description of the UI, a negotiation takes place in which designers create a specification that “balances user, business, and technical

requirements,” and the engineers are then concerned with the “construction process” of the technical infrastructures and software code, following the requirements.

There is generally a separation between design and implementation, as mentioned in section

“3.1.1 Bridging problem and solution.” Some minimal parts of software code may be written by the designers, but this is usually only the code that deals with the look and feel of the user interface, that is, the HTML²⁰ or CSS²¹ code. However, the majority of the designers do not write code at all, in my observations.

Dourish (2017) has written an extensive work on the materiality of digital technological

infrastructures, and how local software code is rendered through a vast network of servers and cables.

Digital information is displayed by the local devices in use, such as computers, mobile phones, or tablets, which are in the hands of the users. These local renderings of screens, of which the shorthand is the UI of a software program, are constituted through the technical infrastructure and the

dependencies between designers and developers that “bleed through” to the UI (p. 202). This constitution of the UI is made up of many interrelating factors. If a server is down, the user may not be able to see the UI, or the UI may show an error instead of the expected content. If the code has a bug,²² the user might see something unintended. If the UI works in Safari browser for Mac, but not in Google Chrome browser for Mac, the user on Google Chrome browser for Mac will not see the UI or will see it jumbled up. If the designer was not able to get the developer to put the link to the contact page on the screen, then the user might never find out how to contact the company. If the user is blind, and the web content is not made available to the assistive technology of the blind, then the user will not be able to read the content. The relationship between the user and the interface is configured amid a “deeply mutual constitution” (Suchman, 2007, p. 260). Considering that the interface as it faces the user has been constituted by a complicated configuration of designers, prototyping software, developers and technological infrastructures, a user interface may be seen as

20 HTML is a markup language which describes web documents. These web documents are rendered and displayed by web browsers on devices such as computers, mobile phones, or tablets.

21 CSS is a style sheet language which describes the appearance of elements written in HTML, for example, the colour, size, widths, margins, etc., and in later versions also animations such as moving an element

22 a bug is something that causes the code to not run as intended

very dense configuration of relationships within the innovation games by the time it renders on the local device of the user. The UI is constituted by relations between design, implementation and use.

Figure 27: The relations of the UI: Design, Implementation and Use

Despite the global constitution of the UI (Dourish, 2017), there are two local descriptions of the UI within the organisation. The local description of the UI happens once in design, through the

prototyping software, user journeys and other representational artefacts of the object, and once in the implementation of these specifications by the engineers. However, instead of viewing them as two linearly dependent stages of organisational process, in sociomaterial practice, these may be seen as two potentially conflicting descriptions of the UI that negotiate in their intra-action the constitution of the UI. This is part of the local negotiation of the innovation game, to create the description of the UI together.

Gerald works on an expert review of an existing website of his organisation. The expert review includes the review of competitor websites, defining what works well in each of the sites, and what doesn’t. The aim is to create a catalogue of improvements for their own website. Gerald takes notes on the cookie messages²³ which appear, which he thinks are not good. He reviews a page on investor

information, which he thinks does not add much value, and should be placed on a secondary level of the website navigation. He also reviews the use of some charts to illustrate information but deems them to be inappropriately technical. Gerald continues with the expert review where he evaluates parts of websites according to their value and effectiveness. This is part of his work as a designer.

Gerald makes a description of the UI in which he defines what is wrong with the cookie messages, with the investor information, and with the information charts. Note the language of review and expert. Gerald negotiates a position for himself where he can make the description with authority. In another setting, Lena and her colleague Jules review the UI for creating reports in their product:

They discuss the new filtering feature. They use the technical terms of search technology. AND and OR are search operators which connect key words and define whether two words build a search key together, of if they build two alternative search keys. The two designers come to the conclusion that it is a problem how the search parameters are used in the UI: “that’s the problem with the AND.” The two designers have a clear idea how the search operators would need to be used.

Similarly, Alice evaluates a search functionality:

She opens the application she is evaluating and uses these terms as search terms in the filters provided. In the search functionality, she enters “[Legal expert]” “OR”

“[Corporate Lawyer].” The application returns zero results. She enters “[Legal expert],” and the application returns a list of results. Alice takes a note in her

23 A cookie message is in this context a popup window which asks the user if some information about the current use of the website may be placed on the user’s computer

notebook. She now enters the third search parameter - “UK.” The application suggests “Ukraine” as a Location. Alice makes a disapproving sound and takes a note in the notebook. The application does not behave in this instance as Alice thinks it should.

Alice documents in her notes in what ways the application deviates from her expectations. An expectation is an anticipation of something. Alice anticipated UK to describe United Kingdom. This would have been the correct version of UK in her eyes. Alice makes a description of the object as she deems it to be correct. In the following, I speak with Jack about taxonomies and the order of things.

I had observed him ordering many items into categories that he had made. I asked him how he knew how to sort the items.

Jack tells the that he usually firsts sorts “taxonomically.” By this, he tells, me he means how things belong together “technically.” For example, “awesome” and

“awful” technically stem from the same word (“awe”). Second, he would organise things “colloquially,” or “how people understand things.” He makes a distinction between the technical and the colloquial order, and when he has completed the ordering, he understands the order to be complete.

Jack differentiates between two orders, the technical order, how things simply are, and the colloquial order, how people use things. There is an acknowledgement that there are several ways of describing things. When making visual design considerations, there are many possible ways of ordering things.

Many descriptions are possible, and none stands out as a correct one. I join Charlotte and her colleague Frank in a review of a UI design:

They discuss the placement of the “back” link on a page with a data visualisation.

Also, prominently on this page is a “word” describing the current data

visualisation. Charlotte says that she is not sure to have “the word like that … floating around” in the “white space.” She means that it might be a problem to have both the single word and the “back” button positioned next to each other in the top left corner of the rectangular data visualisation. Frank responds that it is

“more visible in the white space, than if it sits up there” [in the heading].

Charlotte eventually agrees: “Maybe I am overthinking it.”

Getting lost in the top left, “floating around” in the “white space”, or becoming “more visible in the white space” – these considerations reveal the multi-dimensional space of possible relations.

Possibilities are revealed as far away from right and wrong. They can go anywhere. Designers are aware of their impact on whether users are able to navigate their products and its functions. Don’t make me think is one of the books in the designer library which reminds designers of the many possibilities and constraints which come to bear in the everyday paths which users take through their products (Krug, 2005)*. It is what designers choose to see and problematise, which becomes part of the description. Haraway (1988) reminds that such object descriptions are “boundary projects” in which “siting (sighting) boundaries is a risky practice” through which practitioners participate in

“unequal structuring” (p. 595). Furthermore, whilst siting and creating the description of the bounded object, designers position themselves as “indispensable [to this] problematization” of what its preferred description is (Callon, 1986). A stabilisation of positions and relationships between team members is achieved in the activity of de-scribing of technological objects (Akrich, 1994).

When Olivia reviews the code implementation of the survey opt-in, she knows that the business would like this opt-in to increase the response rates of users. But she wonders about the best thing to do for the user. She looks at the UI which the developers have coded, and she wonders about the effects of it. She is not

convinced about what the developers had done, and says, “This is a typical thing where a developer goes ‘We just tick this box,’ but we need to make sure it's OK.”

The designer enacts a position of being able to make “OK” and to correct what the developers had done. Here, the developers are not able to do that, while the designer is. Designers describe

preferences when they problematize object relations, such as describing what is “OK” and what is not “OK.” Designers enact their indispensable positions within the descriptions, for example by making to-do lists for the engineers:

While I visit David, he works on reviewing a UI which has been coded by the developers. He explains to me that the developer has deployed the code to the

UAT environment which translates to user acceptance testing area. In the UAT environment, David can check everything was implemented correctly. David logs any deviations from expected behaviour as bugs in a Google spreadsheet. This spreadsheet will later serve the developer as guidance to make changes and adjustments to the code.

As I have demonstrated, designers consider many relations in their descriptions of the object in question, such as its value, effectiveness, related business and user needs, visual meanings, technical meanings and colloquial meanings. Designerly knowing is enacted as the description of objects in which many relations are synthesised. Designers also care to make things “OK” and reinforce their description of designs, made indispensable through their positioning in problematising and bounding the relations of the object, through reviewing, evaluating, comparing, taking notes and compiling to-do lists for developers. A separation and hierarchy are created in the description of the UI through locating those who know and care (the designers) and those who don’t (the engineers).

Designers deal with a multitude of different aspects when they create their description of the UI. It is a negotiation in which the user features heavily, as well as visual design aspects, business

considerations and technical meanings, such as search logic and word stems. They locate themselves as the ones who know, and the engineers as the ones who must follow.

By separating the implementation of their designs, designers locate engineers to be responsible for the technology as a knowledge entity. The technology is isolated as what needs to be tamed, by replacing its natural technical inappropriateness of complicated search parameters and taxonomies and with a description embodying the synthesis of taking all aspects into consideration. In the eyes of the designers, the knowledge entity of design takes precedence over the knowledge entity of technology. In the enactment of design, designers are able to synthesise many different knowledges and take a position of design competence. They thus demarcate the engineers to be the ones being given to-do lists, told what the correct order is, and what is OK to do in the UI and what is not.

In the separation between design and implementation, the designers are in the advantageous position of being responsible for the human knowledge entity. The separation may be seen as a move in the innovation games, renegotiating orders and positions of knowledge entities. Only through the separation can a hierarchy between the two be introduced, and this may be the function of the

separation, in which designers reinforce their positions as responsible for the human aspect, likely to enjoy primacy from a human standpoint. Separating design and implementation has isolated technology as the entity over which the designers’ descriptions dominate.

4.3.2 THE NEGOTIATIONS BETWEEN DESIGN AND IMPLEMENTATION