О насБлогКонтакты
Frontend разработка17 октября 2012 г. 5 мин 84Обновлено: 18 мая 2026 г.

Как мы перешли на Mobile-First дизайн в 2012 году

AunimedaAunimeda
📋 Содержание

Как мы перешли на Mobile-First дизайн в 2012 году

К середине 2012 года у нас накопилось достаточно данных, чтобы сделать аргумент внутри команды: мобильный трафик рос быстрее десктопного на каждом проекте, которым мы управляли. Средняя доля была 18% и ускорялась. Вопрос был не в том, приоритизировать ли мобильный - а в том, как сделать «mobile-first» повторяемым процессом, а не разовым усилием.


Проблема с нашим старым процессом

До mobile-first наш процесс выглядел так:

  1. Бриф клиента
  2. Десктопные вайрфреймы в Balsamiq
  3. Десктопные дизайны в Photoshop (холст 1280px)
  4. Фронтенд-разработка - десктоп
  5. «Добавляем мобильный» - обычно двухдневный спринт в конце

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

Контент был неправильным. Навигация была неправильной. Типографика была неправильной. Мы проектировали для мобильного как запасной вариант, и это читалось как запасной вариант.


Решение: перевернуть порядок

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

Логика была простой. Если мобильный макет работает - приоритет контента правильный, навигация чёткая, основное действие доступно - десктопный макет будет несложным. Больше пространства для работы. Но если начать с десктопа, при переходе на мобильный придётся делать тяжёлые сокращения после того, как клиент уже согласовал десктопный дизайн. Ты отнимаешь что-то от дизайна, который клиент полюбил. Этот разговор всегда болезненный.

Начиная с mobile-first, сложные решения по приоритизации происходили до того, как кто-то привязался к конкретному макету.


Процесс мобильного вайрфрейма

Мы собрали кит мобильных вайрфреймов в Balsamiq. Не визуальный дизайн - вайрфрейм приоритета контента. Блоки с подписями. Вопросы, на которые мы заставляли себя ответить до рисования каких-либо рамок:

1. Что одно пользователю на этой странице нужно сделать?

Страница товара: добавить в корзину. Страница контактов: позвонить или отправить форму. Статья блога: прочитать статью.

Это одно действие шло наверх. Всё остальное упорядочивалось по вторичной важности, третичной и «хорошо иметь только на десктопе».

Страница товара - Мобильный стек приоритетов:
━━━━━━━━━━━━━━━━━━━━
│  Изображение       │  ← Полная ширина, свайп-галерея
│  (галерея)         │
├────────────────────┤
│  Название + Цена   │  ← Заметно, читабельно с первого взгляда
├────────────────────┤
│  [ДОБАВИТЬ В КОРЗИНУ] ← ОСНОВНОЕ ДЕЙСТВИЕ - нельзя не заметить
├────────────────────┤
│  Краткое описание  │  ← Максимум 2-3 предложения
├────────────────────┤
│  ▼ Полные детали   │  ← Раскрывающийся - ниже сгиба нормально
│  ▼ Отзывы (12)     │  ← Раскрывающийся
│  ▼ Похожие товары  │  ← Раскрывающийся или карусель
━━━━━━━━━━━━━━━━━━━━

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

2. Как пользователь перемещается?

Наше правило с 2012 года: мобильная навигация должна содержать максимум 5 пунктов, и самый важный никогда не должен быть скрыт.

/* Нижняя вкладочная навигация - мобильный паттерн 2012 года */
.mobile-nav {
  position: fixed;
  bottom: 0;
  left: 0;
  right: 0;
  display: flex;
  height: 56px;
  background: #fff;
  border-top: 1px solid #ddd;
  z-index: 100;
}

.mobile-nav a {
  flex: 1;
  display: flex;
  flex-direction: column;
  align-items: center;
  justify-content: center;
  font-size: 10px;
  color: #666;
  padding: 8px 0;
}

.mobile-nav a.active { color: #0066cc; }

Разговор с клиентом

Сложнейшей частью mobile-first в 2012 году были не технологии - это было управление клиентами. Большинство клиентов никогда не думали о своём сайте на телефоне.

Мы разработали стандартную презентацию, которую проводили на каждом вводном совещании. Три части:

Часть 1: Показать им их текущий сайт на телефоне. Не скриншоты - дать им iPhone и попросить найти товар и добавить в корзину. Наблюдать как они зумируют, прокручивают, нажимают не ту ссылку, зумируют снова. Никаких объяснений не нужно. Они сами видели проблему.

Часть 2: Показать им мобильно-первого конкурента. Мы всегда заранее выбирали одного конкурента, сделавшего адаптивный дизайн хорошо. Контраст был мгновенным.

Часть 3: Объяснить изменение процесса. «Мы собираемся спроектировать ваш сайт сначала для этого. Затем спроектируем десктопную версию. Контент будет тем же - просто по-разному организованным для каждого контекста.»

Типичное возражение: «но большинство наших клиентов используют десктоп». У нас были данные: «Сейчас - да. Но 18% ваших сессий уже мобильные, и эта цифра растёт на 2-3% в месяц. К тому времени, как мы закончим строить проект, будет 25%. К следующему году - 35%.»

Обычно это заканчивало спор.


Что мы делали неправильно в 2012 году

Злоупотребляли гамбургер-меню. «Mobile-first» в 2012 часто означало «помести всё в гамбургер». Теперь мы знаем: гамбургер скрывает навигацию и снижает вовлечённость. Правильное решение - показывать 2-3 самых важных навигационных элемента напрямую, остальное скрывать.

Относились к изображениям как к декорации. Mobile-first подталкивал к текстовым макетам потому что изображения тяжёлые. Мы отдавали те же большие изображения на мобильный и десктоп, полагаясь на max-width: 100% для масштабирования. Но при этом скачивалось полноразмерное изображение на 3G-соединении. Правильный ответ (srcset, <picture>) появился только в 2014.

Не тестировали на реальных устройствах. Мы тестировали на офисных iPhone, но не на бюджетных Android-устройствах, представлявших значительную часть реальной аудитории. Galaxy Y на Android 2.3 был совершенно другим опытом по сравнению с iPhone 5. Мы узнали об этом из тикетов поддержки.


Итоги

К концу 2012 года каждый новый проект, который мы сдавали, был mobile-first. Средний показатель отказов на мобильном снизился с 68% до 41% по клиентским сайтам. Коэффициент конверсии на мобильном вырос с 0.8% до 2.3% - всё ещё ниже десктопного 4.1%, но в 3 раза лучше.

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

Mobile-first не был трендом, который мы приняли в 2012. Это была постоянная переориентация нашего мышления о том, для чего существует сайт.

Читайте также

React против Angular 2: почему мы выбрали React для CRM-системыaunimeda
Frontend разработка

React против Angular 2: почему мы выбрали React для CRM-системы

В 2016 году мы две недели сравнивали React + Redux и Angular 2 для сложной CRM. Честный разбор: двустороннее связывание против однонаправленного потока данных, и что действительно важно при масштабировании.

Переход от jQuery Mobile к современным фреймворкам: ретроспективаaunimeda
Frontend разработка

Переход от jQuery Mobile к современным фреймворкам: ретроспектива

jQuery Mobile был королём мобильного веба в 2011. Мы построили 12 проектов на нём. К 2014 он стал legacy. Честная история взлёта, ошибок дизайна и причин, по которым мы перешли.

Mobile-First: почему в 2012 году мы начали проектировать для пальцев, а не для кликовaunimeda
Frontend разработка

Mobile-First: почему в 2012 году мы начали проектировать для пальцев, а не для кликов

В 2012 мобильный трафик перешёл через 10% у наших клиентов. Мы перестали относиться к мобильному как к запасному варианту и начали считать его основным. Вот смена мышления, которая изменила всё.

Нужна IT-разработка для вашего бизнеса?

Разрабатываем сайты, мобильные приложения и AI-решения для бизнеса в Кыргызстане. Бесплатная консультация.

Разработка сайтов

Получить консультацию Все статьи