“Product in a glass” or how to make a concept overnight and not go crazy
Hello everyone! My name is Nikita, I am the leader of the professional interface team of the Rostelecom design studio! We are one of the youngest, but at the same time the largest, teams of our competence center, and in a relatively short period of time we faced a considerable number of interesting and complex tasks.
As part of the work on the concepts of various products, we have developed a methodology for product intensives, which allows us to give a completely adequate result in the shortest possible time. As of the spring of 2021, we have held about five such workshops. In this article I will try to talk about the essence of the method using the example of our first and most dense intensive.
An important point: the project we worked on is under the NDA, so we will do without a name. It is not important – an article about the process of work. I tried to describe it in as much detail as possible.
Formulation of the problem
It was mid-April outside, the height of self-isolation. Partners came to us and told us about a new and interesting project. The description of the project sounded very cool, interesting and comprehensive, so we were very happy to take on this task. In addition, the project was quite fashionable for us, which in fact meant an urgent need to fit in and do it. But there is one BUT…
“BUT” was that we learned about the project at 16:00. And the partners at the end added that tomorrow at 13:00 there should be a presentation of the concept to the customer, and they should have everything in their hands by 11:00 in order to have time to prepare and give us comments for edits. And such terms obviously look much worse on the scale of the system than the “five-year plan in three years.” But what is to be done? We would not be ourselves if we did not get involved in this adventure.
I’ll make a reservation right away – it was necessary form a concept, determine the direction of work on the project and show an approximate vision that is as close to reality as possible. In the end, we all understand that it is simply unrealistic to create an adequate product overnight.
Therefore, from the department of professional interfaces, they selected a “gang of selected thugs” from the design world and began to think over the process of creating a concept for a system in 19 hours. Obviously, it will not be possible to build “according to the textbook” during this time, so I had to sacrifice idealization and meet reality face to face!
There were several criteria for forming a team: a small, well-played team for quick and easy communication; universal skills from designers, so that you can quickly change and transfer tasks to each other. There were five of us, so we could split into teams and parallel some work. One person kept track of the integrity of the design and threw in ideas that helped optimize the design – a kind of overseer architect.
Okay, the countdown has started. We immediately drew up an approximate plan for the design processes and for the time intervals that we needed for this design:
Creation of wireframe layouts based on the core functionality of the system;
Creation of wireframe layouts for dashboards and additional sections of the main roles;
Search for a UI solution and fast rendering of components;
Drawing main screens using wireframe layouts using UI components;
Writing scripts to demonstrate how the system works;
Drawing a complete set of screens in the UI, corresponding to the scenarios for the demo;
Assembly of clickable prototypes for scripts;
Demonstration to partners;
So, there is a plan. We proceed to the first stage – we divide the remaining four people in pairs: one pair goes to cut the wires (they are wireframe layouts or just rough sketches) of the core functionality, and the other – the wires of dashboards and additional sections.
The first milestone happened three hours after the start. A number of low-detail layouts were prepared for the required sections. We ran quickly, corrected the concept and went on to saw.
During the meeting, we all agreed that wasting precious design time on UI is super-non-rational. We quickly looked at what we have in the bins – and, oh thank you, we have such a large team! Yes, we just boldly reused the components of the projects already existing in the company, slightly changing the colors. It turned out like norms. Trust us – we liked it).
Great, we did the first three tasks! But only on the clock it is already 21:30, so it was decided to rest for an hour and continue to work at 22:30.
Slightly redistributed. Three went to build mock-ups on UI components by wire, and one went to write scripts for demonstration. An hour of rest gave a charge of new strength – we ran to do it.
The next milestone. Demonstration scripts have been written. In order to build an unbreakable flow, we decided to be somewhat imbued with our characters, according to which we are conducting a demonstration, so at first the script was built in the form of a simple text with a description of a certain person and a life case.
Now the abstract description needs to be broken down into screens and actions on them, so we quickly threw a flow in Miro for all three key roles.
In parallel, the main screens were assembled by wire already on the UI components. The three guys continued to work on drawing the necessary screens and states according to the described scenarios, and the scribbler went to bed to rest and continue working.
At about 5 am, the guys finished drawing all the necessary screens and states according to the scripts and went to bed. At 6:30 am, the person who wrote the scripts woke up and sat down to prepare clickable prototypes. I had to edit the screens a little in terms of the data described on them, since the guys did it quickly and did not always pay attention to some attributes and texts, but this is very important for demonstration.
The work on assembling three clickable prototypes (for the three main roles) lasted just until 11:00 – the scripts were given to the partners for review, comments were received, and minor edits were promptly made to the layouts.
At 13:00 our partners left to present the concept of the system to the customer. An hour later, the guys who worked the night shift woke up. And an hour later we found out what the concept was good for, and now we are taking the project for further study in a slightly less frenzied mode. It was a victory. In fact, we carried out a development cycle of a product design solution without research – the concept was based only on our hypotheses and small pieces of information that our partners threw in to us. It’s funny that our hypotheses mostly hit the mark.
It is our process of working in this situation that deserves a lot of attention. We immediately realized that we would have to sacrifice something, and we would not be able to build an ideal in such a time frame. An important role was played by the right choice of a team to work on the project, parallelization of tasks, tight communications and rest. Yes, rest. Let’s remember the hour from 21:30 to 22:30, as well as the fact that the lark-clerk of the scripts was allowed to go to sleep, and then wake up and finish the tasks. But what in any case could not be sacrificed was meaning. Therefore, we moved from general to specific – from warps to layouts in the UI; first the idea, and then the implementation.
After the first intensive, we, as mentioned above, more than once returned to this format. In most cases, the final result and the amount of work varied greatly depending on the understanding of the requirements for demonstrating the concept – to whom we show, what is expected of us, what we ourselves want to demonstrate.
The project was developed for another month, we finished it up, “changed” it into a more meaningful customized UI and gave it up for approval. It was a cool and absolutely invaluable experience of quickly creating a project with a clear organization of the team’s work and an action plan. But is this approach applicable for long design terms? Not really. Relying only on hypotheses is a dangerous path that can lead to the premature death of the product. Information about scenarios should either come from analysts, or be obtained independently during design studies. Perhaps we will talk about this in future articles).
In the meantime, thank you very much for your attention! Until next time!
Denisenko Nikita (TG: @contragore)
Team lead of the team of professional interfaces of the UX / UI competence center of the Rostelecom IT cluster