Say a word about poor mocap
Last week a publication appeared Prototype it , defined by the author himself as "holivarnaya".
Since the conversation has come about the saint, why not throw a couple of branches into the fire?
I am an interface designer. And I love mocapas.
And why don't I love them, if I only do what I do them?
To begin with, note that mocapas and prototypes are by no means the same thing. In a non-Russian IT dictionary, there are several terms for visuals corresponding to different stages of work on an IT product. The boundaries of these terms are blurred, but, nevertheless, having seen something interface-graphic, it is not difficult to classify it.
1. Sketch (sketch, sketch) - the initial instant sketch from the hand of what is wandering into the head.
2. Wireframe (block diagram) - a diagram or drawing representing the "skeleton" of the page of a site or application. No decorations, just the location and approximate sizes of headings, text blocks, illustrations, multimedia and navigation panels.
3. Prototype(prototype) is a model for testing a concept or process. Pictures can be inserted, color tones appear, etc.
4. Simulation (simulation, simulation, full-functional prototype) - on complex projects, also a model for testing a concept or process, but - Hi-Fi (high fidelity - high accuracy, unlike protopip, which is a low-precision model - Lo-Fi) . The iRise program is usually used to create simulations (or simulations, if you like). They use visual libraries that allow you to display pages very close to the final view, there are drop-down lists, buttons that change their appearance on hover, navigation between screens, pop-ups, etc.
5. Mockup or mock-up(mock) - a non-working model, made in full size and looking like a working instance will look like. That is, a web page made in Photoshop, submitted for layout, is a mocap. And it will become a design when interactivity appears. In fact, mocapas can be relatively dynamic and interactive, but more on that later.
Projects in which all these stages are fully represented are extremely rare. And since developers have no time to understand the nuances of what they don’t use, the term “prototype” can be called anything, in the interval between the first handwriting and the finished product.
At the dawn of site building, designers made prototypes for themselves, calling them “sketches,” “sketches,” “sketches,” etc. - who was much in what. Moreover, they somehow did not even imagine that they combine at least two or three different specializations in their work. About a hundred years ago, a motorist was a driver and a mechanic in one person, and even a little earlier - who wanted to make a bronze ax went personally to dig ore.
But now IT specializations have crystallized out, which indicates the growing industry. Replacing the old pure-ponte sites are really working, complex services, estimates are growing, the structure of working groups is becoming more complicated, the 21st century is knocking on managers' skulls. And this is good.
But why don't designers like this division of labor? - Yes, it is very simple: due to a significant loss of control over the product creation process. Previously, you could cook anything, but now in the “kitchen” there was another housewife who knows better how to cook semi-finished products, and from now on the designer’s task is to bring them to condition and serve beautifully. Moreover, these damned “interaction designers” blow at all angles that their work is more important than graphic design, and everyone agrees with them!
Whether these are different professions is not a question. They are different, and this has been proven many times. Can the talents of an interaction designer (I will write “UX” for the sake of brevity) and a graphic designer fully combine in one person? Not always, but they can. Around the same way as some pianists can tolerably play the guitar. The question remains, should you always separate the processes of creating UX and graphics and give them to different people?
In general, everything is simple with this: if a visual designer has enough abilities, experience and time to do UX, it's best to give everything to him (UX specialists can’t cope with visuals if they don’t have a designer past).
But the more difficult the work, the more insistently the question arises of the division of labor. Consider two typical extreme options.
1.Ideal for a visual designer, in terms of UX, it’s as simple as an amoeba: a web design online portfolio.
Here he is to himself - a customer and a contractor, and he can easily cope with UX. A career usually begins with this and other simple sites, carried out by a team of 2-3 people, where the designer communicates with the client tête-à-tête and rests in complete confidence that everything not related to programming is his design diocese. Often with this confidence, he goes further in the profession.
2. Adult option: a large and complex client application that demonstrates in all its glory the difference between interaction design and visual design, for example, a WPF project that has been in development two or three years or more before the first release.
Typically, stakeholders on such projects are people so important that they simply don't have time to talk with designers. Therefore, service owners are responsible for the adequacy of the tasks. These are specialists from the same industry as stakeholders, but with a focus on IT. They understand what tasks and how the product should solve, but at the beginning of the work, the final form of the application is vaguely presented, especially if the project is innovative and has no existing analogues.
The project, of course, is divided into short sections - sprints (usually a month and a half), and the UX group, in a tight, daily interaction with service directors, begins to gradually form user models with different modules and basic principles for working with the product from sprint to sprint. A UX group can consist of 2-3 or more UX designers and a visual designer.
UX designers have their own leader, who is actually a business analyst, and he has to dig deep into the industry-specifics. Based on work with service directors, he determines which methods and techniques for building the interface will be used and which will not, i.e. It develops a certain vision of user interaction with a future product.
And the visual designer develops his vision of managing the user's attention and emotions within the framework of a certain visual identity. It can be said that it creates a script for controlling the user's attention and emotions, but in real life, of course, there is no documented "script", there is only an idea and some initial blocks that gradually "grow flesh". And the designer does not dance from the stove with a business analyst, but spends all his creative energy cumulatively, spending only a few hours a week discussing already created interaction models and using videos with recordings of UX sequences. At the same time, of course, he can offer his UX solutions and implement them if they do not break the general concept of interaction scenarios.
On the other hand, no one intervenes in the work of the designer to visualize the product, because it is like a symphony not yet written - no one but the author can know how appropriate a particular note will be in the finished work.
Most projects are somewhere in the middle between these extremes, and those who manage the project know best whether to entrust the UX to the visual designer or not. As a rule, designing interactions is a more time-consuming and more important part of working on a product, and if a designer wants to control the process of creating interfaces, he must migrate towards UX. But at the same time, you need to be prepared for the fact that one day you will be moved away from creating the visual and you will have to watch it from afar.
Such a prospect somehow does not smile at me. I love prototypes, but I love mocapas even more.
I am on Habré in the Read-only status and cannot leave comments. Therefore, I ask you, my good readers, go through the hub of interfaces and put in a word about poor mockup.
Publications Prototype it followed Questions to the post of Alex Rublev about design . Although they didn’t ask me, I can answer from the shop floor.
1. Why, when designers are asked to remake something, do tantrums happen to them? Moreover, the more significant the improvements - the more terrible tantrums.
- Watson, this is elementary! The designers you were dealing with are not from the big leagues and will never be in it. If a person, making an interface for a touchscreen, draws millimeter buttons, then this indicates his lack of analytical abilities. He can be a good schedule, a good designer - no. Design is not how beautiful everything should look, but how beautiful everything should work and solve tasks. And if the designer was shown a mistake during the work, he should thank his colleagues for the contribution that would make the product better.
2. Prototyping really somewhat limits the freedom of flight of creative thought, but greatly reduces the likelihood of the need for alterations. Thus, there is less likelihood of designer tantrums. Does this not justify the use of the method?
- A rhetorical question that does not require an answer. The creative thought of the designer should fly in a given direction like a carrier pigeon, and not just like a moth. ;-)
Or, maybe I didn’t come across such designers?
If you are not afraid to learn the terribly merciless truth, then the level of your designers corresponds to the level of your projects: “From tens to hundreds of human hours , money, blood and sweat - to get an interface that is convenient for people. And five hours of designer work, before or after. ”
- Does the cost of visual make up half a percent of the design estimate? - So, for you the quality of the visual is a matter of the fifties. Receive and sign! Do you think that in Apple and Google they work according to the same principle - “well, everything is ready, we’ll hire someone to decorate in 5 hours”? - Not at all, they have whole design departments sitting there!
Yes, the customer knows better if the level of visual performance affects the profitability of the project. But what does “before or after” mean? There is a generally accepted, thousandfold proven methodology for developing information systems that defines the sequence: customer request> business analysis> UX> visual design> programming> QA, etc. And it doesn’t matter if the project is done using the vintage waterfall method or with the sprint Edge file - the sequence is the same. You can, of course, dodge and move the cart in front of the horse, but why? Apparently, then, that the project management has visuals on the drum: before or after, that designer or this - if only this fuss of creative personalities ate less money. For some reason, normal designers love it when they take their contribution to the product seriously. And usually they have a choice where to work. Se la vie ...
Since the conversation has come about the saint, why not throw a couple of branches into the fire?
I am an interface designer. And I love mocapas.
And why don't I love them, if I only do what I do them?
About prototypes or spell things by their proper names
To begin with, note that mocapas and prototypes are by no means the same thing. In a non-Russian IT dictionary, there are several terms for visuals corresponding to different stages of work on an IT product. The boundaries of these terms are blurred, but, nevertheless, having seen something interface-graphic, it is not difficult to classify it.
1. Sketch (sketch, sketch) - the initial instant sketch from the hand of what is wandering into the head.
2. Wireframe (block diagram) - a diagram or drawing representing the "skeleton" of the page of a site or application. No decorations, just the location and approximate sizes of headings, text blocks, illustrations, multimedia and navigation panels.
3. Prototype(prototype) is a model for testing a concept or process. Pictures can be inserted, color tones appear, etc.
4. Simulation (simulation, simulation, full-functional prototype) - on complex projects, also a model for testing a concept or process, but - Hi-Fi (high fidelity - high accuracy, unlike protopip, which is a low-precision model - Lo-Fi) . The iRise program is usually used to create simulations (or simulations, if you like). They use visual libraries that allow you to display pages very close to the final view, there are drop-down lists, buttons that change their appearance on hover, navigation between screens, pop-ups, etc.
5. Mockup or mock-up(mock) - a non-working model, made in full size and looking like a working instance will look like. That is, a web page made in Photoshop, submitted for layout, is a mocap. And it will become a design when interactivity appears. In fact, mocapas can be relatively dynamic and interactive, but more on that later.
Projects in which all these stages are fully represented are extremely rare. And since developers have no time to understand the nuances of what they don’t use, the term “prototype” can be called anything, in the interval between the first handwriting and the finished product.
About the principles of the designer or Why prototypes are good
At the dawn of site building, designers made prototypes for themselves, calling them “sketches,” “sketches,” “sketches,” etc. - who was much in what. Moreover, they somehow did not even imagine that they combine at least two or three different specializations in their work. About a hundred years ago, a motorist was a driver and a mechanic in one person, and even a little earlier - who wanted to make a bronze ax went personally to dig ore.
But now IT specializations have crystallized out, which indicates the growing industry. Replacing the old pure-ponte sites are really working, complex services, estimates are growing, the structure of working groups is becoming more complicated, the 21st century is knocking on managers' skulls. And this is good.
But why don't designers like this division of labor? - Yes, it is very simple: due to a significant loss of control over the product creation process. Previously, you could cook anything, but now in the “kitchen” there was another housewife who knows better how to cook semi-finished products, and from now on the designer’s task is to bring them to condition and serve beautifully. Moreover, these damned “interaction designers” blow at all angles that their work is more important than graphic design, and everyone agrees with them!
Whether these are different professions is not a question. They are different, and this has been proven many times. Can the talents of an interaction designer (I will write “UX” for the sake of brevity) and a graphic designer fully combine in one person? Not always, but they can. Around the same way as some pianists can tolerably play the guitar. The question remains, should you always separate the processes of creating UX and graphics and give them to different people?
In general, everything is simple with this: if a visual designer has enough abilities, experience and time to do UX, it's best to give everything to him (UX specialists can’t cope with visuals if they don’t have a designer past).
But the more difficult the work, the more insistently the question arises of the division of labor. Consider two typical extreme options.
1.Ideal for a visual designer, in terms of UX, it’s as simple as an amoeba: a web design online portfolio.
Here he is to himself - a customer and a contractor, and he can easily cope with UX. A career usually begins with this and other simple sites, carried out by a team of 2-3 people, where the designer communicates with the client tête-à-tête and rests in complete confidence that everything not related to programming is his design diocese. Often with this confidence, he goes further in the profession.
2. Adult option: a large and complex client application that demonstrates in all its glory the difference between interaction design and visual design, for example, a WPF project that has been in development two or three years or more before the first release.
Typically, stakeholders on such projects are people so important that they simply don't have time to talk with designers. Therefore, service owners are responsible for the adequacy of the tasks. These are specialists from the same industry as stakeholders, but with a focus on IT. They understand what tasks and how the product should solve, but at the beginning of the work, the final form of the application is vaguely presented, especially if the project is innovative and has no existing analogues.
The project, of course, is divided into short sections - sprints (usually a month and a half), and the UX group, in a tight, daily interaction with service directors, begins to gradually form user models with different modules and basic principles for working with the product from sprint to sprint. A UX group can consist of 2-3 or more UX designers and a visual designer.
UX designers have their own leader, who is actually a business analyst, and he has to dig deep into the industry-specifics. Based on work with service directors, he determines which methods and techniques for building the interface will be used and which will not, i.e. It develops a certain vision of user interaction with a future product.
And the visual designer develops his vision of managing the user's attention and emotions within the framework of a certain visual identity. It can be said that it creates a script for controlling the user's attention and emotions, but in real life, of course, there is no documented "script", there is only an idea and some initial blocks that gradually "grow flesh". And the designer does not dance from the stove with a business analyst, but spends all his creative energy cumulatively, spending only a few hours a week discussing already created interaction models and using videos with recordings of UX sequences. At the same time, of course, he can offer his UX solutions and implement them if they do not break the general concept of interaction scenarios.
On the other hand, no one intervenes in the work of the designer to visualize the product, because it is like a symphony not yet written - no one but the author can know how appropriate a particular note will be in the finished work.
Most projects are somewhere in the middle between these extremes, and those who manage the project know best whether to entrust the UX to the visual designer or not. As a rule, designing interactions is a more time-consuming and more important part of working on a product, and if a designer wants to control the process of creating interfaces, he must migrate towards UX. But at the same time, you need to be prepared for the fact that one day you will be moved away from creating the visual and you will have to watch it from afar.
Such a prospect somehow does not smile at me. I love prototypes, but I love mocapas even more.
Ps Answers to questions asked not to me ;-)
Publications Prototype it followed Questions to the post of Alex Rublev about design . Although they didn’t ask me, I can answer from the shop floor.
1. Why, when designers are asked to remake something, do tantrums happen to them? Moreover, the more significant the improvements - the more terrible tantrums.
- Watson, this is elementary! The designers you were dealing with are not from the big leagues and will never be in it. If a person, making an interface for a touchscreen, draws millimeter buttons, then this indicates his lack of analytical abilities. He can be a good schedule, a good designer - no. Design is not how beautiful everything should look, but how beautiful everything should work and solve tasks. And if the designer was shown a mistake during the work, he should thank his colleagues for the contribution that would make the product better.
2. Prototyping really somewhat limits the freedom of flight of creative thought, but greatly reduces the likelihood of the need for alterations. Thus, there is less likelihood of designer tantrums. Does this not justify the use of the method?
- A rhetorical question that does not require an answer. The creative thought of the designer should fly in a given direction like a carrier pigeon, and not just like a moth. ;-)
Or, maybe I didn’t come across such designers?
If you are not afraid to learn the terribly merciless truth, then the level of your designers corresponds to the level of your projects: “From tens to hundreds of human hours , money, blood and sweat - to get an interface that is convenient for people. And five hours of designer work, before or after. ”
- Does the cost of visual make up half a percent of the design estimate? - So, for you the quality of the visual is a matter of the fifties. Receive and sign! Do you think that in Apple and Google they work according to the same principle - “well, everything is ready, we’ll hire someone to decorate in 5 hours”? - Not at all, they have whole design departments sitting there!
Yes, the customer knows better if the level of visual performance affects the profitability of the project. But what does “before or after” mean? There is a generally accepted, thousandfold proven methodology for developing information systems that defines the sequence: customer request> business analysis> UX> visual design> programming> QA, etc. And it doesn’t matter if the project is done using the vintage waterfall method or with the sprint Edge file - the sequence is the same. You can, of course, dodge and move the cart in front of the horse, but why? Apparently, then, that the project management has visuals on the drum: before or after, that designer or this - if only this fuss of creative personalities ate less money. For some reason, normal designers love it when they take their contribution to the product seriously. And usually they have a choice where to work. Se la vie ...