How we design and prototype all garbage

The main enemy of gibberish is the plan .

A plan does not always come true (moreover, often you have to change a lot according to circumstances), but any plan, even an old and mossy one, is much better than its absence. Because it is clear that when and by whom should be done.
')
The prototype is closely related to the plan. It can be anything: a draft of a new game on napkins, a pointer layout in the subway, hand-crafted in a notebook, a detailed process diagram, or a CAD file, for example, for a store layout.

Such an approach gives rise to several rather strange conclusions. For example, if we are talking about a new site, it is obvious that all texts should be ready before the start of design work. When working with a game, virtual prototypes (in simulations) work only at the last stages of balancing, at first it is much more important to quickly assemble on paper. Speaking more generally, we know that the new XCOM (and XCOM2) was tested and tested as desktops, and then they were being chased to a computer.

It may seem that prototyping is not very necessary. Herak-herak - and in production. In fact, it is damn important in any process; for example, according to the precepts of yuzabelistov - this is 70% of the work. The question is how to do it.

I do not claim the truth in this matter, and I am very interested in your experience. Let's first tell you what we have brought to ourselves the things in prototyping, and then I will ask you to tell you about our prototypes and design processes.

Paper prototypes of games, processes and everything.

The first approximation - take a notebook and write down ideas. When there are a lot of ideas, and you are a project team, you should start a discussion. For discussion, it is best to use the method to them. Batman - take the paper paper and start writing everything that has gone wrong. The fact is that at this stage it is damn important to quickly and randomly fix thoughts. For example, in the photo we discussed a change of one of the production schemes a couple of weeks ago.


^{On this sheet of cardboard in the back, we drew one of the most important schemes of interaction}

If we immediately started to prototype this in the same Visio as a process diagram on a laptop, then it would take much longer. The method of Batman is good because you can record and build a circuit with the speed of speech. That is, in real time without distraction to the processes. Already then, after discussion, someone alone can build a coherent structure. And now “no, it's not like that, it should be different here” - this is one movement, not twenty.

It turns out something like this (this is a diagram of another process, very simple):



But back to the paper. Here is my desktop, which has a box with things I often need for prototyping games. The most important thing is a large stack of empty cards of different sizes, random number generators, timers and chips. In general, if you have a bunch of blank cards, you can do anything. It should be noted that we have repeatedly argued with the authors of games about the approach to the prototype. I adhere to the Rapid Prototyping methods - for example, Uncle Scott Klemmer from the Kachersevskogo HCI course tells about them.



I draw a field right on the table, since A1 is always on the table instead of the tablecloth. On the same table (it stands apart from the main worker) quite a few records can accumulate, which will then either be transferred to todo, or simply be reminded of the context.

The point of rapid prototyping is as follows: hypotheses should be tested as often as possible. Therefore, the idea came - they immediately took and painted, wrote on the cards what they wanted (10 minutes) - and played. To assemble a prototype on a computer - at least half an hour, plus then the same 10-15 minutes for sticking to the base or inserting pieces of paper into protectors with other cards. The shorter the iteration, the easier it is to test many different hypotheses on the fly. And the more you can come up with along the way, without holding the whole picture in your head at once, but focusing on the details. This means productivity. I know the authors of games, tormenting their projects for 5-7 years. I think for about a year they would save on understanding how to prototype more efficiently.

Another advantage of using real components is an instant check of the game process for quantizing attention and logistics of moving all sorts of pieces. It is inconvenient to read the indications from the game interface - he took and redrawn the scheme right during the game. If you need to shuffle the cards, this is very easy to do with real hard, dense white cards. And almost impossible - with printed on standard paper, as is usually the case.

The game is prototyped minimally , to the state of the demo. For example, if we would do a quiz, we would have collected not a thousand questions, but twenty pieces to play two or three rounds.

In general, this means that we put the content and mechanics of the game above art. If the players are touched by the essence, we manage to go through the most important bottleneck of the development process - making decisions about what will be included in the alpha. The fact is that everything else scales perfectly, but this part does not.

In the same way, once upon a time, we drew prototypes of websites and software interfaces on napkins together with customers, and then we wrote technical tasks, knowing how it should all work (and not vice versa).

The next step after having an understanding of the basic assembly is the drill down to the limit .

Here, for example, the prototype for mosigra.com site at the prefinal stage:



At first it was a wireframe like this:



Naturally, I want to give him exactly the work, and then smoothly write texts, collect pictures and so on. In fact, the experience has taught me that you should not do this. First you need to decompose everything on the prototype in order to understand how the pages will look, what is, what to get, what to double-check, what to add. The selection of photos is at least an hour, because we need to go through our archive, and the designer would not do it. Texts should be immediately, because with them it turns out that the structure of the page may not be so. On the other page there were small blocks with addresses in shopping centers and the company's history (the first are needed by tenants, the second is for some reason to journalists), and so, they turned out to be much more than expected at the beginning.

This piece of the page was probably going to be about three days:



The fact is that finding all the data about all the necessary games (just make a list of them for a start) is not a trivial task.

And the designer, and coder, and proofreader want to see everything at once. Because, obviously, if you collect content before starting work, then the result will be unequivocal. The ideal prototype is almost the result, only smaller and different. And if you give the designer blocks with Dolorem Ipsum, any surprise can occur during the filling. Actually, they would have met - as in the old joke about the "concept has changed", the direction of thoughts as the digging out of new facts and statements of departments about what they want to see on the pages, changed.

Yes, one more thing - internal coordination. The fact is that ordinary people do not know how to read non-detailed prototypes such as "this and that will be here." You just have to take and attach. I learned this even when I drew understandable for our customers diagrams of connecting satellite systems at the camp sites (there were no questions about where and how the cable would go, how to mask it, and so on), then consolidated the skill when we coordinated sites several times. Now I can say with confidence - all the content on the prototype, because then half will be cut. This is so that people in the chain do not do extra work. On the other hand, something new will appear exactly what would otherwise be described as: “it was not in the TK, a paid finishing touch”. And it is nafig nobody needs. It is clear that you can lay 10-20% on such unforeseen situations (they always happen), but the more and more densely you prepare yourself on the coast, the better.

As a result, I collected materials, facts, graphics, translations, and checked that it lasted about 6 weeks in total. And only 3 weeks the site was in operation after that. And there were no questions: both the designer and the coder saw how it should be. We brought specific content. If there were doubts, a “clean” prototype was shown at once to choose from two options (it happened once at the beginning and once when determining the degradation of layout for mobile phones). Everything.



And in general, this approach was very convenient in terms of management. I made a prototype - I sent one file to the design, the second - to the translation, the third - to the proofreader. Everything parallels with a minimum of movement.

You can prototype anything

I love scalable WYSIWYG interfaces that allow you to build a project in one work environment. It is necessary to write the text - please click and right on the field. It is necessary to insert a picture - here it is, right here, no ambiguities, a clear understanding of what and how it will lie in the bild. A long time ago, I started with Aldus (then Adobe) PageMaker, then jumped to Visio. But you can use any tools: for example, Sasha, who works with planograms, loves AutoCAD, production workers sometimes send pictures to XLS, Balsamiq Mockups is easy to use on the road.


^{Project area, one of the desktops}

The beauty is that in the development of interfaces you can extremely quickly draw over existing pages:



It’s easy to show the bug principle:



Easy to discuss layouts:



It is very convenient to make the rules of games, combining illustrations and text (this is perhaps the greatest advantage of such prototyping systems). For example, an early prototype of Taxi rules:



And this is how it looks in print:


^{By the way, yes, for everyone - Taxi is a game for teaching children basic algorithmic skills, and last year we opened its components in Creative Commons so that we could print at home.}

Here is a raw prototype of another educational game:



Typical view of our kind of like-newspaper, which we put in orders, in the prototype:



The process flow in the interface:



Part of the preparation of TK for the development of outdoor advertising:



Directly, these prototypes can be put on a photo of the place. This is very convenient for understanding whether the sign can be seen from the desired distance (or changing the layout), whether navigation blocks are shown there, and so on.

But the history of the prototyping of the Nefarius map (here about the process is more detailed ). Here is what the author sent, the first approximation stage:



Files from the technical project (all structural components are listed here, plus there are basic drawings “for something to be”):



Prototyping with us:



Result:



A piece of planogram calculations in the store (navigation on the wall):



Coming back to the question of interface scalability, it's damn nice that you can infinitely detail infinitely deep, plus by necessity easily and naturally switch (as on a real large desktop) or take things from the neighboring area. Of course, this all works wildly conveniently only on the big screen - for example, on a laptop I can dig into Visio, but there will be no high.

This is me going on the road. The main problem is that many devices are charging, the bag is assembled on the basis of a laptop (at the last moment), so not everything works out in a pile. Accordingly, my method is as follows - I take the cards and draw on them what is missing. And already put the cards themselves in a pile. This can be thought through at least a day. We need to get together - just replacing these cards step by step with real things. The list is worse, because here is one object - one card.



A similar principle is used in industry, for example, on the cabinet can be fixed cards of what lies inside, and on the wall - painted tools in their places. For example, it is immediately obvious that the mechanics are Japanese, and the production is Russian. Japanese would die of shame, probably:

Summary

The prototype is a good friend of the plan . Sometimes the prototype replaces the plan with what it immediately shows what to do and how. Like a good plan, a good prototype is fast at first, like diarrhea, as well as sudden and joyous, like a blow with a baton in the dark. In the sense that while you are doing it, total clarity comes to your mind and questions come that would be asked further. And you can immediately search for answers to them in advance, right during the workflow, quickly and without switching attention.

The prototype allows you to avoid long sheets of text, because it makes it possible to show , not tell. And the prototype almost does not allow for ambiguous interpretations (after lapping - after all, it still needs to be learned to read), which is damn important. And both on big tasks, and on small. As a rule, it is better to spend an hour on a prototype than later on 4 hours of your time and a lot of other people's time for rework.

In general, if possible, prototype everything. This is a great discipline. And accelerates projects.

Please tell us how you are prototyping and planning, this is very interesting.