Назад
SX

SX. Web app

SaaS / Infrastructure • Роль: UX/UI / Product Designer • Период: 2023–2025

1. Контекст проекта

SX.ORG — сервис прокси, разработанный с нуля как маркетплейс и операционная платформа для работы с прокси-инфраструктурой.

Ключевые особенности продукта:

  1. 1 Покупка и продажа прокси (через дочерний сервис ProxySell.com)
  2. 2 Первый на рынке продукт с подписочной моделью прокси
  3. 3 Фокус на техническую аудиторию (арбитраж, маркетинг, automation, scraping)

В отличие от большинства proxy-сервисов, SX.ORG проектировался не как витрина, а как рабочий инструмент для ежедневного использования в условиях высокой нагрузки.

2. Моя роль и команда

Моя роль: UX/UI / Product Designer

Формат работы: Продуктовая команда

Зоны ответственности:

  1. 1 Формирование UX-архитектуры продукта с нуля
  2. 2 Проектирование ключевых сценариев (покупка, настройка, масштабирование)
  3. 3 Дизайн интерфейсов (desktop-first)
  4. 4 Участие в продуктовых решениях и приоритизации сценариев

Взаимодействие:

  1. 1 Product Owner — приоритизация сценариев
  2. 2 Backend — API, логика портов, биллинг
  3. 3 Frontend — совместная проработка сложных UI-паттернов
  4. 4 QA-инженеры — тестирование сценариев, состояний и edge-кейсов
  5. 5 Аналитики — формирование гипотез, продуктовых и UX-метрик

3. Цели проекта

Бизнес-цели:

  1. 1 Создать масштабируемую proxy-платформу, а не разовую покупку
  2. 2 Повысить LTV за счет подписочной модели
  3. 3 Масштабировать продукт под high-load пользователей
  4. 4 Снизить нагрузку на поддержку

Пользовательские цели:

  1. 1 Быстро получить прокси и начать работу
  2. 2 Управлять десятками и сотнями прокси без ручного ада
  3. 3 Понимать расход трафика и деньги
  4. 4 Масштабироваться без повторной настройки

4. Исследования и аналитика

Пользовательский контекст и наблюдения:

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

Продуктовые решения формировались на основе:

  1. 1 Анализа поведения пользователей существующих proxy-сервисов
  2. 2 Обратной связи от активных пользователей (арбитраж, automation, команды)
  3. 3 Анализа обращений в поддержку и типовых ошибок
  4. 4 Наблюдений за массовыми и повторяющимися сценариями работы

Ключевые пользовательские барьеры:

  1. 1 Сложный старт и высокий порог входа
  2. 2 Разрыв между покупкой прокси и их фактическим использованием
  3. 3 Непрозрачный расход трафика и средств
  4. 4 Отсутствие удобных инструментов для массовых операций
  5. 5 Интерфейсы, не рассчитанные на масштабирование

Были изучены proxy-сервисы и инфраструктурные SaaS-решения с фокусом на:

  1. 1 Скорость получения результата
  2. 2 Поддержку массовых сценариев
  3. 3 Прозрачность данных и расходов
  4. 4 Удобство интеграции с внешними инструментами

Ключевые проблемы рынка:

  1. 1 Интерфейсы ориентированы на разовые действия
  2. 2 Масштабирование требует ручной работы
  3. 3 Отсутствует предсказуемость расходов
  4. 4 Слабая связь между прокси, портами и трафиком

Выводы аналитического этапа:

  1. 1 Proxy-сервис должен проектироваться как рабочий инструмент, а не витрина
  2. 2 Массовые сценарии — основной пользовательский кейс
  3. 3 Прозрачность трафика снижает ошибки и нагрузку на поддержку
  4. 4 Подписочная модель упрощает масштабирование и планирование расходов

5. Аудитория и поведенческий контекст

Основная аудитория:

  1. 1 Media buyers / performance-маркетологи — ежедневно масштабируют пулы прокси под кампании и требуют стабильной работы в high-load.
  2. 2 Арбитражники трафика — работают с десятками и сотнями прокси, ожидая быстрой замены, контроля расхода и надежности.
  3. 3 Automation / scraping — запускают массовые задачи и требуют предсказуемой нагрузки, стабильных портов и прозрачных лимитов.
  4. 4 Технические команды — ведут инфраструктуру, мониторят качество трафика и масштабируют прокси под разные проекты.

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

  1. 1 Работа в режиме «запуска» — решения принимаются быстро, нужен результат без длительной настройки и ожиданий.
  2. 2 Параллельные задачи — одновременное управление десятками и сотнями прокси требует массовых операций.
  3. 3 Высокий уровень стресса — ошибки и задержки влияют на бюджеты, поэтому важны прозрачность и контроль.
  4. 4 Минимальная терпимость к лишним шагам — интерфейс должен сокращать рутину и исключать ручные действия.

6. Архитектура проекта

Глобальная функциональная карта:

Глобальная функциональная карта

7. Ключевые сценарии и решения

Сценарий 1. Dashboard

Задача:

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

Контекст:

SX — сервис прокси, разработанный с нуля. Аудитория — от новичков до технически опытных пользователей. Один экран должен был работать для разных стадий использования продукта.

Проблема:

  1. 1 Новые пользователи не понимают, с чего начать
  2. 2 Опытным пользователям важны данные, а не инструкции
  3. 3 Универсальный Dashboard перегружает либо новичков, либо продвинутых

Гипотезы:

  1. 1 Dashboard должен адаптироваться под стадию пользователя
  2. 2 Для новых пользователей важнее сценарий, чем метрики
  3. 3 Для активных пользователей важнее состояние системы, чем онбординг

Решение:

Спроектирован двухрежимный Dashboard:

  1. 1 Dashboard для новых пользователей — пошаговый сценарий начала работы
  2. 2 Основной Dashboard — агрегированная информация по балансу, прокси и трафику

Режим определяется автоматически по состоянию аккаунта

Сценарий 1. Dashboard — экран 1
Сценарий 1. Dashboard — экран 2

Результат:

  1. 1 Снижен порог входа в продукт
  2. 2 Пользователи быстрее доходят до первого использования
  3. 3 Dashboard масштабируется без усложнения интерфейса

Сценарий 2. Прокси по ссылке

Задача:

Дать пользователю быстрый способ получить актуальный список прокси в формате IP:PORT без ручного управления портами.

Контекст:

Пользователи работают с прокси через софт, боты и скрипты. Важно не хранение портов, а постоянно обновляемый источник прокси.

Проблема:

  1. 1 Ручное управление портами замедляет работу
  2. 2 Прокси устаревают и требуют постоянного обновления
  3. 3 Сложно быстро собрать нужный пул под конкретную задачу

Гипотезы:

  1. 1 Ссылка с динамическим списком прокси упрощает интеграцию
  2. 2 Фильтры важнее индивидуальных настроек портов
  3. 3 Один универсальный формат снижает порог использования

Решение:

Создан раздел «Прокси по ссылке»:

  1. 1 Конфигуратор фильтров (тип, страна, формат, лимит)
  2. 2 Генерация одной ссылки с актуальными прокси
  3. 3 Поддержка TXT / JSON форматов
  4. 4 Автообновление списка без действий пользователя
Сценарий 2. Прокси по ссылке — экран 1
Сценарий 2. Прокси по ссылке — экран 2
Сценарий 2. Прокси по ссылке — экран 3

Результат:

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

Сценарий 3. Создать новый порт

Задача:

Позволить пользователю быстро и без ошибок создать прокси-порт под конкретную задачу.

Контекст:

Пользователи работают с разными geo, типами прокси и сценариями (арбитраж, парсинг, фарм). Неправильная настройка порта = потеря денег и времени.

Проблема:

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

Гипотезы:

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

Решение:

Реализован конструктор создания порта:

  1. 1 Последовательные шаги: тип → GEO → регион → ASN → расширенные настройки
  2. 2 Смарт-список стран с индикаторами доступности
  3. 3 Предустановленные дефолты для быстрого старта
  4. 4 Создание порта только после прохождения ключевых этапов
Сценарий 3. Создать новый порт — экран 1
Сценарий 3. Создать новый порт — экран 2
Сценарий 3. Создать новый порт — экран 3

Результат:

  1. 1 Пользователи быстрее создают рабочие порты
  2. 2 Снижено количество ошибок и некорректных конфигураций
  3. 3 Создание порта стало предсказуемым и масштабируемым процессом

Сценарий 4. Мои прокси порты

Задача:

Дать пользователю удобный контроль и управление большим количеством портов в одном месте.

Контекст:

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

Проблема:

  1. 1 Сложно ориентироваться в большом списке портов
  2. 2 Нет быстрого понимания статуса и параметров порта

Гипотезы:

  1. 1 Табличный формат с ключевыми параметрами ускоряет навигацию
  2. 2 Фильтры и поиск must-have при большом объеме портов
  3. 3 Быстрые действия прямо из списка экономят время

Решение:

Реализован экран «Мои прокси-порты», основанный на реальном опыте использования:

  1. 1 Список портов с ключевыми параметрами (тип, гео, количество)
  2. 2 Поиск и фильтрация по типу и стране
  3. 3 Архив для неактуальных портов
  4. 4 Быстрые действия и массовое управление
  5. 5 Быстрое создание нового порта из списка
Сценарий 4. Мои прокси порты — экран 1
Сценарий 4. Мои прокси порты — экран 2
Сценарий 4. Мои прокси порты — экран 3

Результат:

  1. 1 Пользователи быстрее находят нужные порты
  2. 2 Управление большим количеством портов стало предсказуемым
  3. 3 Экран масштабируется под рост количества портов без усложнения UX

Сценарий 5. Наши тарифы

Задача:

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

Контекст:

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

  1. 1 Одни считают трафик
  2. 2 Другие количество портов и срок
  3. 3 Третьи хотят подписку без постоянных перерасчетов

Проблема:

  1. 1 Универсальный тариф не покрывает разные паттерны использования
  2. 2 Сложно понять итоговую стоимость до оплаты
  3. 3 Подписки и pay-as-you-go обычно смешаны и перегружены
  4. 4 Пользователь не понимает, что выгоднее именно для его кейса

Гипотезы:

  1. 1 Разделение тарифов по модели оплаты снизит когнитивную нагрузку
  2. 2 Конструктор тарифов упростит принятие решения
  3. 3 Прозрачный расчет стоимости повысит доверие
  4. 4 Подписка должна ощущаться как «простое решение без контроля»

Решение:

  1. 1 Разделили тарифы на два независимых сценария: 1) С оплатой по трафику (гибкий конструктор), 2) Безлимитные порты (подписка)
  2. 2 Конструктор с пошаговой настройкой: тип прокси, количество, срок аренды
  3. 3 Мгновенный пересчет итоговой стоимости
  4. 4 Четкое сравнение условий без скрытых параметров
Сценарий 5. Наши тарифы — экран 1
Сценарий 5. Наши тарифы — экран 2

Результат:

  1. 1 Пользователь быстрее выбирает подходящую модель оплаты
  2. 2 Снижен порог входа для новых клиентов
  3. 3 Увеличено использование подписок для долгих сценариев
  4. 4 Меньше вопросов в поддержку по тарифам и расчетам

Сценарий 6. Реферальная программа

Задача:

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

Контекст:

SX сервис с сильным сарафаном (арбитраж, команды, агентства). Пользователи готовы рекомендовать продукт, если:

  1. 1 Понятны условия
  2. 2 Видно деньги
  3. 3 Просто вывести вознаграждение

Проблема:

  1. 1 Реферальные системы часто выглядят как «чёрный ящик»
  2. 2 Нет прозрачной связи: кто пришёл → сколько заработал → когда можно вывести
  3. 3 Сложно управлять несколькими кодами и источниками трафика

Гипотезы:

  1. 1 Если пользователь видит деньги и статус начислений, он активнее привлекает рефералов
  2. 2 Разделение на этапы (коды → начисления → выплаты) снижает путаницу
  3. 3 Возможность создавать несколько кодов повышает контроль источников трафика

Решение:

  1. 1 Отдельный раздел «Реферальная программа»
  2. 2 Три логических блока: Основное, Ссылки и коды, Выплаты
  3. 3 Прозрачные статусы: в ожидании / выплачено / отклонено
  4. 4 Явные условия вывода и ограничения
Сценарий 6. Реферальная программа — экран 1
Сценарий 6. Реферальная программа — экран 2
Сценарий 6. Реферальная программа — экран 3

Результат:

  1. 1 Пользователи начали активнее использовать реферальную программу
  2. 2 Снизилось количество вопросов в поддержку по выплатам
  3. 3 Реферальный канал стал прогнозируемым и управляемым источником роста

8. Результаты проекта

SX.ORG был спроектирован как продукт для профессиональных пользователей, работающих с прокси в высоконагруженных сценариях. Основной фокус — скорость, контроль и масштабируемость. UX-архитектура строилась вокруг реальных рабочих процессов, а не отдельных экранов.

Ключевые результаты проекта:

  1. 1 Продукт полностью спроектирован с нуля: от архитектуры до ключевых пользовательских сценариев
  2. 2 Сформирована понятная и расширяемая UX-структура для сложного proxy-сервиса
  3. 3 Упрощен вход в продукт через onboarding-dashboard для новых пользователей
  4. 4 Снижено количество ошибок при создании и настройке портов за счёт пошагового конструктора
  5. 5 Ускорен доступ к прокси (IP:PORT, ссылки, выгрузки) для рабочих сценариев
  6. 6 Реализованы две бизнес-модели в одном продукте: оплата по трафику и подписки
  7. 7 Обеспечена прозрачность расходов и использования трафика
  8. 8 Улучшена управляемость больших пулов прокси
  9. 9 Добавлен механизм органического роста через реферальную программу

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

9. Вывод

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

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

Основные выводы проекта:

  1. 1 Пользователи мыслят задачами и результатами, а не настройками
  2. 2 Чем сложнее продукт — тем важнее ясная UX-архитектура
  3. 3 Пошаговые и модульные сценарии снижают количество ошибок
  4. 4 Прозрачность данных повышает доверие и снижает нагрузку на поддержку
  5. 5 Масштабируемость закладывается на уровне сценариев, а не экранов
  6. 6 UX напрямую влияет на удержание, LTV и скорость работы пользователя

Этот кейс демонстрирует мой опыт проектирования B2B и high-risk сервисов с высокой сложностью, а также умение превращать технические системы в понятные и управляемые продукты.