Interactive prototypes. The current user interface model, part 1. Classification

Interface design is one of the key processes in our company. And we are not directly developing all projects - for many, only the interface model, project documentation, and cost and implementation timeline estimates are being prepared. The interface model can be static or interactive. In the first case, these are page layouts (wireframes) , in the second, interactive prototypes. It is rather expensive to create the last ones in a decent form, but they help out at once in several stages.

Prototype classification

Among developers and designers there are several definitions of prototypes. I do not want to enter into terminological disputes, therefore I will describe how we call them within our company . They just reflect the three important stages of work on the system.

Wireframes or paper prototypes

At first, these are sketches of the key pages of the system on paper, then - detailed schemes of almost all pages and AJAX interactions drawn in MS Visio. They are often called paper prototypes, but the word “paper” is most often lost. Here terminological disputes begin - people call different things with the same word, uselessly argue and mislead clients. And if you look, for example, on analogies in the same construction - there are also mockups (the very models of cardboard), and projects - architectural, construction, town planning, etc. ... Therefore, I try to speak of them as page schemes . They give the first visual idea of ​​the future system, allow you to set tasks for the designer, layout maker of the interactive prototype, developers.

Interactive or clickable prototype

The material is just about them. We have a set of interconnected HTML pages that include imitating AJAX interactions using static JavaScript. It usually does not save data, but you can use the same cookies to simulate server interaction. There are also simpler prototyping options - for example, “animating a picture” via Adobe Flash or simply page layouts with clickable zones (imagemaps). The benefits of the interactive prototype are many for all participants in the process of working on the system, but more on that below.

Functional prototype

This is an already developed and fully working system, into which the design has not yet been integrated. One of the most problematic issues in iterative development is the integration of constantly changing and adding program code with HTML layout . The system develops every week and is shown to the customer, functionality is constantly added and changed. There is everything you need in the design, but in the working version of the system - for now or not. But what exactly is not? This is a constant headache for the one who builds the project. And one of the solutions is to first make a black and white, but working according to the specification system. After that, engage in its appearance, fill it with content, show to interested parties.

Immediately make a reservation - I work on web systems, so all the specifics and terminology in the article - just about them. Although generally portable and to other environments.

Lecture hall

The tasks of a clickable prototype and its life cycle are determined based on who needs it. The target audience allows you to define also the goals of creating and supporting the prototype.

Customer

Customer needs may depend on who finances the project and makes major decisions. This may be a startup with an investor, or a division within a company, or another option. But in general, the prototype gives the customer the assurance that:

• The product can be shown to investors or top management long before its development begins. It can be difficult to do on the fingers, but a working system model perfectly helps to find a common language. And if the presentation itself is vigorous - also infect with the idea of ​​a future product. In the end - the receipt or continuation of funding.
• The basic assumptions about the system and its functionality are correct . While the concept of the product is in the head or on paper, it is difficult to say exactly how complete and meaningful it is. Assumptions are collected and documented in the form of page layouts (wireframes) and supporting documents. But only in the process of their materialization there is a sense of the integrity of the system - when you can check specific scenarios for use in practice. Of course, the prototype does not solve all future difficulties - for example, the complexity of integration with third-party databases or the “weight” of the code of the web application pages. But these are already technical rather than conceptual problems - rarely it is required to change usage scenarios to solve them. The result is a coherent and consistent system, a complete product.
• You can start selling a product or enter into partnerships in advance . Development of large systems can go on for a long time, and not all interested parties should show raw working versions. But it can be shown in practice, for example, advertising schemes for potential advertisers, and for possible partners - the mechanisms for selling electronic content or the convenience and completeness of paid services. The result - a preliminary agreement or the first sale.

System users

Users can be both external - working with the main functionality and content in the front office, and internal - ensuring the performance of the system through the back office. The first ones are just consumers, the second ones are also part of the customer’s team. Therefore, to ensure the success of the product using the prototype, you can find out that:

• The product is understandable to users and easy to use . Based on page layouts or visual design, only fairly limited usability testing can be performed. But an interactive prototype allows you to see how users perform basic tasks in the system, as close as possible to reality. Especially great is that the prototype can be quickly refined and usability testing again. And if there are alternatives, make models of all of them and show the user in turn. Of course, there are still reservations - the data in the prototypes are rarely saved, there are no peculiarities of interaction with the server and other working moments. But most often it concerns non-functional requirements - if the backbone of the system consists of user-independent functions, then it rarely needs an interactive prototype. In any case, in the end, the main scenarios of users' work with the system were checked and improved.
• All necessary functions are implemented and work efficiently . This is rather a continuation of the previous paragraph - but it is more convenient to separate it into a separate one. The difference is that the effectiveness of performing not individual tasks, but entire processes is checked. Is everything in the product to ensure that each user group performs its tasks fully and effectively? Is it possible to reach the state of flow when working with the system goes “in one breath” - does it explicitly or implicitly suggest and suggest the next step? As a result, an answer is given to whether the system works as a full-fledged product and whether it helps to achieve business goals.
• The system can be provided with the necessary content, and its functions - support . The success of a web application or service is usually built on the basis of high-quality content or functionality - in sum or separately. It is important to know how much it is possible and costly to support these components. The prototype shows the final result of the work, so you can calculate in advance how often, how much, from what sources, what resources, what revision to get the information. Not forgetting about the functions - in what areas, who, how and by what forces should support the successful operation of services. Starting from moderating user-generated content, ending with reference services, etc. As a result, the study of the system support process and the search for ways to facilitate the work in this process.

Development team

The “last mile” in creating a system is the development team. You can design a fantastically convenient and intuitive user interface, but if you don’t retell all its details and features to developers, a large piece of analytical effort will be wasted. The system interface is anyway documented and described in detail. But the verbal description can be understood wrong, and the developers are not always eager to dig into a pile of documents. So they need instructions and examples of that:

• How the system looks and works as a whole . Developers want to understand what they are doing. Paper descriptions do not really cling - they do not see the finish line, why all this is started. How to convey the essence of the work, the main ideas of the product to those people who did not participate in analytics and design? The best way is to show the most similar system. Or an interactive prototype of the one you want to create. The result - an understanding of the essence of the work.
• What are the features of the individual functions . In the process of developing a specific functionality, big and small questions often emerge about how it all works. The general essence is usually understandable at first glance, but the sequence of the function’s workflow is the source of many potential problems. For example, you need to add a new apartment to the list of real estate. How do your own input fields work? Is there any message when the form is submitted? Do I need to highlight a new apartment with a general list after adding? The prototype does not eliminate the need to describe all these and other points in the specification. But having them in the interface model helps reduce the rework list. The result is a more detailed and comprehensive system specification.
• As far as possible to implement certain functions . In complex systems it is impossible to describe in the specification absolutely all the moments. Is that if you take a fair amount of man-months. This is partly due to the problems of integrating functionality with each other. Partly because it is planned to use new and untested technologies. In the course of work, all this is discussed at meetings or spontaneous meetings - verbally or on marker boards. But it is especially convenient if during the discussion you can refer to an interactive prototype. And even better - immediately experiment with functionality based on it. The result - the results of discussions closer to reality, rather than abstract assumptions.

It remains to put a tick in this checklist. And start working on the prototype itself.

Read the second part of the material with examples of interactive prototypes and a third with features of the process of their creation .

Original: Interactive Prototypes. The current user interface model, part 1. Classification