Multi-device experience design: supporting an equal flow

of fantasy sport platforms played on different devices

SUBMITTED IN PARTIAL FULLFILLMENT FOR THE DEGREE OF MASTER

OF SCIENCE

Wesley Liefhebber

11802979

MASTER INFORMATION STUDIES

HUMAN-CENTERED MULTIMEDIA

FACULTY OF SCIENCE

UNIVERSITY OF AMSTERDAM

July 27, 2018

1

st Supervisor 2

nd Supervisor

Dr. Frank Nack Dr. Dan Buzzo

UvA UvA

Multi-device experience design: supporting an equal flow offantasy sport platforms played on different devices

MSc Thesis: Information Studies (Human Centered Multimedia)

W.B. Liefhebber, 11802979University of Amsterdam

wesley.liefhebber@student.uva.nl

ABSTRACTPlatforms serve their customers across many different devices. Eachdevice has its own characteristics. Therefore, platforms have manydifferent applications which have their own interface design andarchitectural structures. However, when using these devices in-terchangeably, it sometimes occurs that users are not able to findfunctionality or information which they are used to on anotherdevice, which leads to frustration, disorientation and decreaseduser navigation. Therefore, this study will focus on what the effectof designing for an equal flow is on the UX of a fantasy sports plat-form. During this study, a literature review revealed that a sharedMinimum Viable Product (and architecture), visual language andinteraction types have an influence on the equality of the multi-device flow. These parameters were implemented into a prototypeand evaluated, showing that the architecture of a platform is mostimportant in giving a familiar feeling and being able to find func-tionality and information. Further research on this topic shouldinclude how a shared understanding of important tasks within theMVP can be achieved and how structures of various platforms canbe synchronized to improve multi-device and multi-platform usage.

KEYWORDSMulti-device, UX, fantasy sports, interaction design

1 INTRODUCTIONCurrently, platforms are serving customers their services acrossmany different devices. On each individual device, the platformis presented differently due to the specific limitations and oppor-tunities of each device. According to Chiang et al. [3], paradigmsdescribing the design for desktop devices do not work on mobiledevices, since the size of both devices is different. Additionally,Chiang et. al. [3] also addresses that mobile devices are limited totheir size or limited to a single window, while a desktop applicationis not limited to these constraints. This implies that both of theseinterfaces should be designed according to the design rules of thatspecific device, whereby this process is called multi-device experi-ence design [13]. Additionally, devices support different interactions,such as tapping or swiping, which create different in- and outputs[15]. All factors above indicate that a platform has multiple designapproaches regarding each individual device, to optimize the UXon each specific device.

Regarding the difference of devices, tasks that users want to per-form on a platform (running applications on both devices) mightbe different in terms of interface appearance (visual) and the se-quence of steps to perform a task (structure). According to Yanezet al. [27], on a mobile device tasks are typically relatively different

from where users are familiar to compared to a traditional desktopdevice. This implies that tasks could involve more or less steps tofollow, or that some tasks involve different steps during execution.Additionally, information that is needed to perform a task couldbe hidden or located somewhere else on a mobile device comparedto the desktop version of the application [27], meaning that thearchitecture of a platform is different on each device.

According to Levin [13], the concept of using different devicesin daily life can be called a multi-device world, in which devices areconnected together and where users switch between them whilecompleting tasks. Therefore, it is possible that users perform acertain task while using various devices [11], for example a taskthat is started on a mobile device and finished on the desktop. Asstated earlier by Yanez et al. [27], the flow of performing tasks isdifferent compared from desktop to mobile devices. This impliesthat to perform a certain task, different steps have to be undertakento complete the task on different devices, leading to frustrations [7].Think about updating a profile on a platform. The way to get to theprofile settings might be very different on each device (differentsteps to get there). When a user is used to the way of updating hisor her profile on a desktop device, it might be possible that oncethe user changes to the mobile application, the user is not able tofind the profile settings, leading to frustrations.

Functionality or information might be located on different placesor might be missing in the architecture of a platform on each differ-ent devicewhich leads to differences in approaching and performingtasks. These differences lead to disorientation and confusion whenpeople use the platform in a so-called multi-device way. Accordingto MacKay et al. [14], users’ familiarity is very important for plat-forms and websites, in which users establish a mental model of thepage when they first visit. A very important aspect related to thisis the concept of transitional volatility as described by Danielson[5]. This concept explains that platforms may change over time andare experienced differently on multiple devices which can causedisorientation and decreased user navigation [5, 14].

Since the differences between devices lead to disorientation anddecreased user navigation when using multiple devices [5, 14], thegoal of this research is therefore to investigate the effect on userexperience (UX) of a multi-device platform designed for an equal flowwhen played on mobile and desktop devices.

To put these concepts into practice, this study focuses on theinterface of so-called fantasy sports platforms (FSPs) played on differ-ent devices. These platforms are based upon real-world competitiondata (from sports such as basketball, football or cycling), wherebyparticipants compete against each other to enjoy sports outsideof the stadium, often together with friends. These fantasy leagues

typically start with a draft in which participants select a team ofathletes who will generate points based upon their achievementsin the real-world. The participant with the most points after theleague is finished will win the competition [9].

First of all, in section 2 the proposed research questions duringthis study are described. Secondly, the methodologies that wereused are presented in section 3. Thirdly, the results of the researchare covered in section 4, 5 and 6. Lastly, the conclusion, discussionand future work are presented in section 7, 8 and 9.

2 RESEARCH QUESTIONS (RQS)There are a number of research questions (RQs) that should beanswered in order to achieve the goal of this research, as statedin the previous section. First of all, it is important to investigatehow an equal flow can be achieved on multiple (different) devicesof a platform (RQ1). This implies that design parameters shouldbe defined that might have an influence on the equality of the(user) flow, when using a platform on different devices. Secondly,knowing what influence the design parameters have on an equalflow between multiple devices, it is important to investigate howthis would be visualized in the context of a fantasy sports platform(RQ2). Lastly, it is important to validate if the proposed fantasysports platform will enhance the user experience (UX) when thedesign is created based upon the design parameters that imply flowequality on different devices (RQ3). All these questions finally givesan answer to the main research question (MRQ). The followingresearch questions were covered during this study:

• MRQ: What is the effect on the UX of a multi-device plat-form designed for an equal flow, when played on mobile anddesktop devices?

• RQ1:What design parameters support an equal flow of plat-forms used on different devices?

• RQ2: How would a fantasy sports platform with an equalflow on different devices look like?

• RQ3: How would the UX of a fantasy sports platform beaffected by designing for an equal flow on different devices?

3 METHODSThe research follows the Design Science Approach as described byWieringa [26]. Wieringa describes both a design and an engineeringcycle. Within the design cycle there are three phases to be men-tioned: (1) the problem investigation phase, (2) a treatment designphase and (3) the treatment validation phase. The design cycle isthe first part of the engineering cycle, which also involves the im-plementation of the treatment in the real world and the evaluationof that implementation. For this study, there is solely focused ontheexecution of the design cycle.

Regarding the first phase, Wieringa [26] states that this phase isrequired to prepare for the design of a treatment, by first investi-gating and learning about the problem and the characteristics ofa possible solution (building a theoretical foundation). Therefore,during the problem investigation phase there was focused on defin-ing design parameters that support an equal flow when using amulti-device platform (RQ1). The exploration of these design pa-rameters was done by performing a literature review. The literaturereview was conducted by using the Structured Literature Review

(SLR) approach as described by Kofod-Petersen [12], to structurethe way of retrieving relevant literature that was used during theliterature review.

Secondly, during the treatment design phase, an artifact waswhich potentially treats the problem as stated above [26].Within thecontext of this study, the treatment design phase entails the processof defining how a fantasy sports platform would look like when thedesign is made to support an equal flow on different devices for onesingle platform (RQ2), according to the design parameters defined inthe first phase. Prototypes of both the mobile and desktop interfaceof the fantasy sports platform was made by using InVision1.

Thirdly, the artifacts (prototypes) created in the second phasewas evaluated and validated by performing so-called usability tests.These usability tests show whether the UX of such a fantasy sportsplatform is affected by designing for an equal flow on differentdevices (RQ3).

4 PROBLEM INVESTIGATIONDuring the problem investigation phase the first research questionproposed in section 2 was answered. To answer this question, aliterature review was conducted (4.1), while afterwards, the designparameters for creating a multi-device experience on a platformwas defined (4.2).

4.1 Structured Literature Review (SLR)To formally structure the synthesis process of available information,the Structured Literature Review (SLR) method by Kofod-Petersen[12] was used. This method includes multiple steps regarding for-mulating a query to retrieving documents based upon relevancy.The formed query includes multiple constructs, in which the in-tersection of the constructs should give an answer to RQ1. Theconstructs have alternative terms, whereby an overview is givenin Table 1. Although each different digital library has a differentimplementation regarding the formulation of a query, all queriesused were derived from the query below:

(design ∨ interaction design ∨ UX design ∨ interfacedesign) ∧ (flow ∨ user flow ∨ task flow) ∧ (device ∨mobile∨ desktop) ∧ (application ∨ platform) ∧ (multi-device)

Furthermore, after retrieving the papers (N=57), nine papers(15.8%) were excluded based upon not being written in English ornot being accessible (see Table 2). Afterwards, from the 48 papers,11 were found relevant to RQ1 and were therefore selected (seeTable 3). A description of these 11 selected papers can be found inAppendix A. The selected papers were used during the process ofdefining design parameters, which are discussed in the next section.

4.2 Design parametersTo define what a so-called design parameter is, it is important toinvestigate what a the concept of a parameter is. Typically, parame-ters are a combination of certain quantities of a system, that showa certain output [21]. To put this definition in the context of this

1InVision. https://www.invisionapp.com/

3

Table 1: Main constructs and alternative search terms used during the SLR.

Main construct Design Flow Device Application Multi-deviceTerm 1 Interaction design User flow Mobile PlatformTerm 2 UX design Task flow DesktopTerm 3 Interface design

Table 2: Exclusion of papers based on selection criteria during SLR, inspired by Da Silva et al. [4].

Digital library Collected papers Included papers Excluded papersGoogle Scholar 28 28 0Scopus 11 11 0Science Direct 18 9 9Total 57 48 9Percentage 100% 84.2% 15.8%

Table 3: Selection of papers regarding relevancy to RQ1 during SLR, inspired by Da Silva et al. [4].

Digital library Amount Duplicate papers Irrelevant papers Selected papersGoogle Scholar 28 0 19 9Scopus 11 0 10 1Science Direct 9 1 7 1Total 48 1 36 11Percentage 100% 2.1% 75% 22.9%

research, this implies that certain design elements and design ap-proaches (properties) have an impact on the design and thereforean impact on the flow during the multi-device usage of a platform.

As seen in the work of Levin, there are a number of designapproaches with respect to designingmulti-device applications. Thethree main design approaches are the consistent (4.2.1), continuous(4.2.2) and the complementary approach (4.2.3) and are describedbelow. Afterwards, an answer to RQ1 is given regarding the designparameters that were used during the second phase (4.2.4).

4.2.1 Consistent approach. According to Levin [13], the consis-tent approach entails the process of replicating the same contentacross different devices, with respect to individual characteristicsof each device. This implies that a consistent designed applicationdoes not have to be identical, but it implies that the same content isported to each device and displayed whereby the designs are madeas consistent as possible, with respect to the individual devices(such as screen size). This implies that there is a continuous trade-off between consistency within the ecosystem of the applicationand the optimized experience per device [13], meaning that simplycopying a platform from a device to another device is not a goodpractice. While on the other hand, making applications completelydifferent shows problems as stated above [13]. Regarding the de-sign differences of individual devices, the desktop version showsan overview while the mobile has more focus towards a specificselected element. Although this introduces differences in interac-tion, the location of the functionality or information is on the sameplace (in the architecture), and therefore the design is consideredas consistent [25].

First of all, as seen in the work of de Oliveira and da Rocha [7],creating a consistent design involves creating a solid conceptual

model for a multi-device application. A conceptual model is definedas a description that involves the main concepts of what a systemdoes, how it behaves and how it looks regarding the understand-ing of the user [19]. This implies that a good practice would bethat the conceptual model is shared among all different devices,meaning that from the user perspective, the mental model that iscreated should be the same and applicable to each individual device.de Oliveira and da Rocha [7] describe an example of this situation,in which checking account balance (task) should be performed thesame way on a mobile phone as on a ATM machine. This impliesthat the amount of conceptual models is not equal to the amountof devices, regarding the concept of Conceptual Multi-Device De-sign (CMDD) [7]. Levin [13] underlines this concept, by statingthat it is important regarding the consistency approach to keep theMinimum Viable Product (MVP) consistent across all devices. TheMVP is considered as the features that are vital for the experience,meaning the core tasks that are being performed on a platform [13].Additionally, O’Leary et al. [17] points out that it difficult for usersto learn different interfaces and interaction conventions. Accordingto Vo [24], by designing the User Interface (UI) consistently, theuser is able to benefit from so-called transfer of training [24]. Thisimplies that when a certain system is consistent, people learn howto perform a certain task on a specific device and when they moveover to a complete different device, thanks to the consistency theystill can recall what they have learned. This means that peopledo not or generate less inconsistencies with their present mentalmodels when performing the same task on a different device, whichimplies there is no need to readapt which causes frustrations, un-certainties and distrust regarding the platform of use [7]. Therefore,the architecture is important for users to create a clear mental model

4

and to provide a consistent structure and flow [13], to enable usersto transfer the mental model from one device to another accessingthe same platform.

Secondly, Levin [13] defines that it is important to have a com-mon (visual) language and terminology shared among the differentdevices of a multi-device application, since it stimulates the cogni-tive and affective connection between devices.

Thirdly, devices are different regarding their input and output.According to Bangor and Miller [1], a GUI or full-screen websiteis not portable, whereby other interfaces and types of interactionbecome important. For example, interaction with a mouse andkeyboard are not typical for a mobile device, where touch is thestandard. As seen in the work of Dolgobrod [8], touch is moreintuitive compared to a keyboard and a mouse, but is not as precise.This implies that this is a huge factor in designing an application,since zones of interaction and elements should be adapted to thistype of input. Additionally, Dolgobrod [8] states that mouse-basedinteractions are not applicable on mobile devices. For examplehovering, which is widely used among the (desktop) web to showdrop-down menus, is not possible on mobile. Therefore, during thedesign stages it is important to investigate how certain tasks arebeing performed and that they are performed without using device-specific interaction types. Additionally, Dolgobrod [8] states thatalthough interaction zones are different per device, for examplethe bottom of the screen is easier to interact with compared tothe top of the screen on a mobile device, design should also stickto conventions and existing mental models of users. For example,navigation is typically performed by using an F-shaped pattern [8].

To outline a different type of in- and output, speech is a form thatis independent from the device being used [1], which is accordingto Vo [24] a so-called universal remote control. This implies that arange of different devices can be accessed in the same universal way,hence making the UI more coherent [24]. However, environmentalaspects are different for each device type, which could introducenew problems (e.g. too much background noise to interact viaspeech, or switch from a private to public setting) [6, 17].

Although the consistent design approach has a number of ad-vantages such as a shared experience across various devices, it alsofeatures a downside. Making a design consistent also implies thatthe advantages of specific devices are lost [13].

4.2.2 Continuous approach. While making the design consis-tent, it is suggested that since the conceptual model is equal acrossall devices, there is an optimization in flow [24]. However, Levin[13] states that this does not mainly involve the flow of tasks shift-ing between devices. For example, a task might be started at a singledevice, but then could be finished on another device. This processimplies that there is a continuous cycle of events across differentdevices to comply to the specific goals of users.

The idea behind the continuous approach is that each devicepicks up where the previous device has left of [13]. This meansthat there is some kind of service which is accessible through mul-tiple devices. Väänänen-Vainio-Mattila et al. [22] calls this conceptcross-platform service access, under which it should be pleasant andeasy to switch devices and whereby data is synchronized betweenthe various devices [17, 22]. O’Leary et al. [17] state that data syn-chronization between devices is key, since this picking up a task

from the previous device implies that the device understands wherethe user has left of. A good example of such a service is Netflix2, aplatform where users can watch video content on various devices.The service knows which content the user is watching, and whenthe user changes device, he or she can continue watching on thatdevice without having to search for the content again (and thespecific time marker). Additionally, Vaananen-Vainio-Mattila andWaljas [23] proposes that it is important (as we have seen earlierin the context of consistency), that the user can perform the sametasks on each device of the platform to make such interactions andswitching between devices properly available. When functionalityis not available on mobile for example, the user can switch to thatdevice but is unable to finish the task.

To perform tasks or certain activities, Levin [13] distinguishesboth a single and a sequenced activity flow. Within the single ac-tivity flow, the same activity is carried over multiple devices, forexample (as we have seen earlier) watching a movie. A sequencedactivity flow involves a sequence of activities that lead to a certainend goal, for example managing content on a platform. Withinthe context of a fantasy sports platform, this is typically involvingmore activities (e.g. picking athletes, selecting a captain) to reachthe end goal. This can also be seen as a decomposition of a task, inwhich one task has multiple sub-tasks which can be performed ondifferent devices [20].

As Nielsen and Budiu [16] suggest, to design applications formobile devices, it is important to hide information or functionalityon a mobile phone when it is irrelevant in a mobile context [8].This is important to reduce cognitive load to the user [1]. Althoughthis might seen as a good practice, it can also lead to confusionas seen earlier, since information is hard to find and is conflictingwith the mental model of the desktop application. It is thereforeimportant to inform users when functionality is not available orwhat types of functionality are assigned to which specific devices,to make sure people are aware of functionality being not available[1]. The choices of functionality per device are made based uponwhether functionality is accessible on a specific device, made basedupon the MVP we have seen earlier [13] and based upon user needsto comply to their user goals. In most cases though, most of thefunctionality will typically be shared among all devices [1], anddevices are used interchangeably. Additionally, as Vaananen-Vainio-Mattila and Waljas [23] suggest, when changes are made to theservice, it has to be presented to the user, in which cross-platformusage would become more seamless regarding the clarity of the UI.

Lastly, when cloud services are being used, an improved taskflow and the concept of being up-to-date can be facilitated [22].Again, as we have seen earlier this allows a process to be continuedon another device without having to save and load and distributeto the other devices [17], which causes a distorted task process.

4.2.3 Complementary approach. As we have seen in the pre-vious section, devices may have different types of functionality,whereby the devices can also be complementing each other. Thisleads to the complementary approach, which involves interactionbetween the application run on multiple devices of a platform [13].

According to Levin [13] this includes collaboration betweenusers and between devices. For example, other devices may take2Netflix. https://www.netflix.com

5

a part in the experience of other devices. An example of this isonline gaming application that are being played on mobile phones,whereby people are involved real-time.

Secondly, devices are able to complement each other by havingdifferent types of functionality. For example, a second screen appli-cation on a mobile phone for a TV or a specific desktop applicationcan be seen as complementary. In this way, one of the devices serveas a controller for the other device. This also implies that not alldevices contain the same types of functionality, but this has to beclear to the user (the user knows that the mobile application isonly able to control the other device, meaning that both devicesare used at the same time and not separably). This implies thereare different roles which user assign to the devices, for example thedevice having the role of a hub, remote or a notifier [17].

The complementary approach is not the main focus of this re-search, since the case of a Fantasy Sports Platform does not includea controlling or complementing device, but focuses on being ableto perform multiple tasks on all device-types.

4.2.4 Design parameters. To define the parameters that influ-ence flow while using multiple devices, Levin [13] showed that theapproach for consistency, continuity and complementarity are keyfactors in how multi-device platforms are designed and how eventsare being processed.

First of all, regarding consistency it is important that only oneconceptualmodel is defined and ported to all different devices [7], in-cluding visual language and content. Additionally, the MVP shouldbe consistent over all devices [13], meaning that tasks should beperformed the same way as on the other devices, since this wouldlead to less readaptations and therefore less frustrations, uncer-tainties and distrust towards the platform [7]. The most importantfactor is the architecture that should remain consistent over thevariety of devices [13].

Secondly, the continuous approach suggested that tasks can beperformed on different devices and that multiple devices can be usedto reach one specified goal, either the task being single or sequenced[13]. Therefore, (cloud) synchronization between devices was foundto be important [17, 22]. When functionality is not available on acertain device, or when big changes are made to a device, this hasto be informed to the user since that implies that certain goals cannot be reached from a particular device within the platform, whichcan cause frustrations [1].

Thirdly, the complementary approach showed that devices donot have to be consistent when it is clear that one of the devicesis complementary to the other (main) device. For example, secondscreen applications serve as a controller to extend the experienceof the main device [13].

The three main concepts described by Levin [13] indicate thatthey influence how a task can be performed on multiple devices,meaning that these concepts can be seen as design parameters. Thisimplies that these concepts can be tweaked until they perfectly fitthe user needs and the flow of tasks a user wants to perform. Whena device is assisting another device, this implies that there is anotherrole which describes the complementary approach (which gives apleasant flow), or a device should perform the same tasks and shouldbe pleasant to switch (which we are looking for in this study). Addi-tionally, when a task is divided into multiple (sequenced) sub-tasks,

it is very important that devices are synchronized and display thesame content when switching devices in order to make it possiblefor users to continue their tasks and to comply to their goals.

4.3 Fantasy Sports PlatformsFantasy Sports Platforms are based upon real-world competitiondata of sports events, in which participants compete against eachother as an additional experience to enjoy sports. All of these plat-forms are typically located in a web environment or as a native appon mobile devices [9]. The prototype made in section 5 is based onScorito3, although there are many other examples involving manydifferent sports, such as Fantasy Premier League4 and Profcoach5.As seen in Scorito, users are not able to create a poule in the nativemobile app, informing the user to use the desktop (website) version.This implies that one of the (important) tasks is not performableon all devices, which is contrary to the conclusions of de Oliveiraand da Rocha [7].

5 TREATMENT DESIGNIn this section, an artifact (prototype) was created to define a suit-able solution to the problem [26]. First of all, requirements weredefined based upon the MVP (5.1). Furthermore, this section coversthe definition of a conceptual model (5.2). Lastly, the prototype (5.3)and the technical specifications (5.4) are described.

5.1 Requirement developmentTo retrieve requirements that fit the typical needs of a FSP user, twopersonas and their respective user scenarios are described in Table 4and 5. According to Jurca et al. [10], a persona is a fictional personor character that represents a typical user of the platform. Bothpersonas are based upon user profiles of the application Scorito, aFSP which was earlier introduced in subsection 4.3. Additionally,the user scenarios describe a story which involves the user (persona)and the range of typical activities or typical problems that the usermight encounter during the usage of the system [10].

Table 4: Persona 1: Hans de Noteboom.

Name Hans de NoteboomAge 41Gender MaleInterests Sports (football, cycling)Hans de Noteboom is a 41 years old male interestedin sports. Together with a group of cycling friends,he decided to create a fantasy league for the upcom-ing Tour de France, whereby afterwards Hans invitesall his friends. Hans decides upon which cyclists heselects for his team and he changes his formation ona daily basis, regarding the real life events that oc-cur. After the league is over, Hans knew he did notpicked the right cyclists this year, finishing last in theleaderboard.

3Scorito. https://www.scorito.com/4Fantasy Premier League. https://fantasy.premierleague.com/5Profcoach. https://www.profcoach.nl/

6

Table 5: Persona 2: Theo de Vogel.

Name Theo de VogelAge 23Gender MaleInterests Sports (football), gamingTheo de Vogel is very interested in sports and watchesa lot of football matches each week. One of his friendsasked him to compete in a fantasy league of friendsregarding the upcoming World Cup in Russia. Theoaccepts the invitation and picks football players fromall over the world. Every match stage, he changeshis team to obtain the maximum amount of score.Theo picked some players that played very good onthe World Cup. Therefore, Theo became first in theleaderboard, earning him prestige from his friends.

As seen earlier, the consistency of performing the same tasksthe same way on multiple devices is key in creating an equal ex-perience [13]. Therefore, it is important to define the MinimumViable Product (MVP). An important requirement is that the MVPis ported to all devices, since people do not have conflicting mentalmodels about different functionalities for each device on one singleplatform. As seen earlier, having different functionality on eachdevice (some tasks can not be performed) means that users have toreadapt their model, which can become frustrating [7]. A MVP canbe defined as ’that version of a new product which allows a team tocollect the maximum amount of validated learning about customerswith the least effort’ [18], meaning that the MVP insists on the corefunctionalities needed to serve the target audience. The core tasks(and therefore requirements) for a FSP are described below:

• Create poule The user is able to launch the application andcreate a poule in which friends can compete. After the usercreated a poule, he or she should be able to invite friends,select a squad and view results and the leaderboard of thespecific poule.

• Invite friends to poule After a poule is created or the useris in a poule, he or she is able to invite other users of theplatform to the poule.

• Accept invite to poule The user is able to accept (or de-cline) invites from other users to compete in their poule.

• Select a starting squad Once the user either created or ac-cepted an invite to a poule, he or she should pick a startingsquad based upon a certain budget. This starting squad can-not be changed afterwards (as long as the real life seasoncontinues).

• Select amatch-day squad The user should be able to selectdifferent players each match-day from his starting squad thatwill earn score.

• View results of match-days After each match-day, theuser should be able to see the results.

• View athlete information Each (selected) athlete earnsscore, which the user should be able to view, including in-formation about the athlete.

• View leaderboard During the whole poule, the user shouldbe able to view the standings.

Some of these requirements are dependent regarding the typeof poule. For example, it is possible that score is not earned onindividual athlete-level, but based upon team performances, whichwould alter the tasks a bit. Additionally, all tasks should be availableon both devices [13]. When a user is able to create a poule on thedesktop but not on a mobile device, this inconsistency can lead tofrustration. However, if this is the case it is important to informpeople about these decisions [1]. In the context of this study, someelements however are hidden to lower complexity, which will befurther explained in subsection 5.3.

5.2 Conceptual ModelIn order to let users develop a clear mental model of the platform,Benyon et al. [2] state that designers should conceptually design thesystem so that it fits their expectations and is easily learn-able. Asseen earlier, creating a conceptual model is key for the consistencyof the platform, regarding the concept of CMDD [7]. By makingsure that the conceptual model is consistent over the range of useddevices, the process or flow of using devices interchangeably forone platform can potentially be easier and more coherent [24].

According to Benyon et al. [2], various design concepts should bedefined, including the architecture for the design and considerationof the organization. Regarding the structure (architecture) of theplatform, a sitemap has been constructed showing the differentpages and their relationships. All the pages are featured on alldevices (every part of the architecture is available on all devices).In the case of not designing for flow equality, the site-maps of themobile and desktop version would look different, showing morecontent and information on the desktop and therefore combiningpages together (and therefore moving information and functionalityin the architecture). In Appendix B, the sitemap can be found.

The concepts involved in this research are furthermore focusedon creating a team of athletes, changing it on a matchday basisand creating poules or accepting invites to poules. Furthermore,according to Nielsen and Budiu [16], when creating applicationsit is important for people to be able to recognize icons and habitsthat occur in most applications, since that implies that users canuse already existing mental models of other applications wherebythe level of confusion and disorientation is lower. As we have seenearlier, having a consistent approach, this would also potentiallypositively impact themulti-device use of the platform [7]. Therefore,icons such as user icons and cog wheels for settings were used,which are known for other platforms as well. An icon frameworkcalled FontAwesome6 was used, since this has been implementedin many applications and websites, and is therefore recognizable.

5.3 PrototypeSince we have stated the MVP and conceptual model, these bothare implemented in the final prototype. Regarding the prototype,the tasks that an user has to perform are equal on both the mobileand the desktop prototype of the FSP application. The choices madeduring the design stage of the prototype are based upon the findingsof phase one (4). In Appendix C, the screens of both the mobileand desktop prototype can be found. Below, the various choices arefurther explained and analyzed regarding the consistency of the6FontAwesome. https://fontawesome.com/icons/

7

MVP (5.3.1), shared visual representations (5.3.2) and device-specificinteractions (5.3.3).

5.3.1 Consistent MVP. To reduce complexity in the prototype,there has been chosen to hide all the competitive elements (budgetsfor selecting a squad) or fake these (such as leaderboards and scoreper player), since this is not the main focus of the study, and is hardnot testable in a short time. This means that for example the focusis on selecting and editing a squad, instead of picking a startingsquad and only being able to choose from those athletes, whichis common for FSP applications [9]. This also means that, due tothe clickable nature of the prototype, teams are prefilled (meaningthat the selection of the starting squad is skipped, but tasks remainincluded).

Figure 1: Comparison of the structure of the home screen onboth mobile and desktop, indicating the same functionalitybut a difference in appearance.

The two applications visually look different (see Appendix C,Figure 1 and Figure 2), for example a comparison of the page forediting a squad shows that the desktop prototype has more visualinformation, but the interactions and clickable elements are retainedfor both devices (consistent, but not identical). Information that isnot vital for performing a task the same way can be removed on asmaller device, as stated by Levin [13] earlier. In Appendix D, theuse cases are displayed showing the steps needed to perform thetasks explained earlier in the context of the MVP (5.1).

Another example of the differences between interfaces but con-sistency regarding the architecture is the poule page shown inFigure 2. For example, the desktop screen is divided into a sidebarwith the elements of the poule and a frame which changes accord-ing to the selected element on the left. On the mobile version, theseelements will lead to different pages. Conceptually though, eachelement still has a different page on the desktop prototype, while allelements can be reached the same location and on the same page,indicating consistency during poule-specific tasks. Furthermore,both versions contain different (visual) information, such as thedesktop version having the feedback in terms of shirt color (basedupon position or based upon team), but there are no differencesregarding the performance of a task, which is most important (andprescribed by Levin [13]). Therefore, although interfaces are differ-ent of both applications, tasks should be performed the same waywith the same amount of steps.

Lastly, both prototypes accidentally contain the same amountof available functionality, meaning that the content is fully ported

across all devices. This implies that the architecture of both de-signed devices is consistent (regarding the sitemap seen earlier insubsection 5.2) and therefore should insist on a consistent structureand user flow during the multi-device usage of the platform [13].

5.3.2 Shared visual representation. As Levin [13] stated, it isimportant to have a shared visual representation, so the cognitiveand affective connection between the applications ran on the twodevices is stimulated. The representations are not identical, forexample the poule elements on the home screens are different, butcontain the same icons, colors and font formats. As indicated earlier,the framework FontAwesome was used for the icons, since theseare icons that people are familiar with since it is implemented inmany applications and websites.

5.3.3 No device specific interactions. As Bangor and Miller andVo [1, 24] stated, having a universal remote control can be benefi-cial for making the UI more coherent. In the prototype, there arestill differences due to the differences of the device regarding theinput of the user. The desktop interaction is based upon mouseinteractions or touchpad interactions, while the mobile prototype istouch-only. The tool used to design the prototype (InVision Studio7distinguishes many forms of interactions, including tap, hold andswipe-gestures. There has been chosen to use the tap-gesture onall devices and elements in the prototype, which implies that thereare no differences regarding device-specific interactions (such asswiping is in most cases exclusive to mobile devices such as tabletsand phones).

5.4 Technical specificationAs seen earlier, Fantasy Sports Platforms (FSPs) are being played ina cloud environment and mostly on multiple devices. There are nocomplementing factors in these type platforms, since the platformspropose a solution to fill in team data on each device. This impliesthat the design approach fits into the description of the consistentapproach of, creating one application which content is being portedto all available devices [13]. Furthermore, there are some technicalaspects to be mentioned regarding the continuous (cloud) usage ofthe proposed FSP application.

Firstly, the synchronization of the application is very important.As seen earlier, to switch properly across devices, data synchro-nization is necessary since the data then is able to ’follow the user’regardless of the device he or she is using [17, 22], making the datadevice independent. For example, users might select athletes onone device and later finish the selection process on another device.This implies that multiple small sub-tasks can converge into onemain goal (preparing the draft, managing the content). The datasynchronization currently is faked in the prototype, but is a vitalpart in the multi-device usage of a platform, since when there is nosynchronization people get frustrated that data is not available [17].Therefore, when creating a FSP platform, using cloud services isvital, since the applications retrieve information from the cloud anddisplay it on the screen, rather than having to synchronize eachsingle device.

Lastly, regarding the requirements of a device that runs such aplatform it is important that the device has an internet connection

7InVision Studio. https://www.invisionapp.com/studio

8

Figure 2: Comparison of the structure of the poule page on both devices, showing the (visual) differences between the devices.

to perform the data synchronization. Additionally, the proposedFSP application is typically run on browsers for desktop and (native)apps for mobile device. At this moment, the prototype is createdas an implementation of two native applications, but this could beextended to a browser-based application (website) with the sameidentical characteristics.

6 TREATMENT EVALUATIONIn the treatment evaluation phase, the treatment that was designedin the previous phase (prototype) is tested and evaluated by poten-tial users of a FSP application. In subsection 6.1, the setup for theusability tests is explained. Afterwards, the findings of the usabilitytests are discussed in subsection 6.2.

6.1 Setting up the usability testsAs explained earlier in subsection 5.3, competitive elements wereremoved from the prototype to remove complexity, since it is notin the scope of this study. The prototype was evaluated by usingso-called usability tests. These tests followed a set of tasks whichthe participant performed with the prototypes (same tasks on bothmobile and desktop) and afterwards a set of questions was asked.These questions were focused on the performance of tasks on bothdevices and the equality of the experience (regarding the switchfrom mobile to desktop). This means the usability tests were heldto find out if both devices shared the same experience due to theconsistent architecture, while still having interface differences. Thetasks that the participant had to perform were the same as thetasks mentioned in the MVP, described in subsection 5.1, and wereexecuted on both devices. The devices used during the test werean Apple iPhone 6S and an Apple MacBook Pro 2017 13,3". Thetests were all hold when sitting at a table in a relatively quiet place,which is one of the typical locations where a FSP would be played.

The usability tests were held in Dutch, since all the participants(N=11) spoke Dutch. The form that was presented to the participantcan be found in Appendix E. It includes the specific tasks the partic-ipants had to follow as well as an introduction to the platform andFSPs in general (for the participants that did not knew what these

platforms stand for). Lastly, summaries of each individual usabilitytest can be found in Appendix F.

6.2 Findings from usability testsAs seen earlier, the participants were asked to follow a set of taskson both the mobile and the desktop device and were asked questionsrelated to the switching between the devices and the differencesbetween performing the tasks on both devices. All participants(except P5) stated that both the applications shared the same kind ofarchitecture, which made the applications share a same experience.For example, a large group of participants (P1, P3, P4, P6, P7, P9,P10 and P11) stated that the second device was easier to pick up,while others (P2, P4 and P8) stated that the visual aspects showeda feeling of recognition. Due to both of the applications sharingthe same architecture, it was more easy to find functionality andinformation, since the participants stated that they practised theapplication on mobile, and they could apply the knowledge to thedesktop application (as stated by P7 and P11). Additionally, one ofthe participants (P7) indicated that he expected both applicationsto cover the same functionality, meaning that users expect bothapplications to be able to perform the same tasks.

Regarding the interactions, participants (P3, P4, P8 and P11)stated that on both devices it was clear how buttons and otherUI elements would be behave when being clicked and that thesame terms and concepts were used. The shared visual componentscreated a feeling of recognizability according to the participants. Forexample, P11 mentioned that the drop-down menus during playerselection showed were familiar, especially regarding the behaviourof the buttons (after clicking, a drop-down menu showed up). Sincethe architecture of the application was clear and the interactionswhere familiar on both devices, the participants (P6, P8 and P9)suggested that it could be possible to skip some steps in the processof executing a task if this architecture is known. For example, P8stated that a desktop device contains a larger screen, which couldinclude more buttons to different pages (such as going back to theuser profile, instead of going to the home screen first). Importantly,the functionality should still be accessible on the same way as theother device.

9

Another aspect the usability tests revealed is that users use mod-els from other application and apply it to their new unknown appli-cation when they are learning it. For example, the participants (P5,P6, P8, P9, P11) stated that they were unfamiliar to the way howthe invites were represented. They expected the functionality to belocated on the home screen with an mail-icon, but it was locatedunder ’add poule’. This caused the participants to not being ableto find the functionality, on both devices. After using the mobiledevice though, the participants (P6, P8, P9 and P11) indicated thatthey made the same error on desktop, but directly knew how tofix the problem due to earlier experiences on the mobile device.However, P5 stated that she forgot where the option was locatedon the mobile device and therefore showed inconvenience withperforming the same task on the desktop version.

P3 mentioned that the applications were not completely iden-tical, which could even be extended to fit the devices better. Forexample, in some cases buttons can be made larger on a mobiledevice compared to the desktop device, without causing mentalmodel differences. This also implies that the architecture of theapplication is the most important factor in a pleasant feeling duringmulti-device usage of a (FSP) platform.

Preferences regarding device type were mostly based upon thecontextual aspects (P1, P2, P3, P7, P9, P10 and P11) or personal pref-erence of the device (P4, P5, P6 and P9), indicating that the mobiledevice was easier to pick up and do some small tasks like replacingan athlete or viewing the leaderboard. However, P9 mentioned thatwhen the tasks become more complex, he eventually would pre-fer the desktop version. On the other hand, P8 and P10 preferredthe desktop version since it had more visual information such asathlete heads in the ’edit squad’-section, but this was only relatedto the fact that it was more fun, indicating that there was no pref-erence in performing tasks and finding information related to thearchitecture, lay-out (structure of the interface) and interactions.

7 DISCUSSIONThere are also some limitations that need to be mentioned. First ofall, during the selection of constructs in the first phase of the SLRexecution, there might also have been chosen for the concept of’mobility’, which has links to the mobility of devices, transfer ofdata and multi-device usage.

Secondly, the designed prototype focused mostly on executingtasks on both devices and not on the competitive elements, whichhave more to do with synchronization between the devices. Forplatforms such as FSPs, most of the times the data is stored inthe cloud and accessed by the devices when needed. However, theexperience on other platforms might be different when there issynchronization of files stored on the device itself (i.e. may taketime, may be frustrating when not synchronized).

Thirdly, the prototype contained a port of all functionality ofthe MVP to all devices, meaning that every task was executable onboth devices. In other cases or platforms, this might not be the case.For example a platform that allows making pictures on mobile hasdifferent types of tasks than the desktop version (which might bemore useful for organizing pictures). In that case, the tasks eachdevice can perform are different, which includes that the user hasto be made aware of which tasks can be performed with which

device. Additionally, when this is not done, there might also be adifference in interpretation of important functionality regardingthe user and the designer of the application. For example, when adesigner states that editing a profile is not a task to be performedon a mobile platform (and therefore does not implement it), thismight become frustrating to users who think this is a functionalitywhich should be included on mobile. This implies that there mightbe more differences regarding the complementary approach whichwas out of the focus for this study.

Lastly, speech was found to be device-independent and there-fore a good solution towards a multi-device usage. However, usingspeech might lead to new problems such as awkwardness in public,or problems with noisy places.

8 CONCLUSIONIn order to provide an answer to the main question (MRQ) statedin section 2, a SLR was performed, a treatment (prototype) wasdesigned and evaluated afterwards. There were some elements thatshowed impact on switching between devices, and the experiencethat is involved during the switching process.

First of all, this study showed that an equal MVP is very im-portant when there is a multi-device usage of the platform, sinceinformation and functionality is available on each device. Addi-tionally, the architecture is important in terms of location of thisinformation and functionality, which is located on the same familiarplace on all devices, which is shown to be an important factor inthe transfer of a mental model from one device to the other device.This implies that executing the MVP on each device and in thesame way has shown to be important regarding a pleasant flow onmultiple devices. Additionally, there should be a balance betweenwhat the users expects and what the designer thinks is the corefunctionality of each individual device (and the overall platformitself). When those two actors share the same vision, users willunderstand what goals can be achieved on which device and arenot confronted with devices that cannot perform certain (in theirvision) important tasks.

Secondly, visual interface design is an important in creating anequal experience. Elements that shared the same look and sameinteraction afterwards (e.g. buttons popping up drop-down menus)showed a familiar feeling to the user, knowing the behavior ofthe element when clicked. This also implies that using the sameinteractions (tapping) on both devices is beneficial for the clarityof the UI during multi-device use of the platform.

Another conclusion from the usability tests is that when thearchitecture of a platform is known (after some practice on oneof the devices), some shortcuts can be implemented to speed upthe process of tasks. However, the shortcuts may introduce newproblems regarding a shortcut not being present on each device(for example accessing the user profile on desktop from each pageand on mobile only from the home screen).

Lastly, it is found that current existing mental models have animpact on how the platform is perceived and how each individualdevice is used. For example, users might expect information orfunctionality being located at some place in the platform because ofother experiences, which show problems when there is multi-deviceusage of a platform.

10

Concluding, having an equal MVP, architecture and conceptualmodel for each device within a platform is important for an equalUX of a multi-device platform on each device. Meaning, the effecton the UX of a multi-device platform when designing for an equalflow is that the UX is enhanced when the conceptual model canbe transferred from one device to the other device (which the pa-rameters above take care of). This implies the perspective duringdesign shifts. Instead looking to optimize the UX for each singledevice, there is a focus on how the combined experience of devicescan be optimized to be served as one service. These results wouldbe applicable to any other type of platform rather than FSPs. Forexample, each platform that has differences in the architecturalmodel or the conceptual model for each device is likely to havedisoriented and frustrated users regarding the problem of this study.Therefore, having an equal MVP, equal architecture and conceptualmodel would be beneficial for each platform to overcome thesekind of problems.

9 FUTUREWORKAs seen earlier, the prototype involved a port of all functionalitiesto both devices, meaning that all tasks were executable. However, insome cases, there might be chosen for a complementary approach,in which devices have different functionality on each device, whichcomplement each other (think about making photos on an app andnot on a desktop). Future research should point out how users canbe made aware of what functionality is included in which device,where there is no port of the MVP to all devices. Additionally, thereshould be researched how designers and users can create a sharedunderstanding of what functionality a specific device has, regardingthe difference in interpretation of important functionality regardingthe user and the designer of the application. As seen earlier, it mightbe possible the user wants to perform some certain task but thedesigner has not included it for the device-type.

Secondly, during the evaluation phase (6) there arose a problemregarding the usage of the mental model conflicting with mentalmodels from other applications. It is almost sure that there are differ-ences in how information is being presented on mobile and desktop(e.g. a hamburger icon on mobile, menu already fully displayed ondesktop). It is important to design these differences based on earlierexperiences and familiarity to the user (enabling them to find whatthey want on both devices). Most importantly, there can also bedifferences based upon the architecture of the application (as seenin this study, regarding the invites-section). Normally, these arethe things a usability test reveals (which is a good indication), butthere should be further researched how these conflicts might beprevented during the design phase to optimize multi-device andmulti-platform usage. Since regarding this study it is mostly rele-vant to the architecture of an application (knowing where to findinformation or functionality), this means that there should be aframework for organizing a (FSP) platform.

Thirdly, during the treatment evaluation phase (6), the partici-pants stated that steps can be removed when the architecture of anapplication is known, leading to shortcuts to various functionalityand information. This might lead to new implications (such as theshortcut not being present on another device), and therefore needsto be further looked into.

Lastly, speech is device-independent and therefore a solutiontowards the multi-device usage of platforms. Therefore, furtherresearch should look into this topic.

REFERENCES[1] Aaron W Bangor and James T Miller. 2008. Multimode 11 Interfaces: Two. HCI

Beyond the GUI: Design for Haptic, Speech, Olfactory, and Other NontraditionalInterfaces (2008).

[2] David Benyon, Phil Turner, and Susan Turner. 2005. Designing interactive systems:People, activities, contexts, technologies. Pearson Education.

[3] Ching-Liang Chiang, Chi-Pang Chiang, Chih-Wei Tai, and Chao-Yi Chen. 2013.Mobile device interface with dual windows. (Dec. 3 2013). US Patent 8,600,446.

[4] Tiago Silva Da Silva, Angela Martin, Frank Maurer, and Milene Silveira. 2011.User-centered design and agile methods: a systematic review. In Agile Conference(AGILE), 2011. IEEE, 77–86.

[5] David R Danielson. 2003. Transitional volatility in web navigation. It & Society1, 3 (2003), 131–158.

[6] Waltenegus Dargie, Anja Strunk, Matthias Winkler, Bernd Mrohs, Sunil Thakar,andWilfried Enkelmann. 2007. AModel Based Approach for DevelopingAdaptiveMultimodal Interactive Systems.. In ICSOFT (PL/DPS/KE/MUSE). 73–79.

[7] Rodrigo de Oliveira and Heloísa Vieira da Rocha. 2007. Conceptual Multi-DeviceDesign on the Transition between e-learning and m-learning. In Advanced Learn-ing Technologies, 2007. ICALT 2007. Seventh IEEE International Conference on. IEEE,332–334.

[8] Maxim Dolgobrod. 2013. Developing a user interface for a cross-platform webapplication. (2013).

[9] Lee K Farquhar and Robert Meeds. 2007. Types of fantasy sports users andtheir motivations. Journal of Computer-Mediated Communication 12, 4 (2007),1208–1228.

[10] Gabriela Jurca, Theodore D Hellmann, and Frank Maurer. 2014. Integrating Agileand user-centered design: a systematic mapping and review of evaluation andvalidation studies of Agile-UX. In Agile Conference (AGILE), 2014. IEEE, 24–32.

[11] Amy K Karlson, Shamsi T Iqbal, Brian Meyers, Gonzalo Ramos, Kathy Lee, andJohn C Tang. 2010. Mobile taskflow in context: a screenshot study of smartphoneusage. In Proceedings of the SIGCHI Conference on Human Factors in ComputingSystems. ACM, 2009–2018.

[12] Anders Kofod-Petersen. 2012. How to do a Structured Literature Review incomputer science. Document released as a guide to performing a StructuredLiterature Review at NTNU 19 (2012), 2014.

[13] Michal Levin. 2014. Designing Multi-device Experiences: An Ecosystem Approachto User Experiences Across Devices. " O’Reilly Media, Inc.".

[14] Bonnie MacKay, CarolynWatters, and Jack Duffy. 2004. Web page transformationwhen switching devices. In International Conference on Mobile Human-ComputerInteraction. Springer, 228–239.

[15] Fiona Fui-Hoon Nah, Fan Zhao, and W Zhu. 2003. Factors influencing users’adoption of mobile computing. Managing E-Commerce and Mobile ComputingTechnologies Book (2003), 260–271.

[16] Jakob Nielsen and Raluca Budiu. 2013. Mobile usability. MITP-Verlags GmbH &Co. KG.

[17] Katie O’Leary, Tao Dong, Julia Katherine Haines, Michael Gilbert, Elizabeth FChurchill, and Jeffrey Nichols. 2017. The Moving Context Kit: Designing forContext Shifts in Multi-Device Experiences. In Proceedings of the 2017 Conferenceon Designing Interactive Systems. ACM, 309–320.

[18] Eric Ries. 2009. Minimum viable product: a guide. Startup lessons learned (2009).[19] Yvonne Rogers, Helen Sharp, and Jenny Preece. 2011. Interaction design: beyond

human-computer interaction. John Wiley & Sons.[20] Gerd Szwillus. 2011. Task Models in the Context of User Interface Development.

In Model-Driven Development of Advanced User Interfaces. Springer, 277–302.[21] John Dezendorf Trimmer. 1950. Response of physical systems. (1950).[22] Kaisa Väänänen-Vainio-Mattila, Jarmo Palviainen, Santtu Pakarinen, Else Lager-

stam, and Eeva Kangas. 2011. User perceptions of Wow experiences and designimplications for Cloud services. In Proceedings of the 2011 Conference on DesigningPleasurable Products and Interfaces. ACM, 63.

[23] Kaisa Vaananen-Vainio-Mattila and Minna Waljas. 2010. Evaluating user ex-perience of cross-platform web services with a heuristic evaluation method.International Journal of Arts and Technology 3, 4 (2010), 402–421.

[24] Chuong Cong Vo. 2010. A Task Computing Framework for Taskable Places.(2010).

[25] WeigangWang andManuele Reani. 2017. The rise of mobile computing for GroupDecision Support Systems: A comparative evaluation of mobile and desktop.International Journal of Human-Computer Studies 104 (2017), 16–35.

[26] Roel J Wieringa. 2014. Observational Case Studies. In Design Science Methodologyfor Information Systems and Software Engineering. Springer, 225–245.

[27] Rosa Yáñez Gómez, Daniel Cascado Caballero, and José-Luis Sevillano. 2014.Heuristic evaluation on mobile interfaces: A new checklist. The Scientific WorldJournal 2014 (2014).

11

Appendices

A SLR: PAPER DESCRIPTIONS

Table 6: Selected papers during SLR to define the design parameters in subsection 4.2 and a description why they were selected(regarding their relevancy to RQ1).

Reference Digital library Description[1] Google Scholar Bangor and Miller describe that devices have different in- and outputs, which can

cause different interaction patterns. There is described that speech and tactile in-teraction are device-independent, and could be suitable to be a universal remotecontrol. Bangor and Miller also state that users should be informed when certaintasks can not be performed on a certain device. The findings of this study are relevantsince they describe how frustrations can be prevented and how having a universalinteraction pattern supports an equal UX on multiple devices.

[6] Google Scholar Dargie et al. describe that there are multiple aspects that define how devices are beingused and what their characteristics are. Dargie et al. describes that environmentalaspects influence interactions and the choice for device types being used, which isrelevant to knowing what context might influence the design choices on a multi-device platform.

[8] Google Scholar Dolgobrod states that certain interaction types are not suited for each device. Thisfinding is relevant to the context of designing for a multi-device platform, since thismeans some interaction types are not possible on each device and therefore need tobe considered during the design stages.

[13] Google Scholar Levin proposes multiple strategies or approaches to design a platform for a multi-device usage. Furthermore, it shows that roles of devices or the design approachhas an influence on the UX of a multi-device platform, and therefore can be seen asdesign parameters.

[17] Google Scholar O’Leary et al. describe that shifts in context influence the way how we perceive anduse devices, while on the other hand, this study describes that specific roles (e.g.hub, remote or notifier) can be attached to a certain device, indicating that thereare differences in the tasks that can be performed on both devices. This is relevantsince to design for equality, devices should include the same set of functionality andtherefore should not have differences in their roles.

[20] Google Scholar Szwillus states that tasks can be decomposed into multiple subtasks, which can beperformed on multiple devices. Knowing the sequential steps of performing a task(task decomposition, as seen in the Use Cases), it is therefore relevant since thesetasks should be performed equally on all devices.

[22] Google Scholar Väänänen-Vainio-Mattila et al. state that synchronization and data access is key forthe design of a personalized multi-device service. Väänänen-Vainio-Mattila et al.also states that mobile tasks should fit the user needs on that specific device. Bothfindings show relevancy since they are a big factor in using multiple devices whileaccessing the same service.

[23] Google Scholar Vaananen-Vainio-Mattila and Waljas state that differences between devices shouldbe clear for users, while on the other hand the cross-platform (or in this contextcross-device) usage should be seamless. This implies that Vaananen-Vainio-Mattilaand Waljas states that for designing a multi-device platform, it is important to havethe most important tasks to be ported to all devices to let users complete their tasks.

[24] Google Scholar Vo has some interesting findings regarding the transfer of conceptual models fromone device to another device, indicating that when the transfer is smooth (withoutreadaptations), the UX of a multi-device platform is enhanced. Additionally, havinga universal interaction on all device was seen as beneficial to make the UI coherent.

12

[7] Scopus de Oliveira and da Rocha introduce the concept of Conceptual Multi-Device Design(CMDD), which is relevant to the research question since it shows that one concep-tual model should be carried over all devices to succesfully design a multi-deviceplatform. Therefore, this can be seen as a parameter to design for an equal UX. Addi-tionally, present mental models should not conflict with the new model according tode Oliveira and da Rocha.

[25] ScienceDirect Wang and Reani make a comment on how mobile and desktop applications arepresented and show that there is a difference in presentation regarding the viewpoint(overview or focused) of a device. There was found that having such differences donot influence the consistency of a platform, when the information is on the samearchitectural location.

13

B FSP SITEMAP

Figure 3: Sitemap of the proposed FSP, containing the different interactions between different pages and their components.

14

C FSP PROTOTYPE

Figure 4: The login page of the FSP application on both mobile and desktop.

Figure 5: The home page of the FSP application on both mobile and desktop.

Figure 6: The add poule page of the FSP application on both mobile and desktop.

15

Figure 7: The create poule page of the FSP application on both mobile and desktop.

Figure 8: The invite friends page of the FSP application on both mobile and desktop.

Figure 9: The confirm add poule page of the FSP application on both mobile and desktop.

16

Figure 10: The view poule page of the FSP application on both mobile and desktop.

Figure 11: The edit squad page of the FSP application on both mobile and desktop, indicating equal structure.

Figure 12: The edit squad page of the FSP application on both mobile and desktop, containing selection menus, indicatingequal structure.

17

Figure 13: The leaderboard page of the FSP application on both mobile and desktop.

Figure 14: The view match-day page of the FSP application on both mobile and desktop, indicating equal structure.

Figure 15: The view athlete page of the FSP application on both mobile and desktop, indicating equal structure.

18

Figure 16: The requests page of the FSP application on both mobile and desktop.

19

D USE CASESFor all use cases, logging in and logging out of the application are steps that have been described. However, these steps are not necessary(only once) when the user is performing multiple tasks during one session. Even, the user can remain to be logged in on the platform,meaning that the logging in process only is done once.

D.1 Create poule and Invite friends

Table 7: Use Case: Create poule and invite friends.

Use Case: Create poule and invite friendsPrimary actor UserConditions User has an accountResult User has created a poule and invited friends to this poule

Activity flow

1. The user logs into the application2. The user clicks on add poule3. The user clicks on create poule4. The user fills in the poule details5. The user submits the poule details6. The user clicks on invite friends7. The user fills in the usernames of his friends8. The user fills in submits his friends9. The user clicks on go to overview10. The user clicks on his personal settings11. The user logs out of the application

Alternative flow 6a. The user clicks on go to overview

D.2 Accept invite

Table 8: Use Case: Accept invite.

Use Case: Accept invitePrimary actor UserConditions User has an accountResult User has accepted an invite to a poule

Activity flow

1. The user logs into the application2. The user clicks on add poule3. The user clicks on view requests4. The user selects the request he wants to accept5. The user clicks on go to overview6. The user clicks on his personal settings7. The user logs out of the application

Alternative flow

5a. The user clicks on invite friends6a. The user fills in the usernames of his friends7a. The user fills in submits his friends8a. The user clicks on go to overview

20

D.3 Edit squad

Table 9: Use Case: Edit squad.

Use Case: Edit squadPrimary actor UserConditions User has an accountResult User has edited his squad selection (selected another athlete)

Activity flow

1. The user logs into the application2. The user clicks the poule he wants to manage3. The user clicks edit squad4. The user clicks on the athlete he wants to swap5. The user selects the athlete that he wants on this position6. The user clicks back to the overview7. The user clicks on his personal settings8. The user logs out of the application

Alternative flow 4a. The user clicks on the empty field, where he wants to add an athlete

D.4 View athlete information

Table 10: Use Case: View athlete information.

Use Case: View athlete informationPrimary actor UserConditions User has an accountResult User has viewed a specific athlete’s information

Activity flow

1. The user logs into the application2. The user clicks the poule he wants to view3. The user clicks view squad4. The user clicks on the athlete he wants to view5. The user views the information of the athlete6. The user clicks back to the overview7. The user clicks on his personal settings8. The user logs out of the application

D.5 View match-day result

Table 11: Use Case: View match-day result.

Use Case: View match-day resultPrimary actor UserConditions User has an accountResult User has viewed a result of a match-day

Activity flow

1. The user logs into the application2. The user clicks the poule he wants to view3. The user clicks view match-day results4. The user clicks on the match-day he wants to view5. The user views the results of the match-day6. The user clicks back to the overview7. The user clicks on his personal settings8. The user logs out of the application

21

D.6 View leaderboard

Table 12: Use Case: View leaderboard.

Use Case: View leaderboardPrimary actor UserConditions User has an accountResult User has viewed the leaderboard of a poule

Activity flow

1. The user logs into the application2. The user clicks the poule he wants to view3. The user clicks view leaderboard4. The user views the ranking of the users on the leaderboard5. The user clicks back to the overview6. The user clicks on his personal settings7. The user logs out of the application

22

E USABILITY TEST FORMThe informed consent can be found in Figure 17.

MSc thesis: usability tests Wesley Liefhebber (11820979)

Multi-device experience design: supporting an equal flow of fantasy sport platforms played on different devices

[1. Voor de test] Naam: ________________________ Handtekening: ________________________ [2. Introductie] Beste participant, Voor mijn MSc thesis onderzoek heb ik een prototype gemaakt van een zogeheten Fantasy Sports Platform. Dit is een platform waarin gebruikers een team van sporters kunnen selecteren die op basis van prestaties in de echte wereld punten voor jou kunnen verdienen. Deze platforms worden meestal gespeeld in de vorm van poules met vrienden (bijvoorbeeld een WK of Tour de France poule). Om de complexiteit van het prototype te verminderen zijn competitieve elementen zoals start budgetten (waarvoor je een team van sporters kunt kopen, die allemaal voor een aparte waarde staan) niet meegenomen, maar ligt de focus op het uitvoeren van een aantal simpele taken zoals het vervangen van een sporter, een poule toevoegen en het bekijken van informatie. Het prototype bestaat uit pagina’s waar je doorheen kunt klikken. Dit betekent dat alle informatie van tevoren is ingevuld en je alleen hoeft te klikken. Het prototype omvat een applicatie op mobiel en op een desktop apparaat. Het testen van het prototype gaat volgens het principe ‘Think Aloud’, dit betekent dat jij als participant moet vertellen wat je doet tijdens het uitvoeren van de taken. Nadat je alle taken hebt doorlopen zal ik een aantal vragen stellen met betrekking tot de verschillen tussen beide apparaten. Voor analyse van de test wordt het geluid opgenomen, ga je daarmee akkoord? Heb je daarnaast verder nog vragen voordat het onderzoek gaat beginnen? Alvast bedankt voor het meedoen aan dit onderzoek, Wesley Liefhebber (11802979) Universiteit van Amsterdam

[3. Taken] [3.1 Mobiele prototype]

1. Login op de application 2. Voor het WK organiseer jij een poule met wat vrienden! Maak een WK poule aan en

nodig je vrienden daarna meteen uit! 3. Je hebt een lege plek in je elftal, pas je team aan en selecteer Messi (A, ARG) 4. Bekijk het leaderboard, op welke plek sta je? 5. De eerste resultaten van het WK zijn binnen! Bekijk de resultaten van Groep A in de

groepsfase. 6. Je bent nog steeds niet helemaal zeker over je team. Kies Kroos (M, GER) in plaats

van Fernandinho (M, BRA) in je team. 7. Je hebt een uitnodiging voor de Tour de France poule gehad! Accepteer de

uitnodiging en ga naar het overzicht. 8. Pas je Tour de France team aan, selecteer Tom Dumoulin (SUN). 9. Stel je voor dat het spel al een tijdje bezig is. Bekijk het leaderboard. 10. Chris Froome zit ook in jouw team, bekijk informatie over hem. 11. Log uit via je persoonlijke instellingen op het hoofdmenu.

[3.2 Desktop prototype]

12. Je hebt je bedacht, Alisson (GK, BRA) was toch niet zo’n goede keuze in je WK poule. Log in en kies Lloris (GK, FRA) in plaats van hem.

13. Bekijk informatie over Messi (A, ARG). 14. Er is wat tijd overheen gegaan, bekijk het leaderboard van je WK poule. Doe je het al

beter? 15. Start een nieuwe poule voor Wimbledon (tennistoernooi), nodig ook anderen uit. 16. Wat een pech! Een van jouw wielrenners moet de Tour verlaten omdat hij een

blessure heeft opgelopen. Haal Julien Alaphilippe (QUI) uit je team en selecteer Jakob Fuglsang (AST) in plaats van hem.

17. Bekijk de resultaten van de achtste etappe van de Tour de France. 18. Er zijn een aantal dagen overheen gegaan, bekijk het leaderboard van de Tour de

France. Doe je het al beter? 19. Een van jouw vrienden had het laatst over een nieuwe poule op dit platform! Bekijk je

uitnodigingen en accepteer de uitnodiging. 20. Log uit via je persoonlijke instellingen op het hoofdmenu.

[4. Vragen na de test]

● Kon je meteen van start gaan met het desktop prototype omdat je het platform al eerder gebruikt hebt op mobiel, of voelde deze versie anders aan?

● Waardoor voelde dit prototype hetzelfde of anders aan, denk je? ● Waren alle taken even goed uit te voeren op beide apparaten? ● Zou je het platform gebruiken op beide apparaten, of zou je alleen een van de twee

apparaten gebruiken? Wat beïnvloed jouw keuze hierin? [5. Afsluiting] Nogmaals dank voor meedoen aan dit onderzoek. De gegevens zullen worden gebruikt om te bepalen of een bepaalde benadering met betrekking op het veranderen van apparaat tijdens het gebruik van een platform de gebruiksvriendelijkheid zal verbeteren.

Figure 17: Informed consent of the second usability test.

23

F USABILITY TEST SUMMARIESF.1 Participant 1The first participant indicated that both of the applications showed a lot of similarities, which made the second device (desktop) duringthe test a lot more convenient and easy to pick up. The participant mentioned that this was the case due to both the visual aspects of theprototype as well as the interactive aspects of the prototype. The participant stated that both applications were similar in use, meaning thatfinding information and executing tasks gave a similar feeling to the user due to the second device having the same sort of base as the firstdevice. On both devices, tasks were easy to perform according to the user and were not showing any conflicting concepts making it clearwhere information could be found. The user therefore did not have a preference regarding a certain device, since both applications wereequally easy to use. However, the participant mentioned that the decision to use a certain device over another device would rely on thecontext of use, for example a mobile phone is easier to carry and therefore more suited in specific situations.

F.2 Participant 2The second participant stated that he could use the second device during testing (desktop application) very easy, since it contained a similarinterface and steps to perform as the mobile variant of the FSP platform. The participant added that regarding the interactions on bothdevices, it was very clear what each button does and what he can expect based upon the earlier experiences. During testing on mobile,the participant showed some inconvenience with the task of adding a poule based upon invites, which is located in the ’add poule’-page.Afterwards, due to the same architectural structure the participant stated that it was more easy to relocate this functionality, meaning thathe did not made the same mistake again. Additionally, the participant stated that there were no big differences in executing tasks on bothdevices (regarding architecture), but the difference occurred in sometimes not being able to click fast due to device and screen size on mobile.Lastly, the participant stated that he did not have any preferences regarding which device he wants to use. The choice would mostly bebased upon the contextual surroundings the user is in, according to the participant.

F.3 Participant 3According to the third participant, it was easier to play the platform on the second device, because he had played a different version of it onmobile first. The participant stated that this was the case due to the architecture of the platform, which showed a lot of similarities betweenthe devices. The participant also indicated that some parts of the application might not have been that intuitive, but tasks were executablein a proper way. The interactions that needed to be performed to accomplish a task were labeled as identical according to the participanton both devices, but were different in type of shape (e.g. button size, large enough on mobile). The participant also stated that he did notfeel that the applications were any different to him, both regarding visual and interaction perspectives. Additionally, there was stated thatthe interfaces of both applications may show some similarity in design, but for example buttons on mobile could be larger to make theinteractions more suited to the device. This would not impact the interactive part, according to the participant. The participant preferredthe mobile version of the application, but also indicated that the usability of the desktop version was higher, but that would be due to itbeing the second used device during testing (if it was the other way around, it might be that the interactions with the mobile version weresmoother). Lastly, the participant stated that it might not be wrong to hide information on a mobile platform, as long as this does not harmthe performance of some certain tasks. For example, you want to know information about a cyclist regarding the Tour de France. You’dpossibly be more interested in his time than his birthplace, which means this could be hidden on mobile.

F.4 Participant 4The fourth participant agreed on the opinion that the desktop device was easier to use due to earlier experiences on the mobile version. Thelogic, or architecture, behind the application was the same according to the participant. Additionally, both the application shared the sameconcepts, leading to a certain recognizability. The participant additionally stated that the logic behind the application was the key factor inboth applications sharing the same feeling, instead of some visual overlapping aspects. The participant furthermore added that the tasks thatneeded to be performed shared the same sequential steps and were easy to follow and execute. The preference regarding device type mainlywas founded in the easy of use and the user preference of a device (namely the desktop version), rather than the application differences itself.

F.5 Participant 5The participant felt that the applications were almost the same, but had some differences. On the first application (mobile) the participantnavigated to the add poule for invites (which was by accident). On the desktop application, the participant was not able to find this featureagain. The participant stated that this was the case because she knew from other applications that this functionality should be somewhere onthe home screen with a message icon, whereby she did not knew where to navigate to. She pointed out that she probably forgot where theoption was located on the mobile platform, while she was also struggling with the placement of the functionality in the architecture (whichto her was not logical). The tasks were mostly easy to perform although there were some visual differences on the screens making it more orless easy (for example the desktop was more clear compared to the mobile), but this was not a big issue regarding the performance of thetasks (except the last one where she was not able to find the functionality). The user had a big preference towards the mobile application,since this is her preferred platform overall. Sometimes, according to the participant the interactions were not smooth and there needed to be

24

clicked multiple times to navigate on both devices which felt odd. The participant stated that most of the opinion was based on not beingable to find the envelope icon for invites to a poule, while on other applications this was visualized differently.

F.6 Participant 6The sixth participant stated that the desktop version went faster because it has already been done on the mobile phone. The participant statedthat there are differences in both applications regarding the screens (e.g. size, looks and layout of the interface), but that the architecture isequal on both devices. Regarding the interaction, both applications were found easy to use and switching between the devices felt easy. Thesequential steps to perform some certain tasks were found equal, in a way that the structure of the application was easy to learn and wasclear. For example, each poule page contained the same info on both devices, which after learning once, the participant stated that you canreplicate it afterwards. The participant stated that regarding the desktop device, it could be possible to skip some steps, for example clickingon the back icon when viewing athlete information, while it would be much faster to click the menu again. The participant did not have apreference towards one of the two devices, but from a practical perspective the mobile platform seems more likely to use. The participantwas (again as participant 5) searching for the invites section on both devices, stating that this structure was unclear and unfamiliar. Theparticipant, however, stated that he knew how to fix the problem (not knowing where the invites are located) since he fixed the problemearlier on the mobile phone.

F.7 Participant 7Participant seven stated that the desktop version of the application was clear form the beginning what the structure of the desktop versionwas since it has been played before on the mobile device. According to the participant, some information might be located on a differentplace on the screen, but the participant stated that he expected that the functionality on the mobile phone was also available on the desktopon the same location. The participant had a preference towards the desktop application, but stated that the architecture of the applicationwas the same, but on a personal space the participant had a more clear overview of the application on the desktop. Regarding the interactions,the participant stated that there was a lot of recognizable elements that where shared across both devices, meaning that there was a directaffection between the two. The participant additionally stated that it was very important that all the information was on the same place (inthe architecture of the application), since this meant all tasks were easy to perform (since you know where to find the information). On thedesktop, additional elements were added which were good according to the participant. As the participant additionally stated, these elementsshould be hidden on mobile, since this would lead to more scrolling and therefore making the task harder to perform. The participant had apreference towards the desktop device, which was fed by the fact that the participant is familiar to this device and uses it often.

F.8 Participant 8The eight participant stated that the desktop was easier to use after using the mobile platform, especially because the structure was clear andthe overview of the poule page was well-presented. The participant stated that therefore the desktop application was more clear comparedto the mobile application, but this did not prohibit or made the tasks harder to perform. The steps to perform a certain task were found tobe equal. This was the case due to information being location under the same names (such as ’view leaderboard’ or ’match-day results’),leading to the same navigation on both devices. The participant also stated that it was unclear where the invite section was located, but theparticipant pointed out that she knew how to find the functionality after making the same error. Also, some of the steps could have mademore logical, for example accepting a poule-invite did not really include accepting, since there was no way to decline the invite. Regardingthe invites-problem, the participant stated that she was familiar with a certain inbox-icon on the home screen leading to the invites section,which was under a different location on the application. The participant also stated that it could be possible to show some elements onthe desktop version (for example edit profile-icon top left) since it is possible to skip some certain steps when the architecture is clear andknown. The participant had a preference towards the desktop application since there were some fun elements such as the heads at the ’editsquad’-section, but these did not affect the performance of the tasks.

F.9 Participant 9The ninth participant stated that the second used device (desktop) was easy to use based on earlier experiences on the mobile application. Thestructure and visual information was very familiar to the participant which helped him during the performance of his tasks. The participantstated that the second part of the tasks (desktop) were more open for interpretation than the first part of the tasks (mobile), indicating that itwas very common that you have practised the tasks earlier on mobile and that he was able to apply the knowledge to the desktop prototype.The tasks were easy to execute on both applications according to the participant. The participant stated that the desktop application waseasier to use, but mainly thanks to the earlier experiences on the mobile application. However, the mobile application was better due to theplatform not being very complex and therefore not needed to open a laptop and take more time to accomplish the tasks. Additionally, theparticipant stated that sometimes to make the platform more intuitive, some steps can be removed, such as clicking on the back icon whileexiting view athlete information.

25

F.10 Participant 10Participant ten described the switch to desktop as easy since it was known where to navigate to. The structure of the application was clear,indicating that for both devices this made it easy to switch device. Both devices felt the same in terms of interaction, including tasks. Thetasks contained the same steps, whereby there was no feeling that one of the two applications was different. The participant had a preferencetowards the desktop application because of the visual icons (such as at the edit squad section). The participant pointed out that the visualinformation that was available on the desktop supported the tasks, for example when an athlete is injured since it made it more clear whowas injured, but this is not necessary to complete the tasks properly.

F.11 Participant 11The eleventh participant again indicated that the second used device showed a feeling of recognition, for example the structure of the menu,while the first device during testing felt like learning the application. According to the participant, especially the invites-section was a loteasier to find the second time on the desktop, since he knew where to navigate to from the mobile device. However, the location of theinvites was a bit unclear and not corresponding with what the participant expected to see. The participant also pointed out that the sameinteraction styles such as pull-down menus were consistent and therefore easy to follow. The participant had a preference towards the mobiledevice since it is easier to pick up than a desktop, but there was no preference based upon the differences between the two applications.According to the participant, multiple things could be made more intuitive such as combining the view and edit squad section, which couldconceptually be merged together.

26