Новая админка: что действительно нужно менеджерам

Часть 7 из 7 · Серия «Старый сайт — новая рабочая система»

Сайт переделали, всё работает быстрее и выглядит лучше. А через месяц выясняется, что менеджеры по-прежнему ведут цены в таблице и просят «вернуть как было».

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

Между тем именно админка чаще всего и есть настоящая причина переделки. Ради неё считали часы ручного труда во второй части.

Почему «сделайте как в старой» — плохая цель

Формулировка звучит безопасно: люди привыкли, не придётся переучиваться. На практике так копируются и ограничения.

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

Правильная цель формулируется иначе:

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

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

Начинать с ролей, а не с экранов

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

Типичный набор ролей в небольшой компании:

• контент-менеджер — товары, описания, фотографии, страницы;
• менеджер заказов — обработка заказов, статусы, связь с покупателем;
• бухгалтер — выгрузки, документы, сверки;
• руководитель — сводки, отчёты, ничего не редактирует;
• администратор — настройки, права, интеграции.

У каждой роли своё представление о том, что должно быть на главном экране. Для менеджера заказов главное — новые заказы; для контент-менеджера — товары, требующие внимания; руководителю нужны цифры, а не списки.

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

Что менеджер должен уметь без разработчика

Самый практичный список во всей статье. Проверьте по нему будущую админку.

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

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

Общее правило: если задача повторяется чаще раза в квартал, она должна решаться без разработчика. Всё, что реже, можно оставить в ведении исполнителя — делать под это интерфейс дороже, чем изредка просить.

Массовые операции

Здесь прячется основная экономия времени, и здесь же чаще всего экономят при разработке.

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

Что стоит предусмотреть:

• изменение цены или остатка для выбранной группы, в том числе процентом;
• перенос товаров между категориями;
• снятие с публикации и возврат группой;
• загрузка изменений из таблицы;
• массовая смена статуса у заказов.

Два обязательных требования к любой массовой операции: предпросмотр — что именно изменится и у скольких записей, и возможность откатить. Без них первая же ошибка обойдётся дороже, чем вся экономия.

Что убрать с глаз

Перегруженный интерфейс работает так же плохо, как недостаточный.

Убирайте из повседневных экранов:

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

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

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

Как проверить, что админка получилась

Четыре способа, от быстрого к честному.

Посчитайте действия. Пять типовых операций до и после. Если стало больше — что-то пошло не так.

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

Спросите через месяц, к чему возвращаются в старую систему. Если к чему-то возвращаются, значит, это не перенесли или сделали неудобно.

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

Частые вопросы

Кто должен участвовать в проектировании админки?

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

Можно ли обойтись стандартной админкой платформы?

Часто да, и это разумно на старте. Настраивать её под роли и убирать лишнее всё равно придётся, но с нуля рисовать интерфейс обычно незачем.

Как понять, что нужны массовые операции?

Спросите менеджеров, что они делают повторяющимися действиями. Если ответ «меняю цены по одному товару» — нужны.

Сколько ролей заводить?

Столько, сколько реально разных наборов задач. Плодить роли «на будущее» не стоит: неиспользуемые права только запутывают.

Что делать, если менеджеры сопротивляются новой админке?

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

Чем закончим

Серия получилась про то, что переделка сайта — это не про новый дизайн.

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

Если свести всё к одному предложению, оно такое: сайт переделывают не для того, чтобы он лучше выглядел, а для того, чтобы люди перестали делать руками то, что должно происходить само. Админка — то место, где это либо случилось, либо нет.

Про то, как выбрать исполнителя и как устроен процесс работы, — отдельная серия «Разработка без сюрпризов».

Покажите текущий сайт — разберусь, что мешает, и предложу план переработки: siteko.net/development.