Interactive prototypes. The current user interface model, part 2. Approaches to the process
In the first part of the material I described the purpose of creating an interactive prototype . Now I will talk about the process of working on it in our company. The work on the interactive prototype begins after the page layouts (wireframes) are designed and their visual design is drawn. The process takes on average a couple of weeks, after which it begins its independent voyage. The interface model is studied and commented on by the customer, users, and developers.
The interactive prototype itself is built up in HTML and interconnected key pages of the system. Approach may be two.
It can be done quickly and cheaply, especially if you use rapid prototyping tools like Axure RP Pro or a plug-in for MS Visio Intuitect . Even more cool is that you can get it at an early design stage, without waiting for visual design to be drawn. And that means start usability testing too.
')
But, first of all, many people know from experience that it is dangerous for an unprepared client to show raw materials (the same wireframes) to an unprepared client. You can spend a lot of time trying to convince him that this is not yet a system design and will continue to be different. Secondly, when it comes to quite specific pixels, rather than relative values ​​and sketches, the perception of the interface can change a lot. And thirdly, when designing, it is better to deal with only one “layer” of work. As soon as constant switching between tasks of a different nature begins - by thinking through diagrams and charts and working out clicks and mouse over, both productivity, quality and depth of work are reduced.
It is worth doing it in those cases when either the budget is very small and there is enough money only for the simplest model. Or vice versa, when there is enough money and time for both prototypes - both early black and white, and normal color. Although there is another excellent case for the use of early models. Recently, a client came to us who brought with him a prototype product created in Axure. It contained all the key pages of the future service and it was much easier for us to immediately assess the time and cost of its design and development. The design stage “clean” was required in any case, but the pre-project analysis was greatly simplified - the initial prototype had already given many answers.
It is much easier to communicate with the customer, users and developers, having on hand a model of the interface that looks as close as possible to the final result. Here those bonuses for the audience , which are described in the first part of the material, are just starting to work. A customer can, with far greater success, show a prototype to investors or management, partners or advertisers. It is not necessary, as is the case with page layouts (wireframes), at each stage it is a long time and not always effective to explain that this is not yet a design. Usability testing also passes with fewer reservations, and the effect of it is closer to reality. Well, in communicating with the developers constantly helps out.
True, making a color prototype can be quite expensive and time consuming. We try not to do cross-browsering at this stage - we usually take IE7 and, possibly, Firefox. First, it takes a lot of time. Secondly, constant experiments are going on with the prototype and they need to be done quickly, so there’s no need for accurate and logical code support. Therefore, in any case, it will need to be re-turned from scratch. Practice shows that hemorrhoids and a cloud of bugs in the development is not worth saving on rework. So there is a lot of work for the typesetter here.
In some cases it is beneficial not to bother with prototype usability testing, but to quickly launch a beta version of the system. And already receiving feedback, making quick corrections is the case with the web-constant-constant beta. For example, in the case of the development of a new version of EPAM PMC, we did so. But such an approach is more suitable for projects with a guaranteed and loyal audience than for replicable (be it the number of copies sold or the volume of traffic) products with strong competitors.
Very few people are willing to spend large budgets on an absolutely complete prototype, and this makes sense only for very long-term projects. Therefore, it is important to choose the optimal set of pages and interactions that will be included in the interface model. Here is what you should focus on:
In the prototype, it is worthwhile to show and test at least the basic capabilities of the system. For example, for a job search site it will be keeping resumes and vacancies, finding suitable jobs and candidates, job offers and job vacancies, getting information about new vacancies and resumes. So we need at least the pages of the employer and applicant profiles, the forms for adding a vacancy and editing a resume, the lists of offers and the page of one of them, the archive of responses and offers of work, the page for setting notifications.
To do this, it is worthwhile to combine all the important functions of the system into real scenarios of working with it. To the original composition is to add service functions. For example, for the same job search site, you need to send a response to it from the vacancy information page. And after sending the user would be shown a message that everything went well. And, perhaps, that he has already sent a response to another job of this employer. So you need to make a version of the job information page with a message about success. Or, for example, to transmit to cookies data that it is necessary to show a hidden block with this message.
Even better, more complex scenarios will be shown. For example, the user received an invitation to register on the site. After filling out the registration form, he was asked to fill out a resume. And after filling out a resume - find suitable vacancies on several criteria. The list of required pages in the prototype adds the input of the invitation, registration, authorization and search for vacancies based on the resume. And do not forget that, besides the applicant, we also have an employer - he may need to pay for job placement services.
It is possible that the customer may need to show the future partner or investor additional features of the future product. For example, import a list of jobs from MS Excel-file or intranet system. So the list of necessary pages will expand again.
Now it is clear that in what form and volume you need to do. It's time to take up the construction tools.
Read the first part of the material with the classification of interactive prototypes and the third, with the peculiarities of the process of their creation .
Original: Interactive Prototypes. The current user interface model, part 2. Approaches to the process
Prototyping Approaches
The interactive prototype itself is built up in HTML and interconnected key pages of the system. Approach may be two.
Black and white page layout prototype
It can be done quickly and cheaply, especially if you use rapid prototyping tools like Axure RP Pro or a plug-in for MS Visio Intuitect . Even more cool is that you can get it at an early design stage, without waiting for visual design to be drawn. And that means start usability testing too.
')
But, first of all, many people know from experience that it is dangerous for an unprepared client to show raw materials (the same wireframes) to an unprepared client. You can spend a lot of time trying to convince him that this is not yet a system design and will continue to be different. Secondly, when it comes to quite specific pixels, rather than relative values ​​and sketches, the perception of the interface can change a lot. And thirdly, when designing, it is better to deal with only one “layer” of work. As soon as constant switching between tasks of a different nature begins - by thinking through diagrams and charts and working out clicks and mouse over, both productivity, quality and depth of work are reduced.
It is worth doing it in those cases when either the budget is very small and there is enough money only for the simplest model. Or vice versa, when there is enough money and time for both prototypes - both early black and white, and normal color. Although there is another excellent case for the use of early models. Recently, a client came to us who brought with him a prototype product created in Axure. It contained all the key pages of the future service and it was much easier for us to immediately assess the time and cost of its design and development. The design stage “clean” was required in any case, but the pre-project analysis was greatly simplified - the initial prototype had already given many answers.
Color prototype based on customer-accepted visual system design
It is much easier to communicate with the customer, users and developers, having on hand a model of the interface that looks as close as possible to the final result. Here those bonuses for the audience , which are described in the first part of the material, are just starting to work. A customer can, with far greater success, show a prototype to investors or management, partners or advertisers. It is not necessary, as is the case with page layouts (wireframes), at each stage it is a long time and not always effective to explain that this is not yet a design. Usability testing also passes with fewer reservations, and the effect of it is closer to reality. Well, in communicating with the developers constantly helps out.
True, making a color prototype can be quite expensive and time consuming. We try not to do cross-browsering at this stage - we usually take IE7 and, possibly, Firefox. First, it takes a lot of time. Secondly, constant experiments are going on with the prototype and they need to be done quickly, so there’s no need for accurate and logical code support. Therefore, in any case, it will need to be re-turned from scratch. Practice shows that hemorrhoids and a cloud of bugs in the development is not worth saving on rework. So there is a lot of work for the typesetter here.
I managed to visit many fronts of web development, including in HTML-layout. Templates are being built and combined into a prototype for common sites. But these are quite simple and understandable things; the task of experimenting with the interface is not there — rather, it is rather just the provision of development.
In some cases it is beneficial not to bother with prototype usability testing, but to quickly launch a beta version of the system. And already receiving feedback, making quick corrections is the case with the web-constant-constant beta. For example, in the case of the development of a new version of EPAM PMC, we did so. But such an approach is more suitable for projects with a guaranteed and loyal audience than for replicable (be it the number of copies sold or the volume of traffic) products with strong competitors.
The composition of the prototype
Very few people are willing to spend large budgets on an absolutely complete prototype, and this makes sense only for very long-term projects. Therefore, it is important to choose the optimal set of pages and interactions that will be included in the interface model. Here is what you should focus on:
Key functionality
In the prototype, it is worthwhile to show and test at least the basic capabilities of the system. For example, for a job search site it will be keeping resumes and vacancies, finding suitable jobs and candidates, job offers and job vacancies, getting information about new vacancies and resumes. So we need at least the pages of the employer and applicant profiles, the forms for adding a vacancy and editing a resume, the lists of offers and the page of one of them, the archive of responses and offers of work, the page for setting notifications.
System User Scenarios
To do this, it is worthwhile to combine all the important functions of the system into real scenarios of working with it. To the original composition is to add service functions. For example, for the same job search site, you need to send a response to it from the vacancy information page. And after sending the user would be shown a message that everything went well. And, perhaps, that he has already sent a response to another job of this employer. So you need to make a version of the job information page with a message about success. Or, for example, to transmit to cookies data that it is necessary to show a hidden block with this message.
Even better, more complex scenarios will be shown. For example, the user received an invitation to register on the site. After filling out the registration form, he was asked to fill out a resume. And after filling out a resume - find suitable vacancies on several criteria. The list of required pages in the prototype adds the input of the invitation, registration, authorization and search for vacancies based on the resume. And do not forget that, besides the applicant, we also have an employer - he may need to pay for job placement services.
It is possible that the customer may need to show the future partner or investor additional features of the future product. For example, import a list of jobs from MS Excel-file or intranet system. So the list of necessary pages will expand again.
Now it is clear that in what form and volume you need to do. It's time to take up the construction tools.
Read the first part of the material with the classification of interactive prototypes and the third, with the peculiarities of the process of their creation .
Original: Interactive Prototypes. The current user interface model, part 2. Approaches to the process
Source: https://habr.com/ru/post/17436/
All Articles