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

Interface design is one of the key processes in our company. Moreover, we do not directly develop all projects - for many, only an interface model, project documentation, an assessment of the cost and implementation time are prepared. The interface model can be static or interactive. In the first case, these are page layouts (wireframes) , in the second - interactive prototypes. Creating the latter in a decent form is quite expensive, but they help out a lot at once at several stages.

Prototype classification

There are several prototype definitions among developers and planners. I don’t want to enter into terminological disputes, therefore I will describe how we call them inside our company . They just reflect the three important stages of work on the system.

Page block diagrams (wireframes) or paper prototypes

First, these are sketches of the key pages of the system on paper, then detailed drawings 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. This is where terminological disputes begin - people call different things with the same word, argue uselessly and mislead customers. Yes, and if you look, for example, on an analogy in the same building - there are models (the same models made of cardboard) and projects - architectural, construction, urban planning, etc. ... Therefore, I try to talk about them as page layouts . They give the first visual representation of the future system, allow you to set tasks for the designer, layout designer of the interactive prototype, and developers.

Interactive or clickable prototype

The material is just about them. We have a set of interconnected HTML pages, including a simulation of AJAX interactions using static JavaScript. It usually does not store 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 just 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 in which design has not yet been integrated. One of the most problematic aspects of 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. In the designed design there is everything you need, but in the working version of the system - yet or not. But what exactly isn’t? This is a constant headache for someone who is assembling a project. And one of the solution options is to first make a black and white system that works in accordance with the specification. Then engage in its appearance, fill it with content, show it to interested parties.

I’ll make a reservation right away - I work on web systems, so all the specifics and terminology in the article are just about them. Although generally portable 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 determine the goals of creating and supporting the prototype.

Customer

Customer needs may depend on who finances the project and makes key decisions. It can be a startup with an investor, or a unit within the company, or another option. But in the general case, the prototype gives the customer the confidence that:

• The product can be shown to investors or senior management long before its development begins. It can be difficult to do on fingers, but a working system model helps to find a common language. And if the presentation itself is peppy - also infect with the idea of ​​a future product. As a result, receiving or continuing financing.
• 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 for sure how complete and meaningful it is. Assumptions are collected and documented in the form of page diagrams (wireframes) and supporting documents. But only in the process of their materialization does a sense of the integrity of the system appear - when you can verify specific use cases in practice. Of course, the prototype does not solve all future difficulties - for example, the complexity of integration with third-party databases or the "heaviness" of the code for the pages of a web application. But these are more technical rather than conceptual problems - to solve them, it is rarely necessary to change usage scenarios. The result is a holistic and consistent system, a complete product.
• You can start selling a product or making partnership arrangements in advance . The development of large systems can take quite a long time, and not all interested parties should show raw working versions. But you can show in practice, for example, advertising schemes for potential advertisers, and possible partners - mechanisms for selling electronic content or the convenience and completeness of paid services. As a result, preliminary agreements or first sales.

System users

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

• The product is user friendly and easy to use.. Based on page layouts or visual design, only fairly limited usability testing can be done. But the interactive prototype makes it possible to see how users perform the main tasks in the system, as close as possible to reality. It’s especially cool that the prototype can be quickly modified and usability tested again. And if there are alternative options - make models of all of them and show the user in turn. Of course, all the same, reservations remain - data in prototypes is rarely saved, there are no features of interaction with the server and other working moments. But most often this relates to non-functional requirements - if the backbone of the system is composed of user-independent functions, then it rarely needs an interactive prototype. Anyway,
• All necessary functions are implemented and work efficiently . It is rather a continuation of the previous paragraph - but it is more convenient to separate it into a separate one. The difference is that it checks the effectiveness of not individual tasks, but entire processes. Is there anything in the product so that each group of users fulfills its tasks fully and efficiently? Is it possible to achieve a state of flow when working with the system is "in one go" - 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 - with support . The success of a web application or service is usually built on the basis of quality content or functionality - in total or separately. It is important to know how possible and costly the support of these components is. The prototype shows the final result of the work, so you can calculate in advance, with what frequency, in what volumes, from what sources, with what resources, with what refinement to take information. Not forgetting about the functions - in which areas, who, how and by what forces should support the successful operation of services. Starting from moderation of user-generated content, ending with help services, etc. As a result, we will study the system support process and find ways to facilitate work in this process.

Development team

The "last mile" in creating the system is the development team. You can design a fantastically convenient and intuitive user interface, but if you do not retell all its details and features to the developers, a large piece of analytical effort will be wasted. The system interface is in any case documented and described in detail. But the verbal description can be misunderstood, and developers are not always eager to delve into the heap of documents. So they need instructions and examples of this:

• How the system as a whole looks and works . Developers want to understand what they are doing. Paper descriptions are not very catchy - they do not see the finish, 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. As a result, an understanding of the essence of the work.
• What are the features of the work of individual functions . In the process of developing specific functionality, big and small questions often come up about how this all works. The general essence is usually understandable at first glance, but the sequence of the process of the function is the source of many potential problems. For example, you need to add a new apartment to the list of real estate. How do custom input fields work? Is there any message when submitting the form? Do I need to highlight a new apartment with a common list after adding? The prototype does not replace the need to describe all these and other points in the specification. But their presence in the interface model helps to reduce the list of alterations. The result is a more detailed and comprehensive system specification.
• How possible is it to implement certain functions . In complex systems, it is impossible to describe absolutely all aspects in the specification. Unless if you devote to this 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 process of work, all this is discussed at meetings or spontaneous meetings - verbally or on bulletin boards. But it’s especially convenient if you can refer to the interactive prototype during the discussion. And even better - immediately experiment with functionality based on it. As a result, the results of discussions are closer to reality, rather than abstract assumptions.

It remains to check this checklist. And start work on the prototype itself.

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

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