Development of an online service for the ZIL Museum from idea to implementation
Hello! PixelPeak product team is in touch. In the article we will tell you in detail how our team came together, why we decided to create a ZIL online museum service, what research we conducted, what difficulties we encountered, and much more. The case will be useful for those who want to know how work on a project is carried out in digital studios.
Nonprofit start
Our story began at the end of March 2024. Nastya Krasovskaya, founder of the digital agency PixelPeak, moved with her family to the ZIL art district. Every day, when she went for a walk, regrets appeared that once upon a time there was a legendary ZIL plant in this place, and now there is nothing left of it: the memory of it is gradually erased, and the stories about the great exploits of heroes fade into oblivion .
Time moves forward, the old is replaced by the new, and many would come to terms with this, but not Nastya! She wrote in her Telegram channel that she was gathering a team for a non-profit project – those who respond will become employees of her studio for the duration of the project. The hiring conditions included responsibility, consistency, a desire to learn and listen to the manager. No commercial experience was required; UX/UI knowledge gained after completing the courses was suitable. We expected 5-7 responses, but in the end we got more than 20, so in addition to the festival website, we decided to create a grocery service.
The offer was beneficial for both parties: Nastya received a team to implement the service, and we, the project participants, received experience working in the studio + training from the founder. More than thirty people gathered, we divided into teams depending on the role we wanted to perform in the project (development of a festival case, product service, copywriting, PR).
So, in April 2024, the non-profit project “Oh, let’s do it!” was launched, work began on a food service for the ZIL Museum and a festival website, which we will talk about in the following articles.
Setting up team processes
Nastya took over the festival team, and handed over the management of the grocery store to Igor Shulga, a product designer from T-Bank. There were 12 people in the product team (11 reached the end – a good result for a non-profit project).
The development of the service lasted almost six months: we conducted qualitative and quantitative research, drew up hypotheses, thought through job stories and features, drew wireframes, selected references and created visual concepts (the first one, by the way, didn’t work out, but first things first). The work was carried out in weekly sprints. according to the development plan, where all stages were visible. The work plan was implemented in Notion; in the same service we posted research results and other materials necessary for development. Later we had our own wiki, which contained useful articles, videos and books.
The work process was structured as when working with clients in the studio, therefore, in addition to schedules and deadlines, we had a completed brief. After the brief, we divided into teams, and Nastya appointed leads – they managed the processes in their teams, put the data in order and helped the participants when difficulties arose. Participants only had to be responsible for their part of the work.
The main task of an online museum service is to earn money. We had to figure out how to generate profit, and we started researching.
Qualitative Questions and Integrating Meanings
We were given the task of conducting qualitative research (interviewing). In order to get more data, nine people from the festival team and copywriter Anya Kazakova joined us. She lives in the USA, and we have a big time difference, but this did not stop us from preparing materials for the call. Below, Anya tells how she did it.
During the calls, Igor, the leader of the product team, taught us the correct approach to research. For example, to conduct a quality interview, he advised using the “five whys method.” Igor spoke very lively and interestingly, gave many examples, and we took notes in notebooks during the call so as not to forget anything.
Here's an example of what the beginning of our interview looked like:
Hello (name)! My name is Kamilya, and I am doing research (on the topic…). Thank you for agreeing to talk. Our conversation will take no more than 30 minutes. Let me give you some background information: 1) our entire conversation is confidential, and the results will be as anonymous as possible; 2) there are no right or wrong answers. Try to answer honestly and sincerely. First, let's get to know each other: tell us a little about yourself, where are you from, what do you do?
Each interviewed at least two respondents: one who visits museums and one who does not go to them. Interviews were taken with acquaintances and strangers, and even with museum workers. The data was entered into a table, and leads were collected from the summary responses. At this stage, difficulties began: Igor told everyone to use stickers, one of the leads decided to write in text. “As a result, we were a little focused on the call, but still combined the answers according to their meaning,” recalls one of the project participants. This is what our summary looked like:
Igor said that there is a lot of information, and it can be greatly compressed. Here's what Igor did:
At this stage, the festival team separated, and work was carried out only inside the grocery store. In the summary, we identified the main barriers to visiting museums and began forming hypotheses to find optimal solutions. For example, a person does not go to a museum because there is no one with him. We formed a hypothesis that if we add the “join our chat” block, a group of people with similar interests will gather, and the problem will be solved.
During the process, we also came up with questions that could be used to confirm or refute the hypotheses, after which the leads created a survey from this list to test the hypotheses.
The basic rules for compiling a survey that guided our group:
Calculate the required number of respondents
Write qualitative questions:
– one question – one topic
– simple and logical
– objective, without pressure on the respondentThink about the answers we can get
Work out the style:
– clear, lively speech without jargon
– ask questions in the second person, answer in the first
– the question and answer should form a dialogue
– the wording must be universal, not tied to the gender of the respondent.The survey was designed in such a way that each question tested one of the hypotheses. After receiving the results, we compiled a list of confirmed hypotheses, then divided them between the teams and began developing job stories and features.
You can view the survey results in detail at this link.
We chose the Job stories format because they shift the focus from the user's characteristics to the situation in which he needs to use the product. Thus, what matters most is what value the service can provide to the consumer, rather than his personal interests or education.
When [описание ситуации] – I want [мотивация] – To [результат]
Below is the format we used to create the job story.
For example, we had a story “I, as a museum visitor, want to buy water because my child is often thirsty” or “when I, as a primary school teacher, go to the museum with my students, I want to be able to organize a group excursion so that I can and every student had a discounted ticket.” Based on them, we form functions (features) and make a list of necessary features. Next, based on them, we form the site architecture and design where everything will be located.
We came up with a lot of features. But the implementation of some of them will be unreasonably expensive to develop.
To avoid wasting time on such features, we used the ICE (Impact, Confidence, Ease) scoring prioritization method. It shows which ideas need to be implemented first, which ones can be done later, and which ones can be completely forgotten about.
Usually, the next step is to develop wireframes and meet with developers to figure out the time and cost of development.
In our case, we will take a different path. First we design the warframes, then we draw the concept, because we don’t have a design system. If there was one, we would immediately go and create a highly detailed concept).
Igor Shulga, product designer at T-Bank
After all the research, Igor formed three teams from the participants: Terra, Aurora and Stella, each of which had its own role: terra – the main page and online museum, aurora – the entire purchasing process and stella – the offline segment (pages of routes, guides, exhibits). Next, the leads compiled the information structure of the service in order to understand what pages the service would have and determine the amount of work. Then we agreed on the structure with Igor, and all three teams began creating wireframes.
Creating wireframes
We called to coordinate wireframes. Igor approved the decisions of the Stella team, and we began to discuss the content of the wireframes: we decided what indents, font size, cards, etc. would be.
At the same call, Igor disbanded the Terra team because one of its members did not participate in the work. It turned out that there were three wireframes in this team in order to meet the deadline (the lead helped with this, although he did not have to deal with other tasks). Terra participants were divided between teams Stella and Aurora.
After that, we called each other within the teams, where the leads passed on everything that was agreed upon with Igor.
Search for references and development of visual concept
To make this stage more predictable, Nastya recorded a video where she described her method of finding solutions: which ones are suitable and why, what you need to pay attention to when searching, and much more.
We took the colors and fonts from the festival team, but the result did not please Nastya and Igor. The concept did not reflect what we would like to see in the service, and the visual did not fulfill its tasks.
We began to experiment, try different colors, fonts and coordinate with Nastya. A few days later we submitted 9 concepts, of which one was selected and agreed upon.
Our product team began rendering the service pages in a consistent style. The leads collected all the layouts that needed to be sent to Nastya for feedback, she checked them, made corrections, and we finalized our solutions.
Before starting development, Igor held a call, during which he explained in detail the nuances of developing a UI kit and sorted out errors. We decided to assign one person to this task (because when everyone is responsible for the work, in the end no one is responsible). One of the leads, Kamilya, volunteered for this task (which did not relieve her of her lead duties).
During the call, I realized that I didn’t understand tokens and ui kits, so I volunteered to collect it. I wanted to understand this topic.
Kamilya, project participant
When Nastya approved the main page and catalog of exhibits, Kamila began developing a UI kit, starting with fonts. She put all the fonts that were used on a separate page to identify patterns of use and thereby collapse, that is, reduce the variations in font use.
For example, styles (Bold and Black) and dimensions were “collapsed”, where fonts differ by several pixels. Then Igor checked the work and “slammed” the solutions even harder. Kamila was worried that we would be unhappy with this result, because… It took a lot of time to select fonts, there were many options, and as a result, only a few styles were left.
We weren't going to have a dark and light theme, so the colors were chosen for the light theme. Kamila also set the general distances for the cards in tokens.
During the call with the presentation of the UI kit, many of us really didn’t recognize our pages. It seemed that they turned out completely different from what we intended them to be. But in the end, Igor explained everything, and we realized that there were really an unreasonably large number of fonts – this prevented us from moving forward.
Finally, we achieved consistency and tied consistent styles to our layouts. After that, Kamilya continued working on other elements of the UI kit: cards, buttons, links. This is how we got ready-made entities – ready-made design solutions that can be used.
Scenarios
At first we thought through the scenarios at the wireframe development stage, but it didn’t work out very well, so Igor decided to put the scenarios at the end of development.
When all the pages in the project were ready, we began developing scripts. This stage really went faster and easier than at the beginning of the project – we now have a holistic vision and experience of working together.
The leads divided the work, and we started working on scenarios. Somewhere it was easier (for example, on the page about the museum), somewhere it was more difficult. The purchase page suggested a more detailed and complex scenario; there we didn’t go into depth – we stopped at working out the most basic ones.
As we worked, we asked Igor questions; during calls, he made corrections and explained the logic of the scenarios, showing examples.
Testing
After the scenarios were worked out, we made interactive prototypes for testing. Each participant tested the page of his colleague, and not the one he developed himself (this was done in order to avoid subjectivity). To conduct tests on one page, it was necessary to find 5 people and run them according to a certain scenario.
As a result, we had data from which we could draw conclusions about where and how to improve the user journey. Of course, we did not implement them 🙂 The goal was to develop an MVP, and the testing stage was needed to set the vector for the development of the online service of the ZIL museum.
Result
We have developed an MVP of a museum service that stands on a strong foundation, and it contains not just one building, but an entire city!
You can view the “construction plan” using the links to Diprofile And Behance – come in, look, explore, leave reviews, we will definitely answer you. If your studio has the resources to design a project according to our drawings, write Anastasia Krasovskaya.
Conclusion
With stream development in a studio, the time frame is half as long as we had, the deadlines are asked more strictly, and without work experience it is difficult to withstand such immersion in the work process. But where to get this experience, how to learn to run when the first step has not yet been taken?
We were all very happy about the initiative of Nastya Krasovskaya, who invited us to the project, where we took our first steps in developing product services!
Over the course of six months, we became a well-coordinated team, learned a lot about product development from playing coach Igor Shulga, and about the processes of work in the studio from Nastya Krasovskaya. For many of us, this was the first experience of working in a studio on a product service, and it is very important that it took place with an adequate leader.
Thanks to the new knowledge and skills gained while working with the T-bank product designer and the art director of PixelPeak, many of us can get a job in the studio.
