Interactive prototypes. The current model of the user interface, part 3. Features of the process
I already wrote about the classification and two main ways of creating interactive prototypes . In most cases, we make just a color prototype. In fact, this is the usual layout of HTML-based page templates based on visual design, which includes JavaScript interactions. The difference is that these templates will change and be supplemented many times.
Automatic prototyping tools based on page layouts - the same Axure RP Pro and Intuitect - I try not to use. They themselves are sharpened for typical tasks, so when you need to do something non-standard, all their advantages are lost. But the complexity of cooking porridge from the ax is added. Therefore, we try to make prototypes manually using conventional HTML-layout programs.
The process is quite simple. At the input of the layout designer, a set of design layouts arrives, and at the output, a set of HTML files. There is nothing special to paint here, it is better to turn to any article on HTML-layout. But there are a couple of points that are important when creating prototypes:
')
After the prototype is ready, its discussion and usability testing begins. So changes come in batches. And it is far from always clear how exactly it is necessary to correct some element of the interface. Even after long discussions and a series of sketches, there are at least a couple of alternative solutions. It is best to implement all the controversial alternatives - to prepare several versions of those prototype pages, where there are elements for discussion.
There is an option to get carried away. In an amicable way, of course, with all the changes, you need to update the entire documentation package - page layouts (wireframes), design layouts, HTML templates, usability testing scripts. But if you run the whole cycle of design -> design -> layout -> usability testing for each edit, you can spend a lot of time. Which then will not be enough to work out more important decisions. So if this is not a multi-year project and there is no army of designers and designers, you need to risk the integrity of the documentation in favor of a better interface. Somewhere to simplify the stages of the cycle, somewhere - to throw out. More precisely, leave on the following cycles. The main thing is to keep a journal of changes - to add them to the documentation after the experiments.
About the process of usability testing it is better to write in a separate article. And even better - refer to the excellent benefits of Vlad Golovach . I will only note that in the course of the work it is more convenient to show intermediate results to colleagues or just acquaintances. There are, for example, good practices of expert assessments. But testing is carried out at the end or at several important intermediate points.
Another important point is the support of the prototype. If its use is planned as one of the documentation sources, as described in the first part , it is necessary that it always reflect the latest version of the interface. Developers often refer to it as a last resort. And if something is outdated there, it is very likely that it will be outdated in an already working version. This means that a permanent layout designer should be assigned to the prototype, recording all changes.
The main thing is not to forget for what and for whom the interactive prototype is being made. Then it will not be an expensive toy for someone from the participants in the process, but it will help a lot at many stages of the project. Yes, and sell the idea to an investor or partner, having a tangible thing in your hands instead of just a set of promises on paper is much easier.
Read the first part of the material with the classification of interactive prototypes and the second, with a description of the approaches to the process of their creation .
Original: Interactive Prototypes. The current model of the user interface, part 3. Features of the process
Process of creation
Automatic prototyping tools based on page layouts - the same Axure RP Pro and Intuitect - I try not to use. They themselves are sharpened for typical tasks, so when you need to do something non-standard, all their advantages are lost. But the complexity of cooking porridge from the ax is added. Therefore, we try to make prototypes manually using conventional HTML-layout programs.
The process is quite simple. At the input of the layout designer, a set of design layouts arrives, and at the output, a set of HTML files. There is nothing special to paint here, it is better to turn to any article on HTML-layout. But there are a couple of points that are important when creating prototypes:
- Thoughtful file names . The list of interactive prototype files and their names is best written before starting. I try to follow the principle of bread crumbs - for example, “catalog.html”, “catalog-category.html” and “catalog-category-item.html”. It’s also easier to navigate the list of files - you often need to show a specific prototype page. And the connectivity of the interface once again helps to check.
- Linking pages in the course of the layout . The prototype should be linked to each other for ease of usability testing and just working with it. If the page is minimized and links to it lead, the page URL should be in them. It’s trite, but if you don’t do it right away, you’ll have to spend a ton of time on it after the layout. Although the prototype itself usually makes the layout designer, it is better for the designer to link pages — he knows much more about interface interactions.
- Actual content . For a better perception of the prototype by both the customer and users, it is better not to use lorem ipsum and image substitutes, but test data. Recently, I try to prepare them even before the start of design. This helps to better understand the context of use of the system, its individual features. Yes, and is perceived much better. Plus, by the nature of the same news titles, it is easier to understand the essence of the project and the development team, and the designer himself.
- Do not get too carried away with the validity and beauty of the code . The prototype will change frequently and quickly, so you do not need to spend time on crystal clear code - it only slows down the process. It is better to turn HTML completely clean as soon as the active experiments with the prototype end.
')
Prototype Usage
After the prototype is ready, its discussion and usability testing begins. So changes come in batches. And it is far from always clear how exactly it is necessary to correct some element of the interface. Even after long discussions and a series of sketches, there are at least a couple of alternative solutions. It is best to implement all the controversial alternatives - to prepare several versions of those prototype pages, where there are elements for discussion.
There is an option to get carried away. In an amicable way, of course, with all the changes, you need to update the entire documentation package - page layouts (wireframes), design layouts, HTML templates, usability testing scripts. But if you run the whole cycle of design -> design -> layout -> usability testing for each edit, you can spend a lot of time. Which then will not be enough to work out more important decisions. So if this is not a multi-year project and there is no army of designers and designers, you need to risk the integrity of the documentation in favor of a better interface. Somewhere to simplify the stages of the cycle, somewhere - to throw out. More precisely, leave on the following cycles. The main thing is to keep a journal of changes - to add them to the documentation after the experiments.
About the process of usability testing it is better to write in a separate article. And even better - refer to the excellent benefits of Vlad Golovach . I will only note that in the course of the work it is more convenient to show intermediate results to colleagues or just acquaintances. There are, for example, good practices of expert assessments. But testing is carried out at the end or at several important intermediate points.
Another important point is the support of the prototype. If its use is planned as one of the documentation sources, as described in the first part , it is necessary that it always reflect the latest version of the interface. Developers often refer to it as a last resort. And if something is outdated there, it is very likely that it will be outdated in an already working version. This means that a permanent layout designer should be assigned to the prototype, recording all changes.
It is necessary to decide at the very beginning that the project is a standard of the interface - page schemas (wireframes), design layouts or an interactive prototype. It’s expensive to maintain all three layers, and the manager doesn’t have enough time for decent quality control of all three processes. True, the result often still turns out to be “look at the cap and footer in the prototype, the body of the page in wireframes”. This is largely solved by the constant presence of the designer, who will tell you where it is right.
The main thing is not to forget for what and for whom the interactive prototype is being made. Then it will not be an expensive toy for someone from the participants in the process, but it will help a lot at many stages of the project. Yes, and sell the idea to an investor or partner, having a tangible thing in your hands instead of just a set of promises on paper is much easier.
Read the first part of the material with the classification of interactive prototypes and the second, with a description of the approaches to the process of their creation .
Original: Interactive Prototypes. The current model of the user interface, part 3. Features of the process
Source: https://habr.com/ru/post/17482/
All Articles