Product Designer · Middle

5 лет в дизайне, два года в продукте

Мобильный вебВеб-приложения
Решения сверяю с рынком117 российских приложений, 7 360 сценариев и 36 880 экранов разложены по шагам и лежат под рукой.
Лента для ассистента Для ассистента

Один адрес со всем: анкета, опыт, навыки, кейсы, договорённости. Скопируйте и вставьте в ChatGPT или Claude, ставить ничего не нужно.

prokhor.me/llms.txt
Знак ПрохораПрохор
РезюмеCV Telegram

Спросите что угодно о Прохоре

Отвечает модель по материалам сайта. Чего нет в кейсах, того она не знает.

Отвечает модель и может ошибаться. Проверяйте важное у самого Прохора.

Кейс, prokhor.me

Сайт-портфолио, который сам подтягивает правки из Figma

( А )

Этот самый сайт: Next.js на своём сервере, живая связь с Figma без пересборки, сжатие картинок вдвенадцать раз и заголовки безопасности, закрывшие тринадцать уязвимостей.

( Б )

Портфолио дизайнера обычно статично: сделал один раз и забыл. Хотелось наоборот, сайт, который остаётся рабочим инструментом, а не витриной, и который я сам понимаю на уровне кода, а не только слоёв Figma.

( В )

Frontend Development, DevOps, Design Engineering
2026
Самостоятельный концепт

Открыть проект
Сайт-портфолио, который сам подтягивает правки из Figma
рис. 1, prokhor.me · разработка и инфраструктура

Результаты

17.5 МБ
экономия на AVIF по всем скриншотам
×12
разница в весе SVG против PNG у одного экрана
13
закрытых уязвимостей после обновления Next
5 мин
кэш Figma-рендера без ожидания вебхука

Референсы

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

Крутите мышью

Проблема бизнеса

Что было сломано.

Макет меняется в Figma, а сайт об этом не знает. Обычное решение, экспортировать картинку и перезалить, работает, пока правок одна-две. При частых правках это превращается в ручную синхронизацию, которая рано или поздно расходится с оригиналом.

Гипотезы

Что я предположил.

  • H1Сервер может сам ходить в Figma REST API и рендерить нужный фрейм по запросу, тогда сайт не хранит устаревшую копию.
  • H2Вебхук Figma на изменение файла достаточен, чтобы сбрасывать кэш без ручного действия.
  • H3Растровый формат в двойном разрешении легче, чем кажется: SVG из Figma вшивает фотографии base64 целиком.

Ограничения

С чем работал.

  • ·Сервер один, два ядра и три гигабайта памяти, значит любое решение должно быть лёгким по ресурсам.
  • ·Токен Figma не должен попасть ни в браузер, ни в git.
  • ·Figma присылает не больше одного вебхука на файл за тридцать минут, кэш не может полагаться только на него.

Дизайн-решения

Как я это сделал.

  1. 01

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

  2. 02

    Формат по умолчанию сменил с SVG на PNG в двойном разрешении: тот же экран с тремя фотографиями весил девять мегабайт вместо семисот килобайт.

  3. 03

    Широкая доска с несколькими экранами разбирается на объекты по дереву узлов Figma, а не рендерится одной картинкой с серой подложкой.

  4. 04

    При сборке рядом с каждым PNG и JPG генерируется AVIF, nginx отдаёт его тем браузерам, что его понимают, по заголовку Accept.

  5. 05

    Заголовки CSP, HSTS и остальные выставлены в конфиге Next, а не в middleware: прошлогодняя уязвимость показала, что middleware обходится подделкой одного заголовка запроса.

Пользовательский сценарий

Линейный flow.

  1. 01
    Правлю фрейм в Figma
    сохранение файла
  2. 02
    Figma шлёт вебхук
    FILE_UPDATE
  3. 03
    Сервер сбрасывает кэш
    без пересборки сайта
  4. 04
    Следующий заход отдаёт свежий рендер
    секунды, не минуты

Что не получилось сразу

Пришлось переделывать.

  • Первая попытка привязать процесс к localhost вместо всех интерфейсов положила сайт на несколько минут: Next 15.5 сравнивает адрес переноса с адресом прослушивания и посчитал внутренний перенос внешним. Откатил и оставил порт открытым только для внутренних процессов через брандмауэр.
  • Лимит одновременных соединений в nginx ловил живых посетителей в 429. Причина оказалась не в частоте запросов, а в том, что по HTTP/2 каждый параллельный поток считается отдельным соединением, а страница тянет три десятка файлов разом. Поднял порог, проверил.

Передача в разработку

Что отдаю фронтенду.

  • ·Скрипт генерации AVIF встроен в команду сборки, новые картинки обрабатываются сами.
  • ·Отдельная зона nginx на вход в админку с лимитом попыток, чтобы подбор пароля упирался в 429.
  • ·fail2ban на повторяющиеся 429 и на неудачные входы, банит адрес на уровне брандмауэра.

Кадры

Ключевые экраны.

рис. 2, Главная prokhor.me
рис. 3, Живой рендер из Figma в кейсе

Результат

Итог

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

Моя роль

Что делал я.

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

Следующий кейс

Заголовок бренда, который прошёл шесть правок за неделю

prokhor.me · позиционирование и подача

2026