Stages of user needs interface design. Fear of a blank slate when designing interfaces. So what to do to start designing

User interface design principles.

Interface design principles are high-level concepts and representations used in software design. The design principles are based on the physical and mental models of users, their psychology and mental ability.

When designing, it is necessary to highlight the most important principle that will be used when looking for compromises. Trying to adhere to all the principles will negatively affect the result.

There are 3 principles of user interface development:

User control of the interface;

Reducing user memory load;

User interface sequence.

Rules:

It is necessary to give control to the user... Experienced designers allow users to solve some problems in their own way. But : Users must have the necessary skills. If the problem is not solved by the user, then he must be able to control the process. The principles that give the user control over the system: 1) it is necessary to use the mode prudently. 2) provide an opportunity for the user to choose: work with a mouse or keyboard, or with both. 3) it is necessary to allow the user to focus attention (discontinuity). 4) usefulness: to show the user explanatory tips and texts. 5) immediate feedback and feedback. 6) it is necessary to enable the user to freely navigate the interface. 7) the interface should adapt to users with different skill levels. 8) the user interface must be clear (transparent), i.e. with a good interface, the user does not perceive it, but feels as if inside a computer and can freely manipulate objects.

Reduce the load on user memory. Principles: 1) Don't follow short-term memory. Do not force users to remember and do what a computer can do. 2) it is necessary to rely on recognition, not repetition. You must provide lists and menus that contain objects or documents that you can select. Do not force users to enter information manually without system support. 3) visual cues must be provided. Users need to know where they are, what they are doing, and what they can do next. When users are in any mode, they should be informed about it by means of appropriate indicators. 4) it is necessary to provide the function of undoing the last action, its redo and the function of setting the default. It is necessary to use the computer's ability to store and retrieve information about the user's choice and the properties of the system. It is necessary to provide for multi-level systems of undo and redo commands. 5) it is necessary to implement direct access to the interface elements using the keyboard. As soon as the user is familiar with the software product, he begins to experience the need for accelerators. However, when implementing them, you need to follow the standards. 6) it is necessary to use the syntax of actions with objects: object-oriented syntax allows the user to understand the relationship between objects and actions in a software product. Object-oriented syntax was described by the developers of the Palo Alta Research Center (PARC). Xerex. 7) you should use real-world metaphors. Metaphors allow users to transfer their knowledge from the real world to the world of computers. If you find that the metaphor does not meet its purpose in the entire interface, you need to choose a new metaphor. If the metaphor is chosen, then you should strictly follow it throughout the interface. 8) It is necessary to explain concepts and actions. Users should not hesitate about programmatic migration. It is not necessary to show all the functions, but only those in which there is a need. You need to provide easy access to the most frequently used functions and actions. Functions that are rarely used should be hidden and allowed to be called by the user as needed. For untrained users it is necessary to use the "Master" mode. 9) it is necessary to increase visual clarity. it is necessary to use the principles of visual design to facilitate the perception of information.

User interface sequence. Users can transfer their knowledge and skills from one program to another program - these are the benefits. Principles for creating a compatible interface: 1) designing a serial interface. the user must have anchor points when moving in the interface. These are window titles, navigation maps, tree structure. In addition, the user should be able to complete the task without changing the work environment or switching between data entry styles. 2) general compatibility of all programs. Compatibility is implemented at three levels: information delivery; program behavior; interaction technique. Compatibility in the presentation of information- the user can perceive information similar in logical, visual, physical form throughout the program. Behavior compatibility- the same objects have the same behavior. interoperability- ways of working with the mouse and keyboard should be the same in all programs. 3) preservation of the results of interaction - when performing the same actions, they should receive the same results. 4) aesthetic appeal and integrity. 5) encouragement of learning.

Interfaces.

Interface types:

Graphical User Interface (GUI);

Web User Interface (WUI).

GUI: input is carried out by means of keyboard and mouse; for input, a graphical image on the monitor is used.

There are 2 approaches to building a GUI:

Object oriented user interfaces;

Application-oriented user interface (function-oriented interface).

WUI: interaction with the program is carried out via the Internet using the HTTP protocol, i.e. The software generates a Web page that the user views and that the Web browser generates.

Other types of interfaces:

Command line interfaces: the user makes input using the keyboard, but the system outputs the output on the computer screen (prints the text).

Tactile interfaces: are implemented through tactile feedback. They are widely used in computer simulators.

Touch interfaces: These are graphical user interfaces that use the touchscreen as both input and output devices.

Batch interface: these are non-interactive user interfaces in which users specify all the details of a batch task in advance, and receive output at the end of the program.

Attentive PI: are characterized by the fact that they control the user's attention, determining when to interrupt the user, with the help of which message and what level of detail of information to provide him with.

Gesture interface: it is a GUI, in which input is carried out in the form of gestures with hands or with the help of a mouse.

Speech-based interface: an attempt was made to personify the actions of a computer using an animated character that implements interaction in a speech form.

Intelligent PI. These are human-machine interfaces that aim to improve the efficiency and naturalness of human-machine interaction by special presentation of reasoning and actions based on user models of the domain, task and tools such as graphics, natural language and gestures.

Non-team PI. They are implemented by tracking the needs of the user, his actions in order to identify his intentions and needs without the need to enter explicit commands.

Text PI. Differs from command line interfaces in that they enter text, but use different forms of input.

Natural language interfaces. Input is done in natural language (search engines).

Zero-input interfaces. The input is not carried out by interrogating the user, but by means of various sensors automatically.

Scalable UI: This is a GUI in which information objects are presented at different levels of scale and detail, where the user can change the scale of the viewable area to display more details.

Interface history: Batch interfaces were the first to appear (1945-1968), followed by command line interfaces (1969-1980). in 1981 GUI, tactile and touch interfaces appeared.

Interface standardization: ISO / IEC 24752 was published in 2007. This standard deals with the requirements for information technology-based systems. The IBM Common User Access (CUA) is the most comprehensive guide to defining a standard for an object-oriented user interface.

Graphical user interfaceGUI.

Developed in 1981. Consists of graphical interfaces: windows, menus, icons and a mouse was used as an input device in addition to a keyboard. Information is displayed on a two-dimensional graphic screen. The user uses an input device to control the position of the cursor. The information on the screen is organized using windows and is represented by icons. The available commands are collected in the pointing device menu. There is a window manager that provides interaction between windows, programs and the OS. In the PC, this is all modeled using desktop metaphors.

InterconnectionGUIwith object oriented UI.

In OOPI, the user directly interacts with objects that represent entities in a specific domain. The main differences are: the user perceives and acts on objects; the user can classify objects based on their behavior. In OOPI, an object is first selected, and then actions on this object.

Naked Objects technology is a pattern for building a user interface.

This technology has three ideas:

All business logic is encapsulated in domain objects;

UI should be a direct representation of objects in the domain, and all user actions should be reduced to creating or receiving objects and calling the methods of these objects.

UI is 100% generated automatically based on the definition of domain objects.

Benefits: shorter development cycle; changes can be easily made, hence flexibility; simple analysis of user requirements.

Disadvantages: the encapsulation of all business logic in domain objects is questioned. This will make it difficult to scale in terms of speed or lead to the creation of closely related objects. The quality of the automatically generated user interfaces is questioned. The criticism is directed at specific implementations of this pattern.

TechnologyModel-View-Controller (MVC). It is both a pattern for UI design and a pattern for building the entire architecture of an application. This template isolates the business logic from the UI, allowing you to change one without affecting the other.

Describes the relationship between model, view and controller 50. Solid lines are a direct link. The dotted line is an indirect link.

Model - represents information (data) that the application operates on and business rules used to manipulate the data.

View (representation) - UI elements (visual design elements).

Controller- implements the transfer of a model of user actions (keystrokes, mouse movements, etc.)

Template description

Template for building an application. Typically, an application is broken down into separate layers that run on different computers.

Presentation layer;

Business logic layer;

Data access layer.

In MVC, the presentation layer is broken down into View and Controller. Web application, where the view is the html page and the controller is the code that processes dynamic data and generates the content of the html page, the model is represented by the actual data stored in the database, xml files, etc. business rule - a rule that transforms actual data in response to user input.

The script of the program:

The user interacts with the UI (clicks a button);

The controller handles the UI event, which is often logged with a callback function;

The controller informs the model about the user's actions, leading to a change in the state of the model.

The view uses the model implicitly to generate the appropriate UI. The view gets the data it needs from the model, but the model has no direct relationship to the view.

The UI is waiting for further user actions.

Design template.

A model is a domain-specific representation of information that an application operates on.

Business logic gives meaning to raw, unprocessed data. Many applications use a persistence mechanism in the database. Often, object-relational mapping libraries can be used to store model state in the database.

The view displays the model in a form suitable for interactions. Usually - in the form of user interface elements. Moreover, for the same model, different representations can be used for different purposes.

The controller responds to events and processes them. These are usually user actions, but not always.

User interface development stages (user interface design process)

UI design consists of the following stages:

Determination of the required functionality of the system (analysis of requirements). This stage is very important in its essence. Traditionally, the definition of system functionality comes from the sales department. There are two sources of information for the sales department (complaints from existing customers and a competitor's system). Both of these sources are unreliable. There are also two methods of analysis: 1) analysis of user goals: people do not need tools on their own, but they need the results of their work. The main task is to avoid unnecessary specifics, i.e. a description of what the future functionality should be. 2) analysis of user actions: This method consists of observing people performing their task using existing tools (this can be a system of competitors and objects of the real world). In addition, in addition to actions, it is necessary to analyze the results of work. One should strive to minimize the number of functions. There are two approaches to the allocation of functions: 1) the system as a whole is considered. the maximum number of functions is allocated, and the results of many of the functions are the sum of the results of other functions. 2) all composite functions are removed from the system.

Creation of custom scripts. The goal of this stage is to write a verbal description of the user's interaction with the system. It is necessary to pay more attention to the goals of the user, without specifying how exactly the interaction takes place. The number of scenarios can be arbitrary, but they must include all types of tasks facing the system and be realistic. The benefits of scripts are: scripts are used for subsequent testing; scripting leads to a better understanding of the system design and allows you to optimize future interactions.

General structure design. At this stage, based on the collected information, it is necessary to create a general structure of the system, highlighting individual functional blocks and connections between them. All functions must be grouped, however, more than three functions should not be included in one block. There are three types of links between blocks:

Logical connection;

Communication on the basis of users' submission;

Procedural communication.

Logical link defines the interaction between blocks from the developer's point of view.

Communication by user view- the connection between the blocks arising in the course of solving a specific problem. A relationship capable of identifying relationships as perceived by users is a card sorting classification. All concepts are recorded on the card, then a group of users needs to sort or divide them into groups. Disadvantages: the need to search for representations of the target audience. At least 4-5 people are required.

Procedural links: the only way to get information is by observing users. As a result of this observation, we get the structure of the system, which must be represented graphically.

Design of individual blocks. At each stage, separate user interface screens are designed.

GOMS (Goals, Operators, Method and Selection rules- goals, operators, methods and rules for their selection).

Objectives Are simply the goals of the user.

Operators Are those actions that the software allows the user to perform (for example, mouse actions).

Methods Is a sequence of actions familiar to the user that allow you to complete a task.

Selection rules- what the user is guided by.

Developed in 1983. All user actions can be decomposed into components. By limiting the nomenclature of these components, you can measure the time of their execution on a mass of users and get statistically correct estimates of their duration. To determine the speed of solving any problem, knowing the duration of each component, you can find the duration of the entire process. The best process will be the one with the shortest execution time. Examples of methods: pressing the mouse button - 0.1 sec; moving the mouse cursor (Fitts model determines the time of positioning the mouse cursor depending on the distance to the object and its size) - on average 1.1 sec; taking or throwing a mouse - 0.4 sec; choice of action - 1.2 sec; system response time - from 0 to ∞.

Creation of a glossary.

Collection and initial check of the complete system diagram.

Modern trends in the construction of user interfaces.

User interfaces have evolved towards increasing intellectualization. The main such areas are:

Increasing the intelligence of interfaces due to a shift in emphasis towards the intelligent choice of methods for solving a problem based on the requirements for a solution formulated by the user. Users indicate what they need, i.e. the result of the program, and do not indicate by what means it should be achieved.

Changing the way a user interacts with a computer. for example, the use of voice technology and natural ways of communication instead of traditional (keyboard, mouse). The main problem in voice technologies is adaptation to a specific user.

AGENT THEORY

Theory of agents (formalized to describe agents and express the desired properties of these agents).

Methods of agents 'cooperation (for studying the methods of agents' cooperative behavior in joint problem solving).

The architecture of agents and multi-agent systems.

Agent programming languages.

Methods, languages ​​and means of communication of agents.

Methods and tools to support the mobility of agents.

Agent properties and terminology

An agent is an entity that resides in some environment, from which it receives data, and which reflects events occurring in the environment, interprets them and executes commands that affect the environment.

When implementing an agent, you can contain both hardware and software components.

Intelligent agent - understands a software or hardware system that has the following properties:

Self-control (the ability to control one's actions);

Autonomy (ability to work without a person)

Social behavior (ability to function with another agent)

Reactivity (the ability to perceive the environment and respond to its changes)

The agent's ability to take the initiative, i.e. generate goals and radically act to achieve them.

Additionally, an agent is required to have a certain subset of mental properties: knowledge (a constant part of agents' knowledge about themselves and about the environment, other agents)

Beliefs - knowledge of the agent about the environment and other agents that can be lured in time, they can become incorrect.

Desires - the state of the situation, the achievement of which, for various reasons, is desirable for the agent. The desires of the agent can be conflicting, and the agent does not assume that all of them can be fulfilled.

Intentions are what an agent must do according to obligations to other agents, or what follows from his desires (in accordance with desires).

Goals are a set of final and intermediate states that an agent has adopted as a behavior strategy.

Commitment - tasks that an agent undertakes, on behalf of other agents in the framework of operational behavior, in order to achieve common goals.

The theory of agents studies various ways of forming a description of agents.

The following tool is used to describe agents:

calculus of predicates (there are restrictions and it is impossible to fully describe the properties of an agent)

use of metalanguages

use of extensions of well-known modal logics containing special operators that have non-truth values.

When choosing a formal model, the agent, in particular, can be a representation of mental concepts, solves two classes of problems:

Syntactic problem

Semantic problem

Accordingly, the formalization language must contain both the formalization language and its own semantic model.

The problem with using modal logics is that the agent descriptions are dynamic in nature. It is necessary to establish a connection with time.

For the use of modal logics in describing agents, it is proposed to develop means for describing the temporal aspects of the “behavior” of agents. For this, extensions of existing modal logics are being developed.

An alternative option is to use a set of algorithms and data structures to interpret symbolic structures that are associated with the corresponding symbols and their strings.

Collective behavior models of agents

In the case of agent interaction:

The agent cannot solve the task on his own and turns to other agents for help;

One big difficult task is being solved by a team of agents.

In order for the agent to interact, the following problems must be resolved:

Formation of joint action plans

Taking into account the interests of the agent's companions

Synchronizing collaborative activities

Organization of negotiations on joint actions

Recognizing the need for cooperation

Choosing the right partner

Teaching behavior in a team

Separation of duties and decomposition of tasks

Resolution of conflict situations, etc.

This article will be useful for those who are just starting to create interfaces - you will get an idea in which direction to move. We do not promise anything new to the experienced, the maximum - your knowledge will form a coherent picture. So where do you start designing?

Running to read books and google articles for inspiration is not a good idea. Reading interfaces are not designed by themselves and do not get better quality. Of course, theory is good, but, as in any business, you can't get very far on theory. It is also pointless to refer to reference materials at the initial stage - this must be done with specific questions. And the endless search for design programs does not increase productivity.

So what do you do to start designing?

First, when you get started, you should think about the result: pictures (that is, interfaces) and actions. Secondly, specific steps will help: understand the problem, formulate a task, create at least something and then improve it, write stories (we will tell about them below in the text) or seek advice from experienced people.

No experience and no answer to the question "Where to start?" fear arises. It's scary to do something new, but there is no point in sitting around endlessly. The first pancake will still be lumpy. Don't be afraid to talk about your first experience. Any interface you make - even if it's terrible - can still be used.

Making stories

The first thing to understand is that interfaces are a language that we already know. Any user can read and write in this language. With mistakes, of course, but he can. Like any language, interfaces exist for transmitting thoughts. Among people, it is customary to express themselves coherently, so the first step is to formulate ideas and create a plot that captures the listener and gives impetus to everything that happens.

To understand what we mean by the term “history”, let's imagine: Maxim becomes a client of the Star of the Neva dealership - he bought himself a new car. When concluding a contract at the company's office, the employees of the car dealership inform him about the existence of an online system for customers, where he can see his payments, loan payments, reminders about technical inspection and insurance, as well as news from the car dealership.

With this approach, we begin to "unwind" the story. The most important thing in the process of coming up with a story is to work out all possible scenarios for the development of events.

Upon entering the system, Maxim sees his first payment in a car dealership, the characteristics of his car, documents for the car, the name of his manager. If his purchase falls under the action of any promotion, he will see a notification about the conditions of the promotion in the system (for example, a free car wash of a luxury class during August).

Being at home, Maxim becomes more and more familiar with the system. In the process of acquaintance, the system adjusts to Maxim and shows the most relevant information for him.

Without a story, there is no product, no project, no interface. A coherent story will help explain user behavior and understand what he is missing.

Interacting with a computer, a person tries not to turn into a machine, but, on the contrary, to humanize the system. Whichever functionality you attach, without emotions a person will not be interested. People expect new experiences and reactions from the computer. Good stories evoke an emotional response: like it or dislike it, fast or slow it, want it or not.

Burn with a verb

Before you start drawing something, have a team discuss the coherent story you are going to capture. Add verbs to guide the plot, so you can quickly uncover the scenario of user behavior. The letter component deserves special attention. Analyze the words and wording: no matter what adjectives and nouns appear in the story, nothing will happen without verbs.

Distractions in the style of "it would be nice to make buttons here" should be cut off, because they divert the thought away from the coherent story. When working on an interface, everyone should know the plot of user interaction with the service and scroll through it in their head. Without a coherent history, no coherent interfaces are obtained.

Let it play!

The popular rake that you can step on is to say, "Fuck the theory, let it play!" Of course, this is also a way to learn how to design: we master the tool and along the way we get the skill. But the problem is that the tool will not allow you to solve the problem correctly, knowledge and experience usually help in this. And so that you do not waste time looking through programs, we will briefly tell you about them.

I would like to give you a simple but paradoxical advice: don't believe everything they say about design.

The thing is that design in web development, for many historical reasons, developed through the stump deck and still represents a vague, poorly described and little understood definition. The situation has been slowly improving in recent years, but there is still a lot of explanatory work - and therefore anyone who wants to understand the design needs to turn on their head and not be afraid to question every seemingly common truth.

There are many such "common" truths, and together they give rise to a terrible and terrible set of myths about design - I would like to talk about the most important of them today.

Myth # 1. Design is an add-on service.

A designer engaged in an important community service

Many people think that the design phase is an additional service that can be neglected. This is not true.

Why do we create IT products? If we are in our mind and good memory, we create them for the sake of solving business problems (our own or our clients - it is not so important); the solution of these business problems, in turn, relies on the fulfillment of the user's tasks by the product being created, taking into account market conditions, technological limitations and everything else.

In order for the product to meet all the conditions, it is necessary to collect together a lot of contradictory, non-specific and hard-to-find information - talk with all the actors, study the accompanying business processes, get acquainted with external systems, look at competitors, and so on, and the collected information would be good to capture and bring together so that all team members have an equally good understanding of the input.

Further, on the basis of the collected information, you need to come up with a product, and come up with it so that it does not contradict the conditions of the task, but, on the contrary, would contribute to their implementation - and such a product is a complex organism, where all parts are interconnected with each other. The invented product, again, needs to be properly fixed so that both the customer and the developer understand what they will get in the end (and could refine this product in the future).

Is it possible to make a somewhat complex and useful product, bypassing all these stages? Agree: unlikely. Meanwhile, all the described processes constitute what is commonly called design - analysis (analysis of the problem conditions), synthesis (product formation) and fixation (drawing up the correct design documentation).

Design cannot be an additional service, since this is the flesh of web development and is aimed at an understandable result, and not at mastering budgets or fighting for all the good against all the bad.

Myth # 2. Design is expensive.

The project manager knocks the budget out of the customer

There is an opinion that the design stage only increases the cost of the product.

In this regard, I love to quote Karl Wiegers - the patriarch of systems engineering, the author of the wonderful book "Developing Software Requirements" and just a smart person.

Karl Wigers once conducted a study of the American IT development market and calculated that on average 40% of development budgets are wasted, and this money is lost not through the fault of crooked developers or bad customers, but simply because two parties - the customer and the developer - just could not agree among themselves.

Forty percent - and this is for America, where a completely different relationship between the customer and the developer reigns! For Russia, it seems to me, this figure is even higher - one and a half times of the commercials.

At the same time, the correct system design, according to the calculations of the same Wigers, takes 15-20% of development budgets (and this figure is fully confirmed by our experience).

It turns out an interesting effect: we spend a fixed 15-20% on design, but at the same time we minimize the “waste” expenses (the same 40% of the budget) that can potentially bury the project and, moreover, extremely delay the time for obtaining a workable product.

Thus, the cost of correct design paradoxically affects the cost of the entire project as a whole: on the one hand, the design stage is not free and takes a certain amount of the budget, but on the other hand, it reduces the cost of the entire project as a whole by removing the risks associated with poorly thought out and therefore an unpredictable product.

Myth number 3. Design is writing TK

TK elephant

We often hear that design is a process of writing a technical specification that can be attached to a contract. This is not true.

As we found out during the analysis of the previous myth, design minimizes development risks. You will laugh, but this is its only and main purpose - everything else harmoniously flows from this fact:

• design allows you to take into account the interests of users (and thereby minimize development risks);
• design allows taking into account the interests of the customer (and thereby minimizing development risks);
• design allows you to take into account all significant external factors (and thereby minimize development risks);
• design allows the parties to get a unified vision of the product (and thereby minimize development risks);
• design allows you to accurately predict the timing and cost of development (and thus ... well, you get the idea).

Writing TK- this is just one of the tools that allows you to unambiguously, sufficiently, systematically and alienably fix the requirements for the product in a format that is understandable for the developer. Yes, this tool can be called the most important, but the design stage carries a much more important task - and this must be remembered.

Myth # 4. Design is about user interfaces.

A product with a well-thought-out user-friendly interface

For many reasons, design in our (and not only in our) web development market is strongly associated with interfaces.

Indeed, interfaces are the most noticeable part of the product: it is with it that users will contact, who will perform their tasks using the product and thereby contribute to the fulfillment of the customer's tasks.

On this basis, can interfaces be considered the only worthy design goals? Of course not: the interface is only the tip of the iceberg of the product, and if we are talking about proper design that really minimizes development risks, then we must also deal with what happens inside the product: the structure of its data, the logic of its behavior, connections with external systems, administrative interfaces and much more.

User interface is just one component of a product that provides users with access to product functionality and data. It is important to design it, but it is harmful to be limited only to it.

Myth # 5. A manager can also design

Manager busy with profile activity

As we have already found out, design is a complex process associated with painstaking, delicate work. In order for the design to fulfill its tasks, this work must be done as efficiently and thoughtfully as possible. Design, in other words, requires the performer to have a very specific value system, where the quality of work and personal responsibility will be paramount.

At the same time, design is often left in the hands of managers as people who bring together all the processes and threads of development. It would seem that everything is logical and correct, but one important point is not taken into account: good managers have a completely different system of values, where the project deadline and its budget are at the head of everything.

In large projects and, in particular, in custom development, this plays a very cruel joke with managers: if a manager is faced with a dilemma, solve a problem related to the project as a whole (for example, getting a designer out of a binge is a completely real story, by the way), or solve the problem related to design (write down the data protocol in more detail in the technical specification), then any manager will choose a solution that will extinguish the fires raging here and now. In fact, the unfinished TK will affect somewhere in the long term, but the design fire that is not extinguished in time will lead to the loss of the project right now. And, in the end, how can you calmly write technical specifications when you are constantly distracted by clients on trifles?

And so it will be throughout the development. If we add the professional aspect to this value aspect (after all, a designer must be able to do a lot of things that a manager is not obliged to know), then it is easy to understand why a separate, specially trained person with his own system of values ​​should be involved in designing.

The only exception to this rule is internal development. In conditions when the manager has only one project, and the problem of deadlines and budgets is not so acute, the manager can take on the functions of a designer. True, in this case, he becomes a product manager - and this is a separate story that deserves its own article.

Myth # 6. Designing should be done by psychologists.

The technical content of the product according to the psychologist

Some companies, including the largest ones, believe that people with psychological education should do the design. This myth grows out of the belief that the designer must be solely the interests of the users. As we have already found out, this is not so - the designer deals with the entire product as a whole and takes into account the interests of both users and the customer, not to mention the specifics of the system. All this requires technical skills, which psychologists for the most part lack.

Another thing is that psychologists can be involved in a narrow part of the design - working with interfaces or analyzing user preferences - but all this should take place under the supervision of a product designer who will take into account all the technical subtleties and nuances.

Myth # 7. Design should be done by engineers.

In contrast to the myth about psychologists, there is a myth about engineers - they say, a designer must be a programmer. As you, I think, have already guessed, this is also a bad option - a spherical programmer in a vacuum is able to think over the general architecture of the product, but is unlikely to be able to accurately sense the users and understand the customer's requirements. Actually, I came across such developers, but in their mindset they were, more likely, designers who, through a misunderstanding, became developers.

As with the past myth, developers can be involved in design - but only on data structure and functional descriptions of the product under the supervision of the designer (although the designer must do this himself if necessary).

Who is a designer?

Who should the designers be? This is a very difficult question, which I can briefly answer as follows.

• It is worth accepting that the "correct" system designers are not taught anywhere yet.
• Most often, the correct designer is born at the junction between the conventional humanities and technical sciences.
• More often than not, a good designer does not know that he is a good designer and works in a leftist specialty that does not please him.
• Such a “non-activated” good designer has a schizophrenic track record, a near-technical background, a broad outlook, and the mindset of a good classical engineer.
• The designer must understand designers, developers, customers and users.
• The designer must be able to communicate with people.

My personal experience shows that the designer is a concept rather innate. e It’s possible to teach a designer the necessary tools and techniques relatively quickly (seriously, from three months to six months), but it’s almost impossible to put the necessary system of values ​​and mindset into it.

But there are such people - and it was for their search and formation that I created at one time the Guild of Free Designers, and this is also a separate topic for conversation.

There is no one-size-fits-all design approach

The designer can't stand the heat of the project

There are many approaches to design, and an inexperienced reader can easily go crazy with the abundance of techniques, approaches and abbreviations, generously flavored with terminological mess (all these UX, UI, CX, HCD and other IDDQDs with curved Russian-language counterparts).

Some, however, try to derive universal design models, but in the end it turns out that in an attempt to combine the existing 20 (conditionally) approaches to design, we end up with 21 approaches - and the methodologies seem to begin to breed themselves.

Experts conclude on this basis that a single approach to design does not exist and cannot be - they say, everything is strictly individual, and therefore there is nothing to systematize.

This is also a myth that personally does not suit me categorically. A common design approach exists, but it requires a separate, large and very personal conversation; so, with your permission, we will refute this myth a little later - towards the end of September, when my long article on this topic will be published on Cossa.

Instead of a conclusion

So, what did we find out with you today?

• Designing is worth the money and allows you to reduce your development budget.
• Design minimizes development risks.
• Design advocates for the interests of the product as a whole.
• Designers should be engaged in design (that's the truth, huh?).
• Design is a large and complex process that has its own patterns and common approaches.
• Do not believe what they write about design - do not be afraid to think for yourself, offer your views and defend your vision.

And the last request: do not take my word for it - I will only be glad if you don’t disagree with me and defend your point of view: this will be an occasion for a useful and big conversation, during which another truth may appear - and is it not great?

2.2. USER DESIGN STEPS INTERFACE

Studies of the psychological aspects of human communication with a computer, conducted at one time, have shown that one should in every possible way strive to dehumanize this communication, that is, the user should not perceive the computer as a full-fledged interlocutor. Nevertheless, the exchange of information between the user and the computer (more precisely, its software) in all formalities corresponds to the concept of "dialogue" in the generally accepted sense. Probably, the reader, even without the help of the Explanatory Dictionary, will be able to list the basic rules that must be followed in order for the dialogue to be constructive:

firstly, the participants in the dialogue must understand each other's language;

secondly, they should not speak at the same time;

thirdly, the next statement should take into account both the general context of the dialogue and the latest information received from the interlocutor.

If the interlocutors discuss issues related to any special area, they should adhere to the same terminology; if one of them is trying to explain something to the other, he should first explain the basic terms and concepts.

It should also be added that the use of additional means of expression contributes to better understanding. Sometimes one successful illustration replaces dozens of words. For example, to the question "How to get to the library?" it is best to answer with a city map handy.

Now let's remember what our interlocutors don't like.

First of all - excessive familiarity. In addition, few people like it when, during a conversation, they pull his sleeve, unscrew a button, or use some other original ways to attract attention. Very short answers and too long pauses can confuse the interlocutor, and the abuse of special terms or jargon in general can lead to a premature end of the conversation.

The above reasoning is very general in nature and is applicable to almost any dialogue, regardless of the relationship between the interlocutors and for what purpose the dialogue is being conducted. However, these factors significantly affect structure dialogue, that is, the form of communication. For example, if two friends met, then the dialogue resembles a game of tennis: the initiative alternately passes from one interlocutor to another; if you come to a restaurant, then your communication with the waiter is limited to the choice of dishes from the proposed menu, and when applying for a passport, the official will offer to fill out one or two questionnaires, and then review them, clarifying certain points if necessary.

Thus, when designing a user interface, it is necessary to determine:

Dialogue structure;

Possible scenario for the development of the dialogue;

Visual attributes of displayed information (message syntax).

2.2.1. CHOICE OF DIALOGUE STRUCTURE

The choice of the dialogue structure is the first of the steps that must be performed when developing an interface.

The four variants of the dialogue structure considered below are varieties of the “question-answer” type structure, nevertheless, each of them has its own characteristics and is most convenient for a certain class of tasks.

DIALOGUE TYPE "QUESTION - ANSWER"

The structure of a question-and-answer (Q&A) dialogue is based on an analogy with a regular interview. The system takes on the role of an interviewer and receives information from the user in the form of answers to questions. This is the most well-known dialogue structure; all computer-controlled dialogues, to one degree or another, consist of questions to which the user answers. However, in the Q&A structure, this process is clearly expressed. At each point of the dialogue, the system displays one question as a hint, to which the user gives one answer. Depending on the answer received, the system can decide which next question to ask. The Q&A framework provides a natural mechanism for entering both control messages (commands) and data. There is no restriction on the range or type of input that can be processed. There are systems in which answers are given in natural language, but more often one-word sentences with limited grammar are used.

Dialogue in the form of questions and answers provides sufficient support for the user, since even a short leading question, with a reasonable construction, can be self-explanatory. The Q&A framework does not guarantee a minimum amount of typing in terms of keystrokes, but with the right choice of acronyms, any redundancy can be reduced. However, the Q&A structure has one major drawback. Even if the input is fast enough, for a person who already knows what questions the system asks and what answers need to be given to them, answering a whole series of questions is rather tedious.

With the advent of the graphical interface, the Q&A structure has become somewhat outdated, but nevertheless it has certain advantages. This structure can meet the requirements of various users and data types. In particular, such a structure is especially appropriate when implementing a dialogue with many "branches", i. E. in cases where each question provides a large number of answers, each of which affects which question will be asked next. For this reason, the Q&A structure is often used in expert systems.

DIALOGUE BASED ON MENU

The menu is perhaps the most popular option for organizing data input requests during a computer-controlled dialogue.

There are several basic formats for displaying menus on the screen:

List of objects selected by direct indication, or by indication of the number (or mnemonic code);

Menu in the form of a data block;

Menu in the form of a data line;

Menu in the form of pictograms.

The data bar menu can appear at the top or bottom of the screen and often remains in this position throughout the dialog. Thus, using the menu, it is convenient to display possible options for input, available at any time when working with the system. If the system has a sufficiently large variety of options for action, a hierarchical structure is organized from the corresponding menus. Additional menus in the form of data blocks "pop up" on the screen at the position determined by the current position of the pointer, or "drop out" directly from the top-level menu bar. These menus disappear after you select an option.

The pictographic menu is a lot of selection objects scattered across the screen; often, selection objects contain graphical representations of work options.

The user of the dialog menu can select the desired item by entering a text string that identifies the item, pointing to it directly, or browsing the list and selecting from it. The system can display menu items sequentially, while the user selects the desired item by pressing a key.

The menu can be used with equal success to enter both control messages and data. An acceptable menu structure depends on its size and organization, how menu items are selected, and the user's actual need for menu support.

The structure of the menu type is the most natural mechanism for working with pointing and selecting devices: a menu is an image of those objects that are selected by the user. If the dialog consists solely of menus, it is possible to implement a serial interface in which the user only uses devices for pointing; however, such consistency is rarely achievable in practice. It should also be noted that while working with these devices does not require professional keyboard skills, for a trained user this is not the fastest way to select from the menu. Instead of specifying, the user can indicate his choice by entering the appropriate identifier.

Menu is the most convenient dialog structure for untrained users; strict order of opening and hierarchical nesting of the menu can irritate a professional and slow down his work. Traditional menu structures are not flexible enough and do not fully align with dialogue adaptation methods, such as typing ahead, that can speed up the pace of a trained user. For more details on the organization and visual presentation of the menu, see the section "Designing controls".

DIALOGUE BASED ON SCREEN FORMS

Both the question-answer structure and the menu-type structure assume that a single answer is processed at each step of the dialog. A screen-based dialog allows multiple responses to be processed in a single dialog step. In practice, forms are used mainly where accounting for any activity requires the entry of a fairly standard set of data. The person filling out the form can choose a sequence of answers, temporarily skip a question, go back to correct a previous answer, and even “tear up the form” and start filling out a new one. He works with the form until he fills it out completely and sends it to the system. The software system can check each answer immediately after entering, or wait and display a list of errors only after filling out the entire form. In some systems, the information entered by the user becomes available only after pressing the "enter" key at the end of filling out the form. Whether to validate an answer directly or postpone validation until all responses are entered is a tricky one: error messages displayed immediately after a response can be distracting, but they can also have a positive impact. In general, in cases where information for input is selected from some integral document, it is better to postpone the check until the end of filling out the form, so as not to interrupt the input process; if there is no such integrity, then the check should be performed immediately after entering the answer (after filling in the next field).

If any error is encountered, the application should not re-render the empty form; the form is displayed with previous answers and mistakes. A new "form" is issued only in case of a corresponding request from the user.

Thus, this structure is appropriate to apply where the source of data is the existing input ("paper") form of the document.

It is not necessary for the appearance of these forms to be the same (it may even make the data worse on the screen), but all data items entered must be in the same relative order and in the same format as in the original document.

Often all the required input units cannot be displayed simultaneously within a single screen (or window) and must be divided into groups that are displayed on a sequence of screens (windows). It is important that this splitting maintains logical connections and does not lead to the separation of related parts of the document.

The screen-based dialog structure provides a high level of user support: error messages and help information can be provided for each question on the form. The user can also be assisted by including some elements of the answer format in the question or in the answer field. This structure allows you to increase the speed of data entry in comparison with the structure of the "question-answer" type and to manipulate a wider range of input data than the menu; in addition, users of any skill can work with it. Because this structure is sequential rather than tree-like, it is less suited to work in a choice mode. Another area of ​​application of screen forms is setting query parameters in databases. This mechanism is sometimes referred to as pattern query. ( Query by Example).

One of the types of filling out forms are also multivariate menus. In such menus, the user is presented with a list of options and is not limited to a single choice; several options can be specified.

DIALOGUE BASED ON COMMAND LANGUAGE

The command language-based dialog structure is as common as the menu-type structure. It is very often used in operating systems and is located at the other end of the spectrum of dialog structures in relation to the structure of the menu type. Historically, this is the first of the implemented dialogue structures.

With such an organization of the dialogue, the software system does not display anything except a constant prompt (command prompt), which means that the system is ready for work. Each command is entered on a new line and usually ends with the "enter" key. The responsibility for the correctness of the given commands lies with the user. The system informs about the impossibility of executing an incorrect command, without explaining, as a rule, the reasons.

Like a menu, a command-based dialog is convenient for entering control messages, but it provides more choice at any point in the dialog and does not require a hierarchical organization of the programs serving it.

A software system can support a fairly large number of instructions, but in practice, you should limit their number so as not to overload user memory. The command language structure is not well supported by the user and is suitable mainly for trained professionals. Before using such a system, it is necessary to undergo a training course and further study the features of working with documentation, and not in practice. Moreover, since the system does not know what the user intends to do, it is difficult to offer any real help in the process of work, other than issuing certificates of a fairly general nature.

Since this structure assumes a large amount of memorized material, the names of the commands should be chosen so that they carry a semantic load and are easy to remember. The developer should strive to avoid unnecessary functionality arising from the desire to create a separate command for each function performed by the system, that is, do not create many different commands with often overlapping functions. Such "good" intentions often lead to the emergence of a large number of keywords for commands and syntax rules, many of which are rarely used and only complicate the work.

Dialogue needs to manipulate data. In command language-based interfaces, this is usually accomplished with compound command strings, where the keyword for the command (what to do) precedes the parameter list (input). Parameters in the list can be specified in one of two forms - positional or key. In the first case, the purpose of the parameter is determined by its place on the command line. In the case of key parameters, each value is preceded by a specific identifier that defines its purpose.

Positional parameters reduce the amount of input information, but their significant drawback is that the input values ​​must be specified in a strictly defined order, violation of which is poorly diagnosed by the system and can lead to serious consequences. Setting positional parameters becomes more difficult if the list is large enough. They seek to compensate for this disadvantage by allowing the omission of immutable parameters by introducing two delimiters one after the other.

Key parameters reduce the load on the user's memory in the sense that there is no need to remember their order; in addition, optional parameters can be omitted. On the other hand, in this case, the user needs to memorize a lot of keywords, and the developer needs to choose “meaningful” names for them. This approach also takes longer for the system to recognize random keywords.

Many command languages ​​support macros, which expand the functionality of the dialogue without increasing the number of commands. A macro contains several separate command lines. When accessed during a dialog, individual lines of macro commands are executed one after another, as if they were entered from the keyboard. This significantly reduces the dialogue sessions, the content of frequently repeated sequences of commands, which, in fact, are formatted as macros.

The command language structure is the fastest and most flexible of all dialogue structures in terms of its capabilities. Most natural language-based user interfaces are implemented using command languages ​​with a very large set of keywords. The trained user enjoys the feeling of being in control of the system, not the other way around. However, this structure does not provide support for the user, so even experienced users find it very difficult to use all the capabilities inherent in it. Most users are familiar with only a very limited set of tools, with which they work regularly.

The foregoing can be presented in the form of the so-called "selection table" (Fig. 2.1).

Criteria	Choice user	Dialogue type
		menu	question - answer	language teams	filling screen forms
Purpose: Inquiry Calculations Difficult choice Data input Data input (large volume)		+ + +	+ + + + +	+ + + + + +	+ + +
User type: Programmer Non-programmer Has work experience No experience		+ +	+ +	+ + *	+ + *
Studying time: very small Less than 1 day More than 1 day		+ +	+ +	** +	** +
Evaluation result

* - the use of this type of dialogue by this category of users requires a help system;

** - the use of system funds is possible only to a limited extent.

Fig. 2.1. Selection table option

Along with those indicated in the table, other selection criteria can be included in it (the presence of tools for developing the interface, the nature of the user, restrictions on the available resources, etc.).

The selection of the most appropriate table-based dialog structure is performed as follows.

1. Close the "Dialogue type" columns.

2. In the User Choice box, mark the criteria relevant to the application in question.

The main value of the table is that it can be used as an initial option for choosing the type of dialogue, or as a means of final checking the correspondence of the selected type of dialogue to the considered criteria.

If it is assumed that some items are more important than others, you can take them with different weights. You can also specify which items should be considered unconditionally fulfilled; types of dialogue that do not correspond to at least one of these points should be immediately rejected, no matter how many points they score on the rest of the points.

2.2.2. DEVELOPMENT OF A DIALOGUE SCENARIO

The development of a dialogue in time can be viewed as a sequence of system transitions from one state to another. Obviously, none of these states should be "dead-end", i.e. the user should be able to switch from any current state of the dialog to the required one (in one or several steps). To do this, during the development of the interface, it is necessary to determine all possible states of the dialogue and the paths of transition from one state to another. In other words, it is necessary to develop dialogue script.

The goals of the dialogue script development are:

Identification and elimination of possible deadlocks in the course of the development of the dialogue;

The choice of rational ways of transition from one state of the dialogue to another (from the current to the required one);

Identification of ambiguous situations requiring additional assistance to the user.

The complexity of developing a script is mainly determined by two factors:

the functionality of the application being created (i.e., the number and complexity of the implemented information processing functions) and the degree of uncertainty of possible user actions.

In turn, the degree of uncertainty in the user's actions depends on the chosen dialogue structure. The most deterministic is the dialog based on the menu, the least - the dialog of the "question-answer" type, controlled by the user.

It follows from the above that the dialogue scenario can be simplified by reducing the degree of uncertainty in user actions. Possible ways to solve this problem are:

the use of a mixed structure of the dialogue (the use of menus in order to "restrict freedom" of the user where possible);

application of incoming control of input information (commands and data).

Additional possibilities for reducing the uncertainty of user actions are provided by an object-oriented approach to interface development, in which a list of properties and allowed operations is predetermined for each object. This approach is most effective when creating a graphical interface; these issues are discussed in more detail in the section "Features of the graphical interface".

While reducing the number of possible dialog states, the developer must also remember to reflect the user's support tools in his script, which undoubtedly makes the script more complex.

The way a dialogue script is described depends on the degree of its complexity. The existing methods for describing scenarios can be divided into two large groups:

informal and formal methods.

The main advantage of formal methods is that they allow you to automate both the design of the dialog and its modification (adaptation) in accordance with the characteristics of the user.

Currently, the most widely used formal methods for describing scenarios are based on Petri nets and their extensions, as well as based on knowledge representation systems (frame models and production systems).

Regardless of the way of describing the scenario, its main structural unit is dialogue step, corresponding to one act of user interaction with the system. The dialog step can be schematically represented as shown in Fig. 2.2.

Fig. 2.2. Dialogue step

The dialogue script allows you to describe the process of user interaction with the application at the level of the applied problem being solved by him. However, for a software implementation of the interface, such a description is too general. Therefore, at the implementation stage, it is necessary to move to the level of describing the corresponding processes using the used application development tools.

RATE OF DIALOGUE

The process of communication between a user and a computer is associated with a number of significant objective and subjective limitations and must correspond to the psychophysiological capabilities of a person: the ability to receive and process information, the volume of sensory and short-term memory, the ability to concentrate on the most important information, the ability to reproduce information from long-term memory, etc. P.

In this regard, when developing a dialogue script, such psychophysiological characteristics of potential users as motor skills, reaction time, color sensitivity, etc. should be taken into account. In this section, we will consider in more detail the requirements for one of the most important characteristics of the interface - for the provided pace of dialogue. The rest of the requirements listed above will be discussed in subsequent sections of the book.

The pace of dialogue depends on the characteristics of the computer hardware and software, as well as on the specifics of the tasks being solved. The requirement for the pace of dialogue to correspond to the psychological characteristics of a person puts forward restrictions on the values ​​of these characteristics not only "from above" but also "from below". Let us explain this statement.

Response time (response) systems is defined as the interval between an event and the system's response to it. This characteristic of the interface determines the delay in the user's work when moving to the next step of the task.

The importance of taking into account the pace of dialogue was realized back in the 60s, when the first interactive systems appeared. The slow response of the system does not correspond to the psychological needs of the user, which leads to a decrease in the efficiency of his activities. Responding too quickly can also create an unfavorable view of the system.

Response time requirements depend on what the user expects from the system and how interaction with the system affects the execution of his tasks. Studies have shown [3] that if the response time is less than expected, the accuracy of selecting an operation from the menu increases with an increase in the response time of the system. This is due to the fact that an excessively quick response of the system, as it were, "urges" the user, makes him fuss in an effort to "keep up" with a more efficient communication partner. It has been noticed that a novice user is afraid to work with the system if, after spending a few minutes on input, he instantly receives a response from it with an error message.

Response times should be consistent with the natural rhythm of user experience. In a normal conversation, people expect an answer for about 2 seconds and wait for the same when working with a computer. The waiting time depends on their condition and intentions. User perceptions are also strongly influenced by their previous experience with the system.

Usually, a person can simultaneously memorize information about five or nine objects. It is also believed that data storage in short-term memory is limited in time: about 2 seconds for speech information and 30 seconds for sensory information. Therefore, people tend to break down their activities into stages corresponding to pieces of information that they can store simultaneously in memory. Completion of the next stage is called clause. The delays that prevent the onset of the clause are very harmful and unpleasant, since the contents of the short-term memory require constant updating and are easily erased under the influence of external factors. But after the clause, such delays are quite acceptable and even necessary. The completion of a task leading to rest is called closing. At this moment, the need for further storage of information disappears and the person receives significant psychological relief. Since users intuitively seek closing in your work, you should divide the dialogues into fragments so that the user can "in time" forget the intermediate information.

Users, especially beginners, usually prefer many small operations to one large operation, since in this case they can not only better control the overall progress of the solution and ensure its satisfactory progress, but also distract from the details of the work in the previous stages.

The available research results allowed us to develop the following recommendations for the acceptable response time of an interactive system:

0.1 ... 0.2 s - to confirm physical actions (pressing a key, working with a light pen, "mouse");

0.5 ... 1.0 s - to respond to simple commands (for example, from the moment you enter a command, select an alternative from the menu until a new image appears on the screen);

1 ... 2 s - when conducting a coherent dialogue (when the user perceives a series of interrelated questions as one piece of information to form one or more answers, the delay between successive questions should not exceed the specified duration);

2 ... 4 s - to answer a complex request, consisting in filling out a form. If the delay does not affect other user experience associated with the first, delays of up to 10 seconds may be acceptable;

more than 10 s - when working in multitasking mode, when the user perceives this task as a background process. It is generally accepted that if the user does not receive a response within 20 seconds, then this is not an interactive system. In this case, the user can “forget” about the task, start solving another problem and return to it when it is convenient for him. In this case, the program should inform the user that the delay in response is not a consequence of a system failure (for example, by regularly updating the system status bar or keeping a log of the user's task execution).

FLEXIBLE INTERFACE DEVELOPMENT METHODS

A preliminary analysis (at least at a qualitative level) of a possible dialogue scenario avoids many problems at the stage of application implementation. However, if the application can be used by a group of users with varying degrees of training, a number of issues remain unresolved. Therefore, it is highly desirable that sufficient flexibility is provided during the dialogue. It should be the ability of the application to adapt (by the user or automatically) to any possible level of user experience.

There are three types of adaptation: fixed, complete, and cosmetic.

When fixed adaptation, the user explicitly chooses the level of dialogue support. The simplest version of such adaptation is based on the use of the two-level rule, according to which the system provides two types of dialogue:

detailed (for a novice user);

short (for the trained user).

The two-level rule can be extended to an N-level dialogue rule. However, this approach has several disadvantages:

1) the fact that skills are accumulated gradually is not taken into account;

2) the user may well know one part of the system and not know the other at all;

3) the user himself determines the level of his training, which reduces the objectivity of the assessment.

When complete adaptation of the dialogue system seeks to build a model of the user, which, as the latter learns, determines the style of dialogue depending on these changes. In this case, one of the main problems is the recognition of user characteristics. To solve it, it is necessary to determine what to use as such characteristics: the time spent by the user to answer, the number of his requests for help or the nature of errors and the type of assistance requested.

Currently, full (automatic) adaptation is practically not implemented in any water dialogue system.

Cosmetic adaptation is designed to provide flexibility in dialogue without taking into account user behavior, but also without unambiguous choice of a specific style of dialogue.

Such adaptation can be achieved through the use of the following methods:

Using defaults;

Use of abbreviations;

Entering answers ahead of time;

Multilevel help;

Multilingualism.

Using defaults. The essence of the default is that the system uses some initially specified value of any parameter until the user changes it. In this case, there are two aspects of system adaptation:

firstly, a novice user has the ability to use most of the default system parameters,

secondly, the system can memorize the values, either set during the last session (for example, the name of the file being edited), or the most frequently used ones.

For the convenience of novice users, the default values ​​can be displayed along with the appropriate system question, for example: “Date of registration of the document? [current] ".

The most common way to accept defaults is with null input, i.e. simply pressing the Enter key in response to a system question. If the command language is used, the user simply skips the default parameter.

Using abbreviations assumes that the user can enter any valid command abbreviation instead of the full command name. At first glance, it might seem that abbreviated input is more convenient for a novice user. But it is not so. So that the user can, without hesitation, replace the command with a correct abbreviation, he must have a good enough understanding of the existing set of commands, learn the "vocabulary" of the system. For example, if the system has commandsCopy and Compare, it is easier for a beginner to type the full name than to choose the correct abbreviation.

One of the modifications of this approach is character advance, in which the system, “recognizing” the command by the first characters, “adds” it itself. An example is the system interface GPSS / PC , in which when you enter the initial characters of a command, its full name is displayed on the screen, and the cursor automatically moves to the desired position to enter the parameters of this command. Of course, the user, especially the beginner, feels a sense of "deep gratitude" to such a system for the "feasible help".

Idea typing answers ahead lies in the fact that the user has the opportunity at the next step of the dialogue to enter not one answer, but a chain of consecutive answers, anticipating possible questions of the system.

One of the methods of providing multilevel care consists in the fact that first the entry-level message is displayed on the screen, and then the user can refine the information received using the transition to a lower level by the keyword. This principle is the basis for the work of many modern Help-systems, training hypertext systems.

The essence multilingualism the interface consists in the fact that the structure and semantics of dialog messages that the user issues and receives must comply with the norms of the user's native language and not depend on the language in which the tools that he uses are developed.

A possible approach to the implementation of multilingualism is the creation of means of the system's response to user actions (message-requests, hints, error messages) separately from the syntax of the programming language (tools).

2.2.3. VISUAL ATTRIBUTES OF THE DISPLAYED INFORMATION

The visual attributes of the displayed information include:

The relative position and size of the displayed objects;

Color palette;

Means of attracting the user's attention. Designing the layout of the data on the screen involves performing the following actions:

1) Determination of the composition of the information that should appear on the screen;

2) Choosing the format for presenting this information;

3) Determination of the relative position of data (or objects) on the screen;

4) The choice of means of attracting the user's attention;

5) Development of a layout for placing data on the screen;

6) Evaluation of the effectiveness of information placement.

The design process is repeated until the developer and potential users are satisfied.

The general principles of the arrangement of information on the screen should provide for the user:

the ability to view the screen in a logical sequence;

ease of selection of the required information;

the ability to identify related groups of information;

distinguishability of exceptions (messages about errors or warnings);

the ability to determine what action on the part of the user is required (and whether it is required at all) to continue the task.

The question of what information is to be displayed depends on the specifics of the task performed by the user. Here, an essential role is played by the correct division of the task into operations (stages), which do not require the simultaneous presence of a large amount of data on the screen. This condition follows from such a psychophysiological peculiarity of a person as the limitedness of his short-term memory, capable of storing at the same time no more than five or nine objects. If all the information in the original document does not fit on one screen, some data items may be repeated on other screens to maintain consistency and processing consistency. As a rule, the repeated information should not change its location at all steps of the task.

If there are doubts about the selection of logical groups, it is necessary to carefully consider the wishes of the customer or provide him with the opportunity to independently form such groups.

The naturalness property assumes that information is displayed on the screen in a form suitable for direct use. You should not force the user to additionally process this information, for example, to clarify the values ​​of codes using reference books, to perform any transformations, recalculations, etc. The format for displaying date, time and other similar standardized data should be generally accepted, and not individual for a given system. The generally accepted system of combining large and small letters in the text improves its perception.

A very serious issue that largely determines the quality of information perception is the rational placement of data on the screen. The required data density is a subjective concept. It depends on the specific user and the problem being solved. However, there are some rules governing the density of the data on the screen (or within the window):

leave approximately half of the screen (window) blank;

leave an empty line after every fifth row of the table;

leave four to five spaces between table columns. Fragments of text should be positioned on the screen so that the user's gaze itself moves in the desired direction. The content of the fields should not "nestle" to the edge of the screen, but should be located near its horizontal or vertical axes. A menu containing a relatively small amount of information should move to the top left of the screen. To emphasize symmetry, the contents and names of fields belonging to the same group should be vertically aligned. All logically related data groups should be aligned whenever possible.

Another set of recommendations is determined by factors associated with the right-left asymmetry of the human brain. It is known that the left and right hemispheres are involved in different ways in the perception and processing of information. In particular, when memorizing words, the left hemisphere plays the leading role, and when memorizing images, the right hemisphere is more active. Information from the right side of the screen goes directly to the left hemisphere, and from the left side - to the right (naturally, with the binocular vision of the operator). In this regard, it is possible to recommend grouping text messages on the right, and images - on the left. In some people, this distribution of functions of the hemispheres is opposite; in women, the asymmetry is less pronounced than in men. This fact once again confirms the need for individualization of the nature of the display of information. Taking into account the right-left asymmetry of memory is essential if the message repetition intervals do not exceed 10 s. Therefore, the recommendations given should be primarily taken into account in the interfaces of programs running in real time.

Rational screen layout is the most important, but not the only method to ensure a comfortable and natural user experience. Modern monitors provide the developer with various methods of highlighting the displayed information on the screen.

Highlighting information - it is the use of such attributes that allow you to draw the user's attention to a certain area of ​​the screen. Such attributes can be: color of characters, background color, brightness level, flicker and the use of different fonts for displayed characters. Often, to highlight information, underline, inverse output, various frames and "shadows" are used. The effect of applying these attributes is different, and their combination is often unpredictable and depends on the individual characteristics of users. In the literature on this matter, a significant number of recommendations are given, the main meaning of which boils down to the following provision: you should try to use the minimum required number of attributes (to attract the attention of a person, you just need to lightly "touch" him).

Are there objective criteria for evaluating screen density, data balance, and other quality metrics for screen formatting? The problem is that any person who looks at the screen is influenced by the content of the information, making this assessment difficult. One possible approach to solving this problem is to separate the content from the form. For this, two methods are used - rectangles and selected points.

Using method of rectangles after splitting the screen into fields, each of them is filled with free text and separated from the others around the entire perimeter by at least one space. Axes are mentally drawn through the center of the screen, allowing you to assess the balance of the placement of fields.

Selected points method allows you to determine the number and placement of areas of the screen to which the user's attention will be drawn (due to increased brightness, color or flickering of characters). To do this, each area requiring increased attention is modeled with a group of characters other than a space.

The above methods allow us to eliminate gross errors in screen formatting, but the best way to assess its quality is to give a potential user an opportunity to work with the system.

Some of the technical aspects of using visual attributes of displayed information are discussed in the next chapter.

Creating a complex and good interface is a process that brings together experts in various fields. It takes a long time, so the development of the site or program interface is divided into certain stages.

The proposed division is not universal. Each of the stages can be divided into sub-stages. And on under substages - this makes the process even more complicated, which means more expensive in the eyes of customers :-)

1. Data collection

Data collection is necessary in order to clearly understand what kind of product exists at the moment, what does not suit the client and what result he expects from the collaboration. At this stage of the development of the program interface, the designer:

• communicates with the client to understand the meaning and philosophy of the program;
• looks at developments: ready-made prototypes (even if they exist only on a napkin);
• analyzes competitors' programs(and possibly conducting usability testing of competitors' programs);
• conducts structured interviews with clients or potential clients.

2. Design

At this stage of the development of the program interface, the designer:

• defines the grid, colors, fonts and background;
• and also often creates custom controls such as dropdown menus.

Naturally, at each stage there is a discussion and, if necessary, a free revision. Your order you will receive either as graphic files in Photoshop format, or in the form HTML or XAML code.

4. Implementation

When everything is clear about the interface, little remains to be done :) As a rule, our clients keep full-time programmers, and we are attracted for various work related to the user interface, from designing to creating icons. However, for those clients who do not have their own developers, we offer development and testing of web and mobile applications for iOS. We have a permanent department of developers and testers. We guarantee: no freelancing.

At the stage of implementation, the development and testing (QA, not usability) of the program is underway. Developers will clearly understandable how to do something based on graphic files (sketches) and explanations to them. Otherwise, we will draw and add.

Of course, development is divided into stages, but we will not describe them here for brevity.

5. Usability testing

Involving a good interface designer on your project will not eliminate the need to systematically conduct usability tests. Relying only on a "genius interface designer" is harmful for the following reasons:

• Of course, you should try to attract the best interface designers (for example, VisualPharm :) to work on the project. Unfortunately, this is not always possible. Sometimes people take part in your project those people you can attract to it, not the ones you dream of working with;
• design is not an exact science; even if your designer is a genius, not all of his ideas are created equal. Therefore, to reduce the risk, it would be logical to subject all these ideas to real-world testing with real users. (remember, new ideas can be tested at minimal cost using techniques such as paper prototyping);
• How do interface designers become good designers at all? It's very simple: learning from experience which ideas work and which don't. But tests are needed to gain this experience conducted by usability specialists;
• even the best designers can only create a successful product if they get the job done right. A wonderful interface will not help if the functionality is illiterately built. BUT howinterface designersfind out what users need? The answer is simple: through usability research;
• nobody is perfect. Even a very good design can be improved by going through a step-by-step quality improvement process. At each stage, you conduct tests with users and, based on the results, step by step, improve the quality of the user interface.

• fast: 2-7 days for the test;
• cheap- one or two orders of magnitude cheaper than large studies;
• within your target audience... We'll find her. Do you need midwestern Americans 30-55 years old interested in Russian brides? You are welcome.

You can perform usability testing of both the prototype and the finished product. General recommendation - do many small iteration tests instead of one big test... Made, tested, corrected, tested again. This will allow you to find and fix non-obvious errors.

Timing

The duration of work depends on the number of screens... It takes the same amount of time to design and design one screen. We usually need two days to create prototype (or design) of one screen and another five days to complete the entire order. Thus, it will take 15 working days to develop (design or design) five screens.

Making corrections at your request will take additional time. Although we do not charge additional fees for edits, they can affect the completion time of the project. Often, edits take longer than the actual creation of screens.

To conduct usability testing need about 6 working days... It all depends on whether it is about testing the entire application or about small iterative tests.

The cost

Designing and designing a single screen also costs the same:

• design / design of the first screen is worth 48 800 RUR... The first screen is more expensive because it is the defining one for the entire application. When developing it, we must take into account the structure of the entire application;
• design / design of other screens – 18 350 RUB... for every.

Thus, the development of a prototype (or design) of five screens will cost RUB 48,800 + RUB 18,350. x 4 = 122 200 RUR

Indicative the cost of usability testing is 52 500 rubles. - 126,000 rubles.

Big projects

The description above is for small software interface projects. Big projects will be useful to break down into subtasks, and run a cycle for each of them. For example, if we were developing the Skype interface, we could highlight the following modules:

• voice communication interface;
• video communication interface;
• contact list management;
• etc.

For each of the listed modules it is advisable to go through all the stages , then go to the next module. This development method is called Agile(read "agile"). This methodology is usually respected and mentioned every time you want to impress clients and beautiful girls :-)