До/после: как показать ценность редизайна так, чтобы в неё поверили

«Стало красивее» — не аргумент. Красиво — субъективно. «Стало лучше» — не аргумент. Лучше для кого, по каким критериям?

До/после как инструмент коммуникации работает только тогда, когда показывает не визуальное изменение, а изменение в поведении пользователей и бизнес-результатах.

Это статья о том, как документировать и показывать редизайн так, чтобы руководство, клиент и вся команда поняли: это работает.

## Почему стандартное «до/после» не убеждает

Типичная презентация редизайна: слева старый скриншот, справа новый. Дизайнер объясняет «здесь мы упростили, здесь убрали лишнее, здесь сделали более понятно».

Проблема: это разговор о дизайнерских решениях, а не о результатах. Стейкхолдер смотрит и думает одно из двух: «выглядит лучше» (субъективно, ненадёжно) или «а почему мы должны были изменить именно это» (закономерный вопрос без ответа в скриншоте).

Убедительное до/после отвечает на другие вопросы:

• Что конкретно не работало до (с доказательством)
• Почему именно это решение
• Что изменилось в поведении пользователей после

## Структура убедительного до/после

### Уровень 1: Проблема с доказательством

Прежде чем показывать «до» — покажи что «до» было проблемой. Не мнение дизайнера — данные.

Что работает как доказательство:

• Данные аналитики: «65% пользователей бросали форму именно на этом шаге»
• Запись сессии: «Вот 30 секунд как реальный пользователь не может найти кнопку»
• Цитата из интервью: «Я три раза нажимал не то — это сбивает с толку»
• Тепловая карта: «Кликают сюда — а это не кликабельно»
• Данные поддержки: «47 обращений в месяц с вопросом как сделать X»

Один скриншот «до» без доказательства — это просто старый дизайн. Скриншот + данные — это задокументированная проблема.

### Уровень 2: Логика решения

Почему именно это решение? Не «мы так решили», а цепочка:

Проблема → Причина → Решение

«Пользователи не замечали кнопку (проблема) → потому что она была визуально не выделена и конкурировала с тремя другими элементами похожего веса (причина) → мы сделали её единственным primary-действием на экране и усилили контраст (решение)»

Это занимает 2–3 предложения. Без этого стейкхолдер не понимает логику и начинает предлагать альтернативы «а может просто цвет поменять?».

### Уровень 3: Измеренный результат

Это самое важное — и самое часто упускаемое.

Если редизайн запущен и можно измерить результат — измерь. Это превращает «кажется стало лучше» в «доказано работает».

Если результат ещё нельзя измерить (редизайн не запущен) — честно скажи что это ожидаемый эффект и укажи как будете измерять.

## Форматы документации до/после

Разные аудитории нужен разный формат.

### Для стейкхолдеров и руководства: бизнес-кейс

Одна страница или один слайд:

БЫЛО
[Скриншот до]
Метрика: [значение]
Проблема: [1–2 предложения с данными]

СТАЛО  
[Скриншот после]
Метрика: [новое значение]
Результат: [изменение в % и в деньгах/пользователях]

ПОЧЕМУ ЭТО СРАБОТАЛО
[2–3 предложения о логике решения]

Цифры — это язык руководства. «Task completion rate вырос с 58% до 79%» скажет больше чем «стало удобнее».

### Для команды: дизайн-решение с обоснованием

Confluence/Notion-страница или Figma-комментарии:

• Контекст: что за флоу/экран, кто пользователи, какова задача
• Проблема: данные + качественные инсайты
• Исследование: что смотрели, что нашли
• Решение: что изменили и почему каждое решение
• Альтернативы, которые рассматривались и почему не выбраны
• Метрики успеха: что будем измерять и через сколько

Это не отчёт — это документ для коллег, которые будут работать с этим решением.

### Для портфолио: история с изменением

Структура кейса:

1. Контекст и задача
2. Что было не так (данные + пользовательские инсайты)
3. Процесс: как искали решение
4. Решение: что сделали
5. Результат: что изменилось (обязательно в цифрах)

Без результата в цифрах — это неполный кейс. «Стало лучше на мой взгляд» не считается.

## Как снимать метрики: базлайн перед редизайном

Самая частая ошибка — не зафиксировать «до» перед тем, как выкатить «после». Потом сравнивать не с чем.

### Что фиксировать перед редизайном

За 2–4 недели до запуска нового дизайна зафикси:

Количественно:

• Conversion rate на изменяемом флоу (общий и по каждому шагу)
• Task completion rate (если можно измерить)
• Error rate на проблемных элементах
• Time on task (если актуально)
• Drop-off по шагам воронки

Качественно:

• Результаты SUS-теста (можно быстро провести с 5 пользователями)
• Цитаты из интервью о проблемных местах
• Session recordings с характерными паттернами поведения

### Через сколько смотреть результаты

• 2 недели — минимум для быстрых метрик (conversion rate, error rate)
• 4–6 недель — для retention и поведенческих изменений
• 3 месяца — для бизнес-метрик (revenue impact)

Не смотри результаты через 3 дня и не делай выводов. Novelty effect (пользователи ведут себя иначе просто потому, что, что-то изменилось) искажает данные в первую неделю.

## Честное «до/после»: что делать когда результат разочаровал

Иногда редизайн не даёт ожидаемого эффекта. Это не повод прятать данные — это повод разобраться.

Conversion rate не вырос — что проверить:

• Изменился ли трафик (другой источник, другая аудитория)?
• Был ли novelty effect в первые дни (резкий рост потом спад)?
• Не появились ли новые проблемы, которые компенсировали улучшения?
• Правильно ли выбрана метрика для измерения этого изменения?

Как представить нейтральный или негативный результат:

Честность работает лучше сокрытия. «Мы ожидали +20% конверсии, получили +3%. Вот почему мы думаем это произошло и что хотим протестировать следующим» — это зрелость, а не провал.

## Визуальное оформление до/после

Скриншоты — хорошо. Но есть форматы эффективнее.

### Аннотированные скриншоты

Скриншот «до» с маркерами проблем + скриншот «после» с маркерами решений. Стрелки, выноски, пояснения. Зритель сразу видит связь между проблемой и решением.

### Видео сравнение

30-секундное видео «до» (пользователь застревает на шаге, уходит с ошибкой) и «после» (тот же флоу быстро и без проблем). Это убедительнее любого скриншота.

### Live демо vs. запись

Если стейкхолдеры технически подкованы — живое демо. Если нет — запись лучше: можно заранее выбрать показательный момент.

## ИИ и документация до/после: промпты для работы

### Промпт: написать executive summary изменений

Мы провели редизайн [что именно].

Проблема, которую решали: [описание с данными]
Что изменили: [список ключевых решений]
Результаты: [данные до и после]

Напиши executive summary для руководства (полстраницы):
— Что было не так и как это влияло на бизнес
— Что мы изменили и почему именно это
— Что получили (цифры)
— Что планируем дальше

Тон: деловой, без дизайн-жаргона.

### Промпт: написать обоснование дизайн-решения

Я принял следующее дизайн-решение: [описание]

Контекст: [что за флоу, кто пользователи]
Данные, которые привели к этому решению: [данные]
Альтернативы, которые рассматривал: [список]

Помоги написать обоснование решения для документации:
— Проблема (1 абзац с данными)
— Логика решения (почему именно так)
— Почему отклонены альтернативы
— Что будем измерять, чтобы проверить, что решение работает

### Промпт: подготовить кейс для портфолио

Я хочу написать кейс редизайна для портфолио.

Данные:
— Что редизайнировал: [описание]
— Исходная проблема: [данные]
— Процесс: [что делал]
— Решение: [что изменил]
— Результат: [до и после в цифрах]

Напиши структуру кейса и текст для каждого раздела.

Требования:
— Убедителен для потенциального работодателя / клиента
— Фокус на процессе принятия решений, а не на красоте визуала
— Результаты с конкретными цифрами
— Объём: 400–600 слов

## Как снимать «до»: конкретная техника

Документирование «до» — это не просто скриншот. Полноценное «до» включает несколько слоёв.

### Слой 1: Визуальная фиксация

• Скриншоты каждого экрана флоу в 1x (десктоп) и мобайл
• Screen recording прохождения флоу (30–60 секунд)
• Heatmap если есть инструмент (Hotjar, Clarity)

Инструмент: Loom для быстрой записи экрана с комментарием.

### Слой 2: Количественная фиксация

Снимок данных из аналитики с датой. Что именно снимать — зависит от флоу, но минимально:

• Общий conversion rate флоу
• Drop-off по каждому шагу
• Bounce rate на входном экране (если лендинг)
• Если есть — error rate, time on task

Сохрани не только цифры, но и CSV или экспорт из аналитики. Через 3 месяца исходные данные могут быть недоступны.

### Слой 3: Качественная фиксация

• 3–5 цитат из интервью или отзывов о проблемных местах
• 1–2 session recording где видна проблема (ссылка + timestamp)
• Данные поддержки: количество обращений по теме за месяц

Качественный слой — это «голос пользователя» который делает «до» живым и убедительным.

## Особые случаи: когда стандартное до/после не работает

### Радикальный редизайн

Если изменения настолько большие что «до» и «после» сложно сравнивать напрямую — нужен другой подход.

Вместо сравнения метрик: сравнение достижения целей. «До редизайна: 23% пользователей достигали aha moment в первые 7 дней. После: 51%». Это сравнимо несмотря на то, что сам интерфейс принципиально другой.

### Когда нет данных «до»

Случается — аналитика не была настроена, данных нет.

Что можно сделать:

• Провести ретроспективное исследование: интервью с пользователями об их опыте с прошлой версией
• Найти косвенные данные: обращения в поддержку, отзывы в сторах
• Честно обозначить что baseline отсутствует и результат нельзя сравнить напрямую

Это нормально — но именно это учит фиксировать базлайн в следующий раз.

### Итерационный редизайн

Если редизайн идёт небольшими итерациями (не один большой релиз, а серия маленьких изменений) — отслеживай каждую итерацию отдельно.

Ведение «дизайн-журнала»: дата изменения, что именно изменено, метрики до/после этого конкретного изменения. Через квартал это превращается в понятную историю прогресса.

## Портфолио-кейс через до/после: как написать убедительно

Для портфолио до/после работает лучше всего — потому что показывает не только что сделано, но и какой результат.

### Структура сильного кейса

Не начинай с «мне дали задачу переделать X» — это скучно. Начни с проблемы пользователя или бизнес-контекста.

Хорошее начало: «Продукт терял 60% пользователей на третьем шаге онбординга. Никто не понимал почему — данные показывали drop-off, но не причину».

Плохое начало: «Клиент попросил обновить дизайн онбординга».

### Что показывать

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

• Что показали данные → как это интерпретировал → что решил попробовать → почему именно это

Альтернативы, которые рассматривал — это признак зрелости. «Мы думали о [вариант A], но выбрали [вариант B] потому что...»

Реальные результаты — обязательно. Без них кейс неполный. Если данных нет — честно скажи это и объясни что планировалось измерять.

### Что не показывать

• Бесконечные скриншоты промежуточных вариантов
• Детальные спецификации (это для handoff, не для кейса)
• Только финальный визуал без контекста почему так

## Инструменты для документации до/после

Правильный инструмент делает документирование быстрым вместо обременительного.

### Figma: дизайн-история прямо в файле

Версии в Figma (File → Version History) — автоматически сохраняется история изменений. Можно вернуться к любому моменту и сравнить.

Как использовать для до/после:

• Перед началом редизайна: File → Save to Version History → «До редизайна [дата]»
• После завершения: ещё одна версия «После редизайна [дата]»
• Теперь можно переключаться и делать сравнительные скриншоты

Figma Branching (в платных планах) — работаешь на отдельной ветке, основная версия остаётся нетронутой. При мерже — явная точка сравнения.

### Notion: база знаний дизайн-решений

Страница на каждый значимый редизайн:

# Редизайн [что] — [дата]

## Контекст
[Кратко: что и зачем]

## Проблема (с данными)
[Данные + скриншоты до]

## Решение
[Описание + скриншоты после]

## Логика решения
[Почему именно так]

## Альтернативы, которые рассматривались
[Что ещё думали и почему не выбрали]

## Результат
[Данные через X недель]

## Что бы сделали иначе
[Ретроспектива]

Эта база через год становится мощным инструментом онбординга новых дизайнеров и обосновании будущих решений.

### Loom: видео-комментарий к изменениям

Короткое видео (3–5 минут) где дизайнер сам объясняет:

• Что было не так
• Что изменили
• Почему именно так

Лучше любого текстового документа для async-команд. Стейкхолдер смотрит 5 минут и понимает суть без встречи.

## До/после для команды vs. для клиента: разные форматы

Одни и те же данные нужно подавать по-разному в зависимости от аудитории.

### Для внутренней команды

Команда хочет понять процесс и учиться на нём. Им нужно:

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

Формат: подробный Notion-документ с полным контекстом. Включай «неудобные» детали — это обучает.

### Для клиента

Клиент хочет знать: стоило ли это денег? Им нужно:

• Что было сделано (кратко)
• Что изменилось в результате (цифры)
• Что это значит для бизнеса

Формат: 1–2 слайда. Только ключевые метрики. Без деталей процесса.

### Для портфолио (потенциальные работодатели/клиенты)

Они хотят понять: как этот дизайнер думает? Им нужно:

• Контекст и проблема
• Процесс принятия решений
• Результат

Формат: структурированный кейс 400–800 слов с избранными скриншотами. Акцент на «почему», а не на «что».

## Частые ошибки в документации до/после

### Только визуал без объяснения

Два скриншота без текста — это картинки. Добавь хотя бы 2–3 предложения: что было проблемой и почему именно это решение.

### Данные без интерпретации

«Конверсия выросла с 3% до 4.5%» — факт. «Это означает 45 дополнительных платящих пользователей в месяц при текущем трафике, или около 432 тыс. ₽ в год при нашем ARPU» — интерпретация. Интерпретация убеждает.

### Документируешь только победы

Редизайн, который не дал ожидаемого результата — тоже ценный документ. Объясни что пошло не так. Это обучает команду лучше чем десять историй успеха.

### Слишком поздно документируешь

Документация через 3 месяца после запуска — это реконструкция по памяти. Данные потеряны, детали забыты, контекст размыт. Документируй в момент: базлайн — перед запуском, решение — при финализации дизайна, результат — через 4–6 недель после запуска.

## ИИ для создания визуальных сравнений

Технически ИИ не рисует за тебя сравнительные таблицы — но помогает подготовить контент для них.

### Промпт: структурировать сравнение

Я хочу создать визуальное сравнение «до/после» для презентации.

До: [описание старого экрана, его проблем, ключевые метрики]
После: [описание нового экрана, изменений, результаты]

Помоги структурировать сравнение:
1. Какие 3–4 аспекта лучше всего показывают разницу?
2. Как сформулировать подписи к скриншотам (кратко, по делу)
3. Какую ключевую цитату из данных вынести на первый план?
4. Как подать это для CEO которому некогда читать детали?