[MUSIC] Hello, designing any interactive system including mobile applications does not start from scratch. Designers based their solutions on design decisions that have been made by the fellow designers. This positively affects the usability of systems being designed. Since successful solutions are spread across many apps, which means users do not need to be trained. This approach avoids the invention of the wheel, and increases the design speed. But how exactly does it happen? Who makes these good decisions? Where can they be found? I will try to answer these questions in this lecture. I would like to start by discussing the forms of design knowledge. I'm sure you know them all, but it's possible that you hear about some of the subtleties of each form for the first time. So, design solutions can be described in the form of patterns as well as rules or heuristics that can take the form of detailed guidelines or abstract principles. A few comments on each of them. Design patterns was first introduced by the famous architect Christopher Alexander in his seminal book the Pattern Language, Towns, Buildings, Construction. The idea of patterns is very simple, each of them provides the reusable form of a solution to a design problem. Here is a simple example of a pattern that describes the application of a scrollable list of tabs for Android. Patterns describe this solution at some level of abstraction. For example, this pattern does not say anything about names of the tabs or what should be in the tabs. Has this example show, interaction design patterns detailed not only the appearance of the solution but also as behavior. Each pattern includes one or more idioms. This example describes to the use of tabs for organize and navigation, and the possibility of horizontal scroll of UI controls. According to Christopher Alexander, each pattern must necessarily describe not only a solution, but also a problem that it solves. In the case of indirection design, this is most often a description of the context of use and some dependencies, whereas decisions are already taken. In this example, this is the use when section. On the Internet, you can find many libraries of design solutions which are called libraries of design patterns. But they are not so for this reason, they do not contain descriptions of problems being solved. A description of the effect caused by the application of a pattern is also extremely useful. Most often, this description outlies the changes in usability, it is a behavior, etc. In this example, they are described in the form of a list of pros and cons. In addition to the sections listed, the description of a pattern can contain examples of applying the pattern in various apps as well as the design rationale. You're already familiar with how patterns are used in designing. They are building blocks for which you compose a user interface, creatively combining them. The next form on description of designing knowledge are rules. Each of existing designing rules can be placed somewhere on the continuum. Starting with specific guidelines and ended with extremely abstract ones which do not describe a specific solution, but rather a direction in which you need to think while designing. Design rules should describe the relationship between a solution and the effect of its application. This slide shows an example of a detailed guidelines from Apple and describes the dependence in some of these elements and the speed of searching for the item via the website. However, not all rules created and described the relationship between the solution and the effect. In that case, it's implicitly assumed that the application of a design solution described in such rule increases the usability. Design rules do not require mathematical procedure. It's enough to have some heuristic that will allow designers not to consider unusable solutions. This slide, in contrast, shows an example of the abstract design rule proposed by Ben Shneiderman in his single textbook, Designing the User Interface Strategies for Effective Human Computer Interaction. This rule is one of his eight golden rules of interface design. There are a number of similar ways to force. For example, Don Norman's seven principles for transforming difficult tasks into simple ones. Jakob Nielsen's ten heuristics principles to support his ability proposed by Alan Dix and his colleagues, etc. Design knowledge, regardless of its form, consists of several levels. The top level includes knowledge gained in the course of research from the moment an interaction paradigm first emerges. The second, rules for designer interfaces for a specific platform. But platform, I will the combination of a particular operating system and a type of device. I think it's clear that you cannot use the same design solutions, for example, in a net for Androidware and in another app for regular Android for smartphones. The third level is concerned with product families created by one company. You need to understand that there are always design rules to follow. Interaction design as an applied discipline draws its knowledge from the field of human computer interaction, which formally began its existence since 1983. Since that time, scientists and practitioners have advanced in many directions, including interaction with mobile devices. No matter how tried this device sounds in order to get better at interaction design, you need to read a lot. Principles and rules are related to a specific interaction paradigm are most easily found inside textbooks. This slide shows the rules pertaining to the context aware interaction paradigm from the text book of Alan Dix and his colleagues titled Human Computer Interaction. Since there is no comprehensive work that collects all the principles in accordance with the previously described hierarchy. Written literature on the subject is essentially the only way. During work, the literature should be used more as a reference. My goal here is rather to explain how to think when we need a design rule. You should try to understand the reasons for the emergence of these rules and the rules of its applicability. Later in this week, we will discuss in magnitude design principles of this level applicable in mobile interaction design proposed by Bruce Tognazzini. Google and Apple have invested a lot of effort in the development of their mobile operating systems. They also took care of designers by creating guidelines, which help the designers create more usable interfaces for mobile apps. The guidelines of both companies are structured on rules and patterns with lots of examples. We cover the most common design questions. It should been noted that these guidelines include such that they are not only with interaction design. But also there's visual design and motion design. When you read the guidelines, it's not always clear why this or that will appear on an app. But in any case, you want to get acquired with the content of those guidelines before starting the design. The topics covered by the guidelines are discussed in great detail, so I do not consider it necessary to discuss them in this course. Design knowledge of the platform level also includes pattern library. But unfortunately, at the moment, there is only one library of patterns for the Android platform, which means the requirements of Christopher Alexander but it isn't up to date either. Its creators have not upgraded it for several years. To the best of my knowledge, there are no search libraries for iOS at all. Over the years, design and applications for both platforms. The community of practitioners also did not stand still. On the Internet there are many articles on various topics of interaction design. Sometimes there is materials cover the material deeper than it's covered in platform guidelines. If in your design process you are faced with some design questions to which you have several answers, but to choose between access is difficult due to the presence of a trade off, you can look at how your fellow designers solve similar issues. Such articles are good because in addition to simple list design solutions, they offer some form of justification which can help you make a choice in favor of a decision. Some commercial companies that create many products for at least one of the platforms try to unify not only the appearance of their product for the use of style guides, but also the behavior. The result of such immunification can be interaction design guidelines, which in essence supplement the guidelines of a particular platform. An example here is the SAP Fiori for iOS. Fiori is a technology platform evolved by SAP which is designed to simply the creation of enterprise applications. If you are a designing interactions for a mobile product belonging to a certain family, the avocation of such guidelines is mandatory, if they exist, of course. In addition to the previously described hierarchy, design knowledge can also be divided according to the subject domain to which a mobile app belongs. In various domains, for example, healthcare, e-commerce, etc., user activities have distinctive characteristics. This leads to the fact that some design rules that work well for one domain do not work or even become empty examples in another. When taking on a new project you need to understand whether there are some standards that govern design decisions and or the design process for the given subject domain. Even if there are no such standards you can search for articles in periodic online magazines like UX Matters, Boxes and Arrows, etc. And articles in scientific literature on human computer interaction and design. This will allow you to prepare for the design and gain expertise in this domain. The application of such rules of course does not exclude the need of user research. But allows you not to step on the rake others have already stepped on. For almost the entire fifth week, we talked about how to think design and interactions. So how do design rules work? The most obvious and at the same time correct answer, was given by Alan Dix and his colleagues. Design rules are mechanisms for restricting the space between design options, preventing a designer from pursuing design options that would be likely to lead to an unusable system. The second was all this answer, is that specific designer rules and patterns. How to explore the design base? Suggesting a possible solution that hasn't come to your mind. Is it possible to the rules described for instance in a specific platform guidelines. If you could come up with a solution that, for this context of use, allows you to achieve better usability, then you definitely need to make a choice in favor of this solution. However, do not forget to make sure that it is really more usable by conducting an empirical assessment. A little deviation from the topic. I want to note that you can also accumulate knowledge related to LOH. One way is to identify typical pieces of activity and describe quantitative metrics that allow you to compare the solutions offered for this activity. This slide shows examples of such a generalization. At the level of user experience in general and not only at the level of its pragmatic qualities. To sum up, design knowledge can be stored in free form such as articles, reports, etc., or in structure form like public libraries and sets of design rules. Each design pattern opposite to a design rule must include the description of a design problem that this pattern helps to solve. You need to understand that mobile interaction design is a mature discipline. There are tons of existing solutions or best practices. You just need to know where to find them. These best practices may be specific for a particular subject domain or applicable across domains. The design rules fasten your design process by restricting the space of design options, preventing you from considering unusable ones. However, it doesn't mean that you can't break these rules. If a solution suggested by you results in a high usability in a specified context of use, you are free to choose that solution over the recommended ones by best practices. That's all for now, thank you. [MUSIC]
