UX-исследование пользователей перед переписыванием legacy-приложения на VB6 и WinForms: методы, метрики, чек-лист

Когда старую программу на VB6 или WinForms решают переписать, пользователи просят одного: «только ничего не меняйте». За этой фразой стоят годы привычки. Оператор вводит накладную, не глядя на экран, нажимает F9 вместо кнопки «Провести» и держит рядом Excel-файл, без которого половина работы не делается. Ничего из этого нет в документации, и почти ничего не видно в коде. Поэтому UX-исследование пользователей до начала переписывания — это способ узнать, как на самом деле работают с программой, и не сломать это в новой системе.

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

Ниже — чем исследование legacy-системы отличается от обычного UX-исследования, какие методы дают результат, как собрать статистику прямо из старой программы, как обработать находки и проверить новый интерфейс до разработки. Если интерфейс нужно освежить без полного переписывания, сначала прочитайте разбор о том, как обновить интерфейс WinForms и VB6 без переписывания.

Зачем UX-исследование, если нужно «сделать так же»?

UX-исследование нужно, чтобы заранее узнать, какие привычные действия нельзя потерять в новом интерфейсе. Требование «так же» кажется понятным, пока не начинается разработка. Новый интерфейс неизбежно будет другим: другой стек, другие контролы, часто браузер вместо окна Windows. Вопрос не в том, менять ли интерфейс, а в том, что в нём нельзя потерять. Ответ на него знают пользователи, но сформулировать не могут: привычные действия выполняются автоматически и в интервью не всплывают.

Без исследования переписывание обычно заканчивается одним из трёх сценариев:

• Скорость работы падает. Новый экран красивее, но ввод документа занимает 90 секунд вместо 40, потому что пропали горячие клавиши и привычный порядок перехода по полям. Для отдела из 15 операторов по 60 документов в день это 50 секунд × 900 документов, то есть около 12 часов рабочего времени ежедневно.
• Пользователи возвращаются к старой программе. Если её не отключили, люди тихо продолжают работать в ней, а новая система наполняется наполовину.
• Всплывают скрытые сценарии. Через месяц после запуска выясняется, что склад каждую пятницу выгружал остатки через «секретную» комбинацию клавиш, о которой никто не сказал.

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

Чем исследование legacy-системы отличается от обычного UX-исследования?

Классическое UX-исследование чаще проводят для нового продукта или сайта: ищут потребности, проверяют гипотезы, тестируют прототипы на людях, которые продукт ещё не видели. С корпоративной программой, которой пользуются 10–20 лет, всё наоборот.

Отсюда практический вывод: в legacy-проекте основной метод — наблюдение за реальной работой, а не опрос. И у исследования две аудитории: опытные сотрудники, которым важна скорость, и новички, которым старый интерфейс даётся тяжело. Новый интерфейс должен устроить обе группы.

Какие методы исследования дают результат?

Для корпоративной системы хватает пяти методов. Их можно провести за три–пять недель параллельно с обследованием кода.

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

Как наблюдать за работой пользователей и что фиксировать?

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

Что записывать во время наблюдения

1. Горячие клавиши и порядок полей. Какие комбинации используются, в каком порядке Tab переходит по полям, где пользователь нажимает Enter вместо Tab. Это самые хрупкие привычки, и их проще всего потерять.
2. Обходные пути. Excel-таблицы рядом с программой, бумажные журналы, стикеры с кодами на мониторе, копирование данных через буфер обмена между окнами. Каждый обходной путь — признак того, что программа чего-то не умеет.
3. Переключения между окнами. Сколько форм открыто одновременно, как пользователь сравнивает данные из двух мест. Если оператор держит открытыми три окна, новый интерфейс с одной вкладкой станет для него шагом назад.
4. Плотность информации. Сколько строк и колонок нужно видеть сразу. Опытные пользователи часто предпочитают плотный грид «как в Excel», а не просторные карточки.
5. Ошибки и исправления. Где человек возвращается назад, отменяет действие, перепроверяет. Это кандидаты на улучшение.
6. Время операций. Засеките ключевые сценарии секундомером: ввод документа, поиск клиента, печать комплекта. Эти цифры станут базой для сравнения с новой системой.

Как оформить записи наблюдений

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

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

Как собрать статистику использования из самой программы?

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

Для VB6 достаточно общего модуля, который пишет строку в файл на сетевой папке, и вызова из Form_Load каждой формы и из обработчиков печати отчётов:

Option Explicit
Private Const LOG_DIR As String = "\\fileserver\usage$\"

Public Sub LogUsage(ByVal objName As String, ByVal action As String)
    Dim f As Integer
    On Error GoTo Done
    f = FreeFile
    Open LOG_DIR & Environ$("COMPUTERNAME") & ".log" For Append As #f
    Print #f, Format$(Now, "yyyy-mm-dd hh:nn:ss") & vbTab & _
              Environ$("USERNAME") & vbTab & objName & vbTab & action
    Close #f
Done:
End Sub

' В каждой форме:
Private Sub Form_Load()
    LogUsage Me.Name, "open"
End Sub

Обработчик ошибок здесь обязателен: если сетевая папка недоступна, программа не должна падать из-за журнала. Отдельный файл на каждый компьютер избавляет от конфликтов записи. В VB.NET то же делается через общий базовый класс формы с переопределённым OnShown или через подписку на события в ApplicationEvents.vb; для записи удобно использовать стандартный механизм трассировки — класс System.Diagnostics.Trace.

Если нужно понять, какие горячие клавиши используются, включите у главных форм KeyPreview = True и пишите в журнал комбинации с Ctrl, Alt и функциональными клавишами. Сами вводимые значения не записывайте: журнал должен содержать только имена форм, действий и клавиш. Имена пользователей — это персональные данные, поэтому сотрудников нужно уведомить о сборе, а после анализа журнал обезличить или удалить.

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

Как провести интервью и не услышать только «оставьте всё как есть»?

Интервью проводят после наблюдения, когда уже есть конкретные вопросы. Общие вопросы («что улучшить?») дают общие ответы. Работают вопросы о конкретных событиях и действиях.

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

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

Как превратить находки в требования к новому интерфейсу?

Сырые записи наблюдений и интервью нужно свести в три артефакта, которые передаются дизайнерам и в ТЗ.

1. Карта сценариев. Для каждой роли — список операций с частотой, временем выполнения, задействованными формами и обходными путями. Пример: «Оформить отгрузку — 60 раз в день, 45 секунд, формы Накладная и Остатки, обходной путь — проверка резерва в Excel».
2. Реестр привычек. Всё, что нужно сохранить как есть: горячие клавиши, порядок полей, автоподстановка последнего значения, плотность грида, возможность открыть два документа рядом. Каждая строка — с указанием, кто и как часто этим пользуется.
3. Матрица решений. По каждой находке — одно из четырёх решений: сохранить, улучшить, автоматизировать, убрать.

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

Как проверить новый интерфейс до разработки?

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

• Пять участников на сценарий. Для поиска основных проблем этого достаточно; аргументы разобраны в статье о тестировании на пяти пользователях. Для каждой роли нужна своя пятёрка.
• Реальные данные. Прототип с данными «Иван Иванов, товар 1» не покажет, помещаются ли длинные наименования и как выглядит грид на 300 строк. Возьмите обезличенную выгрузку из боевой базы.
• Клавиатура, а не только мышь. Если прототип нельзя пройти с клавиатуры, проверить главное — скорость эксперта — не получится. Для ключевых экранов делайте прототип в коде, а не только в графическом редакторе.
• Новички отдельно. Дайте сценарий сотруднику, который программу почти не знает. Если в прототипе он справляется быстрее, чем в старом интерфейсе, обучение станет дешевле.

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

Какие метрики зафиксировать до и после переписывания?

Цифры, снятые до начала работ, — единственный способ доказать, что новая система не хуже старой. Без них обсуждение на приёмке сводится к ощущениям.

Эти же метрики стоит снять через месяц после запуска каждого модуля. Если время операции выросло, это сигнал вернуться к реестру привычек и посмотреть, что потерялось.

Кто проводит исследование и сколько оно длится?

Минимальная команда — исследователь или UX-дизайнер, аналитик, который знает предметную область, и владелец процесса со стороны заказчика. Исследователь ведёт наблюдения и интервью, аналитик связывает находки с кодом и данными, владелец процесса принимает решения по матрице. Разработчики старой программы полезны как консультанты: они объясняют, почему форма устроена именно так, и добавляют журнал использования.

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

Типичные ошибки UX-исследования перед переписыванием

• Только интервью без наблюдения. Люди не рассказывают о том, что делают автоматически. Половина важных привычек всплывает только у рабочего места.
• Говорить только с руководителями. Руководитель знает, как процесс должен работать, а оператор — как он работает на самом деле.
• Исследование после дизайна. Если макеты уже нарисованы, исследование превращается в поиск подтверждений. Его место — до проектирования экранов.
• Перенос форм один в один. Копирование старого окна в новый стек сохраняет и все его проблемы. Сохранять нужно привычные действия, а не расположение каждой кнопки.
• Игнорировать обходные пути. Excel рядом с программой — не прихоть пользователя, а требование, которое не попало в систему.
• Нет базовых метрик. Без замеров «до» нельзя доказать, что стало лучше, и нельзя заметить, что стало хуже.

Чек-лист UX-исследования перед переписыванием

1. определены роли пользователей и по 5–8 участников на каждую;
2. проведено наблюдение на рабочих местах в обычный и пиковый день;
3. в старую программу добавлен журнал открытия форм и отчётов, собрано не меньше месяца данных;
4. проанализированы обращения в поддержку за последний год;
5. проведены интервью с опытными сотрудниками, новичками, руководителями и наставниками;
6. составлены карта сценариев, реестр привычек и матрица решений;
7. решения «убрать» и «улучшить» согласованы владельцем процесса и внесены в реестр отличий ТЗ;
8. сняты базовые метрики: время операций, число действий, ошибки, обходные пути;
9. прототип ключевых экранов проверен в сравнении со старой программой на реальных данных;
10. запланирован повторный замер метрик через месяц после запуска каждого модуля.

Как это делают сегодня

Вопросы и ответы об UX-исследовании legacy-приложения