1 Introduction

A smartphone is a device that not only offers telephony capabilities but also provides advanced functions and services that commonly require a touchscreen and progressive computing capabilities usually provided by sophisticated mobile operating systems (OSs) [1]. Smartphones can be used for essential functions (e.g. voice and text communication) and advanced functions (e.g. Internet surfing and taking photographs).

To interact with smartphones, the user interface (UI) is the way through which users can do various functions. Nevertheless, the UI is considered as a crucial challenge for designing mobile applications for elderly users [2]. According to the United Nations, the elderly are those persons aged 60 years and above [3]. The recent increment of the numbers of the elderly as well as of smartphones shipments, as indicated by [4, 5], boosts the necessity of considering the needs of the elderly when designing smartphones for seniors.

Despite the necessity for smartphones to be designed to better accommodate the elderly, the currently available smartphone UIs are complicated [6]; they have not been optimised for the elderly [7,8,9]. Instead, smartphone UIs address the young and tech savvy [10, 11], whose attributes and requirements are varying from those of elderly users. Hence, usability concerns may arise when the elderly are interacting with smartphone UI. Usability is defined as a ‘quality attribute that assesses how easy UIs are to use’ [12]. Interacting with touchscreen devices and applications poses several challenges for elderly users, including usability problems that result in anxiety and frustration [13,14,15,16,17,18]. The effect of failure to design usable interfaces to the elderly may lead to reluctance to the use of smartphones [7, 9, 19]. Designing user-friendly interfaces for the elderly can tackle this reluctance [7, 8, 20].

The main objective of this study is to present a design framework for fabricating smartphones with usable UIs for elderly users. The framework development process, derived from the process outlined in [21], was composed of the following four phases: (1) identifying source data, (2) concepts identifications and data categorisation, (3) deciding the framework structure and (4) framework validation. The developed framework presents a procedure that organises the smartphone UI design process into six sequential stages; each stage has a predefined objective. These stages are: (1) divide UI into three sections, (2) draw a sketch to present UI information, (3) specify the appearance of each UI element and overall UI, (4) articulate language related to each UI element, (5) associate appropriate gesture to its relevant UI element and (6) set adequate feedback for the potential user’s actions and system responses.

This paper is organised as follows. Section 2 reviews the usability concepts and measurements. This section also highlights the usability of smartphones UIs for the elderly and approaches to design a UI that can be easily used by older users. We also provide a review of the smartphone design guidelines and emphasise those guidelines that target the elderly. Section 3 describes the proposed framework along with the prototype and validation process. In Sect. 4, we state our results, and in Sect. 5, we discuss the effects of the UI design. Finally, our conclusions are presented in Sect. 6.

2 Related work

2.1 Usability: concepts and measurements

Usability is considered a crucial requirement for new product designs, highly important to individuals when choosing a product [22,23,24]. Usability is defined in various ways in the existing body of the literature. Among the various definitions of usability are the ISO standard 9241–11 [25], Bevan [26], Nielsen [12] and Lewis [27]. ISO 9241–11 [25] defines usability as the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use. Bevan [26] defines usability as the extent to which a user can easily interact with a software product, and it measures how easily such a product can be operated, learned and memorised. Nielsen [12] states usability as a quality attribute that assesses how easy UIs are to use. Although there are many definitions for usability, Lewis [27] states that it should be possible to make an appropriate distinction between formative and summative usability, the two major concepts of usability. The following paragraph demonstrates the formative and summative usability concepts based on Lewis’s definition [27].

The focus of formative usability is the detection of usability problems and the design of interventions to reduce or eliminate their impact (diagnostic usability). The main concern of formative methods is the qualitative observations of what occurred during the evaluation process and the reasons behind why something went wrong [28, 29]. Typical examples of usability methods, which are used for formative evaluation, are heuristic evaluation (HE) and cognitive walkthrough (CW). Both methods include experts inspecting the human–computer interface and predicting problems users might have when interacting with it [30]. On the other hand, the focus of summative usability is on metrics associated with meeting global task and product goals (measurement-based usability). Following the summative concept [27], a product is usable when people can use it for its intended purpose effectively, efficiently and with a feeling of satisfaction. More in detail, effectiveness is defined as the accuracy and completeness with which the user achieves specified goals. Efficiency refers to the amount of resources expended in relation to the product’s effectiveness. Satisfaction is related to the experience that the user can complete his/her tasks without discomfort and feeling positive about using the product. According to the summative concept, usability data include subjective and objective measurements [10]. Subjective measurements are concerned with the aspect of satisfaction, while objective measurements are concerned with the aspects of users’ performance indicated by effectiveness and efficiency. Subjective data are normally collected through questionnaires filled in by the participants [10, 31], whereas objective data are commonly collected by using usability experiments [31].

Research in human–computer interaction (HCI) requires a proper experimental design. An experimental design involves deciding and defining the variables to be used. MacKenzie [32] states that independent and dependent variables are essential for experimental research. These two variables are described as follows [32].

An independent variable is also called a factor. The variable is ‘independent’ in that it is independent of the participant’s behaviour; that is, there is nothing a participant can do to affect an independent variable. An independent variable is a circumstance or a characteristic that is manipulated or systematically controlled to bring about changes in human response when a participant interacts with a system. This variable is manipulated across multiple (at least two) levels of the circumstances or characteristics. In HCI research studies, the concept of ‘manipulating’ refers to systematically giving one UI, followed by another, to participant as part of the experimental procedure. Examples of independent variables in HCI include display size (with levels large and small), feedback modality (with levels auditory and visual) and tree visualisation (with levels traditional, list, and multi-column). The levels of an independent variable are often called test conditions.

A dependent variable measures human behaviour. The variable is ‘dependent’ in that it depends on the human (person); that is, the measurements depend on the participant’s responses. For example, if the dependent variable is the task completion time, then the measurements are very much dependent on the participant’s behaviour. In HCI, the common dependent variables are speed and accuracy. Speed is often reported as the metric of task completion time, whereas accuracy is often reported as the percentage of trials or other actions that are performed correctly (e.g. the task completion rate) or performed incorrectly (e.g. the error rate).

2.2 Smartphone user interface usability for elderly users

The smartphone UIs that are currently available in the market are complicated [6]; they are not optimised for elderly users [7,8,9]. Generally, interacting with touchscreens presents several challenges for the elderly, including usability problems that result in anxiety and frustration [13,14,15,16,17,18]. The concept of a usability problem can be defined as a set of negative phenomena, like user’s inability to reach a goal, inefficient interaction and/or dissatisfaction, caused by a combination of factors that include poor UI design [33]. In the domain of mobile phone technology, elderly users encounter numerous difficulties when interacting with the smartphone UI [4, 34]. Such difficulties often lead to uncompleted tasks and user frustrations, meaning that current smartphone UIs designs are violating usability and triggering usability problems for the elderly. The low acceptance levels of smartphones among older populations are because of their poor UI designs that are unsuitable for the elderly [7].

Kalimullah, Sushmitha [8] stated that the preferences of older persons about UI designs are often neglected, a situation which makes it difficult for them to use mobile applications. Petrovčič et al. [9] stated that we require more research-based development of smartphones, which considers the recommendations of age-friendly UI designs. However, [8] and [9] did not provide a detailed diagnosis of usability issues that elderly users could suffer from while interacting with the smartphone UI. On the contrary, in another study aiming to explore the usability dimensions of the mobile phone design for elderly users, Petrovčič et al. [19] presented the key findings from several studies related to the most important interaction elements addressed in the research on smartphones involving the elderly. The study categorised the interaction elements into feedback, target size and position, and gestures. The elements regarding gestures indicate four main problems the elderly users could experience. These problems are attributed to the difficulty that the elderly have in recognising when a button or target is tapped, which often leads to long taps and pressing incorrect buttons. Thereby, the difficulty is caused by the limitations in the UI design that does not afford enough system feedback (e.g. visual/audio), to update the elderly user about the consequences of his/her action. Similarly, there are issues related to difficulties in identifying tappable areas and additional time needed to comprehend the movements required for gestures. A UI is not backed by design that: (1) makes the tappable areas recognisable from those are untappable and (2) provides instructions (either presented as text or visual cues) to inform the elderly users on how to perform various smartphone gestures.

As stated by Balata et al. [7], there are two main approaches to tackling the mobile phones’ UI usability problems faced by the elderly. The first approach is to design a ‘senior’ phone dedicated for older users; this phone would be equipped with hardware buttons, a simplified UI and a reduced set of features. The second approach involves designing a user-friendly UI for elderly users which can be used for smartphones that are currently available in the market. The first approach is not recommended because older persons mostly do not want to use phones with limited features [7]. The second approach is a common and accepted approach [7]. This approach was adopted by researchers, such as Tsai et al. [35], who designed a social application specifically for older persons; they investigated how the UI design affects older people’s intentions and attitudes related to using social networking sites. Various researches advocated that the second approach can tackle reluctance to the use of smartphones by the elderly [8, 20]. To put the second approach into practice, guidelines have been suggested for designing a smartphone UI that accommodates the elderly users [19]. In this study, we focus on the second approach.

2.3 Smartphone user interface design guidelines targeting elderly users

The Android developers’ site provides a developers’ guide that consists of documents that help to show designers and developers on how to build Android applications using application programme interfaces in the Android framework and other libraries. Among the provided documents are those related to the UI and navigation that present documentation related to the layout, look and feel, notifications, search and so on. However, these documentations suggest material designs that were identified to be problematic for the elderly. For example, under the look-and-feel documentation, a suggestion made was to ‘Promote your UI’s main action with a Floating Action Button (FAB)’. Using the FAB to add contacts (see Fig. 1a) was not obvious to the elderly participants in the previous usability evaluation study [36]. The participants were not able to understand the button’s function. Similarly, under notifications, the documentations specified that the received notifications should appear to the users as an icon in the status bar, as a more detailed entry in the notification drawer and as a badge on the application’s icon. Again, all these locations and formats of the received notifications were identified as problematic for the elderly participants [36]. In one instance, the notification for missed calls was not distinguishable on the status bar (see Fig. 1b); therefore, the elderly participants could not determine whether or not they had missed a call.

Fig. 1
figure 1

UIs showing: a creation of a contact using FAB; b notification of a missed call in the status bar

Full size image

Nevertheless, when designing smartphones for older persons, it is important to use guidelines that are specifically targeting the elderly. Design guidelines are recommendations that can inform the development of interactive software systems [13]. This section reviews sets of design guidelines for designing smartphone UIs for elderly users.

The collection of guidelines was performed through following the search approach defined by Moher et al. [37]. The search approach consisted of four phases: (1) identification phase, (2) screening phase, (3) eligibility phase and (4) included phase.

In the identification phase, the search involved various databases. Search queries were made using Google Scholar, IEEE Explore, SpringerLink, ACM Digital Library, Web of Science, Science Direct and Taylor and Francis. A broader search was performed on the SCOPUS database, so as to cover the relevant literature from works not presented in the aforementioned databases. For each database, the titles and abstracts were investigated for each article. The searched key terms were related to the following topics: ‘elderly’ (elders, older adults, seniors, ageing, aging), ‘mobile phones’ (mobiles, smartphones, mobile applications, touch-based, touch devices) and ‘design guidelines’ (guidelines, recommendations, suggestions, principles, solutions).

In the screening phase, each of the identified articles that could contain relevant content was assessed to a deeper level. The authors screened the content of each article and tagged it with either ‘Yes’ or ‘No’, where ‘Yes’ indicated that the identified article met the inclusion criteria and ‘No’ indicated that the article did not comply with the inclusion criteria. The inclusion criteria were defined to be in line with the research area of this study. In further detail, inclusion criteria for articles were:

  1. 1.

    Presenting guidelines specific for smartphones or touch-based mobiles. In various studies, the term ‘touch-based mobile’ is used to refer to smartphones. Even the term ‘mobile’ in some studies is also used to refer to smartphones. Articles presenting guidelines for feature phones were excluded;

  2. 2.

    Targeting elderly users. Elderly users are those who fall in the age bracket of 60 years and above [3]. Articles presenting guidelines oriented for elderly people with disabilities were excluded. Disabled users, particularly the elderly, require specific design guidelines that cater to their needs and consider their impairments. Investigating the needs of elderly users with disabilities was beyond this study’s focus, and thereby, articles targeting them were excluded.

In the eligibility phase, from each article selected in the screening phase, the authors extracted the design guidelines and the related information (i.e. publication date, authors, source, article summary and method used to develop guidelines). We used Microsoft Excel Spreadsheets as a tool to store the records extracted from the selected articles in order to further analyse them in the following phase.

Finally, in the included phase, we conducted an in-depth analysis of the extracted design guidelines (and their related information) to fully investigate the guidelines and to identify and examine their potential gaps. To perform the analysis, we utilised the records gathered in the Microsoft Excel Spreadsheets prepared in the previous eligibility phase. In the next paragraph, sets of the extracted guidelines that pertain to the interface design of smartphones or touch-based mobiles targeting the elderly are highlighted.

Al-Razgan et al. [38] reviewed the literature on the use of mobile phones among elderly people. After consolidating and refining the literature, they presented certain design guidelines for touch-based mobile phones for the elderly. The design recommendations and guiding principles were categorised as: (1) look and feel, (2) functionality and (3) interface. Díaz-Bossini, Moreno [39] reviewed the literature, best practices and guidelines that addressed the accessibility for older persons within the context of mobile phones. Their study provided a set of guidelines that were to be kept in mind for achieving accessibility in mobile interfaces for older people. Similarly, Loureiro, Rodrigues [4] presented a set of design guidelines and design recommendations distilled and extracted from the relevant works on the design of multi-touch interfaces for elderly people available in the literature. The results are a set of design guidelines, organised by 10 groups that include as an example target design, use of graphics and content layout design. In the same context, Claypoole et al. [40] synthesised the previous guidelines and research into nine guidelines for improving the interface of touchscreen devices (including smartphones) for elderly users. The guidelines include such considerations like gestures, sizes of UI element, complexity and feedback. Recently in 2019, Nurgalieva et al. [13] conducted a systematic literature review that analysed 52 relevant research articles. The review results in research-derived design guidelines for touchscreen applications targeting elderly users.

Regardless of their benefits, examining the reviewed sets of design guidelines identified three main gaps that limit their effective use. The identified gaps are:

  • Limitation in the guidelines’ development method. The reliability dimension was used to evaluate the quality of the methodology used to define design guidelines [13]. Reliability assessment is important because it can be an indicator of how likely a guideline is to support elderly users [13]. Reviewing the literature and then synthesising the guidelines into categories were the approach on which the reviewed guidelines were developed. This approach can be criticised because the literature mostly investigated the usability of devices other than smartphones designed for the elderly, i.e. web-based systems, feature phones or smartphones usability for generic users. UIs of web-based systems and feature phones have essential differences compared to that of smartphones, in addition to the differences between the characteristics of the elderly and other users’ groups. The aforementioned differences include (1) device size, (2) ergonomics and (3) user characteristics. Rather than depending on the literature as a source data to develop design guidelines, guidelines developed based on the findings of a robust usability evaluation for smartphone UI in supporting elderly users are still rare.

  • Lack of implementation procedure. Implementation procedure is a method to implement design guidelines to design UI. Lacking implementation procedure could make it challenging to use guidelines for designing a smartphone UI for the elderly. The significance of organising design guidelines and presenting them logically to enhance their effective use was early recognised by Zaphiris et al. [41]. Yet, there is still a little guidance on how to select and apply the available design guidelines [13].

  • Limited validation of the guidelines. Validation refers to applying the guidelines in the development of an application and later testing the application with the target users [13, 42,43,44]. Nurgalieva et al. [13] found out that guidelines were validated in only 15% of articles analysed in their study. This is a disappointing trend that raises awareness of the need for more experimental investigations to determine the trustworthiness and efficacy of existing design guidelines. Petrovčič et al. [19] stressed the need for future research that would empirically validate the design guidelines.

While design guidelines are recommendations to inform UI designers in the development of interactive systems, a more comprehensive tool that addresses the gaps of the current guidelines is needed. Accordingly, that tool should: (1) incorporate design guidelines developed based on the findings of a robust usability evaluation for smartphone UI in supporting the elderly, (2) provide an implementation procedure for the incorporated design guidelines and (3) experimentally validate the tool and its incorporated guidelines. Based on this conclusion, we have developed our proposed design framework.

3 Materials and methods

3.1 Framework description

The framework development process was derived from the process outlined in [21]. The framework development process was composed of four phases, as described in the following.

  1. 1.

    Identifying source data. The findings of usability evaluation for an Android-based smartphone UI in supporting elderly users, conducted in the previous evaluation study [36], formed the source data to develop the framework and decide its structure (as it will be further demonstrated in the following phases). The usability of the Android-based smartphone UI was evaluated using a heuristic evaluation technique, complemented by user testing with elderly participants. As a result of the usability evaluation, there were 32 usability problems identified on the Android’s UI.

  2. 2.

    Data categorisation. The overall usability problems, identified through usability evaluation of Android smartphone UI, were classified into categories. The detailed classification procedure was elaborated in the study [36]. The following description provides a recap of the classification procedure. The classification considered the usability defects presented by ISO/IEC 25,066 [45] as the basis to define the usability problem categories (i.e. information, appearance, language, dialogue). The usability problems categories were further analysed and classified into subcategories and design guidelines were devised for each subcategory by the experts involved in heuristic evaluation (conducted in identifying source data phase).

  3. 3.

    Deciding the framework structure. To decide the framework structure, a focus group was conducted with six user interface/user experience designers who have relative experience in planning and implementing UI design process of various mobile applications developed for diverse groups of end-users that include the elderly. Based on their experience, designers participating in the focus group, decided on the framework structure that has six stages. Figure 2 presents the graphical illustration of the framework that consists of six stages. The designers selected a framework structure that in each stage considered a set of usability problems categories/subcategories and their corresponding design guidelines (categories/subcategories and guidelines were defined in the data categorisation phase). In more detail, Table 1 shows that each stage has two dimensions: (1) the usability problem categories/subcategories to be avoided and (2) the corresponding design guidelines to be implemented. The designers defined these two dimensions as: (1) the problems dimension and (2) the guidelines dimension. This structure would support the understanding of the usability problems that hinder the elderly. Meanwhile, the design guidelines would provide insights into potential design improvements for each category/subcategories of the usability problems.

  4. 4.

    Framework validation. The validation refers to applying the framework and its incorporated design guidelines in the development of smartphone UIs and following testing the UIs with the elderly users [13, 42, 43]. Hence, we developed a framework-based prototype and experimentally compared the usability of the prototype’s UI design with that of an Android smartphone UI (i.e. comparative usability experiment). The framework validation is demonstrated in Sect. 3.3.

Fig. 2
figure 2

Design framework for a smartphone user interface for elderly users

Full size image
Table 1 Framework stages
Full size table

In Stage 1, the UI is divided into three sections: A, B and C. Each section hosts a certain sort of information. Information related to each section is identified based on the definition of that section. The definitions are as follows:

  • Section A (Memo). This occupies the upper part of the UI. This section hosts the status bar and the notifications reminder strip in the lock screen and home screen interfaces (Fig. 3a), respectively. For the remaining screens (e.g. contacts), Section A only shows the reminder strip and omits the status bar to provide a larger area for the Section B information (see the top arrow, Fig. 3b). The notifications reminder strip is a dynamic function that shows the missed calls for 4 s (Fig. 3a). Then, this strip shows the received unread messages for 4 s (see the top arrow, Fig. 3b) and then the system alert for 4 s (e.g. low battery charging). The missed calls or unread messages shown on the reminder strip are received either through a SIM card or by installed applications, such as WhatsApp. With special applications, such as the camera (Fig. 4) and alarm (Fig. 3c), this section is eliminated to prevent interference with the functions and the information of the applications.

  • Section B (Essential Content). This occupies the middle part of the UI. This section hosts the main body of information that should be conveyed to the user; it includes all the necessary functions related to the presented information. For example, in the Contacts List screen (see the middle arrow, Fig. 3b), the contact information (i.e. the name, profile picture and contact number) is accompanied by the functions related to each contact (e.g. call, message and edit). A search function is also provided with a proper placeholder.

  • Section C (Navigation and Essential Functions). This occupies the lowest part of the UI. This section hosts either the tabs required to navigate among the various screens (see the bottom arrow, Fig. 3b) or the essential functions related to the active screen (Fig. 3c). Section C could also host a mix of tabs and functions. Deciding on the role of this section, that is, whether it is to be used for navigation or providing functions, depends on its context.

Fig. 3
figure 3

Screen images of the prototype UI sections

Full size image
Fig. 4
figure 4

Applying the framework to design a camera application UI

Full size image

The objective of Stage 2 is to draw a sketch to present the UI information as a low-fidelity design that considers the definitions of the three UI sections, as defined in Stage 1. A sketch is a freehand drawing using symbols to capture the essence of the targeted UI elements and the overall UI design. The sketch is drawn to provide a UI design that (1) avoids the usability problems subcategories related to the information category and (2) implements their corresponding design guidelines. The usability problems of appearance, language and dialogue categories/subcategories were also considered in Stages 3, 4, 5 and 6, respectively, along with their corresponding guidelines. The objective of Stage 3 is to specify the appearance by using icons, colours, sizes and positions of each UI element and the overall UI design. The objective of Stage 4 is to articulate the language in relationship with each UI element (icons labels, terms and expressions). The objective of Stage 5 is to associate the appropriate gestures with the relevant UI elements. Finally, in Stage 6, adequate feedback is specified for each potential user action.

Based on the framework, we developed a prototype and experimentally compared the usability of the prototype’s UI design with that of an Android smartphone UI (comparative usability experiment). A framework-based prototype was used for the validation purpose to check whether the UI usability of the prototype is improved in comparison to that of Android UI with respect to the elderly users. Section 3.2 demonstrates the framework-based prototype UI design, and Sect. 3.3 demonstrates the validation procedure.

3.2 Prototype description

The UIs of the framework-based prototype were designed by applying the framework stages. Section 3.2.1 represents a framework implementation example to design camera application. Section 3.2.2 demonstrates the design of the overall prototype UIs. The Justinmind software was the prototyping tool used to create the UIs of the framework-based prototype.

3.2.1 Framework implementation example

As an implementation example, Fig. 4 illustrates the implementation of the framework stages to design the camera application UI. The following explanation further elaborates the sequences in Fig. 4.

  • Stage 1: The UI was divided into the two sections B and C. Section A was eliminated to prevent any potential interference with the application functions that could distract the users (according to Section A definition, See Table 1).

  • Stage 2: The UI information was sketched to capture the essence of the target UI design. The three design guidelines were implemented for the camera UIs to address screen overloading because of unwanted information. The camera applications had only two UIs. In the first UI (representing the home/main screen of the camera application), Section B hosted the information that gave users the control to specify the basic camera application settings by using two radio button groups (see arrow #1, Fig. 4). The first radio button group set the function to either take photographs or record videos. The second radio button group used either the rear or the front camera. Information other than that about the setting functions was moved to the subsequent UI because the design guideline suggested placing the most important information in the front, that is, in the first UI (home screen of the app). The camera function was grouped into two groups of radio buttons because the design guideline suggested grouping the related information. Radio buttons were used for exclusive selection in a list with two or more options (i.e. take photograph vs record video and use rear vs use front camera) when all list options need to be visible to users simultaneously. The first UI was minimised to present the information related to the basic camera functions, and further information was avoided. This was done in the light of the design guideline that suggested preventing or minimising unwanted information on the screen. Section C of the first UI did not have any information because the required navigation tabs were provided by using two physical buttons on the smartphone: ‘Home’ to navigate to the home screen and ‘Back’ to navigate to the previous screen. In the second UI, section B showed the scenes captured by the camera (see arrow #2, Fig. 4). Section C contained the following: (1) the navigation control tab ‘Go to gallery’ and (2) two essential function buttons, namely, ‘Capture’ to take pictures (or ‘record videos’ when the record video option was selected in the first UI) and ‘modify settings’ to change the settings (see arrow #3, Fig. 4). Similarly, the information about the second UI was drawn in the light of the design guidelines for the problems subcategory ‘Overloading the screen with unwanted information’. Accordingly, the related information was grouped (the setting options were grouped under one function, that is, modify settings) and unwanted information was avoided (the information in the second UI was within the scope of performing the required functions and navigation).

In the light of the design guidelines to address the absence of tooltips and instructions, the two radio button groups in the first UI were accompanied by permanent instructions to demonstrate the purpose of the radio buttons, for example, ‘Use front or rear camera’ (see the arrow #4, Fig. 4). A tip was also included to demonstrate how to use the button, ‘Tap on the preferred option’ (see arrow #5, Fig. 4). The first UI was supplemented by a step indicator as a visual cue; it was employed to differentiate the set of each buttons’ group as an individual step (see arrow #6, Fig. 4). The second UI was drawn using an identical procedure. The instructions and tips language were articulated in Stage 4.

Both UIs did not have any hidden content, such as performing a swipe-down to reload the webpage in the ‘Google Chrome’ browser. In case any notifications or alerts were received or initiated, the notifications or alerts would be assembled and organised in the notification control widget provided in the prototype home screen.

  • Stage 3: The appearance of the UI elements and the overall design of the two UIs were specified based on Stage 3 design guidelines that addressed the related three problem subcategories. The UI elements in both UIs, including the buttons, the visual cues and instructions, were presented using distinguishable colours and noticeable sizes; we also ensured that there was adequate contrast between the elements and the screen background (see Stage 3, Fig. 4). In the first UI, the UI elements were placed in the centre of the screen. In the second UI, a user could reach the buttons by using the thumb. The design made the tappable buttons recognisable from the untappable buttons. For example, both groups of radio buttons were presented in blue colour and were supplemented by providing textual tips to guide users to tap the preferred option (see the arrow #7, Fig. 4). The overall UI elements had consistent designs in the UIs; for example, the buttons were always presented in blue colour. Uncommon or drastically new designs were avoided in the UIs of the first and second screens.

  • Stage 4: The button labels, expressions and instructions were articulated by employing a vocabulary that was familiar to the elderly and by avoiding the use of ambiguous concepts. Accordingly, the button labels in the first and second UIs, for example, ‘Go to gallery’ in the second UI (see arrow #8, Fig. 4) used a language that conveyed the corresponding button’s function to the user. The use of system-oriented concepts and abbreviations was avoided for labelling the UI elements. The terms applied for labelling the UI elements were unique, that is, dissimilar terms were used for labelling the UI elements that performed contrasting functions.

  • Stage 5: A tap gesture was adopted to activate each tappable UI element, and the use of tricky gestures (‘drag and drop’, and ‘tap and hold’) was avoided. The definition of the recommended gesture (i.e. tap) and tricky gestures was in light of the findings of [10, 46] as well as our previous study [36].

  • Stage 6: To address the problem of the lack of confirmation messages for major actions, our proposed design provided a confirmation message that popped up after the user tapped on the ‘physical’ back button. The role of the message was (1) to indicate to the user that tapping on the back button would quit the user from the camera application and (2) to give the user the control to either approve the action or cancel it. Immediate consistent and mixed-mode feedback were provided in response to the user actions. For example, in the second UI (see arrow #9, Fig. 4), whenever the user tapped on the capture button, its colour immediately changed to red. Stage 6 was concluded by testing the camera app to ensure that it was functioning and supported by proper feedback.

3.2.2 Prototype user interface design

Each of the prototype UIs, presented in Fig. 5, was designed following a gradual design process identical to that of designing camera app UI (demonstrated in Sect. 3.2.1). In this subsection, we describe the final design of the UIs of the framework-based prototype concerning the comparative usability experiment. In the comparative experiment, the elderly participants performed a set of experimental tasks using Android smartphone and the prototype while their performance and satisfaction were measured. The experimental tasks are described in Sect. 3.3 (Table 2).

Fig. 5
figure 5

Screen images of the prototype UIs

Full size image
Table 2 Experimental tasks
Full size table

In Task 1 (call a contact), the contacts screen for the prototype was designed to provide recognisable buttons for the frequently used functions associated with each contact. As indicated by the top arrow in Fig. 5a, the functions for a call, message, edit, share and delete were provided beside each contact.

Task 2 (create a new contact), a ‘Create a contact’ function was provided for the user using a blue button with a text label that conveyed the button function. The ‘Create contact’ (see bottom arrow in Fig. 5a) button was located in the ‘Navigation and Essential Functions’ section. When the user taps the ‘Create contact’ button, a new screen appears (see Fig. 5b). Then, the user can add the contact details guided by the step indicators (see left arrow in Fig. 5b) and the placeholders to fill the associated input fields (see right arrow in Fig. 5b).

In Task 3, the participants were asked to send a message to a certain contact. A button labelled ‘Write a message’ was located in the ‘Navigation and Essential Functions’ section to provide a function for sending a new message. The UI design was supported with instructions that guided the user until the task of sending the message was accomplished by tapping on the ‘Send’ button.

Task 4 involved connecting to the Internet using a Wi-Fi network. Internet settings were provided as an option under the general settings screen, which included other setting options, such as the language and input settings. After tapping on ‘Internet settings’, a new screen supported by an explanation gives the user control to connect to the Internet using the preferred option (see Fig. 5c). The UI of the prototype was designed to provide an Internet setting function that grouped the connection into two Internet options: mobile data and Wi-Fi. After the user tapped on the ‘Connect to a Wi-Fi network’, the following UI would give users the control to choose among the available networks.

Task 5 was related to detecting the received notifications (missed calls and unread messages). The UI of the prototype provides a ‘dynamic notification reminder strip’ at the top of the screen (see top arrow in Fig. 5d). The role of this strip was to display the notifications that could be important to the user (e.g. missed calls and unread messages received through the various applications). This strip would also show critical system alerts such as the low battery charge alert. The reminder shows each notification for 4 s before switching to the next notification. The dynamic notifications reminder strip was highlighted in bright yellow to help capture the attention of the participants. The task of the participants was to recognise any missed calls and/or unread messages and identify the callers and the message senders. To respond to the notifications, the home screen of the prototype provides a notification control widget (see bottom arrow in Fig. 5d) that collects the notifications and organises them based on their categories such as calls, messages, applications and alerts. As shown by the top arrow in Fig. 5e, the calls notifications screen consists of: (1) the contact’s details (i.e. picture and name), (2) the call details (i.e. time and the application used to receive the call (see via WhatsApp in Fig. 5 (e)) and (3) the quick response buttons (i.e. call back or hide notification). The navigation section provides four buttons that serve as tabs to navigate between the various notification categories (see bottom arrows in Fig. 5e). Nevertheless, responding to the notifications was not part of Task 5.

Task 6 involves providing feedback to the user about camera usage. The smartphone camera has two screens. The first screen (see Fig. 5f) displays two direct questions to guide the user to ‘take photographs or record videos’ and ‘use the front or rear camera’. In the second screen (Fig. 5g), the buttons are provided in the ‘Navigation and Essential Functions’ section to capture pictures/record videos, modify settings and to go to the gallery. For recording videos, as soon as the user taps on ‘Record video’, immediate feedback is provided informing the user that the recording process has begun.

Finally, Task 7 investigated the ability of the participants to discover the hidden contents on the UI. The hidden content in this task was a swipe-down gesture to reload the web page. This gesture was used in various applications, such as Gmail. The Android smartphone UI lacks indicators, such as visual cues, to guide users through the reload task. The prototype UI provides a flashing bright yellow down arrow supported by a textual instruction that informs the user to swipe downward to reload the web page (Fig. 5h). The arrow with the instruction is automatically hidden after flashing for 9 s or when the user performs the swipe-down gesture.

3.3 Framework validation

Validation refers to applying the proposed framework and its embedded design guidelines, in the development of the framework-based prototype and later testing the prototype UI with the elderly users [13, 42,43,44]. In further detail, the framework validation approach comprised the conduction of a comparative usability experiment between the design of the Android smartphone UI and that of the framework-based prototype. The comparative experiment is a measurement-based usability study, in which we considered the summative concept of usability based on the measurements of effectiveness, efficiency and satisfaction of the elderly participants. The elderly participants were given tasks to perform on the Android smartphone and prototype, and their performances (indicated by effectiveness and efficiency) and satisfaction were measured and compared. A higher level of performance and satisfaction by the elderly participants would indicate a more usable UI design.

MacKenzie [32] stated two objectives in designing good tasks: (1) represent and (2) discriminate. A good task is representative of the activities, similar to actual or expected usage, people do with the UI. In this study, the experimental tasks were defined based on the findings of [6, 7, 47, 48], which identified the frequent tasks among the elderly. A good task is also one that can discriminate against the test conditions. The test conditions in this study are the UI of Android smartphone and the prototype. The experimental tasks were designed to attune to the points of differentiation to elicit behavioural responses that expose benefits/problems between the test conditions. We specified the tasks to examine the effect of the UI design on the participants’ performances and their satisfaction levels by using the Android smartphone UI and the prototype. Table 2 presents the experimental tasks. Lastly, the comparison with Android-based smartphones was decided as Android smartphones are more widely used than iOS- and Windows-based smartphones by the elderly [49] and other users [50]. Various researches have made similar comparisons for UI designs presented in their studies using standard Android UIs [7, 47, 48].

3.3.1 Metrics

Following the summative concept of usability, our goal was to measure the metrics of effectiveness in terms of the task completion rate, the efficiency in terms of the task completion time and the participants’ satisfaction levels based on the After-Scenario Questionnaire (ASQ). The task completion rate was calculated by multiplying by 100 the result obtained by dividing the number of participants who successfully completed the task by the number who attempted the task [51, 52]. The task completion time was measured in seconds, and it referred to the time required to successfully complete the task [53]. Regarding the subjective measurements, the participants were asked to respond to a questionnaire to rate their satisfaction levels for performing tasks using the Android smartphone UI and the prototype UI. ASQ consisted of two questions defined by Lewis [54]. Question 1 investigated participants’ satisfaction with the ease of completing the tasks by using the artefacts, and Question 2 investigated the participants’ satisfaction with the time taken to complete the tasks using the artefacts. The artefact here refers to either the Android smartphone or the prototype. The participants rated their satisfaction levels for the artefacts on a 7-point Likert scale (1 = Strongly disagree, 7 = Strongly agree).

The obtained results were analysed using appropriate statistical tests for the significant differences between the design of the Android smartphone UI and that of the prototype in terms of the participants’ performance level (measured by task completion rate and task completion time) and satisfaction (measured by ASQ).

3.3.2 Experimental design and data analysis

Our experiment was a within-subject repeated measures design. A within-subject design is a type of experimental design in which all participants are exposed to every test condition of the independent variable [32]. The test conditions in this research were the UI of Android and that of the prototype. The dependent variables were the task completion rate, task completion time and the subjective preference of the participants (rating of satisfaction level measured by ASQ).

The obtained datasets of task completion rate and subjective participants preferences (rating) were analysed by paired samples t-test using SPSS as a statistical tool. The obtained dataset of task completion time was analysed by analysis of variance (ANOVA) using the GoStats statistical tool. Two statistical professionals were consulted to decide and subsequently perform the tests to analyse each of the three metrics dataset.

The outcome of the paired samples t-test and ANOVA indicated whether there were significant differences between the design of Android smartphone UI versus that of the prototype in terms of the level of performance and satisfaction of the participants. It is a convention in experimental research that significance, in a statistical sense, requires a value of p that is less than 0.05 [32]. When the result is statistically significant, the conclusion in such case is that [32] (a) there is a difference in the means, (b) the difference is statistically significant, and (c) the difference is caused by distinguishable properties in the test conditions (UI of Android and prototype).

3.3.3 Participants

MacKenzie [32] gave two conditions that were essential to apply the experiential results to people other than those who were tested: (1) the participants should be members of the population and (2) a sufficient number of participants should be tested. Accordingly, 12 elderly users (a valid size for a comparative usability study [32, 47, 55]) were participated in this experiment.

Measured by chronological age, the elderly participants, eligible to participate in the experiment, were those who fall in the age bracket of 60 years and above. This age threshold was according to the United Nations report [3]. Additionally, elderly people with disabilities (i.e. with a mental or physical impairment that extraordinarily limits one or more major life activities [56]) were indicated as not eligible to participate in the experiment. Disabled elderly users require a specific smartphone UI design that caters to their needs and considers their impairments. Investigating the needs of disabled elderly, as smartphone users, was beyond the focus of this experiment.

The elderly participants were directly recruited either by approaching them in public settings or using of social networks. The sampling technique that we used to recruit the participants was the ‘judgement sampling’. In judgement sampling, researchers may specifically approach participants with certain characteristics that suit the research focus [57]. Hence, the recruited participants were aged 60 years and above (average age = 64.5 year). Also, none of the elderly participants had any cognitive, motor, visual or hearing impairments.

With regard to their demographic data, the elderly participants were males and females, and they had different levels of education. Five of the participants were females, and the rest were males. As for their educational background, three of the participants had not completed their schooling, five participants had some college/high school credits, and four participants were college graduates or held a postgraduate degree. All of the participants were capable of using smartphones with English language displays.

3.3.4 Procedure

The comparative usability experiment was conducted in the usability testing laboratory, Computer and Information Sciences Department, Universiti Teknologi PETRONAS. We briefed the participants about the purpose of the study and collected their demographic data. We also obtained verbal consent (approval) from the participants who were eligible to participate in the experiment. Before performing the experiments, we prepared the participants by giving them two minutes to freely explore the Android smartphone. The Android-based apparatus used in this experiment was a Samsung Galaxy J7 (hereinafter J7), with a 5.5-inch Super AMOLED capacitive touchscreen with a resolution of 720 × 1280 pixels. All the participants affirmed their familiarity with the UI of the Android-based device chosen for the experiment. Two minutes was given to participants to explore the prototype. The prototype was installed on the J7 using the Justinmind app, which is a prototype viewer for the Justinmind prototypes. Through the Justinmind application, the prototypes could be experienced directly in full screen on a smartphone. The reason for choosing J7 to run the prototype during the usability testing was to avoid any potential differences in the performance of the participants because of the physical characteristics of the apparatus, such as the screen size, the resolution and the device weight. A trial task was given to each participant, and we instructed the participant on how to perform the task using the artefacts (Android and prototype). The trial task was to unlock the screen using a password. This task was set differently from the experimental tasks to avoid any potential learning effect. We informed the participant that there was no time limit for the tasks, and the decision about when to give up a task was solely one’s own decision.

The comparative usability experiment was initiated when the participants attempted the seven experimental tasks using the artefacts. The usability of the design of the J7 UI (under its default settings and theme) was investigated in comparison with the usability of the prototype UI. The twelve participants were divided into two groups, where each group consisted of six participants. The first group was tested on the Android smartphone UI and then on the prototype UI, whereas the second group was tested in the reverse order. This ordering of test conditions (UI of Android and that of the prototype) was to offset the practice effect [32]. When test conditions are assigned within-subjects, as in this experiment, participants are tested with one test condition, then with another. Therefore, participants’ performance might be improved on the second test condition because participants benefited from practice on the first test condition.

Each participant had to attempt the seven experimental tasks using the Android UI and the prototype UI (7 tasks/interface). In total, each participant had to attempt 14 tasks using the two UIs. The tasks were randomly presented on each UI. The tasks were printed out and placed in front of the participants. Before a participant began conducting any task, the experimenter explained the task to the participant to ensure that the participant understood the purpose. The explanation did not include a description of the UI design of the artefacts; no hints were given about the task performance. The measurements of the participant’s performance (i.e. the task completion rate and task completion time) were recorded by the experimenter using a stopwatch. When the task was completed, we asked each participant to verbalise his or her thoughts regarding the tested UI, and the experimenter noted down this information. The participant rested for approximately 15 s, and we returned the UI to the home screen before the participant was given the next task. A questionnaire was administered after each participant completed the tasks using the Android smartphone. An identical questionnaire was administered after a participant completed the tasks using the prototype. For both UIs, the first six tasks in this experiment required only the application of a ‘tap’, which was the essential gesture required to operate a smartphone. Task 7 investigated the participant’s ability to discover the hidden contents on the UI. The hidden content, in this case, was the swipe-down gesture to reload a web page. The performance of gestures beyond the essential tap was outside the scope of this experiment. Thus, the measurement for Task 7 was limited to the task completion rate alone. During the experiment, the gestures and other factors, such as the lighting and temperature of the testing room, the seat height, the table height and the background noise, were kept constant.

4 Results

In this section, we state the participants’ performance regarding the task completion rate and task completion time. We also specify the participants’ satisfaction level, which we obtained through questionnaires (ASQ).

4.1 Task completion rate

Table 3 illustrates the task completion rates for the seven experimental tasks. For Tasks 2, 3, 5, 6 and 7, a higher task completion rate was recorded when the participants performed the tasks using the framework-based prototype; however, no such improvements could be recorded for Tasks 1 and 4, even though a slight improvement was achieved in Task 1.

Table 3 Task completion rate dataset
Full size table

Overall, the mean task completion rate using the prototype UI was 76.19%. This was higher than the mean of 40.46% recorded for the Android UI, as shown in Fig. 6. To compare the two means for a significant difference, a paired samples t-test was used to analyse the dataset given in Table 3. In this case, we concluded that the difference was statistically significant (p = 0.0122). Therefore, the improved performance of the participants was the result of the distinguishable properties of the prototype UI.

Fig. 6
figure 6

Mean task completion rate

Full size image

4.2 Task completion time

We documented the task completion times for tasks from 1 to 6 (i.e. T1–T6) to form the time dataset. Figure 7 illustrates the mean task completion time computed for each task. For all the tasks, the participants required less time to perform the tasks using the prototype.

Fig. 7
figure 7

Mean task completion time per task

Full size image

The time dataset was analysed by using the repeated measures ANOVA. Besides the main independent variable of this experiment (UI design), the tasks were treated as independent variables having six levels ranging from T1 to T6. We examined the effect of the UI design and the various tasks on the task completion time. The ANOVA revealed that the effect of the UI design on the task completion time was not statistically significant (p = 0.3446); however, the effect of the task on the task completion time was statistically significant (p < 0.0001).

4.3 Satisfaction evaluation

The satisfaction evaluation dataset consisted of the participants’ ratings for the ease of completing the tasks and the completion time using the UIs of the two artefacts (Android vs prototype). As shown in Fig. 8, we obtained a mean rating of 5.83 for the prototype and 3.17 for the Android smartphone for Question 1 (satisfaction with ease of completion). For Question 2 (satisfaction with completion time), we obtained a mean rating of 5.42 for the prototype and 3.25 for the Android smartphone. The ratings for both questions revealed the preference of the participants for the prototype UI.

Fig. 8
figure 8

Satisfaction evaluation

Full size image

The satisfaction evaluation dataset was analysed using a paired samples t-test to verify whether the differences in the ratings were real. From the responses to Question 1, it was clear that the UIs of the artefacts differed in terms of user satisfaction for the ease of completing the tasks (p = 0.000). From the responses to Question 2, it was clear that the UIs of the artefacts differed in terms of the participants’ satisfaction with the time taken to complete the tasks (p = 0.0002). Therefore, the higher participants’ satisfaction was the result of the distinguishable properties of the prototype UI.

5 Discussion

The experimental results showed that the UI design of the framework-based prototype outperformed that of its Android-based counterpart in most aspects in terms of the participants’ performance and satisfaction. A higher level of performance and satisfaction by the participants indicated a more usable product [27]. Besides the positive conclusion of the experimental results, the practical implementation of our design guidelines by other researchers/designers could provide another positive indication of the feasibility of the overall design framework in designing smartphone UIs for elderly users. In this context, our design guidelines (defined by our previous study [36] and embedded in the design framework developed in this study) were followed by Mauldin et al. [58] to design UIs of the SmartFall detection app for the elderly. SmartFall is an Android app that utilises accelerometer data gathered from a commodity-based smartwatch Internet of Things device to detect falls.

The following paragraphs discuss the obtained results concerning the task completion rate, task completion time and satisfaction, respectively.

Apart from Tasks 1 and 4, the participants showed an improvement in the task completion rate for Tasks 2, 3, 5 and 6 while using the framework-based prototype; there was an obvious improvement in the task completion rate for Task 7. These results are illustrated in Table 3. The comparative usability experiment also helped to reveal the limitations in the ability of the elderly participants concerning using Android smartphone to successfully perform tasks that were considered basic and essential. For instance, the task completion rate for creating contact (Task 2) and sending a message (Task 3) was 41.57% and 50%, respectively. One participant stated that when he wanted to create a new contact, he asked the intended person to give him a missed call. Then, using the missed call log, the participant could create and save the contact. Other participants mentioned that in daily life, they were only able to respond to the received messages; they could not initiate a conversation on their own. These notes were documented by the experimenter. While performing Task 2 and Task 3 using the framework-based prototype, the participants showed better performances, as shown in Table 3. Our results indicate that for Task 1, the participants had a slightly higher task completion rate. Meanwhile, for Task 4, no improvement was recorded in the task completion rate. In Task 1, the contacts screen of the prototype was designed to provide direct access to the visible frequent functions such as call (refer to Fig. 5a), whereas, in the Android smartphone, an extra step was required to expose these functions. Showing users the recognisable UI elements improved the usability as compared with when they had to recall the functions from scratch [59]. However, in the scenario for Task 1, no remarkable difference in the task completion rate was achieved (91.67% for the Android smartphone and 100% for the prototype). We took notes as the participants verbalised their thoughts; this helped to interpret some of the participants’ behaviours. Making calls is the most essential function of a phone; the participants could comprehend that tapping on the contact icon would give them access to the call function. The iterative daily usage of the function could explain the close task completion rates recorded for both the UIs. Task 4 involved connecting to the Internet using a Wi-Fi network. Table 3 shows that for Task 4, the use of the prototype UI did not achieve the desired improvements in the participants’ performances. The UIs of the prototype provided the Wi-Fi connection option as a function under the Internet settings screen (refer to Fig. 5c). The inability to easily discover the Wi-Fi hidden under the settings screen (as expressed by some of the participants and recorded by us) could explain the low task completion rate and the relatively long task completion time. According to Inostroza et al. [24], sensitive information should be placed in a visible spot in the UI to minimise the user’s memory load. In our future designs, to make up for the limited memory of the elderly [10], a ‘Connect to the Internet’ control widget will be added to the home screen of the prototype to make the widget easily discoverable by older users. Overall, the mean task completion rate for the prototype UI was higher than the mean recorded for the Android UI. The conclusion (supported by a paired samples t-test) was that the difference was statistically significant, that is, the participants’ performances improved because of the prototype UI’s distinguishable properties.

Regarding the task completion time, the participants showed an improvement in the task time for all tasks as shown in Fig. 7. However, the analysis of the time dataset using the repeated measures ANOVA revealed that the effect of the UI on the task completion time was not statistically significant. All the participants lacked adequate prior use experience with the prototype UI. As stated by Mayer [60], when novice users begin in a new domain (such as using the prototype in this study), they make some errors; therefore, they require time to solve these problems. However, making errors will not necessarily lead to task failure. We found that users were still able to successfully complete the task after some attempts, that is, the task completion rate was not affected. Nevertheless, an increase in the number of attempts would lead to an increased task completion time. When users developed expertise through experience, they became faster and more accurate (making fewer errors) [60]. For various information systems, after a period of system usage experience, the user performance would increase over time [61, 62]. In light of the findings of [60,61,62], after using the prototype UI for some time, an enhanced task completion time could be achieved because of the improved user accuracy. Finally, ANOVA revealed that the effect of the task on the task completion time was statistically significant. This could be attributed to the properties of the experimental tasks, which varied from a one-step task that required less time (e.g. Task 1) to a task that consisted of numerous steps that required more time (Task 2).

A questionnaire (ASQ) was used to measure the satisfaction level of the participants. A higher mean satisfaction rating for the prototype was obtained for Question 1 (Fig. 8). By applying a paired samples t-test, we concluded that the satisfaction on the two UIs was statistically different in terms of the ease of completing the tasks. This outcome was consistent with the significant difference in the mean task completion rate found between the UIs of the Android device and the prototype. Meanwhile, a higher mean satisfaction rating for the prototype was obtained for Question 2 (Fig. 8). The UIs for the two artefacts were statistically different in terms of user satisfaction with the time taken to complete the task; this was inconsistent with the non-statistically significant effect of the UI for the task completion time. This inconsistency could indicate the participants’ preference for the prototype’s UI with regard to the time required to perform the tasks, even when the effect of the UI on time was not statistically significant. After responding to the questionnaires, the participants stated that they were more impressed with the prototype’s UI design for reasons such as the better visibility of the UI elements, recognisable blue buttons, the use of simple terminologies and UI features such as the notification strip and step indicators.

6 Conclusions

The results obtained for this study have shown that the proposed design framework is an effective tool for fabricating smartphones with usable UI designs for elderly users. The study’s findings have certain implications as presented in the following.

  1. 1.

    Body of Knowledge. This study has contributed to the body of knowledge through the developed design framework. The framework has two dimensions: (1) usability problems categories/subcategories to be avoided and (2) the corresponding design guidelines to be implemented. A classification represents the usability problems categories and subcategories that capture the essence of the individual problems result in more meaningful problem clusters. Such clusters would improve the researchers as well as the designers’ knowledge of usability problems that hinder elderly users, thereby preventing future smartphone UI design from having these problems. The design guidelines would help to provide researchers with insights into possible design improvements for smartphone UIs.

  2. 2.

    Community of the elderly populace. The comparative usability experiment results showed that the UI of framework-based prototype outperformed that of its Android-based counterpart in terms of the participants’ performance and satisfaction. This higher level of performance and satisfaction indicated that the prototype UIs are easier to use and have a superior usability. This improvement in UI usability would make an impact on the elderly as it may: (1) reduce the reluctance to use smartphone among the elderly; (2) increase elderly productivity in using smartphones through allowing them to utilise the various functions with higher performance and satisfaction; and (3) make the elderly less dependent on seeking other people support by means of the required guidance to utilise smartphones and thereby be more independent.

  3. 3.

    Smartphone industry. Besides being used to validate the framework, the framework-based prototype illustrates the implementation of the framework stages to design various smartphone UIs. The prototype will be able to give factual insights to designers in the smartphone industry regarding how to adjust special purpose applications to serve elderly users. Among these applications are communication apps such as WhatsApp. The UIs for the ‘Contacts’ and ‘Messages’ of the prototype could help to provide a design for special communication apps dedicated to elderly users. Similarly, the prototype of the camera UI could form a base to design elderly camera application. Meanwhile, the dynamic notification reminder strip and notifications control widget provide a novel design to manage the various smartphone notifications and alerts.

A limitation of the current study is the lack of further development for the framework-based prototype UI considering the findings of the comparative usability study with Android smartphone UI. Because of the time constraints, a longitudinal study to further improve the prototype UI was not performed. A longitudinal study would involve redesigning the later version of the prototype UI to address the shortcomings identified in the current prototype UI design.

A future project that would transfer the framework-based prototype to a commercial fully functional launcher application is recommended. By analysing the feedback of elderly users with the launcher, after publishing the launcher application, further improvements will be implemented in a later release of the launcher UI. Another recommendation for future work is to use the framework by other researchers/designers to design smartphone UIs for the elderly. The feedback of researchers/designers would further verify the clarity and comprehensibility of the proposed framework and its embedded design guidelines.