Mobile User Interaction Design Patterns: A Systematic Mapping Study

Abstract

Interaction design patterns have evolved as a resource that facilitates documentation and the reuse of proven solutions. They provide a structured and understandable mechanism for what to do in the design. Mobile devices have characteristics, configurations, and restrictions that make the construction of their interfaces full of particularities to this environment, and problems that are often common to designers and developers. This study presented a systematic mapping of the state-of-the-art regarding interaction design patterns for mobile devices. A total of 23 studies that include articles and books met the selection criteria in this mapping, examining relevant scientific databases and books that were cited in relevant articles. As a main result, 336 patterns were compiled, with 261 of these problems and solutions being dissimilar from each other. The paper describes patterns in 18 categories covering different interaction aspects. Pattern structural elements with mentions in more than five papers included: Name, Solution, Problem, Context, Examples, Related Patterns, Forces, Consequences and Figure. Four studies reported empirical evaluation of the patterns with a limited number of users. The paper contributed with a categorization of existing patterns and the challenges for uniformization of structure and empirical evidence with user evaluation.

1. Introduction

In recent years, we have witnessed significant advances in wireless technology and the ubiquity of mobile devices with increasing processing, storage, and communication capabilities. This evolution of mobile computing has opened up new possibilities in the fields of communication, social interaction, and learning [1]. The increase in the number of mobile users and the variety of tasks possible through these devices has made it crucial to offer a harmonious experience of interacting with mobile interfaces.

Challenges remain frequent for developers, designers, and other professionals who work in building applications. When designing interfaces and interactions, it is necessary to consider issues such as requirements, user limitations, and finally, to merge with available technologies to provide a pleasant experience. Professionals who are new to the process of building interface and interaction design may have difficulties in finding suitable solutions to User Experience (UX) problems due to the lack of knowledge in interface design and their users [2,3].

According to Shneiderman [4], researchers and user interface (UI) designers are increasingly aware of the need to align human cognitive skills and preferences in their projects. They have progressively recognized that their success depends on creating compelling user interfaces and creating engaging user experiences. Thus, designers and other professionals interested in this topic seek an ever closer interaction with users during the stages of design, development and the entire software life cycle. Over the years, the use of interactive design methods has become essential in the development of quality systems, and the contributions of these approaches have become evident.

Design knowledge can avoid numerous problems related to interaction issues in the project’s development phases, such as supporting correct decision making and preventing mistakes from being made repeatedly [5]. Additionally, through the use of user-centred design knowledge, designers and developers can achieve a reduction in development time and project costs [4].

As Reed et al. [6] pointed out, since the mid-1980s, published design knowledge for software user interfaces and Human–Computer Interaction (HCI) has increased in importance as the use of computers has become ubiquitous in work settings and other environments.

These design recommendations can be considered as an intermediate connection between the designer and the knowledge of the user interface. Since user demands, behaviours, and limitations are the most relevant factors in a user-centred interface design [3]. Among the main tools and techniques available that deal with design knowledge are the principles [7,8,9], standards [10], golden rules [4], style guides [11,12], heuristics [13], guidelines [14,15,16,17], and interaction design patterns [9,18,19].

These techniques and tools are based not only on theory but also on existing knowledge and experience, which are recognized as the main contributions to the design of more usable systems [20]. Their purpose is to efficiently support the work of designers with the technical knowledge of other professionals such as cognitive psychologists, human factor engineers, usability engineers, and developers [3].

In the current literature, among the tools and techniques related to existing design knowledge and experience, guidelines and patterns are essential resources for use. Traditionally, guidelines have been used to convey strong design knowledge and experience, and there has been an increase in interest in interaction design patterns as an effective way to capture and communicate design knowledge [20]. Design patterns aim to capture and communicate user interface design best practices with a focus on user experience and usage context. As a result, they are compelling user-centred design techniques and have exciting ramifications for designing in a variety of contexts. Design patterns alleviate many of the shortcomings associated with guidelines [21].

A previous study has performed a mapping of the literature on mobile interaction design patterns, until 2017 [22]. The analysis published in 2017 concentrated on the prevalence of patterns related to different interactive elements, covering the areas with more design patterns and areas with insufficient patterns. However the study did not analyse other aspects, such as the format and ways in which the patterns were communicated and how their use could be evaluated.

To characterize the current scenario of mobile user interaction design patterns (MUIDPs), this systematic mapping was conducted to obtain a compilation of existing patterns and analysis of their features and research gaps in the literature. The systematic mapping has allowed us to outline the main elements used in the format of the descriptions of the patterns, contexts and other relevant characteristics described in the studies involving the MUIDPs.

This article is organized as follows: Section 2 presents a contextualization of design patterns in the context of this research. Section 3 details the methodology of systematic mapping and its stages. Section 4 presents the results and discussions around the research questions and the selected articles. Finally, Section 5 presents the conclusions of this work.

2. Background

Patterns were first described in the 1960s by Christopher Alexander, an architect and design theorist that observed the occurrence of many features in objects that followed patterns in their features [23]. Thus, he adapted his observations to his work and published many considerations on the subject [24]. The original intention of setting patterns was to capture the essence of successful solutions to recurring design problems in a given context.

Patterns have been promoted as a knowledge-transfer mechanism in many domains, including Human-Computer Interaction. In this field, interaction design patterns alleviate many of the shortcomings associated with other design knowledge mechanisms. They represent a more operational tool than principles and guidelines for the explicit representation of design guidance [21,25].

Patterns focus on the context of a stated problem. In the domain of Human–Computer Interaction issues, solutions are expressed in terms of acceptable interaction practices, guiding the designer in the use of design knowledge [5,20,26].

Besides communicating insights into the solution to a given problem, patterns can describe the forces involved in the problem, the justification for the solution, the trade-offs in applying the solution or describing the core of the solution to a given problem. The association of this information aims to offer the possibility of repeatedly reusing the proposed solution [5,20].

Patterns usually use specific structures, and many authors have proposed different structures to describe them [5]. The structure of a design pattern must include specific parameters to make it useful. The same design pattern can be represented in different ways to visualize more extensive or simplified structures [27].

When considering that a design pattern corresponds to a structured description of a proven solution to a recurring problem in a given context, the literature addresses structures for patterns composed of several elements. These structures can include elements such as name, classification, the context of use, problem, forces, solution, implementation, pros, cons, quality factors, metrics, examples, references, synopsis, credits, among other attributes [5,25,27,28].

Patterns are prescriptive and help designers create new instances through a structured description of an invariable solution to a recurring problem in the context [29]. Among the benefits, user interface design patterns can provide consistency, familiarity, predictability, and efficiency to users; clearer and faster communication between areas; better knowledge retention and more efficient training for new team members; accelerated UX and maturity in product development; among other benefits [28,29].

These patterns with specific attributes can be combined in related pattern languages, that result in both a common language for design and promote pattern-oriented design [25,29]. The patterns are used in communication between interdisciplinary teams, such as specialists in human factors, user interface designers, and software developers [30]. For patterns, it is essential that the solution is a proven answer to the stated problem and that other designers or developers agree with the fact that it is a valid solution [5].

In the particular case of mobile interaction, the peculiarities of mobile devices require details to be considered during the design and development of the application in order to offer a satisfactory user experience. Some user groups may have difficulties using mobile apps, such as older users and people with low experience with computers. Usability issues in mobile apps can also cause failure in user adoption [31].

Hinman’s book [32] states that when creating experiences on mobile devices, the use of patterns can help the implementation of proven solutions. However, obstacles to mobile UX can be found and attributed to two main problems. The first is related to low documentation of design patterns in the mobile context and the custom of borrowing desktop design patterns instead of designing and documenting new patterns for mobile devices. The second, caused by the rapid pace of evolution of existing design patterns for mobile devices since the mobile context is highly variable and unpredictable.

3. Research Methodology

The research employed a systematic mapping based on the guidelines and procedures established by Kitchenham et al. [33] and Petersen et al. [34]. The systematic mapping process is illustrated in Figure 1 and consists of three main stages: planning, conduction and results. Each of these three stages is presented in the remainder of this section.

3.1. Planning

In this step, we carried out the following activities to establish a review protocol: the establishment of research questions (RQs), the definition of inclusion (ICs) and exclusion criteria (ECs), definition of the search string, and selection of search engines. The details of the planning are presented as follows.

3.1.1. Research Questions

The main research question driving this systematic mapping was: What is the state-of-the-art in the literature about mobile user interface design patterns (MUIDP)? To answer this question, we state the following sub-questions:

• What MUIDPs are reported in the literature?
  Motivation: With RQ1, we intend to identify which MUIDs are found in the literature, to verify the status of pattern capture and the development of these studies in the area of HCI.
• What are the main aspects of interface and interaction addressed in the MUIDPs found?
  Motivation: With RQ2, we intend to understand the aspects that characterize the nature of pattern development. This characterization illustrates the interface and interaction issues involved in the patterns in the use of mobile applications.
• What are the description formats of the MUIDPs?
  Motivation: With RQ3, we intend to discover the elements that make up the description of MUIDPs, providing a basis for analyzing the most used attributes and the formats of the listed patterns.
• Did the studies involve which types of evaluations and which types of users were the focus of the MUIDPs presented?
  Motivation: With RQ4, we intend to identify the usability aspects commonly assessed and validated in the evaluations of MUIDPs.

3.1.2. Inclusion and Exclusion Criteria

The inclusion and exclusion criteria were defined to filter studies that are not relevant to answers to research questions. The authors evaluated the primary studies and, in case of doubts in the selection, were resolved by consensus among the three authors after the full reading of the article. The following inclusion criteria were used:

(IC1)

 The study should describe interaction design patterns that are used in the mobile context;

(IC2)

 The MUIDPs described must have their description composed of interface elements specification.

The following exclusion criteria were used:

• The study’s language is other than English.
• In case of duplication, only one study was to be selected;
• The study is not a primary study: in this case editorials, summary, lecture, opinion article, discussion panel, technical report, preface to the event proceedings, tutorials, and other secondary studies;
• Studies in other domains of knowledge, e.g., Software Engineering (without application in user interface), etc.;
• The full study cannot be obtained;
• The study is an older version of another study already considered;
• Exclusion by title and abstract: articles that did not have references to MUIDPs or that use the term design patterns for purposes or domains were excluded;
• Exclusion for full articles: articles that did not present evidence related to our research questions or had MUIDPs described without format were excluded.

3.1.3. Search String

The execution of the electronic search requires the definition of a search string, which should provide adequate coverage of the articles for analysis. The search string constructed used key terms that derived from the objective and the set of research questions. Pilot searches were carried out to refine the string by adding or restricting the synonyms and related words used. Our objective was that the set of reference articles known by the authors was returned in the search. In the meantime, the search string continued to evolve.

The automated search was limited to articles that use the terms that make up the string in the title and/or keywords and/or in the abstract. Figure 2 shows the final search string used in this systematic mapping. The string also used, along with the key terms, the prefixes and necessary adaptations to search according to each mechanism used.

3.1.4. Search Strategies

The initial intention of this systematic mapping was to perform only the electronic search to examine studies that presented MUIDPs, identifying evidence on this topic. However, during the initial phase of the research, a failure was identified in the indexing of articles in events of the series Pattern Languages of Programs (PLoP), one of the main venues in the field. Despite several years of PLoP being contained in the listing of the ACM Digital Library, some articles were not returned in searches made with the search string.

The manual search was performed when it is known that a specific event or journal is an important publication vehicle for the topic under study, and it is not included in the results of the electronic search. Thus, the conduction and selection of primary articles were carried out in the first stage with the search string in digital libraries and in a second stage, manually examining PLoP events in order to find articles related to MUIDPs.

Based on the results of the electronic and manual search, the relevance and use of patterns described in books were identified as references to the patterns described in peer-reviewed studies. Thus, to increase the coverage of MUIDPs, the third search was made from the references of the studies selected in the previous searches.

3.2. Conduction

After searching for primary studies, the selection of studies included the exclusion of duplicate titles, titles clearly unrelated to the systematic mapping, and titles that were not classified as primary studies according to the criteria established in this systematic mapping. The first researcher read the titles and removed duplicates and those clearly unrelated to the MUIDP field.

Later, the abstracts were read by the researchers—this analysis aimed at deleting or maintaining the articles for the full reading stage of the article. Articles that did not contain enough information to clarify their objectives and results in the abstract were included for a complete reading of the article to avoid undue exclusion.

The studies analyzed in case of doubt regarding the removal by the researchers were discussed until agreement was reached. The full text of ten articles could not be obtained and one of the articles listed was an older version of another study already considered.

In the case of the analyzed books, the sample of books analyzed was selected through the references of the electronic and manual search studies. Then, the sample of books was reviewed using the applicable selection criteria and ending with the books that met the purpose of our systematic mapping.

In total, 1782 studies from 3 digital libraries and 29 PLoP events were analyzed. Through reference sampling, seven books were analyzed. The analysis resulted in 23 selected studies: 21 papers and 2 books for analyzing the questions about MUIDPs.

3.2.1. Electronic Search

The electronic search was performed using three data sources: Scopus, Engineering Village and Web of Science. To define when a study would be included or not, the inclusion and exclusion criteria were applied.

Table 1. Result by Data Source.

Electronic Data Source	Results 1
Engineering Village 2	428
Scopus 3	566
Web of Science 4	168
Total	1162

¹ These results correspond to searches conducted on 19 February 2020. ² https://www.engineeringvillage.com/, accessed on 4 March 2022. ³ https://0-www-scopus-com.brum.beds.ac.uk/, accessed on on 4 March 2022. ⁴ https://0-www-webofknowledge-com.brum.beds.ac.uk/, accessed on on 4 March 2022.

shows the relationship between results based on the use of the search string, and

Table 2. Total by exclusion criteria.

Criteria	Total
EC2—Exclusion of duplicates	570
EC3—Exclusion of non-primary studies	99
EC5—Exclusion of complete studies not obtained for analysis	10
EC6—Exclusion of an old version of a selected study	1
EC7—Exclusion by title and summary analysis	433
EC8—Exclusion by complete analysis of the study	34

shows the number of studies excluded by criterion. The criteria not shown in Table 2 had no articles excluded by them.

The selection criteria were applied, and in cases where it was not clear from the title, keywords, and abstract that a study should be kept for analysis, the publications were temporarily included and subsequently analyzed in full. After selecting the articles, we revisited those that could not be obtained through the search engine. These searches were made using the DOI (Digital Object Identifier), event name or article title, to locate as many articles as possible for analysis. In Figure 3, the stages of the selection of the primary articles in the electronic search are presented, ending this search with a total of 15 selected studies.

3.2.2. Manual Search

During the electronic search, we found an error in the indexing of one of the articles already known by researchers. The fact teased the need to perform a manual search to confirm the occurrence of the error, to include studies that were being excluded by the electronic search, and to increase the range of studies potentially relevant to the study topic.

Thus, on the same date of the electronic search, 29 events were reviewed, dealing with “Patterns Languages of Programs” (25 in ACM and four in Springer), due to the relevance of these events about patterns. After reading the titles, abstracts, and when necessary, the article in full articles were selected studies using the inclusion and exclusion criteria. The list of target venues analyzed is presented in Table 3.

Three random articles from each event were selected to be searched using the title to check the indexing of events. The searches were carried out in Scopus to find out whether or not the articles’ event was being returned in the searches. Of the 29 events analyzed, two were not found in the searches, which indicates some unknown problem in the indexing of these articles or events. The title search was done in other search bases: Web of Science and Engineering Village, to confirm this error of indexing. However, the articles were not found, proving that there is an error in indexing to such search engines.

In total, 620 primary articles were analyzed, as shown in Figure 4. The search for articles carried out manually at PLOP events ended with seven accepted studies, of which one of these had already been selected in the electronic search.

Table 3. Target venues for manual search.

#	Event
1	AsianPLoP ’10:Proceedings of the 1st Asian Conference on Pattern Languages of Programs
2	AsianPLoP ’11:Proceedings of the 2nd Asian Conference on Pattern Languages of Programs
3	EuroPLoP ’10:Proceedings of the 15th European Conference on Pattern Languages of Programs
4	EuroPLoP ’11:Proceedings of the 16th European Conference on Pattern Languages of Programs
5	EuroPLoP ’12:Proceedings of the 17th European Conference on Pattern Languages of Programs
6	EuroPLoP ’13:Proceedings of the 18th European Conference on Pattern Languages of Programs
7	EuroPLoP ’14:Proceedings of the 19th European Conference on Pattern Languages of Programs
8	EuroPLoP ’15:Proceedings of the 20th European Conference on Pattern Languages of Programs
9	EuroPLoP ’16:Proceedings of the 21th European Conference on Pattern Languages of Programs
10	EuroPLoP ’17:Proceedings of the 22th European Conference on Pattern Languages of Programs
11	EuroPLoP ’18:Proceedings of the 23th European Conference on Pattern Languages of Programs
12	EuroPLop ’19:Proceedings of the 24th European Conference on Pattern Languages of Programs
13	PLoP ’06:Proceedings of the 2006 Conference on Pattern languages of programs
14	PLoP ’07:Proceedings of the 14th Conference on Pattern Languages of Programs
15	PLoP ’08:Proceedings of the 15th Conference on Pattern Languages of Programs
16	PLoP ’09:Proceedings of the 16th Conference on Pattern Languages of Programs
17	PLoP ’10:Proceedings of the 17th Conference on Pattern Languages of Programs
18	PLoP ’11:Proceedings of the 18th Conference on Pattern Languages of Programs
19	PLoP ’12:Proceedings of the 19th Conference on Pattern Languages of Programs
20	Proceedings of the 2002 Conference on Pattern Languages of Programs—Volume 13
21	SugarLoafPLoP ’10:Proceedings of the 8th Latin American Conference on Pattern Languages of Programs
22	SugarLoafPLoP ’12:Proceedings of the 9th Latin-American Conference on Pattern Languages of Programs
23	Transactions on Pattern Languages of Programming I—Lecture Notes in Computer Science (2009)
24	Transactions on Pattern Languages of Programming II—Lecture Notes in Computer Science (2011)
25	Transactions on Pattern Languages of Programming III—Lecture Notes in Computer Science (2013)
26	Transactions on Pattern Languages of Programming IV—Lecture Notes in Computer Science (2019)
27	VikingPLoP ’16:Proceedings of the 10th Travelling Conference on Pattern Languages of Programs
28	VikingPLoP ’17:Proceedings of the VikingPLoP 2017 Conference on Pattern Languages of Programs
29	VikingPLoP 2014:Proceedings of the 8th Nordic Conference on Pattern Languages of Programs

Table 3. Target venues for manual search.

#	Event
1	AsianPLoP ’10:Proceedings of the 1st Asian Conference on Pattern Languages of Programs
2	AsianPLoP ’11:Proceedings of the 2nd Asian Conference on Pattern Languages of Programs
3	EuroPLoP ’10:Proceedings of the 15th European Conference on Pattern Languages of Programs
4	EuroPLoP ’11:Proceedings of the 16th European Conference on Pattern Languages of Programs
5	EuroPLoP ’12:Proceedings of the 17th European Conference on Pattern Languages of Programs
6	EuroPLoP ’13:Proceedings of the 18th European Conference on Pattern Languages of Programs
7	EuroPLoP ’14:Proceedings of the 19th European Conference on Pattern Languages of Programs
8	EuroPLoP ’15:Proceedings of the 20th European Conference on Pattern Languages of Programs
9	EuroPLoP ’16:Proceedings of the 21th European Conference on Pattern Languages of Programs
10	EuroPLoP ’17:Proceedings of the 22th European Conference on Pattern Languages of Programs
11	EuroPLoP ’18:Proceedings of the 23th European Conference on Pattern Languages of Programs
12	EuroPLop ’19:Proceedings of the 24th European Conference on Pattern Languages of Programs
13	PLoP ’06:Proceedings of the 2006 Conference on Pattern languages of programs
14	PLoP ’07:Proceedings of the 14th Conference on Pattern Languages of Programs
15	PLoP ’08:Proceedings of the 15th Conference on Pattern Languages of Programs
16	PLoP ’09:Proceedings of the 16th Conference on Pattern Languages of Programs
17	PLoP ’10:Proceedings of the 17th Conference on Pattern Languages of Programs
18	PLoP ’11:Proceedings of the 18th Conference on Pattern Languages of Programs
19	PLoP ’12:Proceedings of the 19th Conference on Pattern Languages of Programs
20	Proceedings of the 2002 Conference on Pattern Languages of Programs—Volume 13
21	SugarLoafPLoP ’10:Proceedings of the 8th Latin American Conference on Pattern Languages of Programs
22	SugarLoafPLoP ’12:Proceedings of the 9th Latin-American Conference on Pattern Languages of Programs
23	Transactions on Pattern Languages of Programming I—Lecture Notes in Computer Science (2009)
24	Transactions on Pattern Languages of Programming II—Lecture Notes in Computer Science (2011)
25	Transactions on Pattern Languages of Programming III—Lecture Notes in Computer Science (2013)
26	Transactions on Pattern Languages of Programming IV—Lecture Notes in Computer Science (2019)
27	VikingPLoP ’16:Proceedings of the 10th Travelling Conference on Pattern Languages of Programs
28	VikingPLoP ’17:Proceedings of the VikingPLoP 2017 Conference on Pattern Languages of Programs
29	VikingPLoP 2014:Proceedings of the 8th Nordic Conference on Pattern Languages of Programs

3.2.3. Books Search

To obtain greater coverage of MUIDPs, in addition to searching through the search for scientific article bases, a search was done for books describing collections of MUIDPs. The books were identified through the references of the studies selected in the electronic and manual search.

The use of patterns as references in the selected studies was the primary justification for including the MUIDPs collections in the books. Besides, they consist of material with effective use by designers, still presenting a proper amount of patterns compared to the collections published in articles.

However, it is essential to note that patterns in books were only included, when they demonstrated relevance in the literature (being cited by scholarly studies) and met the applicable systematic mapping criteria. Most of the analyzed books were cited as references for the articles selected in the systematic mapping, and the rest were results of the references found during the search.

This way, seven books were listed as candidates for inclusion in the systematic mapping. In these books, the MUIDPs were analyzed manually. Table 4 shows the title, the decision for acceptance/exclusion, reference, and the number of citations raised in the Google Scholar entries of the analyzed books.

Although most books have a title in line with the systematic mapping, the exclusion of these books was supported by the fact that the description of the patterns presented was made in blocks of text without mentioning any interface elements or other similar structures that composed the patterns.

Table 4. Analyzed books.

#	Book Name	Status	Citations	References
1	Designing Interfaces	Excluded	1621	[19]
2	Designing Gestural Interfaces	Excluded	551	[35]
3	Mobile First	Excluded	249	[36]
4	Mobile Design Pattern Gallery	Excluded	163	[37]
5	Designing Mobile Interfaces	Accepted	157	[38]
6	UX Design for Mobile	Excluded	5	[39]
7	Mobile UI Design Patterns	Accepted	2	[40]

Table 4. Analyzed books.

#	Book Name	Status	Citations	References
1	Designing Interfaces	Excluded	1621	[19]
2	Designing Gestural Interfaces	Excluded	551	[35]
3	Mobile First	Excluded	249	[36]
4	Mobile Design Pattern Gallery	Excluded	163	[37]
5	Designing Mobile Interfaces	Accepted	157	[38]
6	UX Design for Mobile	Excluded	5	[39]
7	Mobile UI Design Patterns	Accepted	2	[40]

3.3. Limitations and Threats to Validity

The main threats to the validity of this systematic mapping are related to the bias of finding studies, the selection, the possible inaccuracies in the extraction and categorization of data.

Among the threats can mention, as presented in Section 3.2, the failure to index articles. It is worth mentioning the possible absence of unpublished studies within the events analyzed manually or of particular limitations in the search engines used, since they work in different ways. To alleviate this threat were carried out the electronic search, manual search, and book search.

The construction of the string for the electronic search was one of the points that most demanded attention in the planning of this systematic mapping. In the case of design patterns, there is a vast literature of studies carried out in the area of Software Engineering and synonyms that can be used. As several people from different fields have worked on Interaction design patterns in recent years, the concept of identification patterns is known under different names.

During the electronic search, a high number of returned articles were excluded when reading their titles and abstracts, as they dealt with software architecture design patterns, where the term “Design Patterns” is used a lot.

To alleviate this threat, the building of the string was based on the recommendations of Kitchenham et al. [41], which advises that the string must be validated before proceeding with systematic mapping. Thus, the items (synonyms) that make up the string were refined and evaluated during the selection of the studies, in which new terms were added, and the search string refined and achieving new results.

Additionally, according to Kitchenham et al. [41], the threats regarding the selection of studies are mitigated using the established inclusion and exclusion criteria. However, as the systematic mapping was carried out by only two researchers, during the study selection process, there is the possibility of influencing the selection based on a personal point of view. Other more complex issues have been discussed among researchers, to obtain a lesser chance of errors about the inclusion or exclusion of studies, categorization of patterns, or analysis of studies.

4. Results and Discussion

The analysis presented in this section is based on the results obtained from the analysis of the 23 studies listed in

Table 5. Selected studies.

#	Authors	Year	# Patterns
S01	García et al. [42]	2014	3
S02	Kultsova et al. [43]	2017	3
S03	Kluth et al. [44]	2014	4
S04	Inostroza et al. [45]	2013	1
S05	Nilsson [46]	2009	14
S06	Knote et al. [47]	2016	2
S07	Tesoriero et al. [48]	2007	4
S08	Gkanatsios and Retalis [49]	2015	5
S09	Wetchakorn and Prompoon [50]	2015	15
S10	Flores et al. [51]	2010	4
S11	D’souza et al. [52]	2017	4
S12	Biel et al. [53]	2008	1
S13	Raj and Komaragiri [54]	2009	1
S14	Ginige et al. [55]	2012	2
S15	Döweling and Walka [56]	2011	6
S16	Morgado and Paiva [57]	2015	2
S17	Homann et al. [58]	2013	1
S18	Suleri et al. [59]	2019	108
S19	Biel et al. [60]	2010	1
S20	Ratzka [61]	2013	12
S21	Ribeiro and Carvalhais [62]	2012	21
B1	Hoober and Berkman [38]	2011	76
B2	Bank [40]	2014	46
		Total	336

. This section presents the results structured by research questions, analyses about the selected studies, and a general analysis of the systematic mapping.

4.1. Research Questions

In this subsection, the answers to the research questions of this systematic mapping are presented.

RQ1: 

What MUIDPs are found in the literature?

This systematic mapping yielded a total of 336 MUIDPs surveyed in 21 articles and two books, distributed over 17 years (2002 to 2019). These 336 catalogued MUIDPs are available as supplemental material, and from their analysis, research questions RQ2, RQ3 and RQ4 are answered.

Through the analysis of the elements of each pattern, an evaluation was carried out to identify how many patterns presented equivalent proposals about the problems presented. Of the total of 336 patterns, there were 75 that were equivalent to other patterns. The equivalence analysis of these patterns disregarded the number of elements and format provided in each pattern and considered its essence main(problem and solution). Thus, 261 MUIDPs were found with different proposals and solutions for recurring practices of interface and interaction on mobile devices. The list of patterns has been organised into different views in Table 1, Table 2, Table 3, Table 4, Table 5, Table 6, Table 7, Table 8, Table 9, Table 10, Table 11, Table 12, Table 13, Table 14, Table 15, Table 16, Table 17, Table 18, Table 19, Table 20, Table 21, Table 22, Table 23 and Table 24 to allow readers to see the different perspectives into which the patterns were classified in the study.

RQ2: 

What are the main aspects of interface and interaction addressed in the MUIDPs found?

Interaction design patterns can include a wide variety of solutions in which problems have been commonly identified. In our study, to assess which leading aspects were treated in the patterns, a classification of the patterns was carried out. In classifying the patterns found, 18 categories were used, 14 of which come from the work of Suleri et al. [59], three categories from the work of Hoober and Berkman [38] (Action, Control and Confirmation; Composition; and Output Design) and only one category was created from the observation of the essence of the raised patterns (Configuration and Customization).

The categories in which the patterns were classified are Action, Control and Confirmation; Anti-Patterns; Authentication and Privacy; Getting Input; Dark Patterns; Dealing with Data; Configuration and Customization; Feedback; Organizing the Content; Guidance; Interactions; Layout; Menu; Navigation; Composition; Output Design; Shopping; and Social. Table 6 shows the classification of MUIDPs by category.

Table 6. Total MUIDPs by category.

#	Category	Total
1	Action, Control and Confirmation	20
2	Anti-Patterns	3
3	Authentication and Privacy	6
4	Composition	7
5	Configuration and Customization	6
6	Dark Patterns	3
7	Dealing with Data	18
8	Feedback	13
9	Getting input	28
10	Guidance	13
11	Interactions	19
12	Layout	10
13	Menu	10
14	Navigation	18
15	Organizing the Content	51
16	Output Design	13
17	Shopping	9
18	Social	15
	Total	261

Table 6. Total MUIDPs by category.

#	Category	Total
1	Action, Control and Confirmation	20
2	Anti-Patterns	3
3	Authentication and Privacy	6
4	Composition	7
5	Configuration and Customization	6
6	Dark Patterns	3
7	Dealing with Data	18
8	Feedback	13
9	Getting input	28
10	Guidance	13
11	Interactions	19
12	Layout	10
13	Menu	10
14	Navigation	18
15	Organizing the Content	51
16	Output Design	13
17	Shopping	9
18	Social	15
	Total	261

It is noteworthy that, although there were already categorized patterns, some were again categorized into another new category that better served their purpose according to the definitions. Assignments of patterns into categories were performed by the first author and revised by another author. When disagreements occurred, discussions were carried out until consensus was reached. In describing the content of each category, the strategy used was to list main issues such as similarities in functionality, problem or context.

The following are the categories of MUIDPs raised in this systematic mapping.

Category: 

Action, Control, and Confirmation—20

The patterns of the Action, Control, and Confirmation category comprise the proposed solutions in which an actionable element can result in dull, significant, relevant, or catastrophic consequences. These results will be a consequence of interactions with these structures in which users need to know what is “clickable” and what is not.

Thus, Action, Control and Confirmation MUIDPs can cover issues such as making clickable elements easy to use (e.g., Huge Button, Indicator), presenting confirmation dialogues for possible actions or with severe consequences (e.g., Cancel Protection, Confirmation, Exit Guard, Social Login), support to back up easily or recover from errors (e.g., Accidental Touch, Iceberg Tip, Touch-based Error Correction) or propose pleasant styles and formats of these clickable elements (e.g., Fitts Law, Touch Friendly Target).

In general, these MUIDPs are responsible for mediating the conversation between user and application. If composed of elements that indicate the action that a user is allowed to complete, they can promote less chance of human error and loss of input data.

Category: 

Anti-Patterns—3

MUIDPs are conventional approaches to recurring problems that have been formalized and generally considered good practice, however, there are repeatable models and ways of solving specific questions, but in a non-ideal and ineffective way. Anti-Patterns MUIDPs describe standard solutions to problems that have decidedly negative consequences. Although it is more straightforward and more understandable to use solutions that appear frequently and are indicated for implementation, the identification of bad proposals can avoid the implementation of projects that would result in an inadequate design.

Because there are fewer and less interested in cataloguing these inappropriate practices, Anti-Patterns MUIDPs category includes patterns from different fields and different principles. Aspects such as non-intuitive interactions (e.g., Needless Complexity), unnecessary interruptions in the user flow (e.g., Idiot Boxes), content overload, or on-screen control (e.g., Oceans of Buttons), among other issues, can be raised in these patterns.

Table 7. Action, Control, and Confirmation MUIDPs.

#	Pattern Name	References
1	Accidental Touch	[44]
2	Auditory Mode Switch	[56]
3	Cancel Protection	[38]
4	Confirmation	[38]
5	Emergency Button	[47]
6	Exit Guard	[38]
7	Finger Friendly Menu Choices	[46]
8	Fitts’s Law	[44]
9	Huge Button	[38,40,50]
10	Iceberg Tip	[62]
11	Indicator	[38]
12	Process Control	[51]
13	Soft Key Window	[54]
14	Sound Mixing	[51]
15	Timeout	[38]
16	Touch Friendly Target	[62]
17	Social Login	[40,59]
18	Speech-enabled Palette	[61]
19	Swipe Views	[40,59]
20	Touch-based Error Correction	[56]

Table 7. Action, Control, and Confirmation MUIDPs.

#	Pattern Name	References
1	Accidental Touch	[44]
2	Auditory Mode Switch	[56]
3	Cancel Protection	[38]
4	Confirmation	[38]
5	Emergency Button	[47]
6	Exit Guard	[38]
7	Finger Friendly Menu Choices	[46]
8	Fitts’s Law	[44]
9	Huge Button	[38,40,50]
10	Iceberg Tip	[62]
11	Indicator	[38]
12	Process Control	[51]
13	Soft Key Window	[54]
14	Sound Mixing	[51]
15	Timeout	[38]
16	Touch Friendly Target	[62]
17	Social Login	[40,59]
18	Speech-enabled Palette	[61]
19	Swipe Views	[40,59]
20	Touch-based Error Correction	[56]

Table 8. Anti-patterns MUIDPs.

#	Pattern Name	References
1	Idiot Boxes	[59]
2	Needless Complexity	[59]
3	Oceans of Buttons	[59]

Table 8. Anti-patterns MUIDPs.

#	Pattern Name	References
1	Idiot Boxes	[59]
2	Needless Complexity	[59]
3	Oceans of Buttons	[59]

Category: 

Authentication and Privacy—6

Patterns in the Authentication and Privacy category include strategies that address issues of the user’s security flow. Authentication and Privacy MUIDPs encompass critical issues such as user identification, authentication of informed data (e.g., Ask Permission, Login), when necessary, creation or recovery of user account (e.g., Account Registration, Forgot Password), and presentation of terms and security conditions about the data collected (e.g., Privacy Policy).

The patterns that involve safety topics are relevant because of the possibility of experiences that they can provide, such as access to exclusive content, customization of the environment by the user, content creation, among other gains that can guarantee to maximize the use and satisfaction of the product. However, on the other hand, we have a greater fear of users in informing data and the need for those who implement such products to guarantee greater confidence in the information collected.

Table 9. Authentication and Privacy MUIDPs.

#	Pattern Name	References
1	Account Registration	[59]
2	Ask Permission	[59]
3	Forgot Password	[59]
4	Login	[38,50,59]
5	Privacy Policy	[59]
6	Trust and Authentication	[53]

Table 9. Authentication and Privacy MUIDPs.

#	Pattern Name	References
1	Account Registration	[59]
2	Ask Permission	[59]
3	Forgot Password	[59]
4	Login	[38,50,59]
5	Privacy Policy	[59]
6	Trust and Authentication	[53]

Category: 

Composition—7

The patterns of the Composition category are related to the assembly of components, concepts, content, and other elements to build the final design of a page. User interfaces can be composed according to several aspects that aim at a greater consistency of the product to the end-user.

Composition MUIDPs can include display states (e.g., Home and Idle Screens, Lock Screen), textual or visual elements (e.g., Titles, Icon), or other elements that make up the product page or screen (e.g., Advertising, Annunciator Row, Circles).

Table 10. Composition MUIDPs.

#	Pattern Name	References
1	Advertising	[38]
2	Annunciator Row	[38]
3	Circles	[40]
4	Home & Idle Screens	[38]
5	Lock Screen	[38]
6	Titles	[38]
7	Icon	[38]

Table 10. Composition MUIDPs.

#	Pattern Name	References
1	Advertising	[38]
2	Annunciator Row	[38]
3	Circles	[40]
4	Home & Idle Screens	[38]
5	Lock Screen	[38]
6	Titles	[38]
7	Icon	[38]

Category: 

Configuration and Customization—6

The patterns of the Configuration and Customization category adapt the content or resources to the specific characteristics of the users or the application. The changes made aim to promote a better experience and control.

The Configuration and Customization MUIDPs can include customization made by the product being used (e.g., Context Adaptation, Immediate Immersion), or customization made by the user that allows general adjustments to content or functionality that match their specific needs or interests (e.g., Branding the controls, Global Channel Configuration, Settings).

Table 11. Configuration and Customization MUIDPs.

#	Pattern Name	References
1	Settings	[59]
2	Brand the Standard	[46]
3	Branding the Controls	[46]
4	Context Adaptation	[61]
5	Global Channel Configuration	[61]
6	Immediate Immersion	[40,59]

Table 11. Configuration and Customization MUIDPs.

#	Pattern Name	References
1	Settings	[59]
2	Brand the Standard	[46]
3	Branding the Controls	[46]
4	Context Adaptation	[61]
5	Global Channel Configuration	[61]
6	Immediate Immersion	[40,59]

Category: 

Dark Patterns—3

The patterns in the Dark Patterns category encompass strategies and resources that force or induce users to follow a path or do things they might not want to do. These are tactics present mainly in e-commerce to generate more sales, obtain subscriptions, and reach the target numbers in transactions, among others. In this way, through the misleading nature of interactions, the user’s vulnerability in the intention to achieve goals and increase revenues is exploited.

For Dark Patterns MUIDPs to achieve their goals, manipulation of colours for incorrect targeting, the use of confusing instead of clarified language (e.g., Trick Questions), the inclusion of ads mixed with the interface components (e.g., Disguised Ads), discouragement or the act of blaming the user for his choice (e.g., Confirmshaming), among other tricks.

Table 12. Dark Patterns MUIDPs.

#	Pattern Name	References
1	Confirmshaming	[59]
2	Disguised Ads	[59]
3	Trick Questions	[59]

Table 12. Dark Patterns MUIDPs.

#	Pattern Name	References
1	Confirmshaming	[59]
2	Disguised Ads	[59]
3	Trick Questions	[59]

Category: 

Dealing with Data—18

The patterns of the Dealing with Data category emerged from the growing demand for the volume of data that applications deal with, and consequently, the need for how this data is viewed, searched, formatted, and navigated. The Dealing with Data MUIDPs addresses issues such as finding, selecting, viewing, categorizing, or evaluating data. All of this from a parameter informed by the user about the set or part of the elements.

Strategies for handling data include quick searches for information (e.g., Search, Search Within), filters that deepen a search or value about which they need more information (e.g., Sort & Filter, Table Filter), management and control of file (e.g., Autosave, Undo), data linked to the content to assist other users in understanding (e.g., Faq, Rate Content, Recommendations), among others.

Table 13. Dealing with Data MUIDPs.

#	Pattern Name	References
1	Abridged Table	[62]
2	Autosave	[59]
3	Dashboard	[59]
4	Details Slider	[52]
5	Dynamic Filtering	[62]
6	Faq	[59]
7	Flagging/Reporting	[59]
8	Legend Filter	[52]
9	Parts Selector	[59]
10	Rate Content	[59]
11	Recommendations	[59]
12	Reviews	[59]
13	Search	[59]
14	Search Within	[38]
15	Selection Brush	[52]
16	Sort & Filter	[38,59]
17	Table Filter	[59]
18	Undo	[40,59]

Table 13. Dealing with Data MUIDPs.

#	Pattern Name	References
1	Abridged Table	[62]
2	Autosave	[59]
3	Dashboard	[59]
4	Details Slider	[52]
5	Dynamic Filtering	[62]
6	Faq	[59]
7	Flagging/Reporting	[59]
8	Legend Filter	[52]
9	Parts Selector	[59]
10	Rate Content	[59]
11	Recommendations	[59]
12	Reviews	[59]
13	Search	[59]
14	Search Within	[38]
15	Selection Brush	[52]
16	Sort & Filter	[38,59]
17	Table Filter	[59]
18	Undo	[40,59]

Category: 

Feedback—13

The patterns of the Feedback category are responsible for providing the user with the results of any interaction, making it visible and understandable. The connection between the action and the result must be visible, which requires successful feedback to be quick, meaningful, and noticeable. Feedback should always simplify and support the user experience so that people know what happened, why it happened, and what they should do next.

Feedback MUIDPs can provide feedback to the user about what is happening (e.g., Interstitial Screen, Loading, Progress, Tones, Wait Indicator), communicate general status information (e.g., Silent Misentry, Tooltip), alert about prevention or the occurrence of errors (e.g., Input Feedback, Warning), or other types of feedback considering the context (physical or emotional) (e.g., Feedback Messages, Haptic Output).

These patterns are used to engage and explain and can improve user satisfaction. The lack of these design principles can make the user try to guess what is happening or become frustrated.

Category: 

Getting input—27

The patterns in the Getting input category include the recurring data entry solutions that will be processed to produce a particular output. User input is a task that can be adapted to the context of use or the user’s preferences to optimize interaction.

Getting input MUIDPs can facilitate and support the inclusion of data in several ways, such as offering the best type of data for input (e.g., Pen Input, Voice Input), presenting filtered or restricted set of input options (e.g., Default Values & Auto Complete, Dialer, Keyboards & Keypads, Specialized Input Mechanisms, Smart Keyboards), in the use of tags or hint resources (e.g., Natural Language Inputs, Focus & Cursors), in the verification or validation of data (e.g., Redundant Input), or other mechanisms that can support the input process (e.g., Expandable Input, Multiple Ways of Input). The implementation of these patterns aims to make user input efficient and to avoid errors.

Table 14. Feedback MUIDPs.

#	Pattern Name	References
1	Control of Autonomous Adaptation	[47]
2	Feedback Messages	[59]
3	Haptic Output	[38]
4	Input Feedback	[59]
5	Interstitial Screen	[38]
6	Loading	[59]
7	Progress	[59]
8	Silent Misentry	[44]
9	Tones	[38]
10	Tooltip	[38]
11	Unwilling To Become Snapped	[49]
12	Wait Indicator	[38,46]
13	Warning	[59]
14	Multimodal Infinitive Area + Context	[55]

Table 14. Feedback MUIDPs.

#	Pattern Name	References
1	Control of Autonomous Adaptation	[47]
2	Feedback Messages	[59]
3	Haptic Output	[38]
4	Input Feedback	[59]
5	Interstitial Screen	[38]
6	Loading	[59]
7	Progress	[59]
8	Silent Misentry	[44]
9	Tones	[38]
10	Tooltip	[38]
11	Unwilling To Become Snapped	[49]
12	Wait Indicator	[38,46]
13	Warning	[59]
14	Multimodal Infinitive Area + Context	[55]

Category: 

Guidance—13

The patterns of the Guidance category exist because of the need for an effective integration process for its users, allowing them to complete their primary objective in the product used. These patterns correspond to the interactions and instructions implemented to facilitate the product experience.

Guidance MUIDPs provide the necessary support that users need to get what they want within an application. These can be explanatory concerning data entry (e.g., Input Hints), informative about where the user is or where is going (e.g., Next Steps, Steps Left, Wizard), or instructive when familiarizing themselves with the components and other aspects of the application (e.g., Guided Tour, Playthrough, Walkthrough, Coachmark, and Guideline). These well-implemented practices can guarantee satisfaction, trust, understanding, and user retention, which will represent a good integration experience and prevention against errors and frustration in the use of applications.

Table 15. Getting input MUIDPs.

#	Pattern Name	References
1	Alternative Input Mechanisms	[38,46,59]
2	Auto Complete	[38,46,59]
3	Clear Entry	[38,62]
4	Contact Form	[59]
5	Default Values & Auto Complete	[40,46,50,59]
6	Dialer	[38]
7	Expandable Input	[40,50,59]
8	Focus & Cursors	[38]
9	Forgiving Format	[59]
10	Form	[59]
11	Form Selections	[38]
12	Inplace Editor	[59]
13	Input Areas	[38]
14	Input Method Indicator	[38]
15	Keyboards & Keypads	[38]
16	Mode Switches	[38]
17	Multimodal N-best Selection	[61]
18	Multiple Ways Of Input	[61]
19	Natural Language Inputs	[59]
20	Pen Input	[38]
21	Redundant Input	[61]
22	Smart Keyboards	[40,50]
23	Specialized Input Mechanisms	[46]
24	Speech-enabled Form	[61]
25	Spelling-based Hypothesis Reduction	[61]
26	Voice Input	[38,43,56]
27	Voice-based Interaction Shortcut	[61]

Table 15. Getting input MUIDPs.

#	Pattern Name	References
1	Alternative Input Mechanisms	[38,46,59]
2	Auto Complete	[38,46,59]
3	Clear Entry	[38,62]
4	Contact Form	[59]
5	Default Values & Auto Complete	[40,46,50,59]
6	Dialer	[38]
7	Expandable Input	[40,50,59]
8	Focus & Cursors	[38]
9	Forgiving Format	[59]
10	Form	[59]
11	Form Selections	[38]
12	Inplace Editor	[59]
13	Input Areas	[38]
14	Input Method Indicator	[38]
15	Keyboards & Keypads	[38]
16	Mode Switches	[38]
17	Multimodal N-best Selection	[61]
18	Multiple Ways Of Input	[61]
19	Natural Language Inputs	[59]
20	Pen Input	[38]
21	Redundant Input	[61]
22	Smart Keyboards	[40,50]
23	Specialized Input Mechanisms	[46]
24	Speech-enabled Form	[61]
25	Spelling-based Hypothesis Reduction	[61]
26	Voice Input	[38,43,56]
27	Voice-based Interaction Shortcut	[61]

Table 16. Guidance MUIDPs.

#	Pattern Name	References
1	Coach Marks	[59]
2	Coachmark and Guideline	[50]
3	Guided Tour	[59]
4	Inline Hints	[59]
5	Input Hints	[59]
6	Next Steps	[59]
7	Onboarding	[59]
8	Door at Back	[48]
9	Playthrough	[59]
10	Steps Left	[59]
11	Walkthrough	[59]
12	Walkthroughs & Coach Marks	[40]
13	Wizard	[59]

Table 16. Guidance MUIDPs.

#	Pattern Name	References
1	Coach Marks	[59]
2	Coachmark and Guideline	[50]
3	Guided Tour	[59]
4	Inline Hints	[59]
5	Input Hints	[59]
6	Next Steps	[59]
7	Onboarding	[59]
8	Door at Back	[48]
9	Playthrough	[59]
10	Steps Left	[59]
11	Walkthrough	[59]
12	Walkthroughs & Coach Marks	[40]
13	Wizard	[59]

Category: 

Interactions—19

The patterns of the Interactions category contemplate all interactions whose operations intermediated between the application interface, and the user can be performed through gestures (e.g., Remote Gestures), touches with fingers (e.g., Pull to Refresh, Press-and-hold, Zoom & Scale), voice (e.g., Select By Touch, Operate By Voice), movements with the device (e.g., Kinesthetic Gestures) or another interaction strategy (e.g., Directional Entry). Except for the unique touch, since it always represents “select”.

Interactions MUIDPs have, in general, non-evident forms of presentation in the application interface and require the memorization of their interaction strategies for active use. In this way, users must be able to easily find, understand, and learn the controls of these MUIDPs offered in the applications so that their use is adequate in providing good secondary alternatives of actions. These patterns may or may not offer clues about interactions before actions are taken, and feedback after actions are provided.

In short, Interactions MUIDPs in their interface and interaction elements aim to cover issues such as reasonable size to interact, location adequate on the screen to reach the finger, familiar layout, and formats, intuitive and straightforward shortcuts for users.

Table 17. Interactions MUIDPs.

#	Pattern Name	References
1	Accesskeys	[38]
2	Continuous Scrolling	[59]
3	Directional Entry	[38]
4	Drag & Drop	[59]
5	Gesture-enhanced Speech Command	[61]
6	Kinesthetic Gestures	[38]
7	Natural Interaction / Natural Behavior	[51]
8	On-screen Gestures	[38,61]
9	Other Hardware Keys	[38]
10	Press-and-hold	[38]
11	Pull To Refresh	[38,40,50,59]
12	Remote Gestures	[38]
13	Select By Touch, Operate By Voice	[56]
14	Swiping For Action	[40,50]
15	Voice-based Distal Access	[56]
16	Zoom & Scale	[38]
17	Hot Areas For Interaction Elements	[49]
18	Interaction Between Snapped and Filled View	[49]
19	The Thumb Rule	[45]

Table 17. Interactions MUIDPs.

#	Pattern Name	References
1	Accesskeys	[38]
2	Continuous Scrolling	[59]
3	Directional Entry	[38]
4	Drag & Drop	[59]
5	Gesture-enhanced Speech Command	[61]
6	Kinesthetic Gestures	[38]
7	Natural Interaction / Natural Behavior	[51]
8	On-screen Gestures	[38,61]
9	Other Hardware Keys	[38]
10	Press-and-hold	[38]
11	Pull To Refresh	[38,40,50,59]
12	Remote Gestures	[38]
13	Select By Touch, Operate By Voice	[56]
14	Swiping For Action	[40,50]
15	Voice-based Distal Access	[56]
16	Zoom & Scale	[38]
17	Hot Areas For Interaction Elements	[49]
18	Interaction Between Snapped and Filled View	[49]
19	The Thumb Rule	[45]

Category: 

Layout—9

The patterns in the Layout category are responsible for the composition and structure of the screens or pages of applications. It encompasses issues such as texts, images, components, concepts, content, and other elements used in the construction of interface design. Layouts can include the presentation and organization of items together or individually (e.g., Cards, Grid, Linearized Layout, Magazine Style), and the division or overlay of the screen with keyboard or diverse content (e.g., Keyboard as part of the layout, Split Screen, Use one large UI control as a buffer).

Layout MUIDPs refer to the patterns responsible for the spatial distribution of components for consistency when presenting content in a more intuitive and useful way. These patterns are not intended to make the arrangement visually pleasing, but to be well organized to ensure visual understanding.

Table 18. Layout MUIDPs.

#	Pattern Name	References
1	Cards	[40,59]
2	Grid	[38,40,50,59,62]
3	Keyboard as Part of Layout	[46]
4	Linearized Layout	[62]
5	Magazine Style	[59]
6	Split Screen	[59]
7	Let the Keyboard Cover Part of The UI	[46]
8	Use Screen Not Covered By the Keyboard	[46]
9	Use One Large UI Control as a Buffer	[46]

Table 18. Layout MUIDPs.

#	Pattern Name	References
1	Cards	[40,59]
2	Grid	[38,40,50,59,62]
3	Keyboard as Part of Layout	[46]
4	Linearized Layout	[62]
5	Magazine Style	[59]
6	Split Screen	[59]
7	Let the Keyboard Cover Part of The UI	[46]
8	Use Screen Not Covered By the Keyboard	[46]
9	Use One Large UI Control as a Buffer	[46]

Category: 

Menu—10

The patterns in the Menu Category include these responsible for presenting the user with a set of options to help him find information or perform functions available within the application. The Menu can be of main or frequently used actions (e.g., Fixed Menu, Action Bars), actions related to specific content (e.g., Contextual Menu, Discoverable Controls), or Menus with hidden lists of options set (e.g., Select Menu, Side Menu, Toggle Menu).

Menu MUIDPs are responsible for users’ sense of orientation and guide them through the application. They deal with the essential resources in the user flow within the app. Generally, the Navigation Menus are presented and supported by the use of icons, drop-down lists, pop-up or other interfaces that are viewed only when activated. This is because due to the limitation of the screen size of mobile devices, where menus cannot be kept on the interfaces as are in desktop applications. When visible, they must be simplistic, usually represented by icons or brief text boxes.

Table 19. Menu MUIDPs.

#	Pattern Name	References
1	Action Bars	[40,50,59]
2	Contextual Menu	[40,59]
3	Discoverable Controls	[40,50,59]
4	Fixed Menu	[38,59]
5	Hamburger Menu	[57,59,62]
6	Jump Menu	[62]
7	Linearized Menu	[62]
8	Revealable Menu	[38]
9	Select Menu	[62]
10	Toggle Menu	[62]

Table 19. Menu MUIDPs.

#	Pattern Name	References
1	Action Bars	[40,50,59]
2	Contextual Menu	[40,59]
3	Discoverable Controls	[40,50,59]
4	Fixed Menu	[38,59]
5	Hamburger Menu	[57,59,62]
6	Jump Menu	[62]
7	Linearized Menu	[62]
8	Revealable Menu	[38]
9	Select Menu	[62]
10	Toggle Menu	[62]

Category: 

Navigation—18

The patterns in the Navigation category compete with the patterns that assist users in the possibility of accessing, moving or navigating back and forth between the different parts, tools or screens of the applications. It is what allows the user to go from point A to point B and to point C in the least complicated way possible. Navigation MUIDPs can be implemented through strategies in the content itself that do not distract the user from browsing internal or external content to the application (e.g., Link). They can also be implemented by means of navigation strategies mainly directed to other parts of the app (e.g., Home Link, Vertical Navigation), or procedure for accessing the content on the page, but do not fit in the display window (e.g., Scroll, Scrollbars).

These patterns also play an essential role in an application’s user flow, supporting the Menu MUIDPs, which allows the user to navigate and achieve their goals. Navigation patterns make use of aspects such as location, the number of elements and behaviour of interfaces to offer a better experience in an environment that requires more effective solutions for navigation on small screen devices. Users should always know how to orient themselves within the application, and these MUIDPs should offer this consistency.

Category: 

Organizing the Content—51

Patterns in the “Organizing the Content” category refer to user interface patterns for managing data and content through a visual hierarchy. These patterns present proposals for organization and arrangement of elements and content, to ensure higher user eligibility. Organizing the Content MUIDPs are numerous and include strategies that mix different aspects such as size, colours, typography, white space, repetition, lists, tables, categorization, ordering, or data type.

These patterns can have several purposes including viewing ordered, divided or classified content (e.g., Hierarchical List, Ordered Data, Pagination), having visualization according to the data format (e.g., Accompanying Maps, Film Strip, Gallery), making better use of device screen (e.g., Client-side Multi-screen Support, Full-Screen Mode, Orientation), personalized display content linked to labels and markers (e.g., Customized Collections, Favorites, Tagging, Recently Viewed, Related Content, Ordered Data), display dynamic view or overlay (e.g., Tabs, Slideshow, Carousel, Transparency), or structure the user interface elements effectively (e.g., Grid, Linearized Table, Stack of Items).

Table 20. Navigation MUIDPs.

#	Pattern Name	References
1	“Sticky” Fixed Navigation	[40]
2	Advanced Scrollbars	[38,40]
3	Bottom Navigation	[59]
4	Call To Actions	[59]
5	Content-based Navigation	[40]
6	Faceted Navigation	[59]
7	Free Will Navigation	[48]
8	Home Link	[59]
9	Jump To Section	[59]
10	Link	[38,40,59]
11	Morphing Controls	[40]
12	Navigational Burden	[44]
13	Nested Forms	[58]
14	Popovers	[40]
15	Scroll	[38,46]
16	Slideouts, Sidebars & Drawers	[40]
17	Sliders	[40]
18	Vertical Navigation	[40,59]

Table 20. Navigation MUIDPs.

#	Pattern Name	References
1	“Sticky” Fixed Navigation	[40]
2	Advanced Scrollbars	[38,40]
3	Bottom Navigation	[59]
4	Call To Actions	[59]
5	Content-based Navigation	[40]
6	Faceted Navigation	[59]
7	Free Will Navigation	[48]
8	Home Link	[59]
9	Jump To Section	[59]
10	Link	[38,40,59]
11	Morphing Controls	[40]
12	Navigational Burden	[44]
13	Nested Forms	[58]
14	Popovers	[40]
15	Scroll	[38,46]
16	Slideouts, Sidebars & Drawers	[40]
17	Sliders	[40]
18	Vertical Navigation	[40,59]

Table 21. Organizing the Content MUIDPs.

#	Pattern Name	References
1	Direct Manipulation of Content & Data	[40]
2	Right—Left Handed Users	[48]
3	Accompanying Maps	[59]
4	Carousel	[38,59]
5	Chunking	[59]
6	Client-side Multi-screen Support	[60]
7	Customized Collections	[59]
8	Discovery	[59]
9	Draggable Objects	[40]
10	Dropdown	[62]
11	Favorites	[59]
12	Featured Content	[59]
13	Film Strip	[38]
14	Fixed Content	[62]
15	Full Screen Mode	[40,50]
16	Full-bleed Images	[40]
17	Gallery	[59]
18	Group Friends & Content	[40]
19	Hidden Information	[40]
20	Hierarchical List	[38]
21	Infinite Area	[38,55]
22	Infinite List	[38,62]
23	Inline Expanding Area	[40,50]
24	Interactive Content Layer	[40,50]
25	Linearized Table	[62]
26	Location	[38]
27	Location Within	[38]
28	Maps as Backgrounds	[40]
29	Ordered Data	[38]
30	Orientation	[38,46,48,49,52,57]
31	Pagination	[38,59]
32	Peel Away	[38]
33	Pricing Table	[59]
34	Profile	[59]
35	Recently Viewed	[59]
36	Related Content	[59]
37	Returned Results	[38]
38	Select List	[38]
39	Shrinking an App When Snapped	[49]
40	Simulated 3D Effects	[38]
41	Slideshow	[38,62]
42	Stack of Items	[38]
43	Tabs	[38,62]
44	Tagging	[59]
45	Thumbnail List	[38,62]
46	Timeline	[59]
47	Transparency	[40]
48	Vertical List	[38,62]
49	Windowshade	[38]
50	Event Sequencing	[51]
51	Avatar	[38]

Table 21. Organizing the Content MUIDPs.

#	Pattern Name	References
1	Direct Manipulation of Content & Data	[40]
2	Right—Left Handed Users	[48]
3	Accompanying Maps	[59]
4	Carousel	[38,59]
5	Chunking	[59]
6	Client-side Multi-screen Support	[60]
7	Customized Collections	[59]
8	Discovery	[59]
9	Draggable Objects	[40]
10	Dropdown	[62]
11	Favorites	[59]
12	Featured Content	[59]
13	Film Strip	[38]
14	Fixed Content	[62]
15	Full Screen Mode	[40,50]
16	Full-bleed Images	[40]
17	Gallery	[59]
18	Group Friends & Content	[40]
19	Hidden Information	[40]
20	Hierarchical List	[38]
21	Infinite Area	[38,55]
22	Infinite List	[38,62]
23	Inline Expanding Area	[40,50]
24	Interactive Content Layer	[40,50]
25	Linearized Table	[62]
26	Location	[38]
27	Location Within	[38]
28	Maps as Backgrounds	[40]
29	Ordered Data	[38]
30	Orientation	[38,46,48,49,52,57]
31	Pagination	[38,59]
32	Peel Away	[38]
33	Pricing Table	[59]
34	Profile	[59]
35	Recently Viewed	[59]
36	Related Content	[59]
37	Returned Results	[38]
38	Select List	[38]
39	Shrinking an App When Snapped	[49]
40	Simulated 3D Effects	[38]
41	Slideshow	[38,62]
42	Stack of Items	[38]
43	Tabs	[38,62]
44	Tagging	[59]
45	Thumbnail List	[38,62]
46	Timeline	[59]
47	Transparency	[40]
48	Vertical List	[38,62]
49	Windowshade	[38]
50	Event Sequencing	[51]
51	Avatar	[38]

Category: 

Output Design—13

The patterns of the Output Design category correspond to the forms of information output that convey general information, point out the occurrence of events, projections of the future, or confirm the actions of users. In short, these patterns are responsible for presenting information about the app used to the user. The outputs correspond to one of the essential components since it is the most visible and decisive in the final evaluation of the product by the user.

The Output Design MUIDPs can transmit information through graphical interfaces (e.g., Expanding List, Notifications Popovers, Pop-up), light signaling (e.g., Led), sound communication (e.g., Voice Notifications, Voice Readback), or can even provide output handling (e.g., Audio Output Volume Increasing, Empty State, Redundant Output).

Table 22. Output Design MUIDPs.

#	Pattern Name	References
1	Annotation	[38]
2	Audio Output Volume Increasing	[43]
3	Display Brightness Controls	[38]
4	Empty State	[40,50,59]
5	Expanding List	[38,59,62]
6	Led	[38]
7	Notifications	[38,40,59]
8	Pop-up	[38]
9	Popovers	[59]
10	Quick View	[59]
11	Redundant Output	[61]
12	Voice Notifications	[38]
13	Voice Readback	[38,43,56]

Table 22. Output Design MUIDPs.

#	Pattern Name	References
1	Annotation	[38]
2	Audio Output Volume Increasing	[43]
3	Display Brightness Controls	[38]
4	Empty State	[40,50,59]
5	Expanding List	[38,59,62]
6	Led	[38]
7	Notifications	[38,40,59]
8	Pop-up	[38]
9	Popovers	[59]
10	Quick View	[59]
11	Redundant Output	[61]
12	Voice Notifications	[38]
13	Voice Readback	[38,43,56]

Category: 

Shopping—9

The patterns of the Shopping category are around the online shopping experience that the user may have. It is, therefore, concerned about design practices used in e-commerce to create a path from research to purchase the product as effectively as possible. The patterns generally cover aspects such as product display (e.g., Product Catalog, Product Page), cart management (e.g., Shopping Cart), order (e.g., Booking, Checkout, Order Confirmation, Order Summary), payment (e.g., Payment Method), and post-sale (e.g., Easy Returns).

In Shopping MUIDPs, as these are points to promote a better shopping experience for users through mobile devices, search results must be accurate and relevant to the user, but the presentation of information is essential. We still have the perception of confidence and security in the use of these patterns as crucial for the success of the applications that implement them.

Table 23. Shopping MUIDPs.

#	Pattern Name	References
1	Booking	[59]
2	Checkout	[59]
3	Easy Returns	[59]
4	Order Confirmation	[59]
5	Order Summary	[59]
6	Payment Method	[59]
7	Product Catalog	[59]
8	Product Page	[59]
9	Shopping Cart	[59]

Table 23. Shopping MUIDPs.

#	Pattern Name	References
1	Booking	[59]
2	Checkout	[59]
3	Easy Returns	[59]
4	Order Confirmation	[59]
5	Order Summary	[59]
6	Payment Method	[59]
7	Product Catalog	[59]
8	Product Page	[59]
9	Shopping Cart	[59]

Category: 

Social—15

Social category patterns are the patterns that allow users of social applications to connect, communicate and interact with other users online. Although social networks are contemporary applications with many purposes and offered to different users, many of its design principles are universal and shared between these applications.

Some of the Social MUIDPs include issues such as the timeline (e.g., Activity Feeds), the reaction metrics (e.g., Like, Reaction, Vote to Promote), the forms of connection and their management (e.g., Find and Invite Friends, Follow, Friend, Friend List, Participation Request), the communication possibilities (e.g., Comment, Direct Messaging), and content promotion (e.g., Single Share Button). The ubiquity of mobile devices and the internet is one of the great promoters of the explosion of social networks. Examples of these commonly used applications are Facebook, Instagram, LinkedIn, YouTube, TikTok, and others. The possibilities that these patterns promote in short represent possible everyday social interaction activities.

Table 24. Social MUIDPs.

#	Pattern Name	References
1	Activity Feeds	[40,59]
2	Comment	[59]
3	Direct Messaging	[40,59]
4	Find & Invite Friends	[40]
5	Follow	[40,59]
6	Friend	[59]
7	Friend List	[40,59]
8	Leaderboard	[59]
9	Like	[40]
10	Reaction	[59]
11	Single Share Button	[40]
12	Vote To Promote	[40,59]
13	Activity Request	[42]
14	Complementary Collaboration Tools	[42]
15	Participation Request	[42]

Table 24. Social MUIDPs.

#	Pattern Name	References
1	Activity Feeds	[40,59]
2	Comment	[59]
3	Direct Messaging	[40,59]
4	Find & Invite Friends	[40]
5	Follow	[40,59]
6	Friend	[59]
7	Friend List	[40,59]
8	Leaderboard	[59]
9	Like	[40]
10	Reaction	[59]
11	Single Share Button	[40]
12	Vote To Promote	[40,59]
13	Activity Request	[42]
14	Complementary Collaboration Tools	[42]
15	Participation Request	[42]

RQ3: What are the description formats of the MUIDPs?

The patterns are composed of elements and have their structure of fields to offer enough information for their reuse. Through the analysis of the 23 works, 23 elements were used to describe the patterns.

No study presented a descriptive format of the pattern similar to another, with patterns varying from a minimum of four elements, a maximum of nine elements, and an average of six elements per pattern. The five most frequent fields were: name, problem, context, solution, and examples; the same five elements defined among essential for the description of a pattern according to Alexander [24]. Eleven elements were presented in only one or two formats, which implies particularity in the description and the format of most of the patterns listed.

Elements such as Forces, Consequences, Figure, Synopsis, and Solution Rationale, are attributes that provide information that reinforce the description of the fields defined as essential to the model established by [24]. Elements such as Related Patterns, Category, Anti-patterns, References, and Variations, reinforce mainly with information to connect and support the relationship between patterns and their components.

The patterns also have elements like Interaction Details and Presentation Details that are responsible for helping to describe patterns that involve questions of interaction with the user and not just questions of the interface. The inclusion of these aspects as attributes in the pattern helps to ensure a better understanding of the proposed solution.

Table 25. Number of elements per the format of MUIDP.

Element	Total
Name	23
Solution	23
Problem	19
Context	17
Examples	13
Related Patterns	10
Forces	9
Consequences	7
Figure	7
Category	5
Solution Rationale	5
Synopsis	4
Anti-patterns	2
Interaction Details	2
Presentation Details	2
References	2
Variations	2
Others 1	6

¹ They refer to six elements present in the description of just one study. These being: For, Gestures, Patterns Group, Type, UI Components, and Weighting.

presents the elements and their frequency in the description of the patterns. The elements “Pattern Name” and “Solution” were the only ones present in all 23 pattern formats. Six elements present in only one pattern were added to a category denominated “Others”.

For the analysis of the elements of each pattern, the elements that although having different names described the same information were verified and merged. For example, “Context or When”, “Solution or How”, “Motivation for Use or Rationale”, “Examples or Known Uses”, among others.

Based on the selected studies and other studies related to the theme of this work, the following is a brief description of the elements found in the description of the MUIDPs surveyed in this systematic mapping:

• Name: The name element is an abbreviation based on the solution to designate the identification of a pattern. It is recommended that this attribute be short and clear and, whenever possible, do not conflict with an existing concept [38,60];
• Solution: The solution element describes the answer to the problem with a particular pattern. The solution must be able to show how the problem is implemented or solved, as well as showing what the pattern involves or what is necessary for its implementation [38,50,60];
• Problem: The problem element states the problem in which a solution is sought and is responsible for showing the obstacle or disorder concisely and directly [40,59];
• Context: The context element concerns the circumstances in which this pattern may or may not be used [40,59];
• Examples: The examples element presents the known uses and samples of applications that implement the respective pattern in the real world. Screenshots are commonly used to demonstrate examples of patterns [50,60].
• Related patterns: The related patterns element indicates which patterns are alternative or extensible. Referring to these patterns related to mandatory or optional patterns, the composition of the respective pattern described [50,60];
• Forces: The forces element describes the influences with effect on the solution of the pattern [60];
• Consequences: The consequences element points out the main benefits and disadvantages of implementing the particular pattern [52];
• Figure: The figure element is a valuable asset to provide a better reading and representation of how the pattern works. They are usually represented by basic style drawings that can offer a better understanding of the main proposal of the pattern [62];
• Category: The category element comprises the classification of the pattern according to some common criteria or aspect within a more extensive set;
• Rationale for the solution: The Rationale for the Solution element is the attribute that describes the motivation for using the pattern. This rationale shows why and the justification for using the pattern [59];
• Synopsis: The Synopsis element is a summarized way of presenting what the pattern proposes and especially its intention;
• Anti-patterns: The Anti-patterns element covers methods that should never be used, the smallest traps, or extreme cases of suitable variations to be observed [38];
• Interaction details: The Interaction details element explains how the user interacts with the described pattern [38];
• Presentation details: The Presentation details element indicates the items on the screen that the user cannot click on or information on how the displayed items are presented that do not directly influence the interaction [38];
• References: The reference element mentions other works or content used in the description of the pattern presented or different patterns with comparable proposals;
• Variations: The variations element describe other patterns that share characteristics or details close to the pattern presented. Variations can reveal changes and differences between nearby patterns.

RQ4: What types of evaluations did the studies involve and which types of users were the focus of the MUIDPs presented?

Most studies did not present any validation. Among the works that performed empirical validation studies, [42] conducted tests with five end-users with a different range of disabilities, [59] conducted a usability assessment with 21 lean UX designers and [46] mentions that a questionnaire was applied in two various tutorials to validate the patterns. In [44], automated tests were carried out to assess the usability of the applications that implemented the patterns presented.

Some studies have presented the category or component of the application in which the patterns had their implementation proposals. Nine studies were focused on the following areas: trust [53], spatial data [55], educational [49], ERP [58], forms [46], groupware [42], museum [48], music [51], and data visualization [52]. In seven studies, the environments in which the patterns were listed were also described. Among the environments we had MUIDPs were Android [57,60], iOS [44,50], PDA [48], Windows 8 [49], and Web [62].

Some studies have briefly described the collection of empirical evidence in previous experiments. However, most studies have only addressed the description of MUIDPs, and few describe too much information related to capture. There is a massive shortage of methods for assessing and validating the patterns presented. This highlights the need for further analysis to create a body of knowledge about the impact of the use and usability of MUIDPs for the applications that implement them.

Although the MUIDPs are repeatedly proposed and implemented, this does not reflect that they are best practices and have no negative impact. The patterns that will be used by designers and developers need to be well described with relevant attributes, and they must propose solutions to problems and not create new doubts. It is about evidencing the productivity gain, one of the main benefits of using patterns through validations.

Additionally, there are a variety of user groups with specific needs and the use of these patterns by most may not correspond to good usability to everyone. It is necessary to analyze these MUIDPs together with those who will use them in the implementation of applications and the evaluation of the user-centered design as shown in Figure 5.

4.2. Discussion

This systematic mapping of the literature showed that there is a substantial body of mobile user interface design patterns to support the development of mobile applications. The diffusion of such design patterns among researchers and practitioners provides important contributions to improving the design of interactive mobile applications. The development of such patterns show the evolving nature of the field, considering how new technologies have provided new means for interaction and types of technologies that provide access to mobile interfaces.

The design and development community can draw important lessons from the types of design patterns compile in this paper, and learn from their lessons to document patterns that can contribute to other designers, as new interaction patterns evolve with new technology.

Despite having a good body of design patterns to provide lessons for mobile user interface design, there is still little evidence of the usability of these patterns from empirical evidence related to user studies. It is important that designers and developers strive to provide more solid evidence of user studies they conduct related to the interfaces that implement the patterns.

This could provide the designers and developers who employ the patterns to have more confidence in their use and to have a better rationale for employing them.

Regarding the use of the patterns by designers and developers, the systematic mapping showed that there is a wide range of elements present in the patterns. However, important elements are not always reported in the patterns found in the literature, which may make it more difficult to employ them in practice. Many pattern descriptions fail to provide examples to support their use, and even fewer provide a solution rationale to help developers and designers understand the conceptual reasoning for using the patterns.

The systematic mapping in this paper provides important guidance that could be used to guide future discussions to enhance the description and documentation of mobile user interface design patterns.

The authors also noticed that there is a lack of accessibility-specific design patterns in the literature. It is important to broaden the coverage of accessibility issues in design patterns, bringing solutions that go beyond specific accessibility guidelines and present integrated design solutions that have been successfully employed. It would also be very important to report reflections as to how different design patterns could impact the use of the resulting user interfaces by users with different profiles, such as people with disabilities or older people. Recent studies have advanced in the investigation of design patterns to create more accessible applications [63].

5. Conclusions

Design patterns have proven to be an advantageous format for storing knowledge for reuse in various areas. With the ubiquity and alarming growth of mobile devices, research, and the use of tools and techniques that can contribute to developers and users of these devices and mobile applications are increasingly important.

Thus, this article presented the results of a systematic mapping conducted to characterize the current scenario of MUIDPs. The study revealed that although there are a low number of publications dealing with MUIDPs, a relevant number of patterns discovered were possible through the insertion of more than one search source. It is noteworthy that most studies describe a low number of patterns and reiterate little information on user usability issues.

Results obtained are essential and provide a current view of the area of patterns in HCI, as well as pointing out the need for further studies related to the capture and description of MUIDPs. Additionally, the study identified a need to describe patterns with sufficient information to be used and to analyze the effectiveness of using MUIDPs.

Most studies do not include an adequate assessment, which makes it challenging to carry out a meta-analysis of the results of these studies and speculates ample reasons for their success or negative effect. The categorization of MUIDPs can help other researchers to get an overview of the main design issues considered for current research.

The systematic mapping has identified some emerging trends in the use of specific recurrent approaches for solving everyday problems of interface and interaction. However, its effect in the mobile context needs a multi-method analysis to be demonstrated in practice what are the best practices.

Although the proper assessment is almost absent, most authors of the studies analyzed share the opinion that the use of MUIDPs has the potential to improve the process of building and to develop mobile applications, offering good usability and high learning capacity.

Thus, research involving more substantial assessments is needed to investigate, in particular, the motivating effects of using MUIDPs and for which specific types of contexts and users. This would inform designers and developers interested in using this design knowledge format, which MUIDPs to use in their particular context.

The rapid advance and updating of interface and interaction issues on mobile devices are one of the main obstacles to raising and describing interaction design patterns in the mobile context. Thus, the probing of MUIDPs that can efficiently support the interface and interaction design needs to be carried out in a quick and updated way so that it contributes with valid solutions and not with underused or obsolete solutions.

Last but not least, finding and sharing new ways to apply or raise MUIDPs is very important to increase the application of this knowledge format. Although the concept of MUIDPs may seem simple, the work analyzed shows that its use requires greater understanding and attention to what is defined as a pattern, due to the different ways that the description is structured. So that the design patterns fulfill their objective of delivering a complete format of design knowledge to designers and developers.

As future work, we propose the evolution of this systematic mapping for a broader study, increasing the effectiveness of the results obtained. Further reviews may also be carried out to deal with generic interaction design patterns for other environments, or analysis of works that address other formats of design knowledge, such as guidelines, to verify whether there are more published works and your effectiveness. Other sources of analysis can also be considered to list patterns, as there are a relevant number of described patterns on the web itself.

By observing the aspects of MUIDPs, each pattern used in an application has an intention and its final result applied in a context. More significant considerations are only possible with evaluations to ensure that the chosen pattern is suitable for the product. Still, the most, the most important point is that the pattern is suitable for the user.