[MUSIC] Hello, in this introductory lecture, I'd like to explain what the design work on the How Level consists of. Examine the structure of the design process and its connections with previous steps of the goal directed design process. Let's imagine that you work on a new product, as you remember the overall structure of the goal directed design process looks like what is shown on this slide. Before proceeding to design interactions, you and your team went through all previous phases at least once. So you have a bunch of design-informing models, design ideas, and best practices from competing products, if competitive audits were carried out. As well as context scenarios and requirements of various kinds. Cooper and his colleagues distinguished aspects of user experience and corresponding to these aspects designed frameworks. Two of such frameworks that are relevant to our discussion are the interaction framework and the visual design framework. You can think of them as two parallel flows of work that start independently at the same time, but then merge later on. The independent part of the visual design framework consists of developing a visual style, elements of which we will consider in the eighth week of this course. It should be noted that visual style is only one aspect of the aesthetics of interactions, that is covered in this course. But there are others, concerned with interface sounds, motions, and text. Once the visual style is developed, it could be applied within the work on the apps user interface. But it doesn't mean that it won't change throughout the work. In opposite, elements of the original style such as color, imagery, type, and typography, will evolve along with other aspects of the design, such as the organization of the user interface, lay outs of different screens, etc. I'll add a couple of thoughts about the interplay of these frameworks a little later. Now, let's talk about the structure of the work on the interaction framework. It is shown on this slide. The instance of the design process on the How Level for the situation of presenting a new product is the most comprehensive and illustrates the process the best. Other design situations, for example, add in a new feature or illuminate interaction problems, imply some variations in the structure of the process and its inputs. That will be discussed towards the end of this lecture. Cooper and his colleagues established six steps of the process. I changed the names of some steps to match the content of this course. But the meaning remains the same as in Cooper's book. The steps do not occur sequentially. But we will consider them turn by turn for the sake of simplicity. The goal of the first tab is to choose the type of your app's user interface and the interaction paradigm. We would be implemented as a conversation action assistant or as an app who is conventional touch user interface. Or maybe, it will be an augmented reality app. If the answer isn't obvious, look at the design and formal models and context scenarios you have to better understand the ideal usage context and environment. Don't limit yourself by choosing only one interaction paradigm. Different user tasks by your app can be designed using different ones. For example, imagine that you're working on a mobile app that is aimed at expanding the vocabulary of drivers who learn foreign languages. The idea here is to use driving hours to enhance someone's words repertoire. Such user tasks as signing up, and booting, and initial setup can be designed within a conventional mobile interface. However, when a driver gets into her car, the app connects to the car via Bluetooth and provides the driver with language exercises through a voice user interface. To start design interactions you must understand what information and functionality will be presented in your app. For example, alarm clock apps typically show the user, a list of, well, alarm clocks and allow to operate them. Alarm clock is an example of what Allen Cooper called, data elements. These are entities of an app's subject domain. Ideally, users know and talk about them, think in terms of these entities. Another example, in a mobile banking app, those entities are created costs, bank accounts, transactions, etc. Each entity has a set of attributes. For an alarm clock, those are its label, time, days of the week in which the alarm clock should ring, and so on. Interestingly, one attribute may play different roles in different user tasks. For instance, when a user is looking for a hotel room before her trip, she may make the choice on the basis of its price. While when the user has arrived at the airport, she may be interested in the address of the property only. Entities of subject domains can relate to each other, for example rooms belong to a hotel, each room has several photos, etc. This kind of relationship is usually called composition. There are other kinds of relationships too, for instance specialization. For example, all credit cards are cards but not all cards are credit cards. Credit card is a specialization of a more general entity, card. Functional elements are actions that can be done through the data elements. For instance, each alarm clock can be added, edited, deleted and turned off or on. These are not equal user tasks. User tasks are usually more complex, have a certain goal and may include interaction with functional elements or not. Data elements can be represented in the form of bulleted list, table as shown on this slide, or using graphical representations such as concept maps and entity relationship models. These kind of models is usually called the main models, as you remember when we were discussing design and forming models in the first week, I said that if subject domain includes numerous entities it would be better to model all of these entities. If you haven't done it yet, Cooper and his colleagues recommend to catalogue the entities in A form and B step. Them from context scenarios. It will help you to decide on the organization of the app's interface. As everybody know, we cannot design user interfaces without thinking about how users will interact with them. People use apps to accomplish end goals. Each goal corresponds to one or several users scenarios. These scenarios form a foundation of your design. On the following steps you will construct interfaces around the flow of users' actions described in each user's scenario. Thus, scenarios become rails that guide the design process. The goal of this step is to envision interactions on the values of context scenarios that, as you remember, focus on how the users behave, think, and feel rather than how the app responds, and your knowledge of current user activities. The later is actually a reason why I used the word redesign as the name for this step. Even if there is no app yet, people's activity is already there. You never start from scratch. To do that, Allen Cooper and his colleagues suggest to construct key path scenarios, that narratives as context scenarios are but unlike them, describe how personas interact with the various functional and data elements of the product. Even the simplest app usually covers dozens of users' scenarios. And opposite to conversational user interfaces that ideally should not limit users in what they're saying, that is, in their repertoire of comments and requests. Conventional touch user interfaces limit the number of options available on each screen. Of course, you can place all the options on one screen, but it will make the choice of each option difficult to the user. That's when navigation comes into play. Dividing functional and data elements to different screens allows you to manage this complexity. On this step you work on the organization of your app's interface. At the beginning it's enough to determine which groups the functional and data elements which you've on the previous step formed. This grouping may change later, but it's still useful to provisionally sort elements. It will speed up the process of creating sketches on the next step. On this step, you start sketching the app's interface taking into account envisioned interactions and the groupings of functional and data elements. Working on the interface is crucial to apply best practices. Design rules and patterns stored in platform guidelines and gathered through competitive orders on the previous phases of the goal directed design process. We will discuss best practices in the sixth week of this course. Now, it's important to mention the following. The use of interaction design rules and patterns will allow you not only save time employing wisdom of your predecessors, but also increase the usability of your app, using familiar UI idioms depicted in those design patterns. Working on the user interface, you add some mirrors in turn making the app's interface more and more complete. After you have finished designing the interface in accordance to this key usage scenarios. Allen Cooper and his colleagues recommend that you consider less frequent or less important ones. These include alternative scenarios that represent deviations of key ones. Or scenarios based on end goals of secondary personas. An example of alternative scenario for the Moscow parking app is parking of someone else's car. For instance, relatives. It's extremely rare and include non typical way of choosing the place of parking. Necessary use scenarios are those that personas must perform but only infrequently. A great illustration of such kind of scenarios is signing up. Edge-case use scenarios are those rare exceptions that the app has to be able to handle. An example here is if someone tries to create two alarm clocks with the same label. Most infrequent scenarios should be described in results of your user research. But as you know, your understanding of the usage context is always incomplete. So it makes sense to spend time asking yourself a series of what if questions to generate these scenarios. That is the last step of defining interaction framework. Returning to the interplay of the interaction and visual design frameworks. The fact is that, many aspects of the user interface are important from both interaction and visual design perspectives. For instance, of screens, the use of color, etc. As a result, to achieve both goals, that is make the interface usable and aesthetically pleasant. You shouldn't just paint each var frame in color after the var frame is done. You should work on all aspects of the design of the user interface, its organization, color, imagery, type and typography, layout and composition, interactive behavior, sounds. The choice of UI controls, information visualization icons and so on, you should work on all of them simultaneously. I have to stop here, we will continue discussing the design process on the How Level in the next part of this lecture. Thank you. [SOUND]
