For MindType, I connected a psychologist’s website, Telegram bot, Mini App and CRM. The aim was to guide people from discovering the practitioner’s approach to self-reflection, materials and booking, while giving the practitioner a separate workspace for client enquiries. Each part has a distinct role.
1. The first screen: explain the offer and next step
The website introduces the practitioner and gives visitors a choice: learn about the services or continue in Telegram. Clear copy, visual consistency and an obvious next step matter here. The psychologist website case study covers the design in more detail.
Moving from website to bot should continue the promised experience. If a button invites someone to take a test, they expect the test’s opening and an explanation of what follows. That small interface detail connects the whole journey.
2. The bot: a short test and a result
The project uses five questions for self-reflection. After completing them, the user receives a profile and relevant materials. The bot keeps the sequence compact: question, answer, next step. The result is saved and linked to the user’s account.
The test is not a clinical diagnosis. The AI companion is a separate feature and does not replace a practitioner. Those boundaries belong in the interface: the copy must accurately describe what people receive.
3. The Mini App: somewhere to return to
The Mini App brings together results, test history, a personal area, a journal, available appointment slots and booking. Several sections are easier to navigate here than by searching through a long conversation.
Users return to their own context rather than starting again. The account, results and later actions therefore need to connect. Behind the interface are data storage and access checks for protected features.
4. Payment: the journey after the button
The project code includes payment creation through YooKassa, status checks and handling successful-payment notifications. A button starts the process but does not prove a purchase: the next action must depend on a verified payment state.
Designing the journey also means accounting for waiting, cancellation and returning to the app. People need to understand whether the operation is complete and what comes next. This describes the implemented integration, rather than reporting a new end-to-end test purchase.
5. CRM: the practitioner’s side of the journey
A separate panel provides workflow stages, client cards, conversation history, notes and reminders. It is the other side of the same product: the practitioner can continue with context instead of gathering details from multiple conversations.
The panel has a separate login, and its API requires authorisation. The public website introduces the product, the personal area shows a user’s own data and the workspace supports the practitioner. These boundaries belong in the structure before screens are styled.
6. What this approach delivers
My work on MindType covered UX, interfaces, copy, development and launch. The product also includes conversation-state persistence and database backups. These support operation beyond the first release.
The project’s main result is a connected set of interfaces and working scenarios. This breakdown does not report sales or conversion figures; those require separate measurement. See the MindType case study for the implementation scope.
The product flow
Discover the service on the website → take the bot’s test → view results and act in the Mini App → confirm payment or book. The practitioner continues the work in a separate CRM.
For a similar project, begin with the client journey and the team’s actions. That reveals which screens, data and integrations the first release needs.
If your service involves a questionnaire, booking, materials and follow-up, start by mapping that process. I can help turn it into a practical first-release scope.
Discuss a similar project →