Интерфейсы корпоративных программ (те программы, которые компании покупают для своих сотрудников) —лакомый кусочек для самоутверждения дизайнера. Всем нравится показывать как там всё технозависимо, неудобно, нелогично, какая там эстетика 15-летней давности. Да что таить, у меня и самого сохранены интерфейсные решения из нескольких, с пометкой «так делать нельзя».
Я попытаюсь рассказать всем, кто не сталкивался с этим, почему так получается. Не обещаю исчерпывающего рассказа и надеюсь, что если что-то пропущу, то кто-то допишет в комментарии.
Почему так
Покупает не пользователь
Все относительно просто, когда пользователь покупает себе программу сам. Если мне не нравится Виндоуз, я куплю Мак, если не нравится мейл.апп на маке, я куплю себе какой-то другой почтовый клиент. В корпоративном секторе не так. Пользователи (например, секретари) не выбирают себе систему документооборота. А у тех, кто покупает (например, Административный директор или ИТ-директор), другие приоритеты (↓).
Другие приоритеты
Не то, что бы всем дизайн до лампочки. Дизайн и удобство приложения вообще стоя́т не очень высоко. Примерно после решения проблемы, технологической платфомы, стоимости лицензии и внедрения, поддерживаемости, интегрируемости в платформу, стоимости лицензий и внедрения, наличия хорошего внедренца.
Фичелисты побеждают
При покупке продукты часто сравнивают по фичелистам: списку возможностей. Менеджер у клиента составляет такую табличку, пробегается по альтернативам и ставит галочки. Удобный интерфейс — одна строчка, а «наличие поддержки протоколов smtp, imap, pop3, exchange» — сразу четыре строки с галочками. Поэтому часто функции делают очень простыми, чтобы заявить наличие галочки.
Компании-разработчики — технологические
Бывают компании дизайнерские, а бывают технологические. Когда возникает конфликт технологии и дизайна Эппл скорей поменяет технологию, чтобы выдержать дизайн, Гугл сменит дизайн, чтобы не менять технологию. В разработке корпоративных продуктов технология часто побеждает дизайн.
Легаси в технологиях
Легаси — профессиональный жаргонизм, которым обозначают старое технологическое наследство. Технологическая основа продуктов часто старая: у многих основные компоненты были написаны 10 или более лет назад. За эти 10 лет к ним с разной успешностью применяли новые на тот момент фреймворки и языки. Такой зоопарк приводит к тому, что современные решения приделать тяжело, удобный поиск не сделать, потому что база не той схемы, современные паттерны использовать нельзя, потому что Джава 1.4 (это старая).
У клиента тоже могут быть старое оборудование и программы. Они разрабатывались ещё для компьютеров с Виндоуз ХР и работают с оборудованием через СОМ-порт. Новые программы должны работать не хуже имеющихся, поэтому вынуждены поддерживать старую операционную систему, браузер, оборудование, этот старый порт и уметь печатать имеющимися матричными принтерами. Как только упоминаешь, что приложение должно работать на ИЕ 6.0, все фронтендеры сразу грустнеют.
Продукт-конструктор выгоден интегратору
Корпоративные продукты редко продаются от вендора напрямую — это сложно. Разработчик продает через реселлеров (интеграторов). Реселлеры зарабатывают на комиссии за лицензии, но основной их зароботок — проекты по внедрению. Проданный продукт надо установить, отладить, настроить отчетность и сбор данных, написать инструкции и обучить пользователей, а потом ещё поддерживать и решать проблемы.
Продукт с большим количеством разнообразных (часто ненужных) настроек более интересен интегратору — его можно дороже внедрить. Простой продукт, который не требует настройки и сразу работает не даст интеграторам заработать, а без интеграторов разработчик не сможет достучаться до клиентов.
Сложно найти дизайнеров
Дизайнеры предпочитают сайты, а не системы документооборота или CRM. CRM обычно непрезентабельна, сложна, её нельзя было выложить на биханс или дриббл. Иногда находятся дизайнеры, которых это не пугает. Часть из них сразу тухнут от сложности систем и уровня абстракции.
А те, что находятся со временем уходят во внутренний Таиланд.
Фичи неконтролируемо растут
Большой, сочный закачик (условный, Росгаз или Нефтьпром) легко продавит нужное ему решение даже в коробочный продукт. Продукт раздуют функцией, нужной только Росгазу. Если таких заказчиков несколько, но получается зоопарк, плохо живущих друг с другом функций.
В любой непонятной ситуации добавляется параметр
Т. к. функций много (см ↑) то в любой непонятной ситуации проще не принимать решение и сказать «давайте сделаем настройку, кому надо — настроят под себя». Излишние параметры делают продукт грузным, неповоротливым и сложным.
Менять что-то страшно и дорого
Часто многие понимают необходимость изменений, но менять большой продукт сильно страшновато, да ещё и дорого. «Сделать красиво и удобно» часто не является достаточной причиной для больших изменений.
Новые решения могут быть слишком смелы
Показывать пароль в открытом виде — хорошо и правильно, но такое решение идет со скрипом на всех уровнях: дизайн, согласование дизайна, в разработке, в тестировании, и даже у пользователей.
Какая-то безрадостная картина выходит. Расскажу что помогает и что можно делать.
Что помогает
Сервисы вокруг приучают к хорошему
Клиенты, пользователи и менеджеры привыкают к удобству почты, телеграма и фейсбука. После того, как они узнали как аттачить файл перетаскиванием, они не хотят обратно бегать по папкам и выбирать файлы по одному. Люди, воспитанные айфоном будут просить себе рабочий айфон, а не блекберри.
Конкуренция
Рано или поздно появляются компании, которые делают продукты не хуже по функциональности, но лучше по дизайну. Со временем забивать на дизайн можно будет всё меньше и меньше, иначе съедят конкуренты.
В новый релиз можно включить и шепотку дизайна
Периодически бывают большие релизы продукта. В них смена технологии, сильные функциональные изменения и иногда даже переосмысление продукта. В этот момент в них можно подмахнуть и редизайн. Почти всегда это воспринимается нормально. Кроме всего прочего, редизайн помогает пользователям увидеть эти сами новые функции, почувствовать, что продукт стал лучше и новей.
Что делать
Не сдаваться и делать хорошо
Важно делать настолько хорошо, насколько можешь, даже если вокруг всем плохо — ок.
Продавать идею менеджеру продукта
Если объяснить менеджеру пользу хорошего дизайна для клиента и его пользователей, то менеджер встанет на вашу сторону, скорректирует планы, заложит дополнительное время и найдет способ это сделать.
Продавать идею заказчику
Если не удается продать идею менеджеру, иногда можно продать её заказчику. Он загорится, а с желаниями заказчиков обычно считаются.
Договариваться с тестировщиками
Можно зайти с обратной стороны: договориться с тестировщиками или внедренцами чтобы завели баг (сообщение об ошибке). Ошибки часто чинят в первую очередь, даже если они не очень критичны. Можно воспользоваться этой особенностью.
Договариваться с разработчиками
Если разработчикам не всё равно, что они делают, то иногда договориться в обход всех прямо с ними. Когда уже сделано, и менеджеры, и тестировщики, и клиент сразу понимают, что так и надо было. Согласиться на сделанное легко.
Переводить на язык бизнеса
Если хороший для пользователя дизайн перевести на язык бизнеса, то его покупают охотней. Не «удобней заводить задачи», а «понадобится на 25% меньше операторов».
Делать концепты
Когда все заранее знают, что это концепт, проще относятся к более смелым решениям. Да и дизайнеру проще принимать более смелые решения. А если концепт удаётся, то у всех участников появляется большее желание его сделать. Эдакая визуализация мечты.
Ссылки по теме:
http://www.lowkee.com/all/sever/
Что забыл? Где не прав? Что думаете?
![[Видео]](http://mikeozornin.ru/blog/themes/my/video-icon.png){kind=icon}
— видео.
