1

2

3

//OVERVIEW MAP//Introduction

//CHAPTER 1 - The Surface05 Service Concept

07Lemonsays and iMeasure 08 Value Constellation10 Service Architecture

12 Touchpoints

//CHAPTER 2 - User Focus

18 User Journey 20Touchpoint map

22 Blueprint29 Use cases

33 Service system overview36 Entity relationship digrams

40 System map 43 Stakeholders map

//CHAPTER 3 - Supermarket Focus

45 User journey46 Data flow and distribution

47 Stakeholder map

//CHAPTER 4 - Service Environment

49 Business Canvas50 Comparison of Stakeholder maps

54 Motivation Matrix

//CHAPTER 5 - Conclusion

57 Future improvement58 Service Relevance

59 Conclusions//REFERENCES

4

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.

5

Introduction

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.

Figure 1: Chapter Overview

6

THE SERVICEChapter 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.

7

Service ConceptThe 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 spac-es, 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 shop-ping, 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 pur-chase 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.

Service Concept

8

9

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

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

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.

Figure 2: Name of the application and the service

Figure3: 3D model of tray

Figure4: Name of the tray

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

10

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.

Value Constellation

Value Experience Constellation

Figure 6: Value Experience Constellation

11

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.

Value Offer Constellation

Figure 7: Value Offer Constellation

12

Service Architecture

13

Figure 8: Service Architecture

This service architecture aims to explain the way the different touchpoints and backstage platforms in-teract 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.

14

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 addi-tion to the way the tray works and gathers information from the user’s’ products.

15

Final Tray Design

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 ser-vice 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 in-dustry. The iMeasure tray works with own intelligence. In Chapter 2 the details of its functionalities are explained in more depth.

Figure 9: Acrylic Prototype of the smart tray

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

16

Mobile Application Interface

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

When one of the users that is shar-ing 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.

The Notification of an ending prod-uct (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 auto-matically added to the shopping list.

The Figure 13 presents the editable shopping list that will gather auto-matically the products that the sys-tem knows are about to finish. The user can change the amounts, de-lete or add even products that are not part of the tray system

Figure 11: Status of product, 25% remaining content Figure 12: Notification for critical product Figure 13: Editable shopping list with option for selecting shopping decision

17

The main interface shows all prod-ucts the users wants to keep track of. In case more kitchens are used it can be switched between the dif-ferent 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 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.

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

Figure 14: Notification of shopping intentions Figure 15: Adding trays Figure 16: Editable shopping list for better overview while shopping and update of the items

18

USER FOCUS

19

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.

20

Use

r Jo

urn

ey

Figu

re 1

7: U

ser J

ourn

ey o

f priv

ate

pers

on a

s a

user

21

The

cust

omer

jour

ney

expl

ains

the

diffe

rent

touc

hpoi

nts

that

are

rel

ated

to th

e us

ers

durin

g th

e us

age

of th

e se

rvic

e. In

this

gra

ph (F

igur

e 17

) it i

s po

ssib

le to

see

the

diffe

r-en

t use

r ne

eds

rela

ted

to th

e fa

cilit

ies

that

the

serv

ice

is p

rovi

ding

thro

ugh

its to

uch-

poin

ts. T

his

first

app

roac

h al

so p

erm

its t

o un

ders

tand

the

bac

kend

tha

t th

e se

rvic

e pr

ovid

er m

ust h

ave

avai

labl

e fo

r res

pond

ing

to th

e us

er p

rovi

ding

the

corr

ect f

unct

ioni

ng

of th

e se

rvic

e.

Web

pag

e Se

rvic

e

Mob

ile A

pplic

atio

n

Phys

ical

Sto

re

Sens

itive

Tra

y

22

Figu

re 1

8: T

ouch

poin

t Map

23

Tou

chp

oin

t m

ap

How

to

rea

d it

?Th

is to

ol p

erm

its th

e un

ders

tand

ing

of th

e us

er’s

inte

ract

ion

proc

ess

with

“Lem

onsa

ys”.

On

the

left

side

of t

he c

hart

in

Fig

ure

18 th

e di

visi

on b

etw

een

the

touc

hpoi

nts

of th

e se

rvic

e (y

ello

w) a

nd th

e us

er ty

pes

(ora

nge)

is s

how

n. In

the

uppe

r sec

tion

from

left

to ri

ght t

here

are

the

prin

cipa

l act

iviti

es th

at th

e us

er d

oes

with

the

serv

ice,

inte

ract

ing

with

ea

ch o

ne o

f the

touc

hpoi

nts

and

othe

r use

rs a

ccor

ding

to th

e ca

ses

of u

se a

nd in

tera

ctio

n w

ith it

.

This

touc

hpoi

nt m

ap p

rese

nts

the

user

’s to

uchp

oint

inte

ract

ions

dur

ing

the

serv

ice.

The

phy

sica

l tou

chpo

ints

take

n in

to a

ccou

nt a

re th

e m

obile

app

licat

ion

and

the

sens

itive

tray

. The

gra

ph d

epic

ts m

ost o

f the

pos

sibl

e sc

enar

ios

of

use,

sho

win

g di

ffere

nt k

inds

of u

sers

, suc

h as

Ben

(as

the

prin

cipa

l use

r), A

nna,

thei

r frie

nds

and

the

Stor

es.

The

obje

ctiv

e is

to p

rese

nt a

ll th

e po

ssib

le in

tera

ctio

ns w

ith th

e se

rvic

e be

twee

n th

e di

ffere

nt u

sers

and

iden

tify

whe

n th

ese

diffe

rent

inte

ract

ions

invo

lve

the

touc

hpoi

nts

of th

e se

rvic

e. T

his

grap

hic

will

be

the

base

for t

he c

on-

stru

ctio

n of

the

serv

ice

blue

prin

t.

24

Figu

re 1

9: B

luep

rint p

art 1

: Bef

ore

and

first

par

t of D

urin

g

25

Blu

e P

rin

tB

efor

eTh

is fi

rst p

art o

f the

Ser

vice

Blu

eprin

t (se

e Fi

gure

19,

par

t 1 )

depi

cts

the

way

the

user

s in

tera

ct w

ith th

e ph

ysic

al

prod

uct o

f the

ser

vice

, the

sen

sitiv

e tra

y, w

hich

will

be

foun

d in

the

diffe

rent

sup

erm

arke

t cha

ins,

or i

n on

line

stor

es.

The

user

s w

ill b

e ab

le to

dow

nloa

d th

e m

obile

app

licat

ion

for f

ree

and

use

it fo

r sha

ring

info

rmat

ion

or m

anag

ing

thei

r pro

duct

s in

the

trays

. Thi

s sh

ared

info

rmat

ion

is a

lso

avai

labl

e fo

r sig

ned

in a

nd a

ppro

ved

supe

rmar

ket-u

sers

.

It is

impo

rtan

t to

rem

embe

r tha

t the

tray

will

be

rela

ted

to th

e us

er’s

dat

abas

e th

roug

h a

proc

ess

of s

ynch

roni

zatio

n.

By th

e us

e of

a c

ode

the

tray c

an b

e id

entifi

ed in

the

dist

ribut

ed s

yste

m. D

urin

g th

is s

ynch

roni

zatio

n pr

oces

s th

e us

er

will

be

able

to la

bel e

ach

tray

acco

rdin

g to

wha

t it c

onta

ins.

It is

als

o vi

sibl

e in

the

grap

h ho

w th

e se

rvic

e’s

dist

ribut

ed s

yste

m c

reat

es d

atab

ases

for e

ach

user

, in

this

cas

e fo

r th

e st

ore

and

Ben.

Thi

s da

taba

se w

ill b

e di

ffere

ntia

ted

for t

he ty

pe o

f ser

vice

eac

h on

e of

the

user

s is

pay

ing

for,

in

case

of t

he S

tore

s th

e Bi

g D

ata

stor

ed b

y th

e se

rvic

e pr

ovid

er, a

nd in

cas

e of

the

user

s a

serv

ice

for a

bet

ter f

ood

man

agem

ent.

26

Figu

re 1

9: B

luep

rint p

art 2

: sec

ond

part

of D

urin

g an

d Af

ter

27

Du

rin

gTh

e du

ring

serv

ice

mom

ent s

tart

s w

ith th

e us

e of

the

tray,

plac

ing

it in

the

diffe

rent

spa

ces

requ

ired,

frid

ge o

r pan

try,

and

the

item

s or

gani

zatio

n in

side

eac

h on

e of

them

(see

Fig

ure

19, p

art 2

). On

ce th

e ite

ms

are

in th

e tra

y the

sys

tem

w

ill s

tart

gat

herin

g da

ta fr

om th

e pr

oduc

ts a

nd w

ill k

eep

the

mob

ile a

pplic

atio

n up

date

d. In

this

way

whe

neve

r the

us

er d

ecid

es to

acc

ess

his

fridg

e he

will

find

the

stat

us o

f his

pro

duct

s in

side

the

trays

.

If a

prod

uct i

s fin

ishe

d, th

e sy

stem

will

not

ify th

e us

er th

roug

h th

e ap

plic

atio

n an

d w

ill a

dd th

is it

em to

the

shop

ping

lis

t. Th

e us

er w

ill b

e ab

le to

che

ck w

hich

pro

duct

it is

and

edi

t the

fina

l sho

ppin

g lis

t, ad

d ne

w it

ems,

del

ete

or a

dd

amou

nts

from

the

sam

e pr

oduc

t.

Afte

r the

sho

ppin

g lis

t is

read

y, an

d if

the

list i

s sh

ared

with

som

eone

els

e, fo

r ins

tanc

e be

twee

n a

coup

le, t

he u

sers

sh

ould

take

the

deci

sion

of w

ho w

ill m

ake

the

shop

ping

. At t

he s

ame

time

the

othe

r one

is in

form

ed fo

r avo

idin

g a

mis

unde

rsta

ndin

g. T

he a

pplic

atio

n w

ill p

rovi

de th

e us

ers

with

the

optio

ns fo

r dec

idin

g w

heth

er o

r not

they

are

abl

e to

do

the

shop

ping

and

info

rm th

e ot

her o

wne

r of t

he li

st a

bout

eac

h us

er’s

dec

isio

n.

Aft

erTh

e us

er w

ill m

ake

the

corr

espo

ndin

g sh

oppi

ng in

the

stor

e of

pre

fere

nce

and

will

re-s

tock

the

item

s in

the

trays

, pos

-si

bly

re-la

bel s

ome

trays

and

org

aniz

e th

em in

the

fridg

e an

d pa

ntry

. Thi

s or

gani

zing

pro

cess

will

mak

e th

e sy

stem

up

date

the

stat

us o

f the

pro

duct

s fo

r fut

ure

user

con

sulta

tions

. All

this

ste

ps a

re d

ispl

ayed

in fi

gure

19.

Blu

epri

nt

28

Use

ca

ses

Figu

re 2

0:Pa

rt 1

: Ben

and

Ann

a se

rvic

e in

tera

ctio

n

29

This

use

cas

es d

epic

t th

e in

tera

ctio

n of

Ben

and

oth

-er

act

ors

with

the

ser

vice

an

d th

eir r

elat

ions

hips

. For

th

is p

urpo

se, i

t w

as c

reat

-ed

sev

eral

blu

eprin

ts:

Ben

and

Ana

use

case

(fig-

ure

20).

Ben

and

his

mot

her

use

case

(figu

re 2

1).

Ben

and

his

mot

her

use

case

(figu

re 2

2).

In t

his

case

, bo

th B

en

and

Anna

sha

re a

com

-m

on s

hopp

ing

list,

both

re

ceiv

e no

tifica

tion

whe

n a

prod

uct

is a

bout

to fi

n-is

h, a

nd t

hey

also

can

de

cide

who

is g

oing

to d

o sh

oppi

ng.

Figu

re 2

0:Pa

rt 2

: Ben

and

Ann

a se

rvic

e in

tera

ctio

n

30

Figu

re 2

1: P

Art 1

, Ben

and

mot

her s

ervi

ce in

tera

ctio

n

31

The

figur

e 21

out

lines

the

fact

that

Ben

can

con

trol

his

mot

her p

rodu

cts

beca

use

he c

reat

ed a

noth

er a

ccou

nt th

at w

as s

ynch

roni

zed

with

his

mot

her’s

tray

s. T

his

way

, he

also

will

be

notifi

ed a

bout

the

curr

ent s

tatu

s of

his

mot

her p

rodu

cts.

Use

r C

ase

Figu

re 2

1: P

Art 2

, Ben

and

mot

her s

ervi

ce in

tera

ctio

n

32

tFig

ure

22:

Ben

and

frien

ds s

ervi

ce in

tera

ctio

n

33

Ben

and

frien

ds u

se c

ase

illus

trate

s m

ore

the

shar

ing

the

shop

ping

list

par

t of t

he s

er-

vice

, the

tray

isn’

t pre

sent

. Ben

cre

ates

an

even

t and

is in

vitin

g hi

s fri

ends

to p

artic

ipat

e to

cre

ate

the

shop

ping

list

and

sel

ect t

he it

ems

they

will

buy

.

Use

r C

ase

34

Ser

vice

Sy

stem

Ove

rvie

w

Figu

re 2

3: S

ervi

ce S

yste

m O

verv

iew

35

Ser

vice

Sy

stem

Ove

rvie

w

The

grap

hic

in F

igur

e 23

rep

rese

nts

the

serv

ice’

s di

strib

uted

sys

tem

of

a si

ngle

us

er: h

ow d

ata

is g

ener

ated

, tra

nspo

rted

and

sto

red

in a

clo

ud, a

nd h

ow it

is b

eing

ac

cess

ed.

The

syst

em c

onsi

st o

f sev

eral

com

pone

nts:

Hom

e LA

N -

loca

l are

a ne

twor

k w

hich

inte

rcon

nect

s m

any

devi

ces

for a

sin

gle

user

an

d en

sure

s da

ta c

omm

unic

atio

n in

this

sys

tem

and

its

priv

acy.

Dat

a pr

ovid

er c

onfig

urat

ion

and

visu

aliz

atio

n ar

e al

l the

dev

ices

thr

ough

whi

ch a

us

er c

an c

onne

ct a

t hom

e to

vis

ualiz

e da

ta o

r pro

duce

som

e da

ta c

onfig

urat

ion.

Dat

a pr

ovid

er w

as c

alle

d th

e se

nsiti

ve tr

ay w

hich

is re

spon

sibl

e fo

r gen

erat

ing

data

an

d pr

oces

sing

it. A

fterw

ards

the

sam

e de

vice

is s

endi

ng it

to th

e se

curit

y ga

tew

ay.

The

sens

itive

tray

con

sist

of a

pre

ssur

e se

nsor

, a W

I-FI d

ata

mod

ule

and

a pr

oces

sor

for w

orki

ng w

ith th

e ga

ther

ed d

ata,

bef

ore

send

ing

furt

her.

Secu

rity

gate

way

is a

sep

arat

e de

vice

that

allo

ws

priv

ate

netw

ork

user

s to

con

nect

to

ext

erna

l ne

twor

ks,

whi

le p

rote

ctin

g in

tern

al s

yste

m f

rom

bei

ng c

ompr

omis

ed.

Thus

, sec

urity

gat

eway

cre

ates

a s

ecur

ed tu

nnel

VPN

(Virt

ual p

rivat

e ne

twor

k ha

s a

slig

htly

diff

eren

t pur

pose

) bet

wee

n cl

oud

and

tray

and

ensu

res

priv

acy

and

inte

grity

of

the

data

tran

smitt

ed to

the

clou

d.

Dat

a pr

oces

sor o

r the

clo

ud fo

r sto

ring,

ana

lysi

ng a

nd d

ata

trans

mis

sion

, a p

rivat

e cl

oud

mod

el w

ill b

e us

ed. T

he d

ecis

ion

of h

avin

g th

is ty

pe o

f clo

ud p

latfo

rm w

as ta

k-en

bec

ause

of t

he h

ighe

r sec

urity

leve

l for

the

cus

tom

er’s

pro

vide

d da

ta, i

nteg

rity

and

redu

ndan

cy.

The

data

pro

cess

or in

terf

ace

is s

truct

ured

in s

ever

al la

yers

:· T

he s

oftw

are

laye

r, ac

ts a

s da

ta p

roce

ssor

. · D

ata

stor

age,

ens

ures

dat

a st

orag

e in

a s

ecur

ed (f

or p

rivac

y) a

nd r

edun

dant

(in-

tegr

ity) f

ashi

on.

· Virt

ual a

nd p

hysi

cal m

achi

nes

are

used

as

host

s fo

r bo

th th

e so

ftwar

e an

d da

ta

stor

age

laye

rs.

Inte

rnet

sho

ws

anot

her

optio

n of

acc

essi

ng th

eir

data

. The

use

rs c

an a

lso

acce

ss

his/

her

info

rmat

ion

by c

onne

ctin

g to

the

clou

d fro

m o

utsi

de o

f LAN

(dire

ctly

from

th

e in

tern

et).

The

com

mun

icat

ion

insi

de t

he s

yste

m is

mos

tly b

idire

ctio

nal.

In t

he “

Hom

e LA

N”

the

data

flow

from

the

tray

is u

nidi

rect

iona

l, as

the

tray

is th

e on

e w

ho p

rodu

ce it

an

d se

nds

it fu

rthe

r. Th

e co

nnec

tion

betw

een

devi

ces

and

secu

rity

gate

way

is b

idi-

rect

iona

l sin

ce it

’s re

ceiv

ing

mes

sage

s fro

m th

e cl

oud

and

is s

endi

ng b

ack

it to

the

clou

d th

e up

date

s of

the

shop

ping

list

.

The

sam

e pr

inci

ple

appl

ies

for t

he d

evic

es fr

om “

Inte

rnet

” cl

oud

and

hom

e LA

N a

s lo

ng a

s th

ese

devi

ces

have

an

inte

rnet

con

nect

ion.

The

cha

nnel

bet

wee

n H

ome

LAN

an

d St

orag

e cl

oud

is a

lso

bidi

rect

iona

l. Fr

om h

ome

the

prod

ucts

sta

tus

inpu

t is

sent

to

the

clou

d, a

nd th

e cl

oud

is s

endi

ng b

ack

a sh

oppi

ng li

st a

nd a

not

ifica

tion

as a

n ou

tput

. So,

this

way

the

hom

e LA

N a

nd S

tora

ge c

loud

are

bot

h cl

ient

s an

d se

rver

be

caus

e th

ey b

oth

exch

ange

requ

est -

resp

onse

s, b

ut in

diff

eren

t situ

atio

ns.

36

Figu

re 2

4: D

ata

Flow

and

Dis

trib

utio

n

37

Da

ta E

xch

an

ge B

etw

een

Dif

fere

nt

Sy

stem

Use

rs

In F

igur

e 24

it is

illu

stra

ted

how

the

syst

em c

onne

cts

mor

e pe

ople

and

the

type

of

rela

tions

hips

bet

wee

n th

em. I

t als

o de

pict

s th

e di

ffere

nces

of t

he fe

atur

e ba

sed

on

the

user

type

. I.E

- Be

n an

d An

a ar

e po

wer

use

rs. T

hey

have

the

full

acce

ss to

the

syst

em a

s w

ell a

s th

e au

thor

ity fo

r mod

ifyin

g it.

Ben

’s m

othe

r doe

sn’t

use

the

sys-

tem

dire

ctly,

but

her

frid

ge is

pro

vidi

ng d

ata

so th

at B

en c

an m

anag

e he

r sho

ppin

g lis

t for

her

.

Fam

ily fr

iend

s ha

ve o

nly

limite

d ac

cess

to s

ome

of th

e ite

ms

in th

e fri

dge.

Vie

w a

c-ce

ss h

as to

be

expl

icitl

y gr

ante

d by

eith

er B

en o

r Ana

(sin

ce th

ey h

ave

Pow

er U

ser

priv

ilege

s)

38

En

tity

rel

ati

onsh

ip d

iagr

am

sIn

the

follo

win

g th

e da

taba

se re

latio

nshi

p fo

r the

ser

vice

is e

xpla

ined

. Firs

t an

over

view

of t

he g

ener

al s

truct

ure

is d

epic

ted

in F

igur

e 25

. Sub

sequ

ent d

iffer

-en

t exa

mpl

es fo

r spe

cific

situ

atio

ns s

how

the

diffe

rent

par

ts o

f the

dat

abas

e.

In F

igur

e 30

a c

ompl

ete

view

of t

he e

xam

ple-

data

base

is s

how

n.

The

follo

win

g re

latio

nshi

p di

agra

m e

xam

ples

con

tain

four

big

ent

ities

:

· Use

r - is

the

entit

y th

at in

clud

es a

ll th

e ac

tors

invo

lved

in th

e se

rvic

e da

ta. T

he

valu

e of

Use

r uni

quel

y id

entifi

es o

ne a

nd o

nly

one

User

ID.

· Frid

ge -

is t

he e

ntity

tha

t co

ntai

ns a

ll th

e us

er’s

tra

ys. T

he v

alue

of

Frid

ge

uniq

uely

iden

tifies

one

and

onl

y on

e Fr

idge

ID.

· Lis

t - is

the

entit

y th

at c

onta

in s

hopp

ing

list i

tem

s. T

he v

alue

of

List

uni

quel

y id

entifi

es o

ne a

nd o

nly

one

List

ID.

· Tra

y - is

the

entit

y tha

t inc

lude

s th

e tra

ys in

form

atio

n. T

he v

alue

of T

ray u

niqu

e-ly

iden

tifies

one

and

onl

y on

e Tr

ay ID

.

Figu

re 2

5 gi

ves

an o

verv

iew

of t

he s

ervi

ce’s

dat

abas

e. It

con

sist

s of

four

diff

er-

ent e

ntiti

es th

at a

re in

terc

onne

cted

and

cre

ate

diffe

rent

type

s of

rela

tions

hips

. Al

l the

ent

ities

hav

e a

prim

ary

key

that

are

mos

t com

mon

ly u

sed

to u

niqu

ely

iden

tify

a si

ngle

ent

ity in

stan

ce. (

Bent

ley,

Whi

tten,

200

7)

A Us

er c

an h

ave

zero

, one

or m

ore

fridg

es (f

or e

xam

ple:

one

frid

ge -

Ben

and

Ana

fridg

e, z

ero

fridg

e - B

en a

nd fr

iend

s ca

se) a

nd e

ach

“frid

ge”

has

one

or

mor

e us

ers

(Ben

and

Ana

).

The

rela

tions

hip

betw

een

“use

r” a

nd t

he “

list”

is o

ne o

r m

ore

inst

ance

s be

-ca

use

a us

er c

an h

ave

one

or m

ore

lists

(Ben

and

Ana

list

and

Ben

and

mot

her

and

frien

ds li

st).

The

“frid

ge”

and

“list

” de

velo

ps a

rela

tions

hip

zero

or o

ne, b

ecau

se o

ne fr

idge

ca

n on

ly h

ave

zero

sho

ppin

g lis

t in

case

of f

riend

s an

d Be

n ca

se; o

ne s

hopp

ing

list i

n th

e re

st o

f the

cas

es.

The

“Tra

y” is

bei

ng u

sed

by o

nly

one

fridg

e si

nce

it ca

n be

onl

y in

one

pla

ce a

t a

time.

One

frid

ge c

an c

onta

in m

ore

than

one

tray

s.

Figu

re 2

5: G

ener

al D

atab

ase

Over

view

39

Figu

re 2

7 ba

sica

lly s

how

s th

e sa

me

situ

atio

n w

ith tw

o us

ers

conn

ecte

d to

one

fri

dge

and

it’s

list.

This

vie

w is

sho

wn

as it

is n

eede

d fo

r the

com

plet

e ov

ervi

ew

data

base

sho

wn

in F

igur

e 30

.

Figu

re 2

6 sh

ows

one

exam

ple

data

base

with

two

diffe

rent

use

rs, u

ser

1 is

Ben

and

use

r 2 A

nna.

The

y sh

are

a fri

dge

and

a lis

t atta

ched

to

it. F

or th

is th

e co

nnec

tions

bet

wee

n bo

th u

sers

and

frid

ge a

nd li

st a

re

give

n. T

heir

fridg

e ha

s fiv

e tra

ys c

onne

cted

to it

.

Figu

re 2

6: D

atab

ase

Exam

ple

for U

sers

Ben

and

Ann

aFi

gure

27:

Dat

abas

e ex

ampl

e fo

r Use

rs B

en a

nd h

is m

othe

r

40

Figu

re 2

9 di

spla

ys th

e vi

ew o

f one

use

r’s p

ersp

ectiv

e, in

this

cas

e Be

n. H

e is

con

nect

ed to

two

diffe

rent

frid

ges

and

the

acco

rdin

g lis

ts, a

s w

ell a

s to

the

addi

tiona

l Eve

nt L

ist.

In F

igur

e 28

the

Eve

nt L

ist

situ

atio

n is

rep

rese

nted

. H

ere

four

diff

eren

t use

rs e

ntiti

es a

re c

onne

cted

to o

ne li

st a

nd n

o fri

dge.

Thi

s du

e to

the

othe

r use

rs a

re ju

st a

utho

rized

by

the

syst

em to

be

part

of t

he “

Even

t Lis

t”.

Figu

re 2

8: D

atab

ase

Exam

ple

for a

n Ev

ent L

ist

Figu

re29

: Dat

abas

e Ex

ampl

e of

Ben

’s V

iew

of t

he s

ervi

ce

41

The

grap

hic

in F

igur

e 30

dep

icts

the

com

plet

e ex

am-

ple-

data

base

tha

t w

as d

escr

ibed

in t

he a

bove

figu

res

sepa

rate

ly. It

is o

bvio

us t

hat

ther

e ar

e m

any

conn

ec-

tions

, inc

reas

ing

with

eve

ry n

ew u

ser a

nd th

eir f

ridge

s an

d lis

ts.

Figu

re 3

0: D

atab

ase

Exam

ple

com

plet

e ov

ervi

ew

42

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.

System Map - Ben

Figure 31: System Map, Ben’s interactions

43

As mentioned before, Ben can control his mother’s fridge. The map in Figure 32 illustrates Ben’s activities for start-ing 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.

System Map - Ben's Mother

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

44

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 gener-ates 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.

Figure33: System Map, interactions between Ben and friends

System Map - Ben's Friends

45

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

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.

Stakeholders map

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

46

SUPERMARKET FOCUS

47

User Journey

The current user journey (Figure 35) shows the service that will be provided to the supermarkets. The Service Pro-vider 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.

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

48

Data flow and distribution

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 prod-ucts 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 statis-tics 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.

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

49

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.

Stakeholders Map

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

50

SERVICE ENVIRONMENT

51

Business 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 main-tenance and the storage of the big data. The tray and most of all the sale of the big data contribute to the revenue streams.

Figure 38: Business Model Canvas

52

Comparison of Stakeholders Map

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 communica-tion 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 distinc-tion 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.

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

53

In the second map, there are three layers as well, with the Store in the green outer layer, since no direct communi-cation 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.

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

54

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 trust-worthy. 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.

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

55

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.

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

56

Motivation Matrix

Figure 43: Motivation Matrix

57

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.

58

CONCLUSIONSChapter four covers the future improve-ments, the relevance of the service as the designers see it as well as the conclusion about the service and the product.

59

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 screen-ing 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.

60

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 bet-ter 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 develop-ment 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 nowa-days 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.

61

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 be-haviour 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 im-prove 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 kitch-en. 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 Kick-starter 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”.

62

63

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/trans-late_c?depth=1&hl=da&ie=UTF8&prev=_t&rurl=translate.google.com&sl=da&tl=en&u=http://www.mindremadspild.dk/&us-g=ALkJrhgSrTx_hAxIfwvJOPMpY20syu0TBw