The HU University of Applied Sciences, where I work, is located on a campus at the eastside of the city of Utrecht in The Netherlands. Amsterdam-IJburg, where I live, is located north-west of Utrecht. My navigation system claims the best route from home to work is a 48.4-kilometer drive (27.6 miles). I, however, say the best route to work is 48.6 kilometers (27.7 miles). We are both right.
Let’s first consider the route my navigation system proposes. The trip is indeed exactly 48.4 kilometers, or 34 minutes, if I were to travel south first and then take a left to drive east, make a short loop around Utrecht and end my journey by sailing into the parking in front of the university building. Now consider my route. I opt for the 48.6 kilometers (still 34 minutes) via two other highways that take me first east and south. Not because it is faster (it is not) but because, for me personally, it is nicer: this latter route brings me past an area that I have fond childhood memories of and I like that moment of contemplation before the workday begins.
My navigation system and me, we have been fighting over those 200 meters (a bit more than 200 yards) for eight full years now: 42 weeks per year, five mornings per week, we have been nagging each other in an old couple’s married-way-too-long type of way. My navigation suggests going south, I actively ignore it and go east. It suggests me to take the nearest exit south to course-correct insisting that is still quicker (it is right), but I stubbornly continue to drive east and tell it to stop interfering. It tells me three or four times more to turn and change my route, sounding more urgent with every missed exit, but I pointedly look out the window and pretend not to notice him (yes, it is a him). It will take a good ten minutes before the system will finally settle for my alternative route and grudgingly recalculates distance, directions and traffic delay for this non-preferred route. The traffic delay information is why the system is on in the first place, by the way. After eight years, I do know my way to work.
Why is my navigation system so stubborn? It does what it was programmed to do: it calculates a route between current location and destination and makes a suggestion. The suggestion is based on data streams that consist of relatively invariable information (roadmaps and traffic regulations, such as maximum speed) and data streams with a high velocity (real-time traffic information, sometimes weather conditions, and road works, etc.). The calculations do, of course, occur within the selected user options. For instance, the navigation will adapt its suggestion by taking into account whether I selected one of the pre-set choices such as shortest route (“no, that will take me through every village between Amsterdam and Utrecht and it will take forever”), most efficient route (“yes, I drive an electric car, so efficient is good, but the efficiency difference between the two disputed routes is practically zilch”), or quickest route (“well, ok, quick is nice”). It can also take into account whether I want to avoid toll or not (“not relevant for my daily commute, no toll roads in The Netherlands, we have a decent general tax system that pays among other things for roads”), whether I want to avoid ferries (“we do have a lot of them but not on my way, so still not relevant”), or whether I want to avoid highways (“no, who in their right mind would want that if they are not out touring for fun in their midlife-crisis convertible?”). So, to a certain extent the navigation’s calculation is personalized. However, it is definitely not personal and that seriously hampers the user experience. For my navigation system, in my car, I would like a system that helps me in the context in which I use it: to establish travel information for my personal travel habits, on a well-known route. Most of the time, I do not turn it on to help me find my way in unknow territory (which is still the only context that navigation systems are generally designed for) (Svahn 2004, p2).
Given the same settings, a navigation system will offer user A the same advice as user B. One reason for that is that it ignores an important data source, namely the behavioral user data, the data that is generated by the user while using the tool. The second reason, as stated above, is that it ignores the context of use: by far the majority of times, navigation systems, to stick with this example just a bit longer, are used not for navigation but for real-time information traffic en route to a known destination, so the driver can make informed decisions about detours or whether or not to make phone calls to warn about delays (Svahn 2004). When a user for these known routes (context of use) consistently selects another route than the one suggested by the system (behavioral data or user data), the system should register that as relevant. That is the exact moment where the shift from merely being personalized (select [shortest] or select [quickest]) to a truly personal tool occurs: historical user data generated by her behavior in a specific context is included in the general calculations. That would result in a truly data-driven design. And in my personal car, for my personal daily commute, I would love it if my car was designed with the quality of personal in mind.
Let’s build upon this personal experience and contemplate the concepts introduced above from a process perspective. Consider the data-driven feedback loop in Figure 1 below. This loop is at the heart of the research program of the research group Human Experience & Media Design at the HU Applied University of Sciences and also functions as the foundation for the one-year Master program Data-driven Design, taught at that same university (Smits, Nguyen, Hekman, Van Turnhout, 2020) . This Master program is intended for media, communication, and journalism students who realize that they are writing and designing for and contributing to an inherently datafied world. During this master program we explore below loop and bring home the idea that each and every element in this loop is relevant, and that current design often fails because one or more of the elements were not taken into account.
Figure 1: Data-Driven Feedback Loop
The Data-Driven Feedback Loop illustrates the essential steps in a data-driven concept. Let’s start with the left-hand side of the loop, the organizational environment. For a navigation system, data from external sources, such as traffic data and mapping data, can be considered part of the organizational environment. There is quality of data to consider (how recent is the traffic data?). And there are partnerships to forge between the builders of the navigation system and the parties who deliver data. And finally, there are APIs to maintain so the data can be accessed. Within that organizational context the data is analyzed in order to deliver a core service: calculate and monitor a route from from A to B at that moment in the least amount of time given the current traffic situation and weather conditions. The analysis will take the defined metricsas a starting point for its analysis: how recent is the traffic data (not more than x minutes), what are the settings of the user (shortest/fastest/most efficient), how much time for corrections to the route to be suggested, etc.
The output of the system, in this case the suggested route, took all those metrics into account and adapted accordingly: the adaptive output, therefore. This brings us to the right-hand side of the loop now, because this output results in a user experience.
Now, if the context of use of the navigation system was indeed a user who would like to know how to reach her destination in an unknown environment, this would be a perfectly acceptable result (supposing the delivery of the route, both visual and auditive is well-designed, too, and the data it is based on is indeed of high quality). However, in the context of use where a user “only turns it on to see if the preferred route is not too clogged today”, this provides exactly zero valuable information. It will only show traffic information of the route it selects, not the one its user would like it to pick. And many navigation systems will not show the amount of delay of an alternative route, until you are actually on that route, and there is no turning back anymore. So, in that particular context of use the user experience is definitely poor. The context of use (you want to know where to go) does not match my actual context of use. On top of that, there is also a clash in the interaction quality that drives the design:
I suppose the interaction quality the navigation has been designed for is ‘efficiency’. However, as stated above: I would like my navigation system to be designed around the interaction quality ‘personal’. I would like it to ‘know’ that I have not driven to a location before, and then it should, please, find me the best route. But if it ‘remembers’ that I have driven a particular route on a regular basis, on that same regular basis ignoring its suggested route, then it should use that data. My behavior, or my user data, should somehow be fed back into the system. At the first go-around, the system registers but does not yet conclude – after all, there could be many reasons for the detour. After a set number of times though (metrics), the system makes a different choice, and uses that personal data as reliable input for its analysis and therefore, also as input for its navigation suggestions: the output is adapted and next time it will suggest the user-preferred route. The user experience has improved. This is actually an important reason why people are willing to share personal data: to improve their individual user experience. That is quite different from giving up personal data in order to be confronted with unsolicited advertisements.
Note that in this particular case, the output is solely adapted for that specific user who has displayed that specific behavior in a specific context of use; it is not suddenly something that is suggested to all commuters between Amsterdam and Utrecht, it has not been transformed into a characteristic of the demographic, it is personal.
Now above description loop works if the tool is somehow able to determine the context of use, and if the mapping between interaction qualities (personal) and the considered metrics (how many deviations from the suggestion before the alternative behavior counts) works.
To illustrate these conditions, let’s consider another data-driven example, because my continuous battle with my navigation system is by no means my only struggle with the datified society. The Spotify algorithm is actually overly active in interpreting and including recent behavior in its recommendations (the user data continuously results in adaptive output). I often (perhaps, foolishly) let Spotify determine what I listen to. On Monday mornings, while driving to work, I am generally happily anticipating my Discover Weekly playlist: every Monday, Spotify recommends a mixtape of fresh music based on my recent listening behavior. However, a while ago I hosted a Mexican-themed dinner party on a Friday night. Obviously, we listened non-stop to Mexican Mariachi-music. We did this in the context of that party, and – being good millennials – we did this ironically. That was our context of use. So while the music was fun for the duration of the party, and greatly contributed to the spirit of the evening, Mariachi music is decidedly less fun to listen to on a drizzly, Monday morning on my way to Utrecht. Los Tigres Del Norte, I cannot recommend it. It has, however, been weeks since that fatal morning, and I am still bombarded with mainstream as well as rather obscure Mariachi types of bands. Most parents whose kids got their hands on their adult Spotify account can relate to that: suddenly there is a lot of Elsa from the Disney movie Frozen in their playlist.
As I said, Spotify’s reaction is the opposite of my navigation system’s but they both miss out. While the navigation system ignores the user data part of the feedback loop and is not too aware of the context of use either, the Spotify algorithm is overly active when it comes to user data, but also has no patience with the context of use, at all: one night of Mariachi does not mean I am now a Mariachi fan.
And here is the thing, since there is no way to correct Spotify except by ignoring its suggestions, it takes a long time to course-correct its wrong assumption (oh please, let it not be eight years, too!). At the very least, there should be an option to explicitly tell it: “stop, I do not like Mariachi to be sprung upon me unexpectedly”. At the very least, I should have the option to tell my navigation algorithm: “listen, whenever the detour is no more than 15 minutes, try to find the route that gets me close to the A27”. At the very least, I should be able to let my tools know if a specific context of use applies. That would give the user power over its tools again, instead of fighting them. That would give me the feeling my personal data actually amounts to something. It would be even more awesome, if the system then automatically changed its interaction qualities and therefore its metrics: “aha, it is an ironic listening spell to Mariachi music, therefore, I will not use ‘developing recent discoveries’ but ‘ignore millennial irony and continue on the earlier discovery path’ as my interaction quality. That means that for my metrics, I can delete Friday night’s sequence entirely”. That would give a user power over its tools again and over its data, and that would give true insight in how the cooperation between me and my tools can work for the best.
Designers in a datafied society need to be aware of the absolute necessity to take every element of the data feedback loop seriously. None of the elements take precedence over any of the other elements, and none of the elements can be ignored if one wants to build a truly good user experience. As a result, the challenge for designers in a datafied world is (1) to find the contexts of use in which a tool is used (and to keep finding them, as use changes), (2) to find the interaction qualities that truly enhance the user experience in that particular context, (3) to identify which user data may reflect those interaction qualities and (4) to design metrics that can help assess if the quality is implemented well or not yet. That requires good old-fashioned user research as well as data-savviness and willingness to experiment. This is no easy task: designers need to be fluent in data ethics and data literacy. This has to be done in the right way, technically, user experience-wise and with regard to ethics. These are the type of things we teach in the Master Data-driven Design.
Students of the Master program are required to continuously experiment with and contemplate on this orchestration of all the feedback loop-elements. One student, for instance, designed an interface for his brother who had a hard time controlling the movements of his hands and fingers and who used an electric wheelchair to move around. The interface our student designed was controlled by eye movements and voice commands. But it also was designed to learn from the brother’s earlier choices (user data). Did he first use the interface to turn on the light in the kitchen and the hallway and then to close the curtain in the living room? And did he do that regularly in a specified time frame? This might be an ‘evening routine’ and the interface would help go through that routine more quickly as result of predicting desired moves (interaction quality: convenience). Our student quickly discovered a challenge in this interface, however. While it was designed for convenience, it quickly became a nuisance. The brother often just wanted to flick on the kitchen light shortly to locate, for instance, his wallet, but the interface started the entire evening routine. Instead of being in and out the door, he had to take a lot of time turning off all the lights that he had never requested to be turned on, and opening his curtains again.
The world needs data-driven designers, who truly see behavioral data as a function of improving user experience in many contexts of use and who are creative in finding metrics to implement the interaction qualities for which they design. The world needs designers who understand the relevance of every element of the data-driven feedback loop and how the user needs to have control of at least the element that can be easily understood: context of use. The new generation of designers is hopefully going to give us a plethora of tools that we love so much, because they have adapted themselves to us so well. There might be a day we do not want to sell our car anymore, because of our well-trained navigation system. Until then, I will continue arguing with my navigation system and will continue to try and convince Spotify that, seriously, I really only do like Mariachi music ironically.
Smits, A., Nguyen, D., Hekman, E. Van Turnhout, K. (2020). Data-driven design. International conference on engineering and product design education, 10-11 September 2020 (Herning, Denmark).
Svahn, F. (2004). In-car navigation usage: An end-user survey on existing systems. Proc. IRIS’27.
Photo: Linda Söndergaard
