Memofy by Ulrik Brink

GROUP 7 Anne Berit Bjering S131783 Benjamin Johansen S102975 Mattias Ingerslev S092865 Maurice Spiegels S131637 Ulrik Uhre Brink S081830

Remember to remember 41072 - DESIGN FOR INTERACTION FALL 2013

INDEX WHO DID WHAT

INTRODUCTION 4 Abstract 4 Problem Description 4 Project Goal 4 PROJECT PLAN

MCI 6 About MCI 6 MCI user 6 TECHNOLOGIES 7 Overview 7 Context 7 STATE OF THE ART Behavioral analysis Planning tools

8 8 8

FOCUS GROUP

REQUIREMENTS 10 User satisfaction 10 CONCEPTUALIZATION 11 Evaluation and combining 11 Mobile application & SmartWatch 11 Prototyping 12 The WallCalendar 13 Feasibility testing 14

1. ITERATION 15 Mobile application & SmartWatch 15 WallCalendar 16 The holistic design 17 Prototype 17 Pilot test 17 USER TEST 1 Conclusion & summary

18 18

2. ITERATION Mobile application & SmartWatch

19 19

USER TEST 2 21 Mobile application & SmartWatch 21 WallCalendar 21 Key take aways 21 OBSERVATIONS 22 EVALUATION OF FINAL DESIGN

Heuristic evaluation

DISCUSSION AND REFLECTION

REFERENCES 27 APPENDIX 28 APPENDIX I: PICTURES

WHO DID WHAT Throughout the process of the project concerning conceptualization, focus group interview, development of prototype and user-testing, we have divided the workload equally. Concerning the development of the report we have divided the workload out in different sections where each group member had different sections. Anne Berit Bjering, s131783 Problem description MCI Conceptualization and development of the WallCalendar 1. iteration, WallCalendar 2. iteration, WallCalendar 3. iteration, WallCalendar Evaluation and final design of WallCalendar Discussion and reflection Video and stand-in The graphical design of the report

Benjamin Johansen, s102975 Problem description Stakeholders/User and MCI Context 1. iteration, WallCalendar 2. iteration, WallCalendar 3. iteration, WallCalendar Conceptualization and development of the WallCalendar Video and video editing The graphical design of the report Mattias Ingerslev, s092865 Technologies Requirements Conceptualization and development of mobile application 1. iteration, mobile application and smartwatch 2. iteration, mobile application and smartwatch 3. iteration, mobile application and smartwatch Evaluation and final design of mobile prototype Heuristic test of system

Maurice Spiegels, s131667 State-of-the-art Observations Conceptualization and development of the WallCalendar 1. iteration, WallCalendar 2. iteration, WallCalendar 3. iteration, WallCalendar Ulrik Uhre Brink, s081830 Technologies Requirements Conceptualization and development of mobile application in Axure 1. iteration, mobile application and smartwatch 2. iteration, mobile application and smartwatch 3. iteration, mobile application and smartwatch Evaluation and final design of mobile prototype Discussion and reflection Design and creation of logo

INTRODUCTION Abstract

In this project, “Remember 2 Remember” the main focus has been on developing interactive solutions for patients suffering from mild cognitive impairment (MCI) in collaboration between Glostrup hospital and DTU. The main finding through the research has been that no current solution is optimized for structuring the everyday life of MCI-patients. Thus the main focus has been on developing a solution that addresses the needs of the patients. The solution found has been based on several iterations. A focus group interview and two user tests has been conducted. By using methods such as co-creation and agile development, the final prototype is the result of a development process of 4 weeks. The final product is named memofy. By integrating a smartphone, a smartwatch and a tangible board, remembering everyday tasks becomes hassle free.

Problem Description

People are getting older and older due to improved medical treatment and an increasing focus on health. The increasingly older population is imposing serious challenges on society in general, and raises a demand for new solutions in many areas of this field. “Remember 2 remember” is a project that will focus on developing a wearable aid to facilitate the everyday life activities for the people who are suffering from MCI, a condition that is making everyday life complicated for thousands of seniors (mainly) around the world. Wearable technology is the next big thing in personal computing - making computing less about the smartphone and more about being a smart human. The wearable technology could ease the everyday life of people suffering from MCI by taking over tasks that the senior (or other) citizen no longer can master on his own. This could for example be to provide reminders, determine the users location, detect any accidents and falls etc., and provide visual appealing feedback to stimulate and assist memory.

Project Goal

The goal for this project is to design, prototype, test and evaluate a wearable and interactive solution and it’s user interface towards MCI-patients, so they would be able to perform and facilitate everyday life activities. Ideally the solution should allow people to live in their own homes without any interference and support from caretakers, and be able to maintain a higher level of life quality for a longer period of time. The core problem that our solution should be able to address is that MCI-patients are forgetting things important for their daily routines. We want to find a solution that acts as an aid for the stage they are in, so they can easier remember their daily activities, but also ease their everyday life in general. We are aiming to find a solution allowing the user to easier plan ahead and remember to attend their planned events. We will also be focusing on the interaction of making appointments with other people, both at home and outside. The project is carried out in collaboration with professor Ali Gürcan Özkil and neuro psychologist Maria Bang from Glostrup Hospital, Neuropsykologisk afdeling, the autumn 2013 in the course 41072 Design for Interaction. We want to thank the 3 patients together with their caregivers who participated in the focus group and the user tests for their valuable information and feedback on our concept.

PROJECT PLAN Focus group interview

2nd user test 2nd iteration

Conceptualization and feasibility test

Time

Introductory meeting with neuropsychologist

Conceptualization

1st user test, 1st iteration

Final concept and prototype

MCI About MCI

Mild cognitive impairment (MCI) is kind of a stage transition between normal aging and dementia. It is most frequently noticed among older people; Of people 70 years and above, the percentage having MCI is around 14 - 18. Forgetting things is the most frequent problem among people with MCI. To find the right way and to get overview of things are also important areas they struggle with. They are still able to do their daily routine, but as soon as things get too complex, it gets really difficult for them [videnscenterfordemens, 2013] MCI-patients are also likely to experience difficulties in the day-to-day planning, in memorizing things, and in keeping the already arranged appointments. It could also concern problems with finding the right words, a shortened attention span and limiting the ability to keep focus on their current activities. MCI can not be cured with medicines. Physical activity has been shown to have a positive effect on the mental functioning, but it does not have a longterm healing effect.

Figure 1: Remembering note

The further paragraps give a description of the users and stakeholders in this project are introduced. It has been noted that the system is complex, thus the analysis is mainly focused on MCI-patients and the stakeholders in close vicinity with these. The analysis is based on observations and research.

MCI user

The first group of stakeholders are the immediate users, e.g the targeted user group. It is important to note that MCI covers a broad range of symptoms and underlying diseases, and thus it can be developed in different levels of severity, as it is classified as â&#x20AC;&#x153;interposed between the cognitive changes of normal aging and what might constitute very early dementiaâ&#x20AC;? [Petersen, 2004]. The typical user is aged 65+, and most of them are around 75 years old, or older. Patients with lower levels of MCI This user has acknowledged that they suffer from MCI. This patient can take care of most of everyday things, but has some cognitive impairments compared to the average population. This patient gets frustrated when he forgets things. As the patient has acknowledged that they are sick, they actively try to fight the disease through various means. The severity of the disease is limited to forgetting everyday things, and getting deorientatetd now and then. Also, it raises concerns from the close family.Avoiding failure is a strong motivator Patients with higher levels of MCI This user has acknowledged MCI, but not always

the severity and progression of the disease. This patient can take care of the most basic everyday things. If tasks have been part of a routine, these tasks will be remembered (for example remembering keys and pin codes). The patient usually needs to keep a diary in order to get through a day. As the illness is not acknowledged, the user gets very frustrated when others tries to help. These patients have a higher tendency to get lost or loose track of their day. This often creates high levels of anxiety for their family. Also as the illness has progressed quite far, there is a general concern from the family about getting worse. The caregivers (family) The caregivers (in many cases family) have a first hand impression of what happens in the everyday life of the patient. They try to be as helpful as possible. Many of them are retired (due to the age of the MCI patients), and can spend a lot of time with the patient. In general they try to be caring and supporting. The caregivers as a group are as diverse as the population, but in general they try to support the patients. Some see it as a duty to help the patient, while others enjoy what they are doing. The common denominator is to help the patient achieving the highest quality of life. However they often get very frustrated when the patients dont want their help. On the other hand, many caregivers experience sadness when the patient doesnâ&#x20AC;&#x2122;t complete what they wanted to complete, so this can also be an issue.

TECHNOLOGIES Overview

The past few years the market for wearable technology and self knowledge has been emerging and it brings intelligent utilization of data to ease specific tasks or help different aspects of life. In more general terms the wearable technology can be characterized as utilizing different kinds of sensors along with computational power. The systems comes in many forms and shapes but is most commonly known on the commercially market in forms like watches, bracelets and such. Despite the smartness of the wearables they still lack the independency and must still be connected to i.e. a smartphone to earn the prefix “smart”. In this project we will make use of different smart devices in order to solve the problems. Smartwatches is one of the most commonly known smart-devices and is in general terms merely an extension of the smartphone and can include a set of different sensors, which can measure many things for instance sleeping-patterns. We have in this project tested and used two smartwatches, the Smartwatch 2 by Sony and the MOTOACTV by Motorola. Both of these devices allows the user to install applications so that the watch can receive notifications via the smartphone i.e. calls, texts and messages from social networks. Without the connected smartphone the two devices are only a simple watch and can’t be categorized as a smartwatch.

The smartwatch is still a new gadget and is still in raging development, and most of the devices requires a certain type of smartphone to even work. Another device that many won’t recognize as a smart wearable is the smartphone itself. Smartphones can be personalized with different application which in turn can provide a solution to specific tasks just like the smartwatch, but many times the smart wearables are more precise in measuring the data. The wearable technology can provide great interaction to specific tasks. Common types of input of different types of data to the system is either by touch or a press of a button. Output from the device can provide feedback to the user i.e. based on inputs, measurements from the sensors or even based on location.

Context

The physical solution space covered in this project is quite wide. As the problem description deals with wearable devices, this extends into the physical use area. It is a unit that should be able to be carried by the user for a whole day without interfering, or creating unnecessary disturbances, while at the same time assisting the users in their everyday life. The user has to become acquainted with a wearable device that can assist them in their

everyday life. This means that the product needs to be accepted, and domesticated, by the user. This may take some time, and depends on the users willingness to use the device. For some users it can be seen as a big help, for others it may feel like a intrusion of the private sphere. As the device is wearable, one of the use contexts is also addressing how the user will ensure to keep the device with them, at most (or all) time.Besides being a physically worn device, it also has to be used in changing environments. The main use will most likely be found in the users home. This means that the device has to be resistant against everyday wear and tear, such as humidity and moist from washing hands or dishes, to be robust enough to deal with minor impacts. The other use case is outside the home. Here the scenario could be a visit to a friend, and outdoor activities such as walking/hiking, shopping or maybe even during leisure events. If for example a person is going for a walk, the device must be able to handle different temperature spans, be water resistant and be shock and impact resistance in order to be robust enough. Also, if it can be worn during higher intensity exercises, such as swimming or gymnastics, it further sets some requirements for the device according to durability of more extreme environments such as water, sweat and heat. To sum up, the use context must be assumed as complex as the everyday life of our standard users.

STATE OF THE ART From information directly gathered through personal contact with MCI patients, their caregivers and involved diagnostic physicians, combined with a thorough research on the internet revealed to us that there are many people, projects and organisations working on solutions to solve problems typical for people that suffer from memory impairments. There are several proposed solutions to secure and monitor the health and whereabouts of elderly and especially seniors with declining mental health.

Behavioral analysis

A currently popular part of the solutions seem to be the use of inertial sensor measurements to be able to detect, reconstruct and analyse more complex but common human behaviour patterns. In combination with physiological measurement sensors, all housed in a wearable electronic system, these devices monitor daily activities of dementia patients. As a result these systems can detect a person falling down or ‘wandering’ activities. A nice example of such a solution is found in a recent research paper of Dong-Min Shin et. al. (2013). The paper describes how a watch-type device (SmartWatch), server system (Cloud), and algorithms are developed to not only monitor patients’ locations, but also help manage patients’ health by determining patients’ activity. See appendix I for picture. As is easily noticed, the use of a smartwatch in this context is similar to our original idea and vision of the total concept where the system should be able to monitor a patient at any given time. To use the watch as the main interface for the patients’

digital calendar and related extra functionalities however, is according to our knowledge not found thus far in this specific context.

Planning tools

Another used tool for MCI-patients is physical calendars on the wall that visualize daily planning. An interesting example of this is the combination of the well-known analog version that consists of a grid with columns depicting weekdays and rows indicating time intervals, and a camera that is linked to a computer vision system, patients and their acquaintances can modify and manage their own scheduling on the wall calendar itself without any mediation or interference by a digital device. The digitized calendar version can moreover be managed from a distance online by people close to the patient. A picture of the interactive classroom calendar can be found in appendix I. Surprisingly enough we found only one similar system that used the same principle but functions in a totally different environment, the Lego Calendar by Vitamins (2013), see figure 2. The lego calendar is a wall mounted time planner that was invented for employees of a design studio. An eyecatching design choice is the building material, since it is made entirely of lego. (re-)Scheduling appointments, deadlines and personal leave-days is made possible by using different colored Lego blocks, and their relative position on the calendar Lego-grid. When an employe takes a photo of the calendar with a smartphone, all the events and timings will be automatically synchronised to an online digital cloud based calendar. To quote

the inventors “It makes the most of the tangibility of physical objects, and the ubiquity of digital platforms”. An interesting aspect of this solution is the use of peoples’ own mobile electronics with camera functionality to make snapshots that are interpreted by an automated system instead of a fixed continuous observation system like a ceilingmounted camera that takes snapshots. Figure 2: The interactive LEGO calendar

The state of the art in aiding elderly suffering from MCI is thus both found in digital aids and in intelligent analysis of data, as well as in analog planning systems combined with ways to digitize the input. We do not claim that this is a full picture of the field, but it represents interesting trends related to our solution space.

FOCUS GROUP In order to start the project we needed first -hand knowledge about the problems that MCIpatients are having. A focus group was set up at Glostrup Hospital where the neuropsychologist invited different MCI-patients with different tech-background and MCI-level. We had some collaboration with another group in the course, that also worked with Remember to Remember. To ensure that both groups got the most out of the focus group, we collaborated on the questions for the patients. The goal of the meeting was therefore to figure out what people with MCI do in their daily lives, what do they forget, and what products they often use so we can develop a device that they would use. The focus group was really important as it would be the ground truth of our project where we could get knowledge about what problems the MCI-patients and their relatives are facing on a daily basis. To get the most out of the focus group we had only one facilitator and two persons transcribing the interview so nothing important information would get lost. A Focus Group guide with our plan and questions can be found in appendix II. Throughout the interview we covered both their strengths and their weaknesses concerning MCI and their working background. This information made it possible for us to create a profile of each participant, which were needed in order to come up with a problem statement.

One important thing on the agenda was to introduce them to the different devices that we wanted to include in our project. We brought different types of smart watches, see figure 4, including a smartphone with different installed applications and NFC-tags, see figure 3. Each of the participants were given a hands-on session where they could “play” with the devices and get an idea of how a solution could be, combined with these devices. The smartphone can be seen in figure 5.

Figure 3: NFC-tag ^

Figure 4: Smartwatch > We received great feedback from the focus group, and the following is the most important to note from the participants’ current situation • They were using handwritten notes to remember, but tended to forget them • Using texts as reminders for scheduled events. • All of them were using cellphones to some extend, but they haven’t really seen or used a smartphone that fits their needs The following are the most important feedback we got from the focus group after introducing the devices and what possibilities they could bring. • A locationbased solution • A shoppinglist on the watch so whenever they entered a supermarket, the device would show the list of groceries to buy • Show reminders on the watch • An interface on the smartphone that could fit their needs, with large text and such.

Figure 5: Smartphone

REQUIREMENTS User satisfaction

When developing a user-centered system it is important to include the needs and values from the core users when designing the different parts of the system.

• Context As a user I need to be reminded about what to remember at certain locations when I am out, as I don´t always remember on my own.

The core users of the system are MCI-patients with a lower or higher level of MCI. By making extensive use of user stories and use-cases, we can make sure that the system will match their needs and values.

From the user stories we can create different use cases as they can provide crucial information about the situations and in which context the different parts of the system will be used.

The following is a subset of the user stories which has been divided into different relevant categories; independance, remembering, interaction and context. These are the most critical to the system and should therefore also be of greatest importance to the design and evaluation of our concept. • Independence As a MCI person I can handle a day-to-day schedule on my own so I don’t have to bother my relatives for help. • Remembering a) As a MCI person I can keep track on future and previous events, so I can add structure to my life. b) As a MCI person I am reminded about events when I need to know about them. • Interaction As a user I need large and unambiguous input interfaces in order to be able to interact with the system, due to reduced eyesight and motor skills.

From the the user stories and use cases we have a good base on what is needed to solve the problem and what features that are merely nice to have. The following are the features that are needed of the system. • Include large and unambiguous input interfaces, so the MCI-patients can interact with the system without any trouble • A day-to-day schedule with a great overview of past and future events • A notification-system which can remind of scheduled events

Kirsten, 65, has been diagnosed with a MCI, which causes her to forget new things. This is often apparent when going out shopping on her own and talking to her children on the phone. But after a few hours she forgets who she has spoken with. A today-view will help her remember who she has talked to earlier.

And the following is features that could be nice to have included in the system. • Location-based notifications

Liam, 80, has been diagnosed with a higher level of MCI. He tends to forget newly scheduled events and his family is troubled with always reminding him about the events. A calendar will help him to get an overview of future events and be reminded when it’s time to leave, to arrive in time for the event.

Based upon the need requirements and demands we can start the process of a concept development based on the actual user needs.

The list of requirements has been subjected to continuous improvements during the process of information search and user testing, to reflect the convergence towards the definition of the optimal elderly aid helping MCI patients with remembering.

CONCEPTUALIZATION Based on the initial research, the focus group and the requirement specification, we started the concept generation with emphasis on investigating interesting directions. Each participant from the group came up with one concept which in terms should be able to solve the general problem. For further elaboration of the concepts see appendix III.

Evaluation and combination

We evaluated, based on the requirement specification, on the pros and cons from each of the five concepts and took the most useful and feasible from each of them. The following is a list of features that we will include in our concept. • A large calendar/smartboard on the wall (a camera detects input) • Mobile application which takes care of the basic planning of presenting contact and other relevant features in a simple manner. The mobile application should be extended by the smartwatch. • A smartwatch without input possibilities that vibrates on the wrist to draw attention to notifications. • Use geo-positioning and nfc as intelligent input for the system, to assist the user. From the combined concept, the individual features were further elaborated and improved, to form a complete concept ready for user testing. The concept consists of the main parts, one being the physical WallCalender and the other being the mobile application and smartwatchinterface. These two systems are developed as

individual sub-project though deeply relying on each other. The coordination in the group and the pre-testing ensures a seamless experience of one system.

Mobile application & SmartWatch

For the mobile application and smartwatch, we started from the concept and then brainstormed to find the necessary features for both the mobile application, smartwatch, and how the two systems would interact in between. The brainstorm also gave us an idea of how the initial interface should look like, and as a reference for the detail level we took in consideration the Doro PhoneEasy 740, see figure 6. on how their interface was designed. Our brainstorm of the system interactions can bee seen in figure 7.

Figure 6: The DORO phone

Figure 7: Concept phase

today-view a more personal touch. At this stage the phone interface was divided in two complexity levels. The first part of the solution include basic functionality for patients with more severe MCI, and featured: • Contacts, to allow access and overview of the users favorite contacts. • Phone, to make a call to a new phone number the user don’t have stored in the contacts • Today, to show an overview of previous activities today, to assist memory • Calendar, which show an overview of future appointments and event, which is synchronized with the WallCalendar. The second part of the solution features input to the system from action-based NFC-tags at the door and the SmartWatch. This solution would include the features from the first part, but also featured the following: • Notes list, which allow the user add elements to a list, i.e. a groceries list. • Input position, which allow the user to add their own POI (Points of interests) to give the

Detailed design Based upon the pretotyping/mockups in the conceptualization phase we made extensive use of Photoshop to create and design each layout to be used in the final prototype. This pretotype is based upon the first and more simple concept, and is illustrated in Figure 8.

Axure. By using Axure we could convert our layouts into an interactive HTML prototype, that allowed real interaction. The prototype could simulate a phone call to the predetermined contacts and the interaction with pre-entered events in both the today-view and the calendar. As the prototype is made of pure HTML and CSS, it can be viewed on any device, and is currently available here, and is also shown below.

The application is interfaced as a “home” which will include different underlying applications/ features which each will serve their purpose. The home includes a section with a large indicated time and battery indicator and this is present on all pages. Also included is contacts, telephone, a today view and a calendar, all of them having a home-button which will get the user back to the homescreen in a one-click operation.

For the icons we made use of colors and unique created rounded icons, so they would be easier to distinguish from each other. The background is made from three positive colors and blurred out to create a greater contrast from the icons. The entire application is made flat and with use of the popular rounded icons. The application includes:

Prototyping

Based upon our detailed design description we were able to create the first prototype. All created elements and unique icons were exported to

Contacts, includes personalized pictures of each contact person including their names with capital letters. In the bottom of the page is situated the home, back and forth button to navigate between the contacts.

Figure 8: First prototype

Telephone, includes a full keypad with again rounded icons, but this time in black and white. This is chosen because of the general use and the more used buttons are highlighted in bright colors - see the phone-icon. Today, includes the timeline of past events and each of them have their own unique icon to represent the activity/event. In the bottom there is situated the up and down bottom so you can move up and down in the timeline. Calendar, includes the daily and future events. At the top of each day we have mentioned the current date and highlighted the day. Each event is made in similar sections showing their start time and the title of the event. In the bottom there is included a back and forth button to look forward.

The WallCalendar

The concept of the WallCalendar was in order for the MCI patients to relate to a real world object and a in-tangible interface from a smartphone and/or smart watch. The idea behind it is also to introduce a familiar concept in order to make the domestication of the new technology quicker. It has been noted that patients can do habitual actions without forgetting, for example if they have been taking the same medication for several years, they will in many cases still remember to take the medication. Another reason for why we wanted to introduce a physical calendar, is the Visual, Auditory and Kinesthetic (VAK) learning style model, by Fleming (1987). People learn in different ways, some think they learn most by seeing, e.g. watching videos, looking at pictures, maps, etc. Others gain more

knowledge through listening, and are thinking through words rather than pictures. A third way of learning is through moving, doing, touching, and by interacting with things. It is shown that the more a person can learn through a combination of all these modalities (visual, auditory and kinesthetic), the more embedded the learning will be. We first started to make a concept of a LEGOsmart grid with a camera able to read the grids, see figure 9. We tried out with some different LEGO-colors and sizes, but found out that the bricks might be a little bit too small to handle for elderly with decreasing dexterity. Based on the LEGO-board, the idea emerged of using Velcro patches on all surfaces, which works more or less in the same way as LEGO. Another principle that could work in the same way is to use a magnetic board with thin, flexible magnet strips.

Figure 10: Prototyping with post-its We therefore moved over to experimenting more using paper and post-its, see figure 10. This was very important in this stage, because we wanted to get a grasp of what size the board and the different elements (simulated by post-its) could have. Paper, scissors and post-its made it easy to do quick prototyping. The main question to figure out was how to put appointments on the calendar. We all agreed that it would be nice to have one card per one appointment, not to confuse the users. Then we wanted to include different colors, to differentiate the appointments even more. In the beginning we thought that it would be nice to have categories like “family”, “friends”, “Doctor” and so on, but later we decided that one color per person would be even more clear.

Figure 9: Prototyping with LEGO

To be able to specify the info needed to make an appointment, we asked ourselves: What information is of absolute importance when we are going to meet someone?

We came up with these headers: Who are we going to meet? What are we going to do? Where are we going to meet? When, the time, are we going to meet? Which date/day are we going to meet? We thought the “at what time”, “when” and “with who” were the most important questions, so we chose to focus on these first. We found that either the camera has to detect where in the calendar grid the appointment is set, or it has to detect a time area on each card. After some testing we saw that a time-grid on the calendar would have to be very accurate if it was going to work.

to change it every single week. For example, you can slide two different parts (superimposing each other) of the calendar that each contain one week like a school board. Since this can be a bit confusing, you could also change the system only every two weeks instead of doing it every week, and sacrificing the possibility to always be able to look one week ahead of the current week. In figure 11 and 12 one can see the early concepts of the 1-week and two-week calendar. Figure 11: 1-week calendar Bekendte

Mandag

Tirsdag

Onsdag Torsdag

Fredag

Lørdag

Søndag

Feasibility testing

The test was a non-structured meeting where the total concept was tested and evaluated based on the intended interaction and the requirement specification. The following improvements were made and taken in consideration for the first iteration: • Only include the four main functonalities in the menu (no notes and no input position) • The colors looks childish and can have a negative effect on elderly (Input from Ali) • Try to make the layout of the calendar even more clear • Try out a one week calendar

Morgen

If Johanne wants to meet Ole at 16:00 and by accident puts the appointment on 17:00, it will give wrong input to the system, making the whole appointment a mistake. We therefore chose the other concept of having specific “time areas” on the cards. This was also chosen because we figured out that only the starting time and not the duration of the appointment is important for these users, since they seldom have planned several appointments on a single day.

Middag

Aften

Fremtidige aftaler

To do

Figure 12: 2-week calendar LØRDAG SØNDAG MANDAG TIRSDAG ONSDAG TORSDAG FREDAG

MANDAG TIRSDAG ONSDAG TORSDAG FREDAG

One of our other main discussed topics was whether to include one or two weeks of planning visible on the calendar. The pros of having a two-week calendar is that you can plan further ahead. You would for example be able to put an appointment with someone Thursday next week, and still see it on the calendar.

LØRDAG SØNDAG

OM 3 (+) UGER

06:00

HVA

08:00

HVOR

10:00

MED HVEM

HVA

NÅR

HVOR

12:00

MED HVEM

NÅR

14:00

HVA

HVOR

16:00

HVOR

MED HVEM

HVA

MED HVEM

NÅR

HVOR

NÅR

18:00

MED HVEM

NÅR

20:00

22:00

HUSK IDAG

The cons is that you will need a calendar board that is more complex when you want to be able

The following prototypes in this project could be characterized as a semi low and high fidelity prototype as it doesn’t feature actual functionality, though it in many cases seems to be the case, as we simulate functionality by a wizard of oz setup, where the user does not realize that output is not caused by the system itself.

VANNE BLOMSTER

OPPGAVER GJORT IDAG GIV MAD TIL KATTEN

GÅ UD MED SKRALDET TA INN AVISEN

HVA

HVOR

MED HVEM

NÅR

1. ITERATION Based on the first feasibility evaluation the overall conclusion is that the WallCalender needs to be simplified and the mobile application needs to look less childish and more sleek. In order to let the mobile application prototype look less childish we’ve brainstormed together and came up with a more professional interface which should eliminate the colored and circled interface that was denoted as ‘possibly childish’. The new interface includes the following features: • A simplified and less colorful interface using only light grey, green and blue (i.e. a restricted color-theme). • Squared buttons including the title. • A non-colored (white) background which ensures clear graphics and makes sure the focus goes to the more important content • New flat icons for each button which represents the color scheme We have also noticed that a camera and memo functionality might be relevant for our users, therefore we decided to test the need with

actual users and build-in these functions. These new functionalities serve the following purpose: • Camera, to take pictures from events and automatically be saved and showed in the today-view and gallery. • Memo, lets the user record a voice memo that will be automatically played when arriving home, or when played manually from a memo-list. The new interface with the two added features is illustrated in figure 13.

Mobile application & SmartWatch

Based on the feedback and the newly created pretotype/mock ups we could create the new squared icons and a substantially improved new interface including the two new features, camera and memo. The home-screen has changed significantly since the first iteration. The colored and rounded icons have been changed with squared ones in similar colors. The new squares now include the title and should therefore make it easier to figure out which title goes to which button.

Contacts have changed to Persons, as it is more personal. The rounded pictures of the persons haven’t changed and neither are the buttons in the lower section. One thing has been added since last time and that is the person profile. This features the profile pictures and buttons to either send a text or make a call to the person. Neither the calling person or telephone have changed besides the new interface. The today-view has a new interface, as the timeline has changed order. The unique icons are still used, but the different activities are now presented as seen in the calendar-view, which makes it a lot easier to read and distinct them from each other. A new feature in the todayview is that future events are shown as well, and the current time is shown as a vertical-line. This line indicates how far the user is in his plan for today. The new camera-feature allows the user to take a picture and view already taken ones, these should in a future iteration be included in the timeline of today. The memo includes two buttons, one for recording a new memo and one to listen to earlier recorded ones.

Figure 13: 2. prototype

WallCalendar

After some experimenting and the feasibility test we found out that we wanted to try out a oneweek calendar in our user test. It looks much simpler, and the user can concentrate on the ongoing week, without having to think of more than just what is necessary. We ended up with a one-week calendar, combined with pre made cards that had a timeand date area, see figure 14.

“done”-area. This gives a visual feedback that the task has been completed. If you have to repeat the tasks the next day as well, you just move the notes to the upper area next morning.

pink frame. Each picture is linked to a nfc-tag, so when you hold the phone up to the picture, the interface directly turns into the contacts-list; like a shortcut to call or text this person.

The family and friends-area consists of pictures of the closest family and friends with coloured frames, one colour for each person. These colours correlate with the colours of the cards, so that all the pink cards corresponds to for example the persona named ‘Morten’, when Morten has a

The third and main area is the calendar itself, including all the weekdays from monday to sunday. To make a grid, but without having a too specific one, we have included three states of the day: Morning, afternoon and evening. Figure 15: The calendar

DATO

Mandag Tirsdag Onsdag Torsdag Fredag

Lørdag

Søndag

Tirsdag 26. November

09:11 Husk i dag

Figure 14: Premade cards The WallCalendar itself has three interaction areas, including a ‘to-do’ section for the current day, the weekly calendar, and an area with pictures of close family/friends/others. The to-do area works as a daily reminder where you can put notes like “remember to water my plants”, “give the cat food”, “bring your keys” and so on. The notes are put in the upper area, and when you have done a task, you can move the note from the “to-do area” and down to the

Bekendte

Fuldført i dag

The user will be putting appointments-cards directly onto this calendar, which have different colours according to which person you are going to meet as mentioned earlier. The cards consist of a what-section where the user can fill in the appointment, and then either write where they will meet, or they tick off a premade often used place. The time and date should be filled in manually, but by connecting dots so the lines in between will represent a oldfashioned 7-segment display number. There is also a premade example on all the cards, made in a light grey to show how its supposed to be done. The point is to make “digital hours and dates” in an easy way with a pen. When the user has filled in the card, it should be placed on the right day, and just for one’s own convenience on the right time of the day, but this is of no importance to the functionality of the system. There is in addition a non-interactive display included in the upper left corner of the WallCalendar that works as a normal “watch and date” display.

The holistic design

So, how are the phone, the watch and the calendar linked together and how are they suppose to work? Lets look at a short user scenario. Karen has MCI, and has just got the new Memofy system. She has talked to her friend Lisa, and they have made an agreement of meeting on friday, 4 o´clock in the afternoon. Karen therefore takes an appointment-

card corresponding with Lisas colour, and fills in the location, time, date and what they are going to do, and puts it on the calendar. The camera detects the horizontal position of the card (which day) and the time and date (in the white area of the card itself). This is transcribed into a web based calendar that is accessible for Karens caregivers. This calendar is also synced with the calendar in the mobile phone application. When friday arrives, Karen gets an early reminder on the SmartWatch, that says she is going to meet Lisa at 16:00 hours in the specific location. More reminders, depending on the personal settings, will make sure Karen doesn’t miss her appointment.

Prototype

Mobile application & SmartWatch: As for the first prototype we again made use of Axure for the creating of the interactive prototype. We started from scratch with the new, more sleek design and made sure that every button had the corresponding action. The prototype was able to simulate the same functionalities as the first one, but this also included the features where a memo is recorded or a picture is taken. As the prototype is made of pure HTML and CSS, it can be viewed on any device, and is currently available here.

onto a wooden plate, and used double sided tape on the appointment cards to simulate the interaction. Our prototype did not feature a camera and interpretation system obviously, therefore we had to manually enter the appointments in to the web based calendar as soon as the participant added an appointment to the calendar (i.e. Wizard of Oz solution).

Pilot test

Before doing a prototype with actual users, it is always beneficial to do a pilot test. We printed out the calendar-board and made pictures with coloured frames, and appointment cards. The pilot test was then done with the whole group present during the evening before the day of the first user test. We went through all the scenarios, with one of us being ‘the patient’ doing all the tasks that we as ‘facilitators’ would provide. This revealed several small details to be remembered or fixed for the next day, but no big issues were discovered, see figure 16. Figure 16: The calendar

In the second prototype we included the SmartWatch, which should be used as an extension to the events entered. We installed applications on the smartphone which could receive notifications at our command. WallCalendar: We glued a color printed version of the calendar

USER TEST 1 The first user testing at Glostrup hospital was two sessions with one patient and related caregiver in each, to get different opinions on the current design, see figure 17. For this test, we used a test setup that utilized all members of the group, but where only two of us played an active role to the user dialogue. The following roles where assigned amongst us: The facilitator: Facilitating the usertest, presenting scenarios and asking for feedback. The co-facilitator: Presenting the application and smartwatch together with the user & relative. The photographer: Documenting the test in video & pictures. The documentor: Writing down all relevant comments, events, behavior and emotions. The ‘wizard’: Simulating the automated system with help of a laptop with internet connection from the far end of the room. When the MCI-patient added an event by hand to the WallCalendar, the appointment was added to the online digital calendar which automatically would send an email in the form of an notification that was passed-on as a reminder to the SmartWatch that the MCI-patient was wearing. The patient got stunned that the created event appeared so quickly in the system and that they were notified by it on the watch.

Conclusion & summary

• It is practical that contacts are marked with color and picture, and that they are similar in the application and the WallCalender. • The timeline is very practical. • Its is good that you can call someone by holding the phone towards a picture (nfc). • It is nice to get messages and notifications on the arm. (SmartWatch) What did they not like? • Writing appointments for the wall calendar by hand is difficult! • Remembering which date it is is also difficult • The “to do” area on the wall calendar is ambiguous in its use. • Memo function and camera is difficult to handle and does not add enough value for people with severe MCI. • The touch interface works, but they tend to push the interface quite hard and too slow. • Adding inputs to the watch does not add much value to the solution and is complicated. It is however easier with physical buttons. • There is lacking consistency between the colors of contact persons on the WallCalendar and the contact persons background color in the application. What did they miss? • The ability for caregivers to remotely add appointments to the online calendar • The ability to track persons based on location to find them when lost. • They would in general like an even more simplistic interface.

Figure 17: Pictures from the user test

Key take aways from the first workshop. What did they like?: • The WallCalendar gives a good overview

2. ITERATION The first user testing verified the basic idea of our concept, but also highlighted some important deficiencies. The feedback showed a need for a more simplified way to add events and appointments to the WallCalender, and a more simplified interface of our mobile prototype. The problem has been taken into consideration in order to cater the need of the users with more severe MCI (e.g. categorized by category 1 MCI, category 2 MCI and so on).

We started from scratch and replaced the colors and the unique colors with simple text, see figure 18. Our intention is to make all interactions intuitive and self explanatory so the users won’t need to learn any icons, as all icon metaphors have not proven to be easily interpreted by all test subjects. Figure 18: Prototyping

The detailed design of the system is not changed much at this stage, due to positive user feedback at the most recent user test. However the interface has changed significantly based on the feedback from this test, see figure 19. The changes are probably of great importance to the user experience.

Mobile application & SmartWatch

Based upon our feedback from the second interview, we have created a more simple and intuitive concept, which comes along with a grading system. In this concept the interface and range of functionalities is to be matched to the capabilities of the user having a certain degree of severity within the MCI category. The simplification will involve the following measures

The added feature to the concept is that relatives can add events and appointments to the application calendar, but this is not worked out in detail at this stage. We have instead chosen to test out the new features with a low fidelity prototype. The same goes for the feature that will remind the users to enter their events and appointments onto the WallCalender, which have been added into the application by their relatives.

Figure 19: Wireframes

• Using wireframes and describe functionality in clear text instead of using icons • A new black/white/grey color scheme (this coloring does not distract). • Fewer features for patients with higher level of MCI • (1) includes only basic features like phone, calendar and timeline, for more severe MCI • (2) includes more features like memo, camera and such, for lower level of MCI • Integrated phone and contacts into one element, instead of having two separate ones

WallCalendar

Based on the observation and feedback from the user test, we wanted to simplify the WallCalendar. The main element we wanted to change were the cards: • Writing the numbers in the white time area is difficult. • Remembering which date it is is difficult • The time and date areas look too similar, easy to write in the wrong place • The what-area can be problematic for interpretation into the system/digital calendar We therefore decided to remove the datearea completely, because from the user test it seemed that they rarely planned a lot of things ahead in the future that would call the need for a date specification. We also changed the whole time system, removed the handwriting part and replaced it with two areas to put stickers on instead. The stickers are in two colours: Black ones with white numbers are for the hours, and white ones with black numbers are for the minutes. This is done to minimize the risk of confusion and wrong time specifications.

were: • the “to do”-area. The users understood the purpose, but to move the note down in the done-area didn’t really work well. A solution to this could have been to remove the donearea itself, but keep the to-do. Still we chose to eliminate this part from the calendar completely, since we wanted to make it even more simplistic. • There was no space to store the unused actual appointment cards in the previous version. This was solved by taking away the “to-do” area, and rearranging the order of the remaining sections. The new board looked like this:

Figure 20: Stickers and iterated card

Figure 21: Iterated wallcalendar

We changed the layout of the card itself as well. We added pre-determined items in the “whatarea” to make it even easier; Now there is no writing, only ticking off and adding stickers, see figure 20. Secondly we wanted to slightly simplify the layout of the board. The parts we considered changing

USER TEST 2 As at the first user testing we had the opportunity to test our prototype on two groups consiting of a user and caregiver.

Mobile application & SmartWatch

For the second user test we brought the newly redesigned concept, but this time we only tested the new interface and the interaction for creating a new phone call. The new feature that relatives could add an appointment is simulated in the following way: • The user gets the smartwatch on the wrist and sits with the phone in the other hand. We have opened the regular calendar on the phone (not our interface) • By another phone we send a meeting to the test account, which appears on both the watch and the phone. • We show the user how the appointment can be accepted or rejected and evaluate the value of this functionality.

WallCalendar

We brought the redesigned printed version of the WallCalendar with the simplified system for writing notes. The primary action we wanted to test was the users ability to plan an event and reschedule it if necessary. Both interviews give the conclusion that our concept is now at a level where all aspects make sense to our users. Pictures from the user test can be seen in figure 22 and 23.

Key take aways What did they like? • The appointment cards are easy to use for both users, and are placed correctly. • The simplified WallCalendar design makes sense for the users. • User(s) with more severe MCI like the wireframe design and reduced options. • Participants think it is great that relatives can add appointments to the calendar for the user to accept or decline. • Participants think it is great that the smartphone asks the user to add new appointments to the WallCalendar, in a 1 meter proximity. What did they not like? • As the patients were troubled with a higher degree of MCI, they did not like the complex versions of the home screen as much as the simplified version. What do we find necessary to change and why? • Even though they liked the concept, we got the feeling that some users had difficulties getting a grasp of the whole concept (i.e. system) over time, which indicates that a prolonged usertest in their own home their environment should be conducted to test if the system can eventually be used without instructions or guidance. • One test group suggest that we should maybe link the level of system complexity/ functionality directly to the official MCI test score of a patient which is performed every 6 month by a medical professional.

Figure 22: User testing

Figure 23: Questions for the patients

OBSERVATIONS Findings based on our observations have been acquired during both the focus group and the feedback received during the two user tests. In general all findings can be classified as either feedback directly received from users, or as statements that can be used as design principles for different parts of our concept. Based on these classifications a division in paragraphs is made to give structure to our observations. The users behavior: Some caregivers are worried their patient might get lost and will not be able to find a way back home “It would be nice … a tool that can tell you if you are not on the route that you were supposed to be”, while actually the patients themselves indicate that they do not have this fear because they know how to find their way home so far. It is also pointed out that unlike appointments and ad-hoc tasks that involve memorizing something for a little while, routines and habits are not likely to be forgotten. In terms of specific practicality issues, almost all users are switching from putting reading-glasses on and taking them of, depending on the type of interaction they are having. Regarding touchscreens, it is our experience that people of older generations, as is the case with most people in our target group, are inclined to touch the screen pretty hard and have difficulties to touch the screen at the right place (i.e. speed, finesse, and accuracy problems). Mental support: Based on the introspection of the MCI patients

themselves, they indicate that positive feedback is important to them (i.e. when people tell them that they remembered something correctly). A side remark is also pointed out about negative feedback. Although MCI patients are likely to forget the specific personal feedback, the associated feeling remains much longer. This provides a good reason for not to make use of negative feedback to prevent feelings of disappointment and accumulated over time even depression.

should be done by a non-obtrusive adjustment of their current activity (i.e. getting them back on track by taking their hand and leading them). Also instead of only remember people to bring their keys with them, we are advised to build-in a solution to help users finding lost keys, especially in the case of a more severe MCI stage. Moreover it is suggested that medicinal reminders should also be part of the calendar system, since medicines are a substantial part of the daily routine for many patients.

Supportive feedback, which has a positive valence by nature for example like reminding people that they usually can do something since they have done it successfully before, can be used to reduce feelings of insecurity. The latter type of feedback is according to the caregivers likely to make patients still feel responsible for their own actions, encouraging them as much as possible to function independently (i.e. doing the groceries on your own). Solutions need to be all encompassing, protecting the user diagnosed with MCI for example from making planning mistakes by taking into account, and giving some control to, their direct social environment. To have the biggest chance of success, it was suggested that a solution like ours should be introduced to patients when they are still in a good state. This way, users can get used to the system and its different elements before they reach a worse state.

WallCalendar related: During the user tests, the appointment-cards with checkbox areas to define the ‘where’ and ‘what’ for appointments were highly appreciated. It appeared difficult however for the users to see the difference between the date- and timeareas on the calendar appointment-cards where both have to be specified using a pencil and connecting dots. In a different design that made use of 2 stickers to indicate the hour and respectively the minutes specified in quarters of an hour, some users didn’t feel the need to use the ‘00’ sticker to indicate an appointment on the hour (e.g. 16:00 o’clock). When both stickers are placed, they are not always placed neatly inside their respective places, even sometimes slightly on top of each other. Although we designed the sticker principle to be correctable so users could remove a ‘time’ and define a new time when an appointment had to be rescheduled, it was interesting to see that a single participant took two new stickers and placed them on top of the old ones of the calendar appointment card. A suggestion was also made to put, depending on

Implementations that gently guides the users activities towards a goal are preferred, instead of correcting them explicitly by a notification, this

the MCI severity stage, names or even pictures on the different colored calendar appointment cards to make it even more clear to which contact person the card is linked. It could thereby also be observed that the colored cards sometimes hindered readability of the always black-colored text. Having a clear overview of the whole week due to the WallCalendar is also experienced positively. This is moreover supported by the fact that some users where able to quickly observe and determine if timeslots were free or booked. One caregiver informs us that they use a calendar at home, and put a large red cross over the date so the patient can see which dates have passed already. Since many patients write things in a small diary or down on little pieces of paper to look at them regularly to remember something we included a scenario where patients where encouraged to use the ‘to-do today’ section of our WallCalendar. Interesting enough, instead of being a tool to help them remember daily tasks, it only seemed to cause confusion and not really be useful at all. One interesting concern of one of the caregivers is about what happens when a patient is no longer able to use this calendar anymore, and what functionality or added value remains of the system. Smartwatch related: The swipe concept to interact with a touchscreen seems better to be avoided, simple singletouch input or tangible press-button interaction seems to be manageable after some trials. The optional vibrating function of the watch when a

notification is received and displayed , seemed to induce quite a strong, positively surprised, initial reaction. Users themselves also indicated that they are more likely to miss a notification if it had only been displayed on a vibrating smartphone. Smartphone interface related: Most users respond initially positive to the memo voice recorder app, but as soon as we simulate its use, it seems that patients have trouble to form a concise and complete audio message. This requires re-recording attempts since they would otherwise confuse themselves when hearing their own message that lacks crucial information like appointment time, date, or place. When using the contact persons overview, some individuals had a little trouble quickly finding one of the fictive persons since they seemed to look for a color in the phone’s interface like the the color coding labels used on the WallCalendar. It therefore took a moment for them to realize they had to look at the pictures themselves instead. Particularly interesting to observe was that almost all of our users forgot to hang up the phone when instructed to end a call and return back to the home-screen. Also an surprisingly simple but obvious valid remark was made by one of the patients about the time that appeared on the screen indicating the duration of the current call “Why should I need to know how long we have been talking? ...I just need the important things!”.

to match the cognitive capabilities, knowledge and experience of the individual user (i.e. personalized). This was even mentioned explicitly by one of the users, telling us that the wireframe interface was “as easy as it can be...I won’t use anything that is more complicated than this”. The latter two characteristics would relate to the type of electronical device interfaces they are familiar with, some of them for example only have experience with simple out-dated electronics like old mobile phones. On top of that, it seems that even within the MCI target-group there are substantial differences in the cognitive capabilities of users, which allows them up to a certain degree to adapt, learn, and incorporate new technologies and devices in their daily lives. Our preliminary research already showed the learning capabilities of MCI patients, to quote “I never thought that with this disease I would ever be able to learn something new again!”. Also depending on the closeness of the relative/caregiver in respect to their relation with a patient, the consequences of MCI and dealing with it is experienced very differently.

MCI and user specificity: During our user tests we observed that probably different ‘interface-complexity’ levels are needed

EVALUATION OF FINAL DESIGN Through the process we have made extensive use of user-centered design principles. Our final design is based upon explicit understanding of the MCI-patients and their environment. In collaboration with Glostrup Hospital the MCIpatients have been involved throughout the development and design. The whole process has been iterative and our prototypes have been through three iterations. After each iteration the prototypes have been refined by a user-centered evaluation from the MCI-patients.

user experience than ordinary analog calendar and such. The system provide the patients and their relatives a new way of communication and scheduling together and this way they will gain more self control. To really improve the user experience of the system, we introduce a simple and yet intuitive interface which is scalable to match the individual patient and their level of MCI.

The collaboration between DTU and Glostrup Hospital was really valuable for the project. Glostrup Hospital made it possible for us to get hold on the most relevant patients and suitable facilities to facilitate our user testing and interviews. Each participant had different level of MCI and technical skills which made it possible to test out different scenarios and features. For instance could one patient find the mobile application very easy to use and another couldnâ&#x20AC;&#x2122;t even handle the different elements included in the application. Throughout the project we have developed different prototypes to meet the requirements and help the MCI-patients with their daily problems. Each of the mobile application prototype, SmartWatch and the WallCalendar solve different problems and by combining them into one system, it was possible for us to fulfill some or all the patients needs. The combined system allows the patient to interact in a whole new way and offer them a far better

Heuristic evaluation In order to evaluate the final design after the last usertest, we have subjected it to a heuristic evaluation [Jakob Nielsen] to highlight the possible issues that might not have been exposed during the user tests due to their limited number of participants. In addition to that, the heuristic evaluation tend to highlight problems that might not be discovered during user tests, and is therefore an important tool at this stage. In the following evaluation we will mainly highlight potential errors based on Nielsens heuristics: 1. Visibility of system status • The analog version of the calendar is not able to provide feedback to the user if they are using it wrong. 2. Match between system and the real world. • The terms “I dag” and “memo” might not be related to the underlying functionality in the users vocabulary. • The digital clock annotation used in the system might be new to some users, as some use analog clocks. 3. User control (Undo and redo: eg ability to leave an unwanted state by emergency exit) • When using the application to make a phone call, the menu will automatically go back to the main menu when hanging up the phone, thus the user has to start over if they want to make another call or misdialed. • If entering a wrong menu on the application, you can go back to main menu by the button “hjem”. However the user needs to remember that “hjem” means going back to the main

menu. 4. Consistency and standards (user should not have to worry whether two things mean the same) • There is an inconsistency between the colors in the last iteration of the WallCalendar and the Black & White color scheme of the application. • Due to the simplicity of the system, there is only one way to perform a specific task

8. Aesthetic and minimalistic design (omit unimportant info) • Each planning card for the WallCalendar displays information about all possible locations and activities, which might slow down the user when filling out the card. • The system might sometimes omit more information than the user wants. For example it is no longer possible to see the duration of a call, which is nice for some but not others.

5. Error prevention (eliminate error prone conditions in advance) • If the elderly places the calendar appointment wrongly on the WallCalendar it could lead to errors. In the current system, the only way to prevent this is to verify the event with the people attending to it.

9. Help the user recognize, diagnose and recover from error (error messages in plain language). • The system offers no feedback on faulty actions. If the user e.g. tries to call but have not entered a number, nothing will happen.

6. Recognition rather than recall (make the important visible, so he don’t have to remember...) • The new application requires the user to recall what is behind the name of each menu as icons has been removed. • When entering an appointment on the WallCalendar, the user must remember that the time indication consist of both hours and minutes, even when the minutes is “00”. 7. Flexibility and efficiency of use (cater for experienced and inexperienced e.g. by shortkey functions) • The current system does not have a seamless overlap between different user capabilities. If the user needs more or less functionality this has to be set up in the backend.

10. Help documentation (If the system fails to be self explanatory, then give the user access to task based information such as tutorials) • The system does in it current state have no help documentation, which makes it interesting to observe the unassisted use to discover where is fails to be self explanatory. The problems identified through heuristic evaluation has not yet been subjected to a severity rating, but when preparing the design for further user testing it will be relevant to take the most important foreseeable problems into account as early as possible, to ensure that a more expensive large scale user test has a high success probability.

DISCUSSION AND REFLECTION During the process of this project we have followed the user-centered design principles and designed, tested and developed Memofy; A combined system of one mobile application prototype, a smartwatch and a WallCalendar prototype. Our solution, Memofy, is addressing the problems concerning planning, scheduling and not to forget remembering. Memofy features a combined solution of both wearable and tangible technologies which in turn will make the day-to-day tasks a lot easier to remember. Project Memofy was facing time constraints and some aspects have therefore been left out of the solution in order to secure concrete results from the limited time and user-tests. Throughout the project we have been doing first a focus group interview and later on two user tests. At the focus group we got knowledge about the problems that the MCI-patients are facing on a daily basis, and based on that we did the first concept. On this concept we did a feasibility test which went well, and from the feedback we were able to do the first prototype. The prototype was then tested on the MCIpatients on Glostrup Hospital and based on the feedback on that we revised it and made the second prototype, which again was tested. Overall the process went really well and we received invaluable feedback from the patients. One thing though is that we had different patients for each user-test and this made it harder to show

a pattern. On the other hand it was rather good to have a new set of eyes for each user-test as we could test out new things without them knowing the first iteration. Concerning the collaboration of the individual team members in our group it went really great. Throughout the project we have been working together in terms of reaching the goal and increasing the the quality of Memofy - good team spirit equals a good quality prototype. The team consists of multidisciplinary team-members with different key competencies and by making use of these we complemented each other through the different parts of the project. For efficiency we divided Memofy into a project concerning the mobile application and the smartwatch, and one concerning the WallCalendar. We had regular meetings within the group to update each part of the project and made it possible for us to be on the same track of Memofy.

When this being said there are some aspects of the solution that are still on an early low-fidelity stage and need further development. The next step for Memofy is to combine all the verified aspects into a high-fidelity prototype and do further user testing both in closed environments and in the patients home environment. In order to do these tests the Memofy mobile application should be developed into a fully functional application, which in turn would require programming the backend functionality. When the functionality at different levels of MCI is tested and found to fulfill the requirement specification and get high user evaluation scores, it will be interesting to try to relate the official MCI test to the different levels in our solution.

When looking back to the beginning of the project neither of us knew what MCI was and what problems the patients are facing on a daily basis. Following the project we gained more and more insight in the problems and the individual MCI-patient. When acknowledging the problems we were able to address them to some extend with Memofy. Based on the process of the project we have moved really far both as individuals and as a group. We are confident that our solution, Memofy, can address the problems of MCI to some extend.

REFERENCES Articles and papers: Dong-Min, S., DongIl, S., and Dongkyoo S 2013, “Smart Watch and Monitoring System for Dementia Patients”, Lecture Notes in C.,omputer Science (including Subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics) — 2013, Volume 7861, pp. 577-584 Fleming (2001) The JCU_090460.html

VAK-model.

Accessed

from

http://www.jcu.edu.au/wiledpack/modules/fsl/

Lego Calendar by Vitamins (2013); http://vitaminsdesign.com/projects/lego-calendar/, 30th of October 2013 Nielsen, Jakob “10 Usability Heuristics for User Interface Design”, http://www.nngroup.com/articles/tenusability-heuristics/ MCI Faktaark, accessed from http://www.videnscenterfordemens.dk/, december 2013 R. C. Petersen, 2004, “Mild cognitive impairment as a diagnostic entity”, Journal of Internal Medicine, PP. 183-194

APPENDIX APPENDIX I: PICTURES SmartWatch, Dong-Min et. al. THe interactive smart calendar

APPENDIX II: FOCUS GROUP GUIDE Keep in mind that the patients will forget things, but the caregivers and experts don’t! It is highly recommended that the focus group should be done in the native language (i.e. in Danish) Make sure the right people sign the correct documents concerning ethical issues and a non-disclosure agreement etcetera BEFORE you start doing the actual focus group. Also, instruct people to write down their name on a name-tag that can be placed on the table, this way you can call people by their first name which makes the focus group more personal and less formal. Finally, be sure to have enough tools that allow for interaction like pen’s, papers, pencils etc. and provide participants basic needs like coffee, tea, cookies (not too much or too crunchy ). 1. Introduction of yourself and the ‘organization’ Hello everyone, my name is _________ , and as you may already know I am a student at the DTU. In collaboration with other students and teachers, we carry out a project “husk at huske” And luckily you were all prepared to help us with this task. 2. Brief background of our project (describe in maximal 6 sentences) 3. What are we going to talk about - bullet-point the topics you are going to ask questions about, try to get a nice logical structure! - Also tell explicitly that it’s the personal opinions what is valuable to our research, not the knowledge about the topics that are discussed. State that personal opinions can affect future

technology, and there are never wrong answers! 4. Let all participants introduce themselves Name, age, and other relevant demographics. (This is really important to be recorded on camera for identification later when using data from the focus group, of course everyone will be anonymized later.) 5. Simple practical exercise/task/interaction ‘to break the ice’ Think of a way how everybody can quickly gain us some insight in the topic of interest by letting them perform a ‘fun’ task (instead of talking) like drawing, writing, playing around with some device etc. 6. Questions Using the previous mentioned bullet-pointed structure, you define and go deeper into the topics you want to ask questions about. This is the main part of the whole focus group, take good care into preparing this) Questions for patients • Can you talk us through your everyday routine? • What is the best/worst part of your day? (value creation) • What is your biggest hurdle in your everyday? • Do you use any auxiliary devices (hjælpemidler) in your everyday? Which one? • Are they homemade or bought? (see activities) • Do you have a computer? If yes, what do you use it for?

• Do you wear a watch usually? • Is there any kind of accessory that you always bring? • Is there any kind of product that you always bring? • Do you have a phone? - If yes - What kind of phone do you have? Do you often call with it? Do you also do other things with it than calling people? (see activities) • How often do you go to the hospital and for what reason? • Can the hospital help you (with what?)? • How do you best remember things (pictures, text, someone telling you something etc.) • Is there anything you would like to tell/ask us? • Questions for caretakers: • Being a caretaker - What is the biggest hurdle in your everyday? • What is the most stressful activity that you must assist/help with? • How often are you there to help? • Have you experienced that they forgot any events lately? • Are the events minor (negligible) or are they of a more serious matter? (for instance forgetting to take their pills) • In which areas would there be an obvious need for improvement? (in what part do you see the most reoccurring problems) • Is there anything you would like to tell/ask us? • When did the MCI start? And how fast is it developing?

APPENDIX III: 5 CONCEPTS Concept 1 - Smart jewelry • Hide the electronics: form as a bracelet/ necklace • sensors situated in the house, used for notifications • controlled by an application by the caregivers or physicians • voice controlled actions “what day is it”, “where am I” • Customized to every user. Concept 2 - Smartwatch/smartband • Based on a smartwatch: assists user inside and outside home. • Tracking of location, voice calls from the watch. • Save frequent locations in terms of easier finding them later on • Relocate the patient if lost • Monitor heart rate and health condition remotely. Let the watch band stay on the arm and just take the watch of to recharge. Use the timeline on the watch to get a visual overview of the recent at activities. Use a camera to make a time-lapse photos/video that can be shown on the watch when pushing a button to recapture what you have experienced during the day.

• Features face recognition and can tell the names of relatives. • Timeline to view previous events. • Auditory feedback from connected smartwatch and smartphone. • NFC tags inside the house for predetermined actions (“call son”) Concept 4 - A mobile launcher for MCI-patients • Mobile Android launcher (elderly friendly interface) • The watch is a natural extension of the phone and draws attention to activities. Concept 5 - The physical smart calendar • A large calendar on the wall allows smart planning of 1 month. • Use nfc tags to move appointments from calendar to Smartwatch (no phone) • Make a call directly from the watch using physical nfc phonebook.

Concept 3- Augmented reality glasses • The user wears smart glasses all the time, and receives relevant guidance on top of normal vision.