Привет! Меня зовут Лена Мезина, я UX-дизайнер в группе компаний «Синтека». Проектирую интерфейсы в сервисе «Фейскит», который помогает вести учет инструментов и рабочего времени на стройке. Часто я наблюдаю, как привычные подходы к дизайну сталкиваются с реальностью на объектах. Сегодня покажу несколько таких кейсов: как «некрасивые» кнопки оказались лучше современного UI, зачем усложнять сценарии и как негативная обратная связь помогает расти. Статья будет полезна тем, кто создает продукты для пользователей с минимальной мотивацией и небольшим опытом работы в мобильных сервисах. 

Классические UX-правила на стройке не действуют

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

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

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

Поэтому я как UX-дизайнер не мыслю только категориями «красиво» или «современно», а придерживаюсь принципа «меньше действий → проще обучение → реже ошибки». В следующем разделе приведу пример, как это работает. 

Отказываемся от трендового UI в пользу огромных кнопок 

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

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

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

UI для строителя — тот, что помогает быстрее закончить работу
UI для строителя — тот, что помогает быстрее закончить работу

Мы поняли, что красивый интерфейс и удобный интерфейс — не всегда одно и то же. Особенно в B2B-продукте для полевых сотрудников. С тех пор соблюдаем правило: между современными UI-трендам и скоростью выполнения задачи в реальных условиях выбирать второе. 

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

Делаем стартовую страницу и ловим поток негатива

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

Вот как раньше выглядел процесс открытия смены: строитель запускал приложение, попадал в реестр ТМЦ, выбирал вкладку «Рабочее время» в боковом меню и нажимал «Начать работу»
Вот как раньше выглядел процесс открытия смены: строитель запускал приложение, попадал в реестр ТМЦ, выбирал вкладку «Рабочее время» в боковом меню и нажимал «Начать работу»

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

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

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

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

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

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

Слева — как меню выглядело раньше, справа — как выглядит двухуровневая структура сейчас
Слева — как меню выглядело раньше, справа — как выглядит двухуровневая структура сейчас

Были и другие изменения в интерфейсе. Так благодаря внедрению стартовой страницы мы сократили путь пользователя до функции «Начать работу». Выше я показала, что это действие занимало три клика. Сейчас открытие смены укладывается в один. 

Теперь начать смену можно сразу на главной странице приложения 
Теперь начать смену можно сразу на главной странице приложения 

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

Сначала нас ругают, а потом принимают обновления. Если вам доводилось делать редизайн продукта, то вы уже догадались, что произошло дальше. Правильно — строителям не понравилось. Первые отзывы были примерно такими: «Верните предыдущий интерфейс», «Ничего не понятно», «Раньше было удобнее». 

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

Я понимала, что негативная реакция в начале — это нормально. Людям приходится перестраивать привычные действия, а мозг не любит менять сценарии. Даже если новый инструмент объективно удобный, какое-то время будет сопротивление на уровне пользователей. Поэтому мы не стали делать выводы по первым отзывам и продолжили наблюдать. 

Примерно через три недели картина изменилась: строители начали перемещать и принимать инструменты через карточки на главной странице 
Примерно через три недели картина изменилась: строители начали перемещать и принимать инструменты через карточки на главной странице 

Что будет дальше. Мы постоянно собираем обратную связь, чтобы улучшать UI/UX нашего продукта. Главный инструмент в этой области — опросы. Размещаем их на главной странице и анализируем статистику. 

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

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

Недавно через опрос в приложении мы выяснили, что 50% пользователей за один раз принимают только одну единицу ТМЦ. Рабочий не получает сразу целый список инструмента и расходных материалов на неделю или месяц вперед. Все выдают по необходимости: сегодня перфоратор, завтра паяльник для пластиковых труб. Такие единичные перемещения мы решили вывести на стартовую, чтобы человек мог принять инструмент, не заходя в полный список ТМЦ.

Скоро главную страницу ждет обновление: появится функция быстрого принятия ТМЦ. Также мы добавили статистику последних смен, которая помогает пользователям контролировать свои недавние смены и не забывать их открывать
Скоро главную страницу ждет обновление: появится функция быстрого принятия ТМЦ. Также мы добавили статистику последних смен, которая помогает пользователям контролировать свои недавние смены и не забывать их открывать

Нарушаем собственные правила

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

Разберу кейс на эту тему. Чтобы запустить смену в «Фейските», строитель делает селфи. Наличие снимка означает, что человек приступил к работе. Но новые требования к работе с биометрическими данными заставили нас пересмотреть подход — и добавить проверку качества фотографии самим пользователем, чтобы при сверке его могли идентифицировать и люди: 

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

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

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

Каждое изменение в «Фейските» проходит через обсуждение и проверку гипотез. Я учитываю мнение продактов, команды внедрения и, конечно, пользователей. Интересная дискуссия прямо сейчас разворачивается вокруг функции «Принятие ТМЦ». Об этом следующий раздел.

Спорим и ищем компромиссы внутри команды 

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

Сейчас строка для комментария и фотографии находится на одном экране с функцией «Принять» 
Сейчас строка для комментария и фотографии находится на одном экране с функцией «Принять» 

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

Чтобы разрешить спор, мы подняли статистику за месяц. Наши пользователи совершили более 36 000 операций по перемещению ТМЦ. При этом всего 2% оставили комментарий или прикрепили фото: 740 и 710 случаев соответственно. Здесь возможно два варианта. 

  • Комментарии и фото почти никому не нужны и требуются только в исключительных случаях. 

  • Функция необходима, но элементы на экране расположены так, что люди их не замечают или не понимают назначение. 

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

Вместо вывода 

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

В статье мы показали лишь несколько примеров, как развивается интерфейс в сервисе «Фейскит». Если интересно оценить другие наши решения в области UI/UX, загляните на страницу продукта.

Комментарии (1)


  1. Chemist_modeler
    20.08.2026 10:32

    Удобство важнее эстетики и даже - о боже - функционала. Понятность интерфейса важнее "правильности". Подписываюсь.