LemonSays-Service book

1

2

//OVERVIEW MAP //Introduction //CHAPTER 1 - The Surface

05 Service Concept 07Lemonsays and iMeasure 08 Value Constellation 10 Service Architecture 12 Touchpoints

//CHAPTER 2 - User Focus 18 User Journey 20Touchpoint map 22 Blueprint 29 Use cases 33 Service system overview 36 Entity relationship digrams 40 System map 43 Stakeholders map

//CHAPTER 3 - Supermarket Focus

45 User journey 46 Data flow and distribution 47 Stakeholder map

//CHAPTER 4 - Service Environment 49 Business Canvas 50 Comparison of Stakeholder maps 54 Motivation Matrix

//CHAPTER 5 - Conclusion

//REFERENCES

57 Future improvement 58 Service Relevance 59 Conclusions 3

Introduction

In this book the designed service is presented in detail after shaping the idea in the process book. Furthermore the connection to the prevailing food waste problem is made. The service “Lemonsays” is created on the one hand, for users to easily keep track of their food supply at home and on the other hand, for supermarkets to improve their planning with data about future demands. Since the most food is wasted in domestic use, like stated in the process book, the focus of the service lays on the consumers. They can use “Lemonsays” to plan better and by this buy less to prevent waste.

To start avoiding waste in this early passage is important, since the most impact can be made here. On the other side supermarkets are a usergroup of the service. They can purchase the gathered data to plan better for avoiding food waste on another level. They have already data they base their supply calculations on. However much is still wasted here. With the additional data from “Lemonsays” about future demands, this process can be improved.

The service is designed around an application to be used on different devices and a smart tray. This smart tray collects informations about the food supply of the users which is, in return, directly provided to them through the application. Additionally this data is gathered and anonymised for improving the supermarkets’ planning process.

In the following, the food management service as well as the application and the tray are described in more detail. The service interactions of the two different users are separately explained in the following chapters, first concentrating on the private person and then adding insights about the supermarkets. The distributed service behind the product is being outlined as well as different use case scenarios. The book ends with a business canvas, a summary of the stakeholders and a conclusion about the service and the design process.

4

Introduction

Figure 1: Chapter Overview

This overview map detail the service scope and stakeholders. It describes how the service is gathering data from the user interactions and selling it to the supermarkets for providing a better input for supplies distribution.

The diverse user interactions are presented here in different personas, having Ben as central user. Ben relates to his mother through the use of the mobile application service, synchronizing her trays in his phone. Ben lives with his girlfriend Anna, so they share together the same trays through their mobile application, having the same rights to edit, create and check products status. Ben and Anna are also connected to their Friends. They can interact only through the mobile application, because they don’t need to share any information from the trays, they just share the information about their food events, such as birthday parties or BBQs.

5

THE SERVICE Chapter one gives a deeper insight in the service and the prototype of the designed product. The smart tray and the user interface are shown and explained in detail.

6

Service Concept

Service Concept

The service “Lemonsays” aims to be a supportive tool for people’s daily, life helping with food management, shopping and storing. It consists of two parts, a physical component represented by a sensitive tray and a digital part represented in a mobile application.

“Lemonsays” will provide users the possibility to have a remote access to its storing spaces, fridge or pantry. It will be necessary just to have the sensitive tray for each one of the products, label them in the application and start receiving notifications for the product status. Having the control of the different products, liquid or solid, the user will be able to generate a shopping list and share it with other members of the family or friends.

This sharing facility helps the users to decide who should be responsible to do the shopping, and avoid to buy more products than needed or forgetting something relevant. In this way, the service will provide a better control of what it is being bought and how much money is being invested in the process.

An additional component of “Lemonsays” is directed to another user, the supermarkets.

The service provider gathers the information of the users about their shopping behaviour, anonymises the data and delivers it to the supermarkets. Thus the grocery stores can improve their supplies planning and contribute on a different level to avoiding food waste.

They need to provide, as basis stocking, what the users of the service are about to purchase and add only some more for the non users of the service.

Why is it Smart Cities?

This proposal is related to the smart cities concept assisting as a preventive tool to help avoiding food waste around the city, serving as a measure of control for what people waste, buy and eat. It also stimulates the connection between different people for taking care of the same products and may end in sharing the different food storage spaces.

Additionally, it creates another level of connection between people and supermarkets.

The service provider will sell information (Big Data) to the supermarkets about the kind of products the consumers are about to buy. With this the service contributes to a better understanding of the markets’ behaviour in the cities, preventing overproduction and waste in the shops.

7

8

The application and the service behind the product is called “Lemonsays”. This conveys that through the possibilities of distributed systems the food can, in an abstracted way, update the user about its status.

Figure 2: Name of the application and the service

The tray is used to gather the data of the home supply and it is called “iMeasure” (see Figure 3). “iMeasure” and “Lemonsays” both emphasize the new communication aspect of the service and express the usability and the area of use.

Figure3: 3D model of tray

The “iMeasure” prototype is connected to a processing unit via an Arduino Pressure Sensor and Thingspeak.com (2015). As shown in Figure 5 Thingspeak is used to visualise the data from the pressure sensor on different devices and store it in a cloud.

For the use with the service, the tray itself will be able to process the input data and send it wireless to the service’s cloud.

Figure4: Name of the tray

Figure 5: Smart Tray with Thingspeak and data visualisation on a phone

9

Value Constellation Value Experience Constellation

Figure 6: Value Experience Constellation

Figure 6 depicts the values that the user will encounter during the use of the service. The highlighted values are the ones that carry the core of the service, making it favorable and important for the user.

The service provider will ensure the data security of its users. He will provide a wireless device (tray) that can work independently once it is configurated. The service is build to be used as a planning tool for the most common used products to keep them always under control, preventing running out of them or buying more than necessary. The service will connect families and friends as they share trays and shopping lists.

10

Value Offer Constellation

Figure 7: Value Offer Constellation

The value constellation in Figure 7 contains the particular elements of the service that can give value to the user while using “Lemonsays”, such us the possibilities to share, control and cooperate with other users. Some features facilitate the use of the service, such as the “decision to buy” process, the different notifications between users and the notifications for food items on low supply.

11

Service Architecture

12

Figure 8: Service Architecture

This service architecture aims to explain the way the different touchpoints and backstage platforms interact with the user. It shows the initial function of the service, determined by the specific actions the user must execute with it. Additionally, it shows the answers and reactions of the system to the actions performed by the user. Either the system has to process information or provide data in selected interfaces.

13

In this chapter the physical prototype is presented and the interfaces of the application explained in more detail. The interaction possibilities for the users are outlined in addition to the way the tray works and gathers information from the user’s’ products.

14

Final Tray Design

Figure 9: Acrylic Prototype of the smart tray

The physical part of the service consists of a smart tray named “iMeasure”. Smart because it contains a pressure sensor as well as a processing unit to calculate the measured data and send it to the cloud for being available for the different users.

The tray depicted in Figure 9 shows a prototype for keeping track of the milk supply.

The detailed drawing is shown in Figure 10. There the dimensions are added for a better understanding of the sizes. The front view shows the logo “iMeasure” and the sides are 40mm high. The width of the tray is 85mm each side. On the bottom the pressure sensor is visible. Further trays need to be available for a complete service coverage. The tray should be available for the users in supermarkets and online stores.

The materials used for the tray should be plastics of commercial use in the food industry. The iMeasure tray works with own intelligence. In Chapter 2 the details of its functionalities are explained in more depth.

Figure 10: Technical drawing of the sensor tray with the pressure sensor

15

Mobile Application Interface

Figure 11: Status of product, 25% remaining content

Status of 25% remaining content (Figure 11) in the product. Can be seen when selecting the item or after receiving a notification when this special product status is reached.

Figure 12: Notification for critical product

The Notification of an ending product (see Figure 12), will be shown on the start/idle screen of the phone.

Can be either ignored or the status of the product can be viewed for more details as presented in Figure 11. Furthermore the product is automatically added to the shopping list.

Figure 13: Editable shopping list with option for selecting shopping decision

The Figure 13 presents the editable shopping list that will gather automatically the products that the system knows are about to finish. The user can change the amounts, delete or add even products that are not part of the tray system When one of the users that is sharing the list cannot do the shopping, he can make the decision through the app and ask other users. They will receive a notification saying that he should be the one doing the shopping.

16

Figure 14: Notification of shopping intentions

Figure 14 shows the notification sent in case the other user took over the shopping duty.

In case all users that share the same shopping list cancel it, the system will notify the users that no one have decided to do it.

Figure 15: Adding trays

The main interface shows all products the users wants to keep track of. In case more kitchens are used it can be switched between the different views. This is also the case for adding new trays into the user’s data base. He can add the corresponding tray according to the fridge he has synchronized in his phone.

Figure 16: Editable shopping list for better overview while shopping and update of the items

When the shopping list is saved, the user will have access to this list visualization that will be usable while shopping. The bought items could be ticked (see Figure 16) and missing products will be automatically saved in a new shopping list.

17

USER FOCUS

18

In the following chapters, the focus lies on users of “Lemonsays�. The different interactions, databases and user journeys are visualized and explained to give an overview on how the users are interacting with the service.

19

20

User Journey

Figure 17: User Journey of private person as a user

The customer journey explains the different touchpoints that are related to the users during the usage of the service. In this graph (Figure 17) it is possible to see the different user needs related to the facilities that the service is providing through its touchpoints. This first approach also permits to understand the backend that the service provider must have available for responding to the user providing the correct functioning of the service.

21

Sensitive Tray

Physical Store

Mobile Application

Web page Service

22 Figure 18: Touchpoint Map

The objective is to present all the possible interactions with the service between the different users and identify when these different interactions involve the touchpoints of the service. This graphic will be the base for the construction of the service blueprint.

This touchpoint map presents the user’s touchpoint interactions during the service. The physical touchpoints taken into account are the mobile application and the sensitive tray. The graph depicts most of the possible scenarios of use, showing different kinds of users, such as Ben (as the principal user), Anna, their friends and the Stores.

This tool permits the understanding of the user’s interaction process with “Lemonsays”. On the left side of the chart in Figure 18 the division between the touchpoints of the service (yellow) and the user types (orange) is shown. In the upper section from left to right there are the principal activities that the user does with the service, interacting with each one of the touchpoints and other users according to the cases of use and interaction with it.

How to read it?

23

Touchpoint map

24 Figure 19: Blueprint part 1: Before and first part of During

It is also visible in the graph how the service’s distributed system creates databases for each user, in this case for the store and Ben. This database will be differentiated for the type of service each one of the users is paying for, in case of the Stores the Big Data stored by the service provider, and in case of the users a service for a better food management.

It is important to remember that the tray will be related to the user’s database through a process of synchronization.

By the use of a code the tray can be identified in the distributed system. During this synchronization process the user will be able to label each tray according to what it contains.

This first part of the Service Blueprint (see Figure 19, part 1 ) depicts the way the users interact with the physical product of the service, the sensitive tray, which will be found in the different supermarket chains, or in online stores.

The users will be able to download the mobile application for free and use it for sharing information or managing their products in the trays. This shared information is also available for signed in and approved supermarket-users.

Before

25

Blue Print

26 Figure 19: Blueprint part 2: second part of During and After

The user will make the corresponding shopping in the store of preference and will re-stock the items in the trays, possibly re-label some trays and organize them in the fridge and pantry. This organizing process will make the system update the status of the products for future user consultations. All this steps are displayed in figure 19.

After

After the shopping list is ready, and if the list is shared with someone else, for instance between a couple, the users should take the decision of who will make the shopping. At the same time the other one is informed for avoiding a misunderstanding. The application will provide the users with the options for deciding whether or not they are able to do the shopping and inform the other owner of the list about each user’s decision.

If a product is finished, the system will notify the user through the application and will add this item to the shopping list. The user will be able to check which product it is and edit the final shopping list, add new items, delete or add amounts from the same product.

The during service moment starts with the use of the tray, placing it in the different spaces required, fridge or pantry, and the items organization inside each one of them (see Figure 19, part 2). Once the items are in the tray the system will start gathering data from the products and will keep the mobile application updated. In this way whenever the user decides to access his fridge he will find the status of his products inside the trays.

During

27

Blueprint

28 Figure 20:Part 1: Ben and Anna service interaction

Use cases

29 Figure 20:Part 2: Ben and Anna service interaction

In this case, both Ben and Anna share a common shopping list, both receive notification when a product is about to finish, and they also can decide who is going to do shopping.

Ben and Ana use case (figure 20).

Ben and his mother use case (figure 21).

Ben and his mother use case (figure 22).

This use cases depict the interaction of Ben and other actors with the service and their relationships. For this purpose, it was created several blueprints:

30 Figure 21: PArt 1, Ben and mother service interaction

31

Figure 21: PArt 2, Ben and mother service interaction

The figure 21 outlines the fact that Ben can control his mother products because he created another account that was synchronized with his mother’s trays. This way, he also will be notified about the current status of his mother products.

User Case

32 tFigure 22: Ben and friends service interaction

33

Ben and friends use case illustrates more the sharing the shopping list part of the service, the tray isn’t present. Ben creates an event and is inviting his friends to participate to create the shopping list and select the items they will buy.

User Case

34

Service System Overview

Figure 23: Service System Overview

Data processor or the cloud for storing, analysing and data transmission, a private cloud model will be used. The decision of having this type of cloud platform was taken because of the higher security level for the customer’s provided data, integrity and redundancy.

Security gateway is a separate device that allows private network users to connect to external networks, while protecting internal system from being compromised.

Thus, security gateway creates a secured tunnel VPN (Virtual private network has a slightly different purpose) between cloud and tray and ensures privacy and integrity of the data transmitted to the cloud.

Data provider was called the sensitive tray which is responsible for generating data and processing it. Afterwards the same device is sending it to the security gateway.

The sensitive tray consist of a pressure sensor, a WI-FI data module and a processor for working with the gathered data, before sending further.

Data provider configuration and visualization are all the devices through which a user can connect at home to visualize data or produce some data configuration.

Home LAN - local area network which interconnects many devices for a single user and ensures data communication in this system and its privacy.

The system consist of several components:

The graphic in Figure 23 represents the service’s distributed system of a single user: how data is generated, transported and stored in a cloud, and how it is being accessed.

35

The same principle applies for the devices from “Internet” cloud and home LAN as long as these devices have an internet connection. The channel between Home LAN and Storage cloud is also bidirectional. From home the products status input is sent to the cloud, and the cloud is sending back a shopping list and a notification as an output. So, this way the home LAN and Storage cloud are both clients and server because they both exchange request - responses, but in different situations.

The communication inside the system is mostly bidirectional. In the “Home LAN” the data flow from the tray is unidirectional, as the tray is the one who produce it and sends it further. The connection between devices and security gateway is bidirectional since it’s receiving messages from the cloud and is sending back it to the cloud the updates of the shopping list.

Internet shows another option of accessing their data. The users can also access his/her information by connecting to the cloud from outside of LAN (directly from the internet).

The data processor interface is structured in several layers: · The software layer, acts as data processor. · Data storage, ensures data storage in a secured (for privacy) and redundant (integrity) fashion. · Virtual and physical machines are used as hosts for both the software and data storage layers.

Service System Overview

36 Figure 24: Data Flow and Distribution

Data Exchange Between Different System Users

Family friends have only limited access to some of the items in the fridge. View access has to be explicitly granted by either Ben or Ana (since they have Power User privileges)

In Figure 24 it is illustrated how the system connects more people and the type of relationships between them. It also depicts the differences of the feature based on the user type. I.E - Ben and Ana are power users. They have the full access to the system as well as the authority for modifying it. Ben’s mother doesn’t use the system directly, but her fridge is providing data so that Ben can manage her shopping list for her.

37

Figure 25: General Database Overview

Entity relationship diagrams

38

The “Tray” is being used by only one fridge since it can be only in one place at a time. One fridge can contain more than one trays.

The “fridge” and “list” develops a relationship zero or one, because one fridge can only have zero shopping list in case of friends and Ben case; one shopping list in the rest of the cases.

The relationship between “user” and the “list” is one or more instances because a user can have one or more lists (Ben and Ana list and Ben and mother and friends list).

A User can have zero, one or more fridges (for example: one fridge - Ben and Ana fridge, zero fridge - Ben and friends case) and each “fridge” has one or more users (Ben and Ana).

Figure 25 gives an overview of the service’s database. It consists of four different entities that are interconnected and create different types of relationships.

All the entities have a primary key that are most commonly used to uniquely identify a single entity instance. (Bentley, Whitten, 2007)

· Tray - is the entity that includes the trays information. The value of Tray uniquely identifies one and only one Tray ID.

· List - is the entity that contain shopping list items. The value of List uniquely identifies one and only one List ID.

· Fridge - is the entity that contains all the user’s trays. The value of Fridge uniquely identifies one and only one Fridge ID.

· User - is the entity that includes all the actors involved in the service data. The value of User uniquely identifies one and only one User ID.

In the following the database relationship for the service is explained. First an overview of the general structure is depicted in Figure 25. Subsequent different examples for specific situations show the different parts of the database.

In Figure 30 a complete view of the example-database is shown.

The following relationship diagram examples contain four big entities:

Figure 26: Database Example for Users Ben and Anna

Figure 26 shows one example database with two different users, user 1 is Ben and user 2 Anna. They share a fridge and a list attached to it. For this the connections between both users and fridge and list are given. Their fridge has five trays connected to it.

39

Figure 27 basically shows the same situation with two users connected to one fridge and it’s list. This view is shown as it is needed for the complete overview database shown in Figure 30.

Figure 27: Database example for Users Ben and his mother

Figure 28: Database Example for an Event List

In Figure 28 the Event List situation is represented. Here four different users entities are connected to one list and no fridge. This due to the other users are just authorized by the system to be part of the “Event List”.

40 Figure 29 displays the view of one user’s perspective, in this case Ben. He is connected to two different fridges and the according lists, as well as to the additional Event List.

Figure29: Database Example of Ben’s View of the service

41

Figure 30: Database Example complete overview

The graphic in Figure 30 depicts the complete example-database that was described in the above figures separately. It is obvious that there are many connections, increasing with every new user and their fridges and lists.

System Map - Ben

Figure 31: System Map, Ben’s interactions

In the first system map in Figure 31 a broad overview of the steps that are taken by Ben to reach the service through an application or a web page are represented. For each user the system will create a new profile and store its activities.

42

System Map - Ben's Mother

Figure 32: System Map, Ben’s Mother’s interactions

As mentioned before, Ben can control his mother’s fridge. The map in Figure 32 illustrates Ben’s activities for starting controlling her fridge. Because Ben registered himself in the system before, he only adds another account. For this new account a separate shopping list will be produced and the data from it will go not in Ben’s database, but his mother’s, since it is for a different user.

43

System Map - Ben's Friends

Figure33: System Map, interactions between Ben and friends

For Ben and his friends circle, the service is different. They use the application not for measuring the products they have home, but more as a connection tool. In this case, Ben is creating a new common event for a party. He generates a new editable shopping list, invites friends to add and select items that they can buy. Here another database is used because each friend has an account for using the service and their particular shopping lists are saved there.

44

Stakeholders map

Figure 34: Stakeholders Map, user in the center (Stickdorn & Schneider, 2011)

This stakeholder map in Figure 34 depicts the influences and interaction possibilities from a User centered perspective.

The different layers show the interaction levels between the User and the different stakeholders. The outer green circle contains the actors that relate indirectly with the User, in this case the Service Provider, the Friends and the Family. They are connected to the User through the use of the Service. The Service is the channel of communication and data sharing between this three actors and the User. Family and Friends are special user types: Friends use the service on special occasions by just sharing a shopping list and Family users can share their shopping list and the information from the trays between them.

In the middle yellow circle the stakeholders are the Store and the Service itself, the Store where the user purchases the trays. The Service itself is in continuous contact with the User, either via the tray or receiving information from the devices, at the same time the Service is connecting the User with the Family and Friends.

45

SUPERMARKET FOCUS

46

User Journey

Figure 35: User Journey from the supermarket’s perspective (Service Design Toolkit, 2014)

The current user journey (Figure 35) shows the service that will be provided to the supermarkets. The Service Provider will give the Stores non-private data from the users, such as products that they are about to buy, frequency, amounts and regions where this market behaviour is seen.

The supermarkets will pay to the Service Provider for this Big Data, as long as it is needed for a market analysis.

There is no “during service�, how it is presented in the chart, the interaction with the Service Provider is limited to the sale and delivery of the Big Data. The during moment of the service corresponds to the process of data gathering.

The after service moment is the gathering the data from the Service Provider, and permanent access to the old gathered information until a new update is registered by the system.

47

Data flow and distribution

Figure 36: Data Flow and Distribution, focus on the supermarket

The graphic in Figure 36 represents the data distribution in the system. The information from the sensitive tray (data provider) will be send to the service provider cloud. The data will be saved, processed, then grouped in different categories for later (offline) processing. The data will be updated in the cloud every time a person will use the products and place them back on the tray. A part of data will be returned back to the users as a notification and editable shopping list, and sent back to the cloud as updates of their shopping list. The user will receive a notification on the mobile device when the products reports a quantity that is less than 25%. The user can always check the status of the product that she/he has on the tray using his phone, a computer from home or other places with internet connection.

An independent and completely parallel software layer will aggregate data from all the users in order to build statistics and make projections at macro level. The output of this parallel process will then be sold to goods providers (like local markets and shops) which in turn can make better provisioning of their shelves (and warehouses). This will be a great value addition for them as this will reduce the waste, energy consumption and logistics costs. In turn, this should also have an impact on the price of the reported goods.

48

Stakeholders Map

Figure 37: Stakeholder Map with the supermarket in the center (Stickdorn & Schneider, 2011)

In the stakeholder map in Figure 37 the other user of the service, the Store, is in the center. In this map, interaction possibilities are connecting the Store as user to the User and the Service Provider. The User and the Service Provider are in the first yellow circle, since the relationships between the two actors with the Store is direct in both cases. The interaction between the Store as user and the Service Provider is frequent, since the gathered and analyzed data is provided to the Stores on a regular basis. The Service plays a mediator role between the Service Provider and the User, and is placed in the outer green circle due to no direct relationship with the Store.

49

SERVICE ENVIRONMENT

50

Business Canvas

Figure 38: Business Model Canvas

The business model canvas in Figure 38 depicts the value generation and the business model behind the product of the smart tray. Key partners, activities and resources are listed as well as customer relationships and segments.

The cost structure and the revenue streams describe how the service is generating value for the provider. Costs are generated at the beginning of the product’s and service’s lifecycle. Additional costs have to be calculated for maintenance and the storage of the big data. The tray and most of all the sale of the big data contribute to the revenue streams.

51

Comparison of Stakeholders Map

Figure 39: Stakeholder Map, User in the center (Stickdorn & Schneider, 2011)

n Figures 39 and 40 the differences and similarities between the two versions of users in the center are depicted.

The two users are on the one side the private person as a User and on the other side the Store receiving data from the Service Provider.

In figure 39, user is in the center, there are three different interaction levels, as described above. The communication between the Store, the Service Provider and the Service are the same as in the second map. In the first Map, the Store and the Service are the connecting level between the Service Provider and the User. Additionally a distinction between the User, the Friends as user and the Family as user is given in Map 1, since the communication vary among these three stakeholders.

52

Figure 40: Stakeholder Map, Supermarket in the center (Stickdorn & Schneider, 2011)

In the second map, there are three layers as well, with the Store in the green outer layer, since no direct communication takes place between the Store and the Service. The Provider and the User are in direct contact to the Store, therefore they are in the same layer. The Provider facilitating the Store with data and the tray receiving money in return, the User purchasing the tray from the Store. However, the communication form between Service Provider and User has not changed, they only communicate via the Service. In this view, with the Store in the center, there is no distinction necessary between the User, the Friends as user and the Family as users. The reason for this is the focus on the data and money flow between the User, Service Provider and the Store. The needed data is collected via the Service from all the different Users that use the service.

53

Figure 41: Stakeholders Map with the Service Provider in the center (Stickdorn & Schneider, 2011)

This stakeholder map evaluates the interaction with the focus on the Service Provider. In this view it is emphasised how important it is for the Service Provider to construct a trustworthy brand. The Users must be able to rely in the Service Provider to guarantee security for the information that is being gathered. Otherwise the Service Provider risks to lose the User as data provider. This is channeled through the service once more, since the User does not need to know who is the Provider behind the Service. The Provider has to make sure, that the Service itself is trustworthy. Like in the other maps, the two users are related to the Service Provider through the Service itself, which works as the channel between the actors. User and Family are represented both by the User.

54

Figure 42: Stakeholders Map with the Service in the center. (Stickdorn & Schneider, 2011)

With the Service in the center as shown in Figure 42, direct communication takes place with the Service Provider, the User and the Friends as special user group. The Friends as users do not have the additional contact with the Store like the User and the Service Provider have. The Service is not directly connected to the Store since all data and communication has to be filtered and secured through the Service Provider. For the Service the relevant data flow is with the different users and the Service Provider.

55

Motivation Matrix

Figure 43: Motivation Matrix

56

This matrix illustrates the motivations of every stakeholder of using the service. Ben and Anna are not having always the same relations between them and the rest of the service stakeholders. It is evident in the relationship with Ben and his mother and Ben and the friends. Thus, it is necessary to distinguish the different user levels of interaction with the service and identify their motivation to participate in it.

Since Ben’s mother is just related to Ben, she hasn’t any connection with other stakeholders of the service. In this case, the data will be gathered through Ben’s account, considering that he is the one who will create a separate account for her, will register all her trays, and control it in the system.

It is also significant to outline how the store can be a provider and user at the same time, still they will have different approaches to the service. While the store as a user it is motivated to the collect and make use of customer data, the store as a provider will enhance some profit from the selling trays activity.

57

CONCLUSIONS Chapter four covers the future improvements, the relevance of the service as the designers see it as well as the conclusion about the service and the product.

58

Future Improvement

The prototype will be available in different shapes, so almost every product the user wants to keep track of can be connected to the smart trays.

Another extension can be the availability and usage of expiry dates. Here the users would be informed about soon to expire products, so they can use them in time. The challenge here is, how to provide the data. A scanner would be one option, another one the user typing in the dates manually. The problem is, this would require too much time and effort of the users and is not widely accepted. There has to be a chance, that either the receipt or the tray itself can provide this information.

A service extension would be a section in which it is possible to volunteeringly do the shopping for others. Either for elderly people that cannot do it themselves or for sick people living alone. The challenge here is to guarantee security for both: the volunteers and the users. The volunteers need to be sure to receive their money after the shopping and the users need to feel secure that the volunteers won’t misuse their information. Therefore a special database and security screening from the provider would be necessary.

Additionally the service could be connected to the supermarkets. The users could send their list and pay, the volunteers can go and pick up the ready shopping package and deliver it to the users in need.

59

Service Relevance

For a better understanding of the scope that this project has, four different perspectives will be presented. They specify how the service benefits its social context by being a solution for the food waste problem and involving the concept of smart cities and the internet of things, to generate a better relationship with food.

Social Impact of the service: The service “Lemonsays” connects people in a new

way over an old issue: food. Nowadays people are gathering around tables to eat together and their relationship with food is the one of buying, cooking and throwing away the left-overs. They let the food get damaged without thinking about the consequences of their actions or the value food has. With “Lemonsays” users can now share information about their food at home. Their relationship with food got transformed from a disinterested relationship to a direct and better communication.

Environmental Impact: In a greater sense the impact on the environment is a social

one as well. Reducing food waste implies having more food that is available for others. A better distribution of goods is another impact; sharing data between consumers, items and food suppliers will solidify a better distribution of the goods of consumption, having an considerable impact in the food production chain.

Technological Impact: The technological impact of this project is lead to the development of the smart cities concept, where the products are now able to have an active role during the food chain process. This possibility of leverage the internet of things for creating a benefit for every stakeholder, in this context, show us that technological development of sensors and communication channels between the users and these sensor will provide solutions for nowadays food waste problems.

Economical Impact: From an economic point of view, households, single persons and food producers benefit from the service. Money are saved when a better strategy for managing the demand and offer in the food chain consolidates the real information of need and market consumption behaviours. This way of perceiving and approaching the food supply chain will make the supermarkets and the people more conscious of the benefits that are connected to taking care of its better organization and management during time.

60

Conclusions

The Lemonsays service represents the output of the 8th semester project. The general theme for this semester was smart city and open/big data. The designers decided to focus on the food waste problem, trying to build a service within the smart city concept that will emphasize the impact of food waste on the environment. In the research face, it was revealed that a typical Danish family in single-family housing has 304 kg food waste a year, this corresponds to a food waste for 9265 DKK per year. (Environmental Protection Agency, 2011). The problem is that most people can’t properly see this loss. Food is losing its value because it can be easily replaced.

The challenge that designers faced was how to interfere in people’s life and change their behaviour without producing radical changes. Another challenge was how to make use of the user’s food data.

Based on the interviews and a workshop, the initial idea of a user centered service around food supply management was created. To meet the discovered needs, the designers developed a service around a smart tray, taking open data to create a smart environment. With this service, not only different kitchens are accessible and connected among each other, but supermarkets are included in the chain as well. They have the chance to get “data of the future” to help improve their planning.

With the service “Lemon says” the designers contribute to the idea of smart cities, connecting so far non smart items to be able to communicate with them. Additionally the service uses the generated big data to help solving the initial food waste problem.

The focus of this book was on the private person as a user that is connected to his smart kitchen. This is due to the fact that data generation, gathering and sharing in connection with smart objects and cities was the focus of the project. However the other users are an important part of the service. They are not elaborated in detail due to a lack in time and resources.

The friends as users participate in a limited way in the service. They are involved for special occasions and solely for sharing data via the shopping list. They have no access to “iMeasure” trays and generate no data from that perspective.

The supermarkets are another important user of the service from a monetary point of view for the service provider. They purchase the data about future behaviour of their clients and can add valuable information to their purchasing plans and market analyses.

The final version of the first prototype of “iMeasure” for the milk carton is presented in a Kickstarter website (Group 1, 2015). The video outlines the problem context and how “Lemonsays” should be used as solution. The second half of the video explains the technical details around “iMeasure”.

61

62

References: Bentley, L., & Whitten, J. (2007). System analyses and design methods. McGraw-hill. Page, 270 Stickdorn, M., & Schneider, J. (2011). This is Service Design Thinking. New Jersey: John Wiley & Sons.

Service Design Toolkit. (2014). Service Design Toolkit. Retrieved from http://www.servicedesigntoolkit.org/downloads.html ThingSpeak.com (2015). Retrieved from http://thingspeak.com Group 1. (2015). Lemonsays Pretended-Kickstarter. Retrieved from http://watchoutsmartfridge.jimdo.com/ Environmental Protection Agency. (2011). Mindere Madspild. Retrieved from http://translate.googleusercontent.com/translate_c?depth=1&hl=da&ie=UTF8&prev=_t&rurl=translate.google.com&sl=da&tl=en&u=http://www.mindremadspild.dk/&usg=ALkJrhgSrTx_hAxIfwvJOPMpY20syu0TBw

63