Путь к ЕГЭ — a mobile app for Russian exam prep

There was no finished spec — the client described the product in words. Alongside the interviews, I captured it as a screen-by-screen map in FigJam. The manager assembled a text spec for development, while the map became the visual backbone: we used it to discuss technical decisions with the developers, and the rest of the design grew out of it.

I organized the content into four themed worlds — rules, text, punctuation, spelling. Inside each world are lessons, and each lesson has three ways to work with a topic: a video breakdown, a cheat sheet, and a quiz. The order isn't forced: you can jump straight into the quiz, then brush up on theory with the cheat sheet and video, and retest. Progress is tracked per world overall. This removed the "watch everything first, then get tested" linearity and let users choose their own route.

For the cross-platform UI, I set up a single system: color tokens with defined purposes (accent, backgrounds, answer states, text, button gradients), typography, and a component library — inputs, buttons, cards, progress bars and rings, avatars. Thanks to it, the app looked the same on iOS and Android, and developers didn't have to build two separate interface versions under time pressure — the team could focus on polishing the features of a single interface for both platforms.

The client wanted "users to compete" but without a clear vision. I used a familiar quiz-duel mechanic as a reference (a well-known quiz-duel app), broke down its UX step by step, documented the user path with screenshots, and adapted it for the EGE exam: 7 questions, two answer options, tap-to-select cards, no text input. This simplified both design and development — the client approved the mode on the first proposal, and the client's team got a clear framework for writing questions. The mode is live: your opponent is a real user who queued up at the same moment. We discussed an asynchronous opponent and shelved it for later versions — per the developers, it would have needed a different implementation and more time.

Together with the client, I went through the structure of the exam: of the 27 question types, 24 made it into the first version — I excluded the essay and two matching-type questions, since their mechanics would have needed a separate, complex build. I fit the rest into four card formats: a question with a text input; a question with checkboxes; a sentence with checkboxes; hideable text with checkboxes or a text input. This sharply cut the interface variations — faster to build, simpler to use; expanding the formats and bringing back the excluded types were left for later versions.

Initially I split them into two separate flows. In a discussion with the backend and frontend developers, we tested a hypothesis: could a new vs. existing user be told apart with a single phone-number lookup in the database? It checked out, and I immediately redesigned the login into a single flow. Less work for the frontend team, and a more coherent path for the user.