La vida del lugar

By designing the experience through technology, the WHAT and the HOW come into focus. Throughout this step, the Experience Story representing the experience and its intended psycho- logical need can be used to maintain focus. The Experience Story can be broken down into single interaction steps, which are then sketched out in a storyboard so as to define the interaction with the system in detail.

Using Storyboard

general A storyboard illustrates theWHATin detail, namely through single interaction steps and the appro- priate functions to go with each step. It is not technology that is shown in detail (e.g., interfaces), but functionality.

As the Experience Story’s focus is on the need(s) to be addressed and fulfilled in the experience, the focus of the storyboard is on the use of the system while the experience is created. Single frames represent the single interaction steps and serve as additional texts (see Section 2.3.3 for more detail), describing the interaction in the experience in detail, as shown in Figure 5.2.

application In the design case of keepClose (see Section 4.1), a storyboard was created. To begin with, the single interaction steps of the experience were extracted from the Experience Story, e.g., for the commute back home from work, the steps of the main character’s interaction with thekeepClose

1. When leaving work the mother, Maggy finds a message awaiting her. She recognises something is there for her on the device in the car.

Even before its actual use, through a state change, the system displays that a message has arrived through a state change.

2. Maggy receives a message from home.

The message sent from the loved ones at home is displayed by the system and recognised by the commuter.

3. Maggy starts to drive home. The system updates her position status.

4. The father, Steve and the children, Emma and Ben, look at the device at home and find that their Maggy has started her drive.

The start of the commute is indicated to the loved ones to inform them that the commuter is on her way.

5. Maggy watches her progress on the device as she comes closer and closer to home.

Displaying the progress on the one hand provides orientation, and on the other hand informs the commuter about the information the home device provides to the loved ones.

6. Emma and Ben watch their Mom’s current progress. The commuter’s vague progress displayed to the loved ones at home. 7. Maggy sees her distance to the home area on the device.

The system divides the commuting route in two areas, and the approximation to the home area is displayed for the commuter as well as for the family at home.

8. Emma and Ben see on the device that Maggy is near.

The status change of the commuter entering the home area is also displayed at home. 9. Maggy is happy to be in the home area, where she can communicate with

her children before arriving(see Figure 5.2, Frame 9).

After entering the home area a communication channel is established between the devices. 10. The children chat with their Mom until the communication stops while

the father is cooking(see Figure 5.2, Frame 10).

The system closes the communication channel shortly before the commuter arrives.

11. Emma and Ben recognise on the device that their Maggy is coming (see Fig- ure 5.2, Frame 11).

The system’s interface shows that the commuter is arriving.

12. Emma and Ben are welcoming their Mom(see Figure 5.2, Frame 12).

The system fades into the background and the physical contact among the family members comes into focus.

Figure 5.2: Maggy is coming home: frames from the storyboard of thekeepClose experi- ence (illustrations from the Folkwang University of Art, Marc Hassenzahl, created by Frank Josten).

This example shows how the storyboard helps to structure the functions over time according to the single interaction steps, thereby clarifying the experience to be designed in detail.

summary To summarise, the storyboard defines the WHAT of the experience. Besides the experience as lived by the characters of the Experience Story, the storyboard also shows the functions of the technical representation of the experience, which is to be designed based upon its representation in the Experience Story. For creating storyboards the interaction steps are extracted from the Experience Story. This includes the interaction steps of addressing as well as fulfilling the intended psychological need(s). A graphical representation is created for each interaction step to offer possibilities of functions for the technology-related experience to be designed. To avoid obscurities each graphical representation also contains a description. The graphical representations should not determine specific technical solutions, such as concrete interfaces, rather they should serve as starting points for different possible implementations.

Once theWHY is defined through the Experience Story and the WHAT through the storyboard, the next step is to define theHOWin detail. This leads to the creation of mock-ups.

Figure 5.3: Mock-up from the design case ofCliqueTrip: a) controller and display of the distance indicator between the cars; b) controller of the audio channel with acoustic feedback; c) controller of the display of the friends in the other car; d) controller and indicator of the direction of the other car; e) controller and indicator of the navigation towards the front car.

Using Mock-ups

general Mock-ups allow the elaboration of technical solutions in detail, without needing to implement a

fully functional prototype. The mock-up brings the story to life in specific aspects. In comparison to the fully functional experimental prototype, the mock-up is focused only on parts of the experience, so as to set up elements of the interaction in detail and then refine them. Mock-ups are a first realisation of the design solutions found in the first step of the analysis, hence they are based on the elements that were the inputs for the Experience Story.

application In applying mock-ups, analyses were conducted to test possible technological interactions towards

the fulfillment of the intended psychological need in an experience. An example of a mock-up is shown with the design caseCliqueTrip(see Section 3.1).

In this case, the experience was about the fulfilling of the need of relatedness. On the one hand, the information about the localisation of the other car in the motorcade should foster the feeling of being one big group despite being separated in different cars. On the other hand, a limited communication channel should foster the feeling of closeness within the group. The purpose of the mock-up ofCliqueTrip is to display different possibilities to devise the functions defined in the storyboard, which were based on the motivation from the Experience Story. The aim is

not to display the interaction steps (as seen in the storyboard), but to make specific functions experienceable. Through this, insights are gained and an optimised prototype can be designed later on. The mock-up forCliqueTrip was implemented as a web interface using mainly Adobe Flash. This enabled fast and easy implementation and testing of different functions. As seen in Figure 5.3, different interfaces show how close the different cars of the motorcade need to be in order to be able to communicate with each other. With the radio button on the bottom of the figure, different interfaces can be selected to be displayed in the top right. With the radio button b) different possibilities for the limited communication channel are tested, e.g., by varying the volume depending on the distance. Button c) shows how the friends in the other car are displayed in the system. In this screen-shot, pictures of the friends are displayed in a symbolic car. Button d) helps withorientation, e.g., an arrow in the top of the screen points towards the other car, as by the needle of a compass. To make the mock-up dynamic the two sliders e) represented by little cars, can be used to reduce or increase the distance between the cars, which is displayed in the middle of the screen. After the mock-up is built, it is tested and discussed in the design team, where everyone interacts with it. Through the mock-up, different versions of the functions are analysed so that the mock-up can be refined. Subsequently, adjustments can be introduced to the system to better match the Experience Story. One example of an adjustment in this design case is the indicator for the distance, as in Figure 5.3 a) on the top right side, which was replaced so as to better match the Experience Story, by using a less technical-appearing solution (described in Section 3.1).

summary In summary, to apply mock-ups for the designing of experiences, the first step is to analyse the elements of the experience to be elaborated through a testing. This interaction is implemented in a mock-up with the focus on specific functions of the later implemented prototype. The mock-up makes different possibilities for the technical solution experiencable. If the proposed technical solution does not match well with the Experience Story, new solutions have to be elaborated for the prototype.

Using Prototyping to Deliver Experience In Situ

general To be able to analyse a designed experience in situ, an experimental prototype is devised. The prototype should enable the participants to live through the designed experience.

All the representations of the experience from the design come together in the prototype, that is, from the Experience Story to the storyboard and the mock-up. To be able to analyse the outcoming experience, the prototype has to contain all the functions necessary to live the experience, espe- cially those that are directly connected to the fulfilling of the psychological needs, as results from the Experience Story. To apply prototyping in the designing of experiences in the automotive in- dustry, the environment, namely the car, also needs to be considered. The experimental prototype should work in a real environment, i.e., on the road. Only those aspects that are not connected to the fulfilment of the intended psychological need must not necessarily work in situ.

application In the design caseExlorationRide(see Section 3.2), the settings of the destination and theme were implemented in the prototype of the system and could not be changed by the participants. Also, the invitation to the trip was not sent by the system. On the contrary, every function linked to the need fulfillment of the experience, as described in the Experience Story (i.e., fostering exploration and relatedness as well as enabling mementos), had to function throughout the designed experience.

Figure 5.4:Prototype ofExlorationRideduring the in-situ user studies.

In Figure 5.4, selected aspects from the ExlorationRide experience are depicted in their imple- mentation in the experimental prototype. In Panel a) of Figure 5.4, the group of friends start the journey together when everyone is sitting in the car, which illustrates relatedness and group belong- ing. Panel b) of Figure 5.4 displays how the system provides additional intermediate destinations, and Panel c) shows the vague guiding in order to foster the joy of exploration. Finally, as shown in Panel d), the system provides a memento at the end of the trip.

Before the experimental prototype is tested in situ, it can additionally be improved through agile refinement. In the example ofExlorationRide, the guiding was improved through an agile testing before the user study (see Section 3.2). Thanks to the experimental prototype, the experience can be analysed in situ to reveal which elements of the experience are working and which ones are not, in order to enhance relatedness and stimulation.

summary In summary, to apply experimental prototyping to Experience Design, all elements of the experi-

ence somehow connected to the need fulfilment have to be implemented and should imperatively work in situ. A function does not have to be fully integrated in the environment unless it is indis- pensable to the experience.

If parts of the experience are not implementable, e.g., because of technical reasons, the participants should, however, have the feeling that they interact with the system, and not with the observator. To this end, Wizard-of-Oz techniques can be used, that is, the user interacts with a system that seems to be autonomic but that really is operated by a human in the background (e.g. [Bux07]).