Привет, Хабр!
Меня зовут Андрей Бирюков. Я — независимый эксперт в области ИТ и ИБ, преподаю в учебных центрах и пишу статьи и книги.
Давайте представим следующую ситуацию: вы потратили три месяца, собрали требования, нарисовали элегантную архитектуру, учли все краевые случаи.
Разработчики в свою очередь написали качественный код. Вы передаёте систему в эксплуатацию, завариваете кофе и ждёте благодарностей.
А через две недели приходит отчёт: пользователи совершают критическую ошибку каждую четвёртую операцию.
Производительность всей системы упала на 40%. Вместо того чтобы ускорить бизнес процесс, система стала тормозом.
Получается, что аналитик спроектировал шедевр, который пользователи не оценили.
«Они просто глупые», — думаете вы. «Я же всё продумал».
Но нет, пользователи не глупые, они просто другие. Они — фантомные пользователи в вашей голове. И это история не о шизофрении, а о разном восприятии людьми многих вещей.
Проклятие прозрачного интерфейса
Разработчики и аналитики являются квалифицированными специалистами и именно поэтому они зачастую страдают профессиональной слепотой. Им кажется, что если логика системы понятна им, то она понятна всем. Они создают интерфейсы, которые требуют от пользователя того же уровня понимания системных взаимосвязей, что и у них самих.
Это называется «ошибка эксперта» (expert blind spot). Чем лучше вы знаете предмет, тем хуже вы способны представить себя новичком, который видит экран впервые и у которого нет вашей ментальной модели.
Механика этой ошибки заключается в следующем. Аналитик видит систему как совокупность модулей, сущностей и связей. Пользователь, в свою очередь, видит только один экран в конкретный момент стресса.
Аналитик знает, что произойдёт, если нажать на эту кнопку. Пользователь гадает, и гадание отнимает у него когнитивный ресурс, которого у него и так нет.
Просто история из жизни
Сеть из 200 продуктовых магазинов решила внедрить новую систему управления товарными остатками. Аналитик, бывший логист с 15-летним стажем, сделал идеальную систему с точки зрения логики складского учёта: 12 полей для ввода поставки, 4 статуса для каждой позиции, автоматические пересчёты и детальные отчёты по просрочке.
Он провёл обучение — все понимали, кивали.
Через месяц выяснилось: менеджеры магазинов НЕ ВВОДЯТ поставки. Совсем. Система стояла пустая. Директор сети в ярости.
Аналитик приехал на точку и увидел:
Менеджер принимает поставку в 6 утра. За спиной стоит фура, водитель торопит. На складе — 400 коробок с разными позициями. Рядом звонит телефон, касса не бьёт, продавец заболел.
Чтобы ввести одну поставку, менеджеру нужно 8 минут. За это время в очереди собираются покупатели, и ему пишет начальник: «Почему не открыт зал?!»
Каждое утро менеджер стоял перед выбором:
Ввести поставку правильно и потерять утреннюю выручку
Ввести поставку быстро, но с ошибкой (и получить выговор за инвентаризацию)
Не вводить поставку вообще и надеяться, что «как‑нибудь проскочит»
Он выбирал третий вариант. Каждое утро. Потому что система была спроектирована так, как будто у менеджера есть час и кофе в тихом кабинете. А не так, как было на самом деле.
Что же не так в этой истории? Аналитик cпроектировал систему для себя — эксперта по логистике.
Он не спросил:
«Что ещё делает этот человек в момент ввода данных?»
«Сколько у него секунд на ввод одной записи?»
«Какое действие для него важнее — точность данных или обслуживание клиента?»
Однако, у этой истории все‑таки был счастливый конец.
Внедрили «режим приёмки» — одно поле для сканера штрихкодов. Менеджер просто пробивает коробки одну за другой.
Система сама распознаёт товар, сама считает количество, сама сверяет с накладной. После того как фура уехала, можно зайти в интерфейс и уточнить нюансы. Но критическая операция — приёмка — сократилась с 8 минут до 1,5 минут.
Почему «подробно» ≠ «хорошо»
Аналитик по определению должен быть дотошным, любить детали. Они боятся упустить что‑то важное, поэтому в требованиях появляется всё больше полей, флажков, выпадающих списков и подтверждающих диалогов.
Но в реальности каждый лишний шаг — это точка отказа. Здесь работают законы когнитивной психологии. Рабочая память человека удерживает 4–7 элементов одновременно. Каждый переход между экранами сбрасывает контекст. А при стрессе (а ведь работа — это всегда стресс) когнитивные способности падают на 30–40%.
На практике это означает, что если ваша система требует 7 шагов для выполнения простой задачи — вы проектируете не для человека, а для робота с бесконечным вниманием.
Статистика или жизнь
Наш следующий практический пример будет посвящен медицине.
Крупная клиника внедряла электронную карту пациента.
Аналитик — бывший врач‑методист — требовал, чтобы каждый приём фиксировался с максимальной полнотой: жалобы, анамнез, осмотр, предварительный диагноз, план обследования, план лечения, рекомендации. 7 обязательных блоков. Ни один нельзя пропустить — система не даёт сохранить карту.
«Полнота данных — это качество медицины», — говорил аналитик.
Врачи на приёме заполняли только имя пациента и диагноз. Остальное — пропускали, нажимали «Отмена» и записывали на бумажке. В статистику попадало 30% приёмов. Руководство требовало «повысить дисциплину», в ответ врачи увольнялись.
Что же здесь не так?
Аналитик спутал две роли:
Врач на приёме: у него 12 минут на пациента, он слушает жалобы, смотрит в глаза, принимает решение. У него нет времени кликать мышкой. Если он будет заполнять все 7 блоков — он пропустит важный симптом, потому что будет смотреть в монитор, а не на пациента.
Врач‑статист: тому, кто пишет научные работы, нужны данные. Но он не работает с пациентом.
Аналитик спроектировал один интерфейс для двух принципиально разных ролей в разных условиях. И выбрал в пользу того, кто ему ближе по менталитету (методиста), а не того, кто систему физически использует.
Эту проблему исправили, сделав в системе три режима:
«Экспресс‑приём» — только диагноз и назначение. 30 секунд. Всё остальное — опционально.
«Полный приём» — все 7 блоков, но это отдельный режим для сложных случаев, когда врач специально планирует время.
«Дозаполнение» — возможность после приёма, во время обеда, открыть карту и добавить детали, если нужно.
Итог: Заполняемость выросла до 85%. Потому что систему перестали воспринимать как врага, который мешает работать.
Когда «настройка под себя» становится проклятием
Ещё одна любимая ошибка всех крутых (без сарказма) специалистов: делать систему максимально гибкой. «Пусть пользователь сам настроит под свои нужды!» — восклицает аналитик. И выдаёт интерфейс с 40 параметрами конфигурации, 20 фильтрами и 15 способами сортировки.
Это звучит как демократия, ведь каждый пользователь может настроить систему как ему удобно. Но на практике получается издевательство.
Причина заключается в том, что настройка требует понимания, как работают все параметры, времени на эксперименты, способности предвидеть последствия каждой опции.
У пользователя нет как минимум двух из трёх пунктов, а зачастую и всех трёх.
Отчётность, где «любая гибкость» убила принятие решений
Вот история из жизни:
Финансовый департамент компании получил новую BI‑систему. Аналитик гордился: «Можно построить любой отчёт! 300 мер, 50 измерений, любой срез данных!»
Пользователь — финансовый контролёр — открыл систему и растерялся. 5 000 комбинаций отчётов. Чтобы получить стандартный P&L за месяц, нужно выбрать 12 фильтров, применить 3 сортировки и не забыть про пересчёт валюты.
В первый день он построил неправильный отчёт три раза подряд, отправил начальнику, получил нагоняй. На второй день он позвонил аналитику и сказал: «Я не могу так работать. Сделайте мне одну кнопку — „Месячный P&L“».
Аналитик удивился: «Но это же ограничивает гибкость!»
Контролёр ответил: «Я не хочу гибкость. Я хочу отчёт, за который меня не уволят».
Здесь аналитик спроектировал систему для аналитика данных. Пользователь был не аналитиком — он был операционным сотрудником, который отвечает за конкретный отчёт, и любое отклонение в этом отчёте — это риск для его работы. Ему нужна не свобода, а предсказуемость и воспроизводимость.
В исправленном варианте сделали два слоя:
«Избранное» — 5 стандартных отчётов, которые контролёр строит в один клик. Это 90% его работы.
«Конструктор» — полная гибкость для тех 10% случаев, когда нужно сделать ad‑hoc анализ.
Контролёр использует «Избранное» ежедневно. Один раз в квартал открывает конструктор. Все счастливы.
Возрастной разрыв и цифровой шовинизм
Это отдельная и нетолерантная очень болезненная тема. Молодые аналитики (25–30 лет) проектируют системы для пользователей 50–60 лет. И они не могут представить, что кто‑то не умеет пользоваться горячими клавишами, боится нажимать на незнакомые кнопки, привык к бумажным журналам и подписям или просто имеет проблемы со зрением (мелкий шрифт для них — непреодолимое препятствие).
Молодой аналитик считает это «цифровой безграмотностью» и пытается «переучить» пользователя. Но это так не работает. Пользователь просто уходит из профессии, и компания теряет носителя критического знания.
Как складской учёт «ушёл в планшет» и провалился
История про склад стройматериалов.
Кладовщику — 58 лет, стаж — 35 лет. Он помнит, где лежит каждая гайка. Ему выдали планшет с новой WMS‑системой. Аналитик сделал красивый, современный интерфейс: swipe‑жесты, мультитач, иконки без подписей.
Кладовщик отдал планшет через три дня: «Я не могу. Оно всё прыгает».
На разборе выяснилось, что кладовщик не умеет пользоваться сенсорным экраном — пальцы толстые, попадает не в те кнопки. Помимо этого, шрифт 14px он не видит вообще, и при этом свайпы срабатывают случайно, пользователь не понимает, куда ушёл экран. Простыми словами: ему нужны кнопки, большие, с текстом, которые НЕ ДВИГАЮТСЯ.
Аналитик возмущался: «Но это же удобно! Я сам так работаю!»
Кладовщик: «Ты не работаешь на складе. Ты сидишь в офисе».
Аналитик проектировал интерфейс «для себя» — молодого, зрячего, с тонкими пальцами и опытом использования планшетов. Он забыл, что ключевой пользователь системы — это не он.
Для исправления просто выполнили все требования заказчика: сделали режим «Крупный шрифт» (шрифт 24px), все иконки получили текстовые подписи, свайпы отключили, навигация — только по кнопкам и убрали все анимации.
Кладовщик работает с планшетом до сих пор. Потому что система адаптировалась к нему, а не он к системе.
Как проверить себя до того, как станет поздно
Есть простой и жестокий способ избежать ошибки «фантомных пользователей». Он называется «Тест на трёх пользователей».
Возьмите три категории людей и покажите им интерфейс ДО того, как вы написали хоть одну строчку кода:
«Самый опытный» — пользователь, который знает бизнес‑процесс лучше всех, но абсолютно не знаком с IT. Просто покажите ему прототип на бумаге и спросите: «Что ты будешь делать, чтобы выполнить операцию X?» Если он начинает спрашивать, куда нажать — вы провалили дизайн.
«Самый уставший» — человек, который только что вернулся с тяжёлой смены (или пришёл после обеда, когда уровень сахара упал). Попросите его выполнить критическую операцию. Засеките время. Если потребовалось больше 30 секунд на ключевое действие — переделывайте.
«Самый далёкий» — человек, который вообще не знаком с предметной областью (например, ваш коллега‑разработчик из соседнего отдела). Если он может выполнить операцию, не зная контекста, — интерфейс интуитивен. Если нет — значит, вы опираетесь на скрытые знания пользователя, которых у него на самом деле нет.
Почему это работает
Этот тест снимает проклятие эксперта. Он заставляет вас посмотреть на систему глазами человека, который не знает вашей терминологии, находится в стрессе или спешке, имеет свои привычки и страхи и не хочет учиться, а хочет работать.
Вместо заключения
В завершении статьи вот семь принципов, которые помогут аналитику при разработки системы для пользователей, а не для себя.
Забудьте слово «должен» — вместо «пользователь должен заполнить все поля» спросите: «Что случится, если он не заполнит?» Если ничего фатального — сделайте поле опциональным.
Минимизируйте шаги — любое действие должно быть выполнено за 3 клика или меньше. Если у вас больше — вы где‑то ошиблись.
Разделяйте роли — врач на приёме и врач‑статист — это два разных пользователя. У них разные задачи, разные контексты, разные интерфейсы.
Тестируйте на бумаге — не надо писать код, чтобы понять, что интерфейс неудобен. Нарисуйте на листе, дайте пользователю и смотрите.
Спрашивайте «А что ещё?» — когда пользователь говорит, что ему нужно ввести поставку, спросите: «Что ещё вы делаете в этот момент?» Услышите про очередь в кассу, про злого водителя и про разряженный телефон.
Настройки — зло — настройки нужны только в 10% случаев. Для 90% сделайте работающий по умолчанию сценарий. Если у вас больше 5 параметров конфигурации — вы проектируете для себя, а не для пользователя.
Наблюдайте, а не спрашивайте — люди говорят одно, а делают другое. Посидите час рядом с пользователем. Увидите, как он на самом деле работает, и ваше требование «ввести 7 полей» будет выглядеть абсурдно.
Системный аналитик — это не эксперт в предметной области. Аналитик — это эксперт в том, как сделать так, чтобы эксперт в предметной области мог работать, не отвлекаясь на систему. Ваша система должна исчезнуть. Пользователь не должен о ней думать. Если он думает о кнопках — вы проиграли.
Система может выглядеть идеально на этапе проектирования, но провалиться после запуска, если аналитик не учёл реальные сценарии работы пользователей. Если вы сталкиваетесь с ситуацией, когда требования собраны, решение разработано, а бизнес всё равно недоволен результатом, важно разобраться, как находить скрытые риски ещё до начала разработки.
На открытых уроках разбираем, как системному аналитику находить риски и проектировать решения для бизнеса и пользователей:
8 сентября, 20:00. «Системный аналитик и его ценность глазами компании». Записаться
15 сентября, 20:00. «Как аналитик 1С ведет задачу от интервью до приемки: сквозной кейс интеграции с мобильным рабочим местом». Записаться
23 сентября, 20:00. «Как системному аналитику проводить архитектурное ревью и находить риски до начала разработки». Записаться
Полный список бесплатных уроков сентября смотрите в дайджесте.
