Messenger development
Role: product designer in a team with two developers and a project manager
Timeline: in progress
Context
Due to the unstable operation and unavailability of popular foreign messengers, the idea arose to develop our own secure messenger. The initial audience is residents of Russia; in the future, the product should meet the needs of small businesses and work teams
Restrictions
the product is being built from scratch; there is no existing design system or ready-made user base
security is declared as a key property of the product, which required planning it from the very beginning, rather than as a later improvement
the target feature of logging in via seed phrases is not yet technically implemented, so the login logic for the MVP is designed separately, with a view to a future transition to seed phrases
Task
Work through the application logic, define key scenarios (including video
and audio calls), form the foundation of the design system, and present the product MVP
Research
Competitor analysis
Studied WhatsApp, Telegram, Imo, BiP, KakaoTalk, Zalo, as well as Russian solutions, including MAX and Signal. Compared them by interface and navigation, call quality, security and privacy, work stability, and the presence of a clear separation between personal and work space.
Telegram remains the leader in flexibility and convenience, but does not separate personal
and work communication and was unstable at certain periods, which became one
of the reasons for the very idea of the project. Signal shows a compromise: maximum privacy at the cost of functionality (no groups, no integrations).
This provided a guideline: nowadays, communication must be as secure and stable as possible, while also being convenient and simple to navigate.
Target Audience Surveys
I spoke with people in emigration and in Russia, asking: whom they communicate with most often, how often they use messengers, which messengers they use and why, what they use messengers for, what annoys them the most, and what is most important when choosing.
The responses showed that people from the Russian Federation choose based on the principle of stability, choosing messengers that allow them to make calls to their loved ones and share photos.
As a result, it became clear that for the MVP of the product, it is more than enough to implement clear functionality to cover the main user needs: text and voice messages with the ability to send photos, videos, and files, as well as video calls.
Process and decisions
Thought through the entire app flow, including custom login via seed phrases
as a target feature (currently in the backlog).Developed the main screens with skeletons and presented them to the development team for a feasibility assessment.
Defined base colors and the icon pack, created main components, and assembled the design of the MVP product.
There was an observation that group calls are still popular, which led to the decision to implement such a scenario with group creation and group calls.
Currently working on the layout of login, registration, as well as video and audio call screens, finalizing them on my own for a completed case study.
Design system
Since the product is being developed from scratch, a separate task was to create a full-fledged design system rather than just a set of screens. At the current stage, basic UI elements (buttons, input fields and their states, switches, toggles, and others) have been defined, and work with tokens and text styles has been configured. All components were initially created with reuse, scaling, and hand-off to development in mind.
There is no separate guidebook yet; this is a conscious decision at the MVP stage: key rules and agreements are recorded directly on the layouts with explanations. As the product and the team grow, formalizing the design system and creating a separate guidebook are planned as a separate stage.
Reflection
This was a new and in many ways challenging experience for me: a product from scratch, with no ready-made logic or requirements. The processes in the team were not established at the start: I joined as a designer, but a complete understanding of the logic and product requirements was not passed on
to me, while the front-end development had already started in parallel. I had to manage the coordination myself: first, I conducted analysis and surveys to avoid designing blindly, then I initiated regular calls with the team to discuss the product logic, and used wireframes so that everyone, not just me, understood how the screens were connected. From this, I realized that on projects
from scratch, the designer's role is often broader than just interfaces, and requires taking charge of structuring the process if no one else is doing it.