Prototypes as a product presentiment

Imagine: your child is dying from a rare and incurable disease. Strangers beat him and he suffers from terrible pain. At the very end, it dries out to the size of a cat, becomes completely gray and finally dies. And then the happy-end happens: you will find out that an error has occurred in the maternity hospital ... F-F, scared, dur-cancer!

Congratulations, you are introduced to the life cycle of an ordinary prototype.

Hello friends! Prototypes are the backbone of product design. I will tell why we in the team use only hi-fi prototypes and abandoned all others.

We have already talked about the structure of applications and the definition of navigation principles. Cool But what to do with all this next? No problem! Of course, you need to develop a prototype. The prototype is needed for early MVP testing, for reducing design risks, for testing the suitability of proposed solutions, for showing to shareholders, for crowdfunding and for saving time when communicating with developers. Everywhere we hear moans. Everybody needs a prototype. We must extend a helping hand, and we will extend it.
And here I have 2 news for you. Good first: bad news could be much worse ...

Problem of choice

The fact is that disputes, which prototype to use, flare up with a new force. And I'm going to throw firewood in this sacred bonfire! In the recently shared MIT course on user interfaces , they preach that the prototype is quite possible to make from shit and sticks. Immersed in this course, you can find out, for example, the composition of the recommended set of tools for paper prototyping, namely (write): a whiteboard 11x14 ”, large cards of 4x6”, glue, white correction tape, transparent film, pen, scissors, etc. I hesitate to ask: are the markers colored? Or read, for example, IBM design thinking . To the music from the Benny Hill show is going great. Well, wow! I do not want to say that there is absolutely no useful information for the ordinary designer. By no means! But she is there in such homeopathic doses, that the effect of her is also homeopathic. As the saying goes, what is the table, so is the chair.
I propose to shake the twentieth century out of the ears, abandon the cargo cult and look at the problem from the trench of real design. I want to warn you that all this reflects our own experience, which may not coincide with yours and hurt someone’s religious feelings. Please understand and forgive me in advance. He who has ears, let him hear the crunch of the pattern .
')

Prototype Types

I will not describe in detail the types of prototypes. If there is already a question of choosing between them, then you probably know them. For brevity, we give them the nicknames:

• paper (paper prototypes);
• clickers (clickable screen sequence);
• zombies (interactive prototypes created using specialized tools like Axure);
• hi-fi (pure html + css).

All of these species, to some extent, are based on two main methods. This is a rapid prototyping, which implies that the layout at some stage will be thrown away and will not become part of the finished system. And evolutionary prototyping, when a product is literally “grown” from a prototype embryo, gradually acquires features and is constantly being tested in conditions close to combat ones.
Practical interest for product design are only evolutionary hi-fi prototypes. And I undertake to prove it.

Slowly down the mountain

A couple of words about speed. Well, to cool you right away and bring you back to earth. The network is teeming with amateur articles about "rapid" prototyping. On paper, on the knee, on the smartphone, in the browser. The main advantage, which usually focuses - time. “In 5 minutes you will have a working prototype of your ingenious program!”, “Without a line of code, you will receive complex, animated interactions!”. Here it is. You are caught on the lure of laziness and greed. You slip products sheath-class. You implement the idea that you can achieve success without much effort. People even manage to sell special notebooks for drawing mobile applications. GHM! When I was young, I believed in this blizzard and, although I didn’t buy notebooks, I walked a path full of pain, from paper to html. Looking back, I can say: fast does not mean good. The result should be adequate to the task, and the speed of its receipt is always secondary. What the hell is fast if wrong? Especially if the development cycle takes several months. Well, in addition, paper and zombies are harmful. Why?

Remember in the movie DMB:
- Will you, Fedya, Bombboy ...
- Why Bomb?
- Because quick-tempered ... You, Vladik, will be the Bayonet - because you are slim ... And I will be the Bullet - because you are on target!

We must remember the goal. Let's talk about paper separately, and zombies distract from the main main movement of the idea - from the head to the product. We need to get the app. An application is a code. Most likely this code is html. Well, and name at least one reason, why should I be distracted from the goal and study the left proprietary solution instead of pure html?

Do not waste time on third-party applications, it is better to invest it in the study of html. You will move towards the goal much further.

Not to mention that your value as a designer will grow. Look through job openings - more and more often they require “html hands”, in addition to “hand-draw”. Today our company is no longer alone.

Paper

Let's start with the paper. Well, what could be the harm from a paper prototype? That's right, no, because the paper prototype is not . With the same success, I can say that I have a “neural” prototype - in my own head. A prototype that is always with me, aha-ha. I have a lot of them. I twist these prototypes in my head all the time - when I go to the pot in the morning or walk with the dog in the evening. But seriously, the prototype is what works, what is shown to users and on the basis of what decisions are made. Paper is a sketch. Paper sketches allow you to capture ideas, structure them and discuss with a colleague. But only. Show them to the user is not worth it. Nah Swam, we know.

A prototype is what the user interacts with and on the basis of which decisions are made. The prototype is an experiment.

The paper gives the false impression that a solution has been found. Once we tried to solve a problem - how to show tabular data with different amounts of information in columns with a lack of space? Spied on how it is implemented in Outlook. In 2 minutes, they sketched a sketch on a piece of paper. Well, here it is, the decision! Quickly conducted corridor testing. Successfully!
“Hop-hey-lal-ley!” - we said with Product Owner and went to the cashier for a bonus. I was lucky that we decided to draw the layout in Fireworks, and not immediately to impose.

After several hours of work, it became quite obvious that the idea is rotten and does not work in our case. The same people who really liked the clumsy handwritten sketches on paper (especially if they themselves drafted over), unanimously condemned a neat, beautiful layout. Wasted a few hours in vain. Unfortunately, this cannot be avoided. You can reduce losses if you do not test the paper. After a couple of such cases, we firmly decided: the place of paper is in the basket.
Do not believe anyone, especially Wikipedia, which likes to write beautiful articles about paper prototypes , as well as about choch, evil eye, palmistry and urinotherapy.

Just make a nick yourself - there are no paper prototypes. Santa Claus either. Not that. Paper is used elsewhere. Do not treat paper as a prototype. Point.

Clickers

We take a set of the screens drawn by the designer, and we connect them with each other by means of image maps. We look in the browser, in an adult way. Benefits do not bring, but do not really harm. I see this view as a transition from a set of images to pure html. What do they allow? They allow you to save on text descriptions of the form “This button leads to the property page. And if you click here, this window pops up. ” You can determine the total number of screens and check if the scripts overlap? But doing this with the help of rendered screens is a waste. I have been through this, and this is not a productive path. Do not go here.



Let's go back to the clickers. The benefits of their use: the "clean" designers, they remove the fear of html and put in order the head. Designers start to think like designers - not by single screens, but by series. It pays off very quickly.
The main problem is that, most often, the screens have already been drawn. The designer has already invested for some time, but an ordinary person will not be able to support and defuse such a prototype. Unless, of course, he is not a level 80 maniac. Yes, you can use symbols in Fireworks, but everything is cluttered very quickly, and absolutely not worth the time to support. In general, after a couple of iterations, the system comes to the state “If you drink milk with sprats, then you can not wash strawberries”. To understand this prototype becomes difficult, and more often - impossible. Separate hell is when you made changes to 10 current screens, and the remaining 40 left the old version (there is no time) and the web designers with the stupid question constantly twitch you: “Why? ..”. Because because!

Rumor has it that on a poppy there is a certain Sketch in which everything is implemented as it should. I'll check when I can reach. Eh! Tell us in the comments about the sketch, please. Especially, about the miracle plug-ins for prototyping and for working with data from json.

Well, and there is a macro problem of microinteractions . About the importance of which does not have to say. Transitions between pages are good, but what about the animation, scrolling, motion and other interactions? Score! Or use other tools. A clicker is not a prototype.

It is possible to show the rendered clickers to users, but not for testing scenarios (this is technically very difficult and dreary), but for evaluating the design. That’s all.

Clickers sketches can not be tested. Denim can not be tested. Re-read again. It is impossible. By testing, I mean usability testing. Do you really think that you can make a decision on the product depending on whether the user has learned the drop-down list or the button in the outline of the screen? And if it korezhit from ComicSans font? And if he did not stick that you can click on this title? In theory, everything is simple and beautiful: flies with meatballs live separately. Button separately, and its color separately. But this is a theory. Life is much more complicated. And it is better to immediately take this into account, and then simple ideas and easy to understand, wrong decisions will come after simple theories.

Therefore, I’m wondering when hand-sketched clickers offer to show users. There are even special skins in Expression Blend. Attention, the argument is as follows: we check the interaction, we need to ensure that the user does not pay attention to the design!
Well, what can I say? Cheek brings success. But if life and sanity are dear to you, stay away from the peat bogs.

Zombie

The selection of specialized prototyping software is huge. As they said in the Soviet stores - in the range. Paid and free. Desktop and cloudy. Monsters and widgets. But the store is large, and the goods in it can be divided into only 2 groups: garbage bags and garbage bags. Here believe me!
This is a dead-end branch of evolution. Why? Restrictions architecture.
As the owner of an adult ridgeback, I know that a one-year-old puppy is much smarter than a one-year-old child. It's true bazaar yoke. And how fast is growing! He easily learns to bring slippers, runs after the ball and wants to please you. But he will never wash his dishes. Never ever, no chance. After all, licked is not considered washed! Quite the contrary. Your indigo prototype is so pretty, so cheap and quickly made. Its so nice to show. But in the long (and product design is a game in the long) you lose. Rest in the wall. Of course, if you need a prototype of a site, a small application, a messenger - take a zombie and do not worry. But we are talking about complex products, right?

By the way, why zombies? Because "as a living." Because it is contagious. And because it is a corpse. Dead corpse of a dead dead man.

What are my arguments against?
1. You can not use a single line of code from your prototype in a real application, despite the fact that the output is generated by html. Double time costs are guaranteed.
2. You are limited in your abilities by the features that your tool supports. You look at the world through Axure or proto.io crack, and therefore are already biased in their prototypes. Decide if you need it?
3. In addition to the prototype, you will have to write a volume TK for developers, where to describe in detail the details. I met the TK in 60 A4 pages. Ash-tree, I did not read it, life is too short.
This is a separate large hemorrhoids, which can affect the choice of method of prototyping. Yes, bridge bridges between the designer and the developer appear periodically. These plugins pull information from layouts - the amount of indentation, font names and size, colors, etc. But working with these plugins is extra time you want to avoid. And when you change any numbers have to make changes to the TK. After the third revision, you will learn that it was a mistake to think that a gentle person could not overwhelm you with a board.
4. How to transfer to the product micro-interaction, animation? Let's say you have been setting up a sly bounce for an offcanvas panel for 1.5 hours and where should you put it all in now? Guess yourself?
5. Developers do not trust zombies. In fact, who said that your prototype can be implemented in a product using standard html? And how many squats have to do for this? This adds additional friction to the process. Although, I met gambling developers who shouted: "I can, I know how to do it!". Meet these - carry on hands.
6. Performance and support. I tested Axure a little, indigo Studio, proto.io. Long did not stand. Sooner or later, there is either a reliable breakdown or terrible brakes.
7. Lack of modularity. You can, of course, not collect one super-duper prototype for all scenarios, but have a small zoo of under-prototypes and deftly juggle them. But this is an ikotka and a shudder, there are no tools for this, no ng-include and it does not smell.
8. Time. You will have to spend time studying the interface, tools, read docks and watch tutor on third-party programs. Spend time away from the goal! Isn't it easier to go to codeschool and start moving in the right direction ?
9. Price. Decent tools cost money. If the budget is limited, you will have to be content with trimmed versions or simpler open-source solutions.

Separately, it is necessary to remind about uncanny valley of prototyping , which can be translated as an ominous valley. See why it is not recommended to show the zombie prototypes to the business angel Pishkin or the investment banker Kakin. Because zombies fall exactly in the gorge, at the lowest point.

It so happens that asthma is like an orgasm, but everyone understands the difference, right?
Hi-fi prototypes "hover" over the ominous valley for the simple reason that they are similar not only from the outside. Strictly speaking, they are the product. Inside the same html, which is simply taken and used "as is".

Boy, bring vodka, we will fly home!

Thank God, all this disgrace is an alternative. Evolutionary hi-fi prototyping. An approach that can be expressed by the slogan Fake it 'till you make it . Ideally, you should aim for a full fidelity prototype. Full fidelity means that with the naked eye it is impossible to distinguish a prototype from a product and it uses production-ready CSS. It looks like a real product, it behaves like a real product, it works in a real product environment and it contains absolutely all micro and macro interactions from hover effects, sliding in accordions before the animation of changing views. The only fiction is data. Bourgeois call such prototypes horizontal. The data used are lorem ipsum, made-up texts (this trains the imagination), or Yandex abstracts. It is important that the data is stored in json, and not hardcoded in html. Therefore, all sorts in tables, filters, searches, and so on work.
All this is absolutely real and every day it becomes easier and simpler. Trust me.

Not to be unsubstantiated, I’ll give two screenshots: a prototype and a real build of one of our products (Light client v.7.0), which is currently being tested and is being prepared for release. Our analysts often confuse them with each other, which brings a merry commotion into the development process. In general, everything we love.


Game: Find the seven differences in the pictures

Such a prototype is not done in half an hour, I have nothing to say here. It is “grown” from the embryo Denim, and as a bonsai it is constantly in the process of forming the crown. Then cut the roots, there to tie a sprig. So that you can estimate the cost of time, I will say that the study of one user scenario (4-5 screens with all interactions on each) takes 16-24 man-hours. Moreover, this time is quickly reduced as the designer uses the framework used, grows into the process and a set of reusable controls appears.

I foresee cries of “This is insane! Kill him, Shilov! The designer should not impose! The prototype is being made to throw it away! ”And others. But they become adults, not when they stop listening to their mother, but when they realize that mother was right. Therefore, I am ready to substantively discuss the advantages and disadvantages of hi-fi prototyping, as well as the reasons why we went this way.

The reasons

The cause of all causes is, of course, economic.
In vertical teams, when designers, developers, testers work separately from each other and you have 3-4 products under development (or about 20, like ours), your production department turns into a tattoo salon: painful, expensive and forever. Change anything on the fly will not work. Once I even won a dispute with the Product Owner that he would not be able to step in and insert a space in the Russian localization of his product. It is possible to do this through blood and guts, but only once. Then you tear your bare hands. Therefore, the mode of operation is as follows: measure seven times, transfer to production once.



Of course, you can experiment on the open heart of a living product, but not for long - after all, the miner is mistaken once. In general, sometimes the price of a question is so high that it is easier to have a copy of the product for experimentation.

But this is not the main thing.
The main thing is that the designer, business analyst and product owner go to several sprints in front of the team and try to build a trajectory to the desired functionality and UX so that:
1. Did not have to do extra work;
2. Use what has been done before;
3. Ensure a smooth interface change and
4. Move forward, despite paragraphs 1, 2, 3.

It turns out that when we move our finger, the brain does not send a special signal to that finger. Actually, there is a general signal “to bend!”, And after it - the second impulse, suppressing movement in “unnecessary” fingers. This is due to the way evolution works. She never creates anything from scratch. It only modifies what is already there. Just like us.

The trajectory of change - this is the most difficult. Evolution. It is much easier to break all the fucking and pile up from scratch convenient and beautiful site Kinopoisk, if you know what I mean. And for laying such a route, you will definitely need a prototype, which, on the one hand, most closely matches the current product, and on the other, it has a much larger set of features, since part of them in the product is always stabbed, because the resources are not infinite.
The presence of such a prototype makes life easier for everyone. But you have to do it for you. And this is the second news, which was mentioned at the beginning.

disadvantages

I have been going to this lovely club for 2 years now and from the shortcomings I can point out the need for constant training. You will have to keep abreast of web development and follow the news. Although what is this drawback?

Secondly, if you step on this path, there will be no turning back. You just can not. You will not be allowed to do this by your analysts, developers, testers. Yes, to be honest, you and yourself will be nauseated at the mere thought that you do not have complete control over the appearance and behavior of the interface.

And third: the ability to evaluate a static layout is atrophied. In my opinion, this is the most unpleasant thing to be encountered. We have a product where we work in the old manner - draw pictures and write TK. So, I found that I can not say, I like this layout or not? I need to move the mouse, click, scroll, and so. To interact. Feel the product. Without this, no opinion appears, you have to squeeze it out of yourself. I continue to observe.

Virtues

All the numerous advantages of hi-fi prototypes are so obvious to me that it causes a monstrous booring. But it is necessary to list all the same:
1. The prototype is not thrown when a real product appears. Your work flies into the basket about never.
2. Miscalculations, when I simply forgot or missed some trifle, emerge already during the layout of the prototype.
3. Design errors are caught during the testing phase.
4. These errors and miscalculations do not fall into the product, so time is saved on their fix.
5. You have your own training ground for experiments! You can, for example, take and estimate "And what if you make this button 2 times more than the others?". Minimal css editing and after 2 minutes can be tested. And get the result!
6. The result of usability testing is simple and unambiguous . Your users see the product as it will in reality. Reservations are not needed "do not look here, the fish were wrapped here." You simply launch users to your range and watch them. From your vocabulary, the phrases “prototype is good, design sucks” or “design is fashionable, but the designer is nosyachil.” This item outweighs all the others combined.
7. No need to remember or go into the documentation to get an answer to the question "What does it look like / work in this scenario?". Do not laugh, but we often just open the prototype in the browser and see how everything should work. At the design stage, all the little things that cannot be remembered after some time are thoroughly discussed. If you fix them on paper, you get those very TK on 60 pages. And the prototype is always at hand, and you will get a visual answer in 10 seconds.
8. The prototype provides more accurate estimates of labor intensity, which reduces the risks of development. The ambiguity of verbal descriptions disappears. You can touch everything.
9. Failure of crutches. If some interface solution requires complex crutches, then it becomes obvious already at the prototype stage, and is immediately discarded. Save time and increase product stability.
10. You use simple and free tools Brackets or SublimeText.
11. Git becomes available to you. It's like an award Mauser. When you realize all its power, the world will become much friendlier. To keep several branches at the same time, switch between them and at the same time have only one project folder - it’s worth a lot, you can believe me. Roll back 3 commits — let me kiss you!
12. The modularity of html allows you to focus on a specific task and get rid of all that is superfluous.
13. Help a gigantic community. Stackoverflow, github, hundreds, thousands of free plug-ins and modules that constantly appear and are ready to use immediately. You will always be at the forefront of progress, and not hostage to the developers of Axure.
14. Reducing friction between the designer and the developer. You will begin to understand each other’s problems, which contributes to a better product.
And everything else that I safely forgot about.

Living style guide free of charge

Yes, another very important thing. With proper construction of the process, you have a chance over time to turn your eternally-living prototype into a kind of living style guide. What is the dream of many, especially in large companies with a large food park under a common umbrella, such as mail.ru. Moreover, without the use of third-party tools. All you need is to put all the controls used in the product on a separate page and monitor the relevance of css. If you need to insert, for example, a drop-down list, the maker-uper visits the page and makes copy-paste a piece of code. And without any documentation that is instantly outdated and which is maintained - a separate sadness.

Materiel

To spend money wisely, two things are needed.
To effectively build hi-fi prototypes, you also need two things:

• sss framework
• angular

I will not describe our specific solution and provide links so as not to divert the conversation in the direction of the bootstrap / semantic UI / skeleton holivar, etc. This is a separate topic. I will say that we use zurb foundation for apps and are satisfied with the result so far. The choice is yours, but the decision must have a developed grid for building complex, adaptive layouts, support sass or Compass and be built using gulp. Plus, angular is needed if you really want to have truly interactive prototypes. And don't be alarmed, it just sounds terrible, and my own experience shows that “a confident PC user”, having received a couple of links, and having driven 3 commands into Git Bash, easily sets all this stuff for himself. Package managers are driving incredibly. But after a couple of days, you find the _variables.scss file in your intern in the folder, and in it the variable colors that it uses. Checkmate, Karl!

Mobile first

Honestly, this approach to development turned out to be not a bro. Either we do not know how to cook it, or it is also an urban legend. Perhaps the fact is that for document circulation the issue of mobility is not so urgent. - . , , , — .
, . . - . , — . . , , mobile only.

, , mobile first . .

? , ! , , , . ! .

. , , — , . , .. . - . css, , . , . , . . , , mobile first .

- . - , . , — confirmation bias:

— . , !
, , , !

, — . ! ! — , . .

Happy prototyping!

TL; DR

« , — '» html hi-fi , . , . , , -. . .