Коротко, что делала

Федеральная компания-застройщик и разработчик IT-решений
в сфере недвижимости

ГК «Самолет»

4

Поддерживала единый язык интерфейсов и согласованность терминов между продуктами
и платформами

3

Работала с текстами в основных сервисах экосистемы: Главная, Страница проекта, Подбор, Генплан, Личный кабинет, Панель колл-центра, Страница лота, Конструктор лендинга, Лендинг регионов

6

Анализировала CJM
и пользовательские флоу, выявляла барьеры и предлагала решения для упрощения прохождения сценариев

5

Переписывала и оптимизировала тексты интерфейсов: кнопки, подписи, подсказки, пустые экраны, экраны ошибок/успеха

2

Вычитала все страницы проектов
ЖК «Самолет» во всех городах
и сформировала задачи
по переработке текстов для команды контента и команды фронтов

1

Разработала гайд по текстам
в интерфейсе и интегрировала
его принципы в ежедневную работу команды

Основной фокус моей работы — проект Онлайн-сделки. Параллельно
я помогала другим продуктовым командам Самолет: объясняла логику формулировок и участвовала в проработке интерфейсов как для клиентских сервисов, так и для внутренних инструментов (панели менеджеров, колл-центра, регистрационного центра и др.).

О работе

Кейсы в сделке

Как я выстроила текстовую логику
онлайн-сделки с нуля

Я подключилась к продукту в августе 2024 года — на этапе пилота.
За время моей работы Онлайн-сделка прошла путь от MVP к масштабированию на большую часть продаж.

2024 — запуск и пилоты

• Март 2024 — MVP: 24 сделки
• Июль 2024 — второй пилот: 9 сделок
• С 11 сентября по декабрь 2024 — сформировано более 250 договоров

2025 — масштабирование

• Январь 2025 — 5% договоров оформлялись онлайн
• Декабрь 2025 — 61% договоров заключаются через Онлайн-сделку (от всех продаж
• по квартирам, кладовым и машино-местам)

Оценка клиентского опыта

• 93% CSAT
• 4,5 из 5 — средняя оценка
• 2100+ оценённых сделок

Что сделала

Проблема

📌 Систематизировала язык продукта

• провела ревизию всей текстовой части сделки;
• собрала с менеджера и дизайнера всю информацию о бизнес-требованиях;
• уточнила тон общения: простой, спокойный, объясняющий;
• выстроила единый стиль CTA, подсказок и ошибок.

📌 Улучшила ключевые экраны

Для первичных итераций мы сделали изменения, которые можно было быстро «пролить» в прод:

• сократили и упростили тексты;
• структурировали длинные блоки;
• добавили пояснения в местах барьеров;
• визуально усилили текстовую иерархию в макетах.

(Здесь можно вставить блок «до / после».)

📌 Работала на основе исследований и анализировала выводы глубинных интервью;

• формулировала гипотезы на основе выявленных барьеров;
• дорабатывала тексты под реальные сценарии пользователей.

Когда я пришла в продукт, в команде не было UX-редактора. Тексты писали менеджер проекта и дизайнер — быстро, под текущую задачу, без единой системы, тона и практики проверки текстов на пользователя.
Продукт находился во второй итерации. Исследования показали, что пользователи путаются
в терминологии, шагах и требованиях сделки, а многие сценарии требуют сопровождения менеджера.

Моя задача была двойной:

1. быстро улучшить текстовую составляющую, чтобы можно было «пролить» улучшения в прод;
2. построить основу для всех последующих итераций, чтобы язык сделки стал системным и понятным.

Проблема
Пользователям было сложно ориентироваться
в процессе сделки. Интерфейс не позволял свободно перемещаться между уже пройденными шагами:
если нужно было изменить ранее введённые данные, это приходилось делать через менеджера и CRM.

Кроме того, были только названия этапов. Пользователю было не всегда понятно, что именно происходит уже внутри шагов и какие действия ему предстоят.


Решение
Мы добавили навигацию по шагам сделки: теперь пользователь видит все этапы и подшаги процесса
и может возвращаться к уже пройденным шагам,
чтобы проверить или изменить данные.

Чтобы эта навигация была понятной, я пересмотрела структуру названий всех этапов и шагов сделки. Заголовки, подзаголовки и описания экранов были переработаны и приведены к единой логике: формулировки стали консистентными и лучше объясняли содержание каждого шага.


Процесс

• пересобрала структуру заголовков, подзаголовков

и описаний всех этапов сделки;

• унифицировала названия;
• переписала описания экранов, чтобы они объясняли смысл действия и ожидания пользователя;
• привела все формулировки к единой логике и стилю.

Результат
Мы превратили линейный процесс под контролем менеджера в управляемый пользователем сценарий.

Поменяла заголовок на фактическое действие, которое нужно выполнить пользователю

На втором и третьем экранах оставила заголовок, как есть. Это однотипные шаги
с одинаковым действием, и повтор формулировки поддерживает ощущение единого процесса. Третий экран — сценарный, поэтому дублирование не создаёт визуального шума

Переписала заголовок (ушла от глагола)
и описание, добавив контекст и объяснение ценности действия (бизнесу было важно сообщить
о номере телефона уже здесь)

Заголовок и описание не помогают понять, что будет происходить в шагах далее: инфинитив описывает нерелевантное действие, а текст не раскрывает сценарий и звучит не по-пользовательски (неуместная форма "телефонный номер")

После ввода всех данных показываем экран
для проверки и даём возможность исправить ошибки при необходимости

Проблема
❌неверный контекст — пользователь оценивает всю сделку, хотя процесс ещё не завершён
❌одинаковые формулировки для разных оценок — не учитывается разница между негативным
и нейтральным опытом
❌оценочная лексика («Жаль», «Круто») — звучит неестественно и задаёт эмоциональный тон; непонятно решение относительно выбор знаков препинания: «Круто!» в варианте с ответом «хорошо» и «Круто.»
в варианте «отлично»
❌навязывание оценки в ответах — формулировки вроде «Сложный интерфейс», «Плохая поддержка менеджера», «Много ошибок» уже содержат негативную интерпретацию → пользователь выбирает из готовых оценок, а не формулирует своё мнение
❌нет мотивации оставить отзыв

В результате фидбек получался искажённым и менее полезным для продуктовых решений.

Решение

• уточнила контекст оценки (не вся сделка, а этапы);
• убрала лишнее упоминание бренда — в этом сценарии оно не несёт новой информации;
• убрала оценочные формулировки и выровняла тон;
• сделала тексты зависимыми от выбора пользователя;
• заменила чекбоксы на нейтральные зоны опыта,
• без навязывания оценки;
• добавила мотивацию: объяснила, зачем делиться обратной связью.

Результат
Пользователь формулирует своё мнение сам,
а не выбирает из навязанных вариантов → фидбек стал точнее и полезнее для продукта.

Сценарий при выборе ипотеки

Сценарий при выборе ипотеки

Раскрытие «Подробнее» одинаковое в обоих сценариях

Сценарий при выборе 100% оплаты

Сценарий при выборе 100% оплаты

Пример 3 — предотвращение ошибки

Пример 2 — ограничения через пояснение

Теперь ограничения вынесены в отдельный блок «Обратите внимание».
Почему это лучше:

• ограничения выделены визуально;
• текст легче читать;
• пользователь понимает последствия выбора.

Пример 1 — контекст вместо общего вопроса

Решение
Я переработала тексты и логику сценария:

• разделила сценарии (ипотека / 100% оплата);
• объяснила условия использования маткапитала в контексте;
• вынесла ограничения в явные пояснения;
• добавила предупреждения в критических точках;
• упростила формулировки.

Ограничение никак не отображалось в интерфейсе → пользователь узнавал о нём слишком поздно.

Результат
Пользователь понимает условия использования материнского капитала в своём сценарии и принимает решение осознанно.
Сценарий стал предсказуемым, а количество ошибок и уточнений — ниже.

Контекст
В некоторых случаях материнский капитал нельзя использовать — например, если до ввода дома в эксплуатацию остаётся меньше двух месяцев.
Важно, что:

• пользователи уже слышали об этом от менеджеров (при подтверждении брони объекта и переходе к покупке (а в покупке сразу же первый шаг как раз текущая анкета));
• но без фиксации в интерфейсе это всё равно становилось неожиданностью.

Короткий контекст
Материнский капитал — один из самых сложных сценариев в сделке: условия зависят от способа оплаты, состава участников и юридических ограничений. Причем вопросы про маткап идут в самом начале сделки — в анкете, поэтому недопонимания
в начале приводили к проблемам впоследствии.

Проблема
Пользователи не понимали, как работает материнский капитал в рамках сделки:
❌условия зависели от сценария (ипотека / 100% оплата), но это не объяснялось;
❌ограничения (например, по долям) раскрывались непонятно;
❌не было предупреждений в критических сценариях (например, срок сдачи дома — пример 3)
❌формулировки были сложными и не помогали принять решение.

В результате пользователи ошибались в выборе сценария, не понимали ограничения или обращались в поддержку.

Пример 2 — сложное ограничение

Проблема:

• длинная и перегруженная формулировка;
• нет объяснения «почему»;
• пользователь читает, но не понимает, как применить это к своей ситуации.

Проблема:

• вопрос не учитывает сценарий (ипотека / 100% оплата);
• часть пользователей получает нерелевантную информацию;
• нет понимания, как это влияет на их сделку.

Пример 1 — общий вопрос без контекста

отвечает на вопрос: «Что нужно сделать, чтобы добавить других участников?»

💡 Наблюдение из исследований
В формулировках важно было явно разделить «детей» и «несовершеннолетних».
Исследования показали, что пользователи воспринимают слово «дети» шире — включая в него и совершеннолетних.
Из-за этого возникала путаница: пользователи выбирали неверные варианты, ориентируясь
на бытовое, а не юридическое значение.

Раскрываем при наведении информер
с информацией из ФЗ

«Подробнее» ведёт на статью
от Самолет Как выделить доли детям при маткапе
(контент в статье не мой)

отвечает на вопрос: «Кто может участвовать?»

Решение
Я переработала тексты вопросов и добавила пояснения:

• уточнила формулировки (например, «официальный брак»);
• объяснила последствия выбора прямо в момент ответа;
• добавила ссылки на подробные материалы;
• упростила юридические конструкции;
• связала вопросы между собой в единый сценарий.

Результат
Пользователь понимает последствия каждого ответа и может пройти сценарий без помощи менеджера.
Ошибок в выборе сценария стало меньше.

Контекст
В анкете пользователь отвечает на вопросы о семейном положении и составе участников сделки.
От этих ответов зависит состав документов и дальнейший сценарий сделки.

Проблема
Вопросы анкеты касались юридически сложных сценариев (брак, согласие супруга, брачный договор), но:
❌формулировки были краткими и не объясняли последствия;
❌пользователь не понимал, какие документы понадобятся;
❌не было связки между вопросами;
❌часть условий раскрывалась слишком поздно.

В результате — ошибки в сценариях и дополнительные вопросы к менеджерам.

Сложная юридическая формулировка

• формулировка звучит юридически и тяжело;
• пользователь должен сам интерпретировать ситуацию;
• нет связки с предыдущими ответами.

Последствия без контекста

• условие есть, но не объяснено, что это за документы и зачем они нужны;
• нет возможности сразу разобраться — только идти дальше или в поддержку.

«Да»
(если супруг участвует)

Упрощение формулировок
Вопросы сформулированы на языке пользователя и не требуют расшифровки.

Прозрачный сценарий
Пользователь заранее понимает, какие документы понадобятся
и что будет дальше.
Ссылка ведет к шаблону документа.

«Нет»
(если супруг не участвует)

Недостаточно точная формулировка

• не уточняется, что речь об официальном браке;
• пользователь может ориентироваться на бытовое понимание, из-за чего может быть риск выбора неправильного ответа;
• непонятная и нераскрытая трактовка.

Пример одной из таблиц промежуточного аудита уже спустя несколько релизов, поэтому здесь более незначительные комментарии по изменениям, однако всё равно с выявлением багов и ошибок.

Контекст
На втором этапе сделки пользователь заполняет личные данные.
Один из шагов — ввод банковских реквизитов для взаиморасчётов (в основном — для возможного возврата средств
от ГК «Самолет»). Это один из самых чувствительных шагов в сценарии — пользователь вводит банковские данные
до завершения сделки.

Контекст
Онлайн-сделка — сложный процесс с юридическими нюансами, а ещё это многомиллионная покупка. Пользователи часто
не понимали этапы, термины и требования, они буквально боялись сделать лишний клик и обращались к менеджерам.
Пересобирая текстовую логику, я в том числе добавила подсказки и определения, так как их много где не хватало либо они были сложными, а местами слабыми.
Частично опиралась на исследования, частично — на собственный «первый пользовательский опыт», чтобы находить неочевидные места, где не хватает пояснений.

Проблема
Пользователи не понимали:
❌что происходит на этапах сделки;
❌зачем нужны данные и документы;
❌что означают определенные формулировки и аббревиатуры;
❌как работают банковские и юридические процессы.

В результате — страх, ошибки и обращения в поддержку.

Решение
Встроила объяснения прямо в интерфейс:

• поясняла термины в момент их появления;
• объясняла, зачем нужны данные;
• добавляла «Подробнее» для сложных случаев;
• провела минимальный онбординг по интерфейсу.

На самом шаге — только поля для ввода БИК
и расчётного счёта, без пояснений.

Перед шагом был общий экран:

Что сделала
Добавила объяснения прямо на шаге:

• зачем нужны реквизиты (например, для возврата средств)
• что с них не будут списывать деньги
• где их найти

В «Подробнее» — модальное окно с простыми определениями (БИК, расчётный счёт) и пояснениями.

Пример одной из таблиц промежуточного аудита уже спустя несколько релизов, поэтому здесь более незначительные комментарии по изменениям, однако всё равно с выявлением багов и ошибок.

Контекст
Онлайн-сделка — сложный процесс с юридическими нюансами, а ещё это многомиллионная покупка. Пользователи часто
не понимали этапы, термины и требования, они буквально боялись сделать лишний клик и обращались к менеджерам.
Пересобирая текстовую логику, я в том числе добавила подсказки и определения, так как их много где не хватало либо они были сложными, а местами слабыми.
Частично опиралась на исследования, частично — на собственный «первый пользовательский опыт», чтобы находить неочевидные места, где не хватает пояснений.

Проблема
Пользователи не понимали:
❌что происходит на этапах сделки;
❌зачем нужны данные и документы;
❌что означают определенные формулировки и аббревиатуры;
❌как работают банковские и юридические процессы.

В результате — страх, ошибки и обращения в поддержку.

Решение
Встроила объяснения прямо в интерфейс:

• поясняла термины в момент их появления;
• объясняла, зачем нужны данные;
• добавляла «Подробнее» для сложных случаев;
• провела минимальный онбординг по интерфейсу.

Контекст
Первый этап сделки — анкета для определения условий и участников.
Раньше пользователь заполнял её без пояснений, а понятие «основной участник» появлялось только позже — на этапе проверки данных.

Почему сделала именно так
Важно было вынести этот вопрос на самый первый шаг: раньше проблема проявлялась только в середине процесса,
из-за чего пользователям приходилось возвращаться назад и фактически проходить часть сделки заново.
Такое решение позволило предотвратить ошибки заранее и сократить количество возвратов и ручных изменений
через менеджеров.

+ обозначила возможность передать оформление другому человеку (недавно реализованная фича)

Добавила вопрос в начало анкеты с пояснением:

Пользователь не видел и не выбирал основного участника на старте.
Термин появлялся позже в интерфейсе без объяснения.

Почему это плохо:
❌ непонятно, на кого оформляется договор
❌ ошибки в сценарии (например, если бронировал один человек, а оформляет другой)
❌ изменения приходилось делать через менеджера

Пример одной из таблиц промежуточного аудита уже спустя несколько релизов, поэтому здесь более незначительные комментарии по изменениям, однако всё равно с выявлением багов и ошибок.

Контекст
Онлайн-сделка — сложный процесс с юридическими нюансами, а ещё это многомиллионная покупка. Пользователи часто
не понимали этапы, термины и требования, они буквально боялись сделать лишний клик и обращались к менеджерам.
Пересобирая текстовую логику, я в том числе добавила подсказки и определения, так как их много где не хватало либо они были сложными, а местами слабыми.
Частично опиралась на исследования, частично — на собственный «первый пользовательский опыт», чтобы находить неочевидные места, где не хватает пояснений.

Проблема
Пользователи не понимали:
❌что происходит на этапах сделки;
❌зачем нужны данные и документы;
❌что означают определенные формулировки и аббревиатуры;
❌как работают банковские и юридические процессы.

В результате — страх, ошибки и обращения в поддержку.

Решение
Встроила объяснения прямо в интерфейс:

• поясняла термины в момент их появления;
• объясняла, зачем нужны данные;
• добавляла «Подробнее» для сложных случаев;
• провела минимальный онбординг по интерфейсу.

Почему сделала именно так
Пользователь принимает решение о подписании юридического документа, не всегда понимая его различия
и последствия.
Важно было объяснить суть каждого договора простым языком и заранее подготовить интерфейс к новым сценариям.

Почему сделала именно так
Важно было явно ввести и объяснить промежуточный статус документа — пользователи не понимали, на каком этапе находятся и какие действия ещё возможны.
Формулировки помогают зафиксировать момент перехода: от редактируемого сценария к формированию документа
с ограничениями.

Контекст
На этапе подготовки договора пользователь видит, какой тип договора будет подписывать. Изначально был вариант только подписания ДДУ. В 2025 году продукт начал готовиться к новым сценариям (ПДКП, ДКП), поэтому важно было заранее объяснить различия между ними.

Контекст
Один из завершающих этапов сделки — подготовка договора.
Перед его формированием пользователь загружает дополнительные документы и согласовывает данные сделки: участников, условия, способ оплаты.
При этом в процессе формируется не финальный договор, а его промежуточная версия — проект. Раньше это никак
не объяснялось, хотя после этого шага возможности редактирования сильно ограничены.

На этом этапе пользователь не только проверяет данные сделки, но и сталкивается с юридическими терминами (ДДУ, ПДКП, ДКП), которые влияют на понимание условий сделки.

Ввела понятие проекта договора и объяснила его в интерфейсе:

В интерфейсе использовался только ДДУ с перегруженным определением

Переписала определение ДДУ и добавила определения для ПДКП и ДКП:

• коротко и простым языком
• с фокусом на смысле для пользователя
• без лишней юридической перегрузки

Пользователь переходил к согласованию договора без пояснений.

• не было понятия «проект договора»
• неясно, финальный это документ или нет
• не было акцента на том, что данные нужно проверить сейчас
• ограничения на изменения появлялись неожиданно

Пример одной из таблиц промежуточного аудита уже спустя несколько релизов, поэтому здесь более незначительные комментарии по изменениям, однако всё равно с выявлением багов и ошибок.

Контекст
Онлайн-сделка — сложный процесс с юридическими нюансами, а ещё это многомиллионная покупка. Пользователи часто
не понимали этапы, термины и требования, они буквально боялись сделать лишний клик и обращались к менеджерам.
Пересобирая текстовую логику, я в том числе добавила подсказки и определения, так как их много где не хватало либо они были сложными, а местами слабыми.
Частично опиралась на исследования, частично — на собственный «первый пользовательский опыт», чтобы находить неочевидные места, где не хватает пояснений.

Проблема
Пользователи не понимали:
❌что происходит на этапах сделки;
❌зачем нужны данные и документы;
❌что означают определенные формулировки и аббревиатуры;
❌как работают банковские и юридические процессы.

В результате — страх, ошибки и обращения в поддержку.

Решение
Встроила объяснения прямо в интерфейс:

• поясняла термины в момент их появления;
• объясняла, зачем нужны данные;
• добавляла «Подробнее» для сложных случаев;
• провела минимальный онбординг по интерфейсу.

Почему сделала именно так
Важно было снизить нагрузку в момент, когда пользователь сталкивается с большим объёмом требований.
Короткие пояснения помогают не прерывать сценарий и не искать информацию вне интерфейса (кроме ссылок, ведущих на Госуслуги и др. источники).

Решение
Добавила краткие пояснения к каждому документу прямо в интерфейсе:

• зачем он нужен в рамках сделки
• в каком сценарии используется
• где его получить (если это частый вопрос)
• в отдельных случаях добавила ссылки с пояснениями

Контекст
В процессе сделки пользователю нужно загрузить пакет документов.
В зависимости от сценария их может быть много: паспорт, СНИЛС, документы о браке, материнском капитале и др.
Даже если названия документов кажутся очевидными, пользователи не всегда понимают:

• зачем нужен каждый документ
• что будет происходить с их данными
• где взять документ, если его нет

Это увеличивает когнитивную нагрузку и вызывает дополнительные вопросы.

Исторически СНИЛС — это зелёная пластиковая карточка, к которой все привыкли.
Но с 2019 года её больше не выдают. Вместо неё используется документ по форме АДИ-РЕГ — он может быть в электронном или бумажном виде.

Пример одной из таблиц промежуточного аудита уже спустя несколько релизов, поэтому здесь более незначительные комментарии по изменениям, однако всё равно с выявлением багов и ошибок.

Контекст
Онлайн-сделка — сложный процесс с юридическими нюансами, а ещё это многомиллионная покупка. Пользователи часто
не понимали этапы, термины и требования, они буквально боялись сделать лишний клик и обращались к менеджерам.
Пересобирая текстовую логику, я в том числе добавила подсказки и определения, так как их много где не хватало либо они были сложными, а местами слабыми.
Частично опиралась на исследования, частично — на собственный «первый пользовательский опыт», чтобы находить неочевидные места, где не хватает пояснений.

Проблема
Пользователи не понимали:
❌что происходит на этапах сделки;
❌зачем нужны данные и документы;
❌что означают определенные формулировки и аббревиатуры;
❌как работают банковские и юридические процессы.

В результате — страх, ошибки и обращения в поддержку.

Решение
Встроила объяснения прямо в интерфейс:

• поясняла термины в момент их появления;
• объясняла, зачем нужны данные;
• добавляла «Подробнее» для сложных случаев;
• провела минимальный онбординг по интерфейсу.

Почему сделала именно так
Важно было быстро дать пользователю базовую модель интерфейса, не перегружая его информацией.
Онбординг объясняет ключевые точки навигации и снижает необходимость «разбираться методом проб и ошибок».

Контекст
Онлайн-сделка — сложный многошаговый процесс с юридическими нюансами и большим количеством данных.
Пользователь впервые сталкивается с интерфейсом, в котором:

• много этапов и шагов
• есть новые сущности (участники, договор, документы)
• важны последовательность и точность действий

Без объяснения интерфейс воспринимается как сложный и перегруженный.

3. Про поддержку
→ как задать вопрос
→ как проходит консультация

2. Про управление сделкой
→ где собрана вся информация
→ где можно редактировать данные

1. Про структуру сделки
→ где находятся этапы и шаги
→ как перемещаться между ними

Добавила короткий онбординг из 3 шагов. Формат — короткие, понятные сообщения без перегрузки.

Из-за этого образовывались следующие проблемы:

❌ высокая неопределённость на старте
❌ больше ошибок и вопросов
❌ зависимость от менеджеров

Онбординга не было.
Пользователь сразу попадал в интерфейс сделки и должен был самостоятельно разобраться:

• как устроен процесс
• где смотреть статус сделки
• куда обращаться за помощью

Пример одной из таблиц промежуточного аудита уже спустя несколько релизов, поэтому здесь более незначительные комментарии по изменениям, однако всё равно с выявлением багов и ошибок.

Контекст
После бронирования квартиры пользователь впервые сталкивается с онлайн-сделкой — сложным многошаговым процессом.
На этом этапе у пользователя нет понимания:

• как будет проходить сделка
• какие шаги его ждут
• насколько это безопасно

При этом внутри интерфейса уже есть подсказки, но до входа в сделку пользователь остаётся без ориентиров. Инструкция выступает как «мост» между бронированием и началом сделки, снижая тревожность на старте.

Результат
Инструкция стала первой точкой входа в онлайн-сделку: пользователь получает её сразу после подтверждения бронирования и заранее понимает, как будет проходить процесс.

• Снижается неопределённость перед началом сделки
• Пользователь понимает шаги и требования до входа в интерфейс
• Меньше базовых вопросов к менеджерам
• Процесс воспринимается как более прозрачный и управляемый

В итоге пользователь увереннее начинает сделку и проходит её более самостоятельно.

Контекст
Как я уже упоминала онлайн-сделка — многошаговый процесс с юридическими и финансовыми действиями: выпуск подписи, открытие счетов, подписание документов.
Не все действия можно объяснить короткими подсказками — в некоторых шагах пользователю нужны пошаговые инструкции.

Проблема
Без инструкций пользователи:
❌не понимали, что делать на отдельных этапах
❌боялись совершить ошибку
❌зависели от менеджеров

Решение
Я добавила инструкции в разных форматах:

• краткая инструкция по всей сделке (отправляется после бронирования объекта недвижимости)
• пошаговые инструкции внутри интерфейса
• раскрывающиеся блоки (FAQ) для сложных сценариев

Инструкции появлялись именно в момент действия

Пример одной из таблиц промежуточного аудита уже спустя несколько релизов, поэтому здесь более незначительные комментарии по изменениям, однако всё равно с выявлением багов и ошибок.

Контекст
Как я уже упоминала онлайн-сделка — многошаговый процесс с юридическими и финансовыми действиями: выпуск подписи, открытие счетов, подписание документов.
Не все действия можно объяснить короткими подсказками — в некоторых шагах пользователю нужны пошаговые инструкции.

Проблема
Без инструкций пользователи:
❌не понимали, что делать на отдельных этапах
❌боялись совершить ошибку
❌зависели от менеджеров

Решение
Я добавила инструкции в разных форматах:

• краткая инструкция по всей сделке (отправляется после бронирования объекта недвижимости)
• пошаговые инструкции внутри интерфейса
• раскрывающиеся блоки (FAQ) для сложных сценариев

Инструкции появлялись именно в момент действия

Что сделала:
объяснила процесс + добавила требования

Почему важно:

• снимает неопределённость в банковском шаге

Что сделала:
объяснила + добавила инструкцию + действия

Почему важно:

• пользователь понимает, куда идут деньги
• повышается доверие

Что сделала:
разбила процесс на шаги + два сценария (курьер / офис)

Почему важно:

• сложное действие стало пошаговым
• пользователь понимает, что его ждёт