User Experience в сложных enterprise-продуктах Константин Романов Tbricks AB

О чем пойдет речь Ease of Use/ UX с точки зрения бизнеса Features vs Experience Трудности user-oriented development

Tbricks AB Создана в 2006 году Orc Software staff Офисы в Стокгольме и Петербурге Система автоматической торговли Tbricks Genesis Performance Ease of use

Разные Ориентации Experience Features

Разные ориентации Features Microsoft (Windows, Office, WM) Smart phones Sony Зеркальные фотокамеры Experience Apple (iPod, iPhone, Mac, iTunes, iWork) Nintendo Wii Компактные цифровые камеры

Features VS Experience Features Упор на количество функциональности Упор на СУЩЕСТВОВАНИЕ функциональности в продукте Experience Концентрация на ограниченном наборе функциональности Упор на удобство, простоту, WOW-эффект

UI, UX User Interface, User Interaction – Как использовать систему чтобы выполнить задачу – Естественные способ взаимодействия – Удобство, эффективность, эргономика User Experience – User satisfaction – User happiness – Polishes, внимание к деталям, excellence – Demo

User Interface

User Experience

Сложные enterprise продукты Исторически Feature-oriented Считается что профессионалам нужны features и полная настройка Считается что от сложной системы ожидается сложность развертывания и настройки Многие продукты feature-rich из-за потери фокуса Information Overload

Пользователи системы Трейдеры Программисты Системные администраторы

Где происходит взаимодействие с пользователем Рабочее место трейдера Frameworks/API Система развертывания и администрирования

Зачем двигаться к сторону User Experience?

Откуда компания берет деньги?

Зачем двигаться к сторону User Experience? Снижение затрат на поддержку – Исторически – основная причина Поддержка продаж Удержание клиентов Уникальное позиционирование на рынке

Employee by Function

Support Является частью продукта с точки зрения клиента – Качество support – качество продукта C ростом числа клиентов увеличивается нагрузка C увеличением функциональности увеличивается нагрузка С усложнением системы увеличивается нагрузка Численность support растет с ростом количества клиентов

На что тратятся ресурсы support Обучение новых пользователей Обучение новой функциональности Помощь в развертывании и настройке Troubleshooting

Обучение: проблемы Users dont read manuals Сложность системы Огромный набор функций Боязнь изучать самостоятельно – Computer literacy Пользователям неизвестно о новых функциях – Неэффективное использование системы – Недооценка ее возможностей – Повышенный риск перехода на другую систему Frameworks / APIs Медленный старт

Featuritis vs. the Happy User Peak (

Обучение: решения Интуитивный интерфейс Discoverability, поощрение изучения – consistency – Безопасность (подтверждения, undo…) – Изучение через эксперименты – Не только UI, но и Frameworks / API Простота Помощь – Не стоит ориентироваться только на manual – Instant help – Tooltips/super-tips Помогающие сообщения об ошибках – Почему не получилось? – Что сделать чтобы получилось? – Как делать можно?

Безопасность ошибка брокера Mizuho TSE. Потери компании 350 MUSD. Президент TSE ушел в отставку ошибка брокера Daiwa Securities. Потери 4.3 MUSD ошибка трейдера Тройка- Диалог. Потери 3.9 MUSD.

Развертывание и настройка: проблемы Распределенные системы Резервное копирование и восстановление Необходимость настройки сторонних компонент (базы данных) – БОльшие требования к администраторам Трудность первоначальной настройки Сложность оптимальной настройки Трудности обновления (upgrade)

Помощь в развертывании и настройке Zero configuration Удобные средства администрирования Сокрытие сторонних компонент – Базы данных Упрощения upgrade – Упрощение процедуры уменьшает вероятность проблем – Безопасность upgrade (Windows System Restore) User-friendly восстановление – Пользователь не обязан знать когда нужно делать backup

Troubleshooting: проблемы Пользователям сложно описать проблему – Описание в своих терминах Пользователи сообщают далеко не о всех проблемах – То что не дает работать – То что раздражает Пользователи забывают сообщать о проблемах – Некогда Трудности локализации проблемы Негатив Пользователи не заинтересованы в сообщении о проблемах – У них есть более важные занятия

Troubleshooting Системы мониторинга состояния системы Error reporting / user feedback Содержательные сообщения об ошибках – Что произошло? – Что делать? – Что нужно сообщить разработчикам? Сокрытие проблем – Если система сделала workaround – не обязательно сообщать о проблеме пользователю

Information Overload: проблемы Действительно много информации – Тысячи и десятки тысяч работающих стратегий Большая скорость обновления Устаревшие методы визуализации Устаревшие концепции взаимодействия Отвлечение внимания на несущественные в данный момент вещи

Information Overload: решения Удаление того что не несет полезной информации Визуальный акцент на полезной в данный момент информации – Подсветка интересующих обновлений и значений – Conditional formatting Другие методы визуализации – Tree maps

Tree maps

Продажи/маркетинг Позиционирование Поддержка новых продаж Удержание пользователей Бренд

Позиционирование

Большинство делает упор только на: – Performance – Scalability – Многоплатформенность – Функциональная насыщенность Выборы – дорогое удовольствие – Head-to-head: максимум 1-2 конкурента в финале – Увеличивает шансы попасть в финал

Поддержка продаж End-users VS demo/buying users – Иногда выбирают одни, а используют - другие Demo – Demo features – Wow effect Удовлетворенные пользователи – внештатные sales – Помогают проникнуть к потенциальным клиентам End-users сегодня – buying users завтра

Удержание клиентов Довольные конечные пользователи не будут требовать замены системы Даже при наличии проблем ощущение удобства использования сузит количество рассматриваемых конкурентов

Чего бояться? Ожидания повышаются – Apple (iPhone, iPod, MacOS) Чрезмерное упрощение Wow effect / Demo вместо Ease of use – Только краткосрочная легкость, потом пользователи упираются в стену – Strategy scripting (write-only) Непонимание ожиданий Культурные различия – В некоторых культурах усложненность ассоциируется с качеством и статусом

Ожидания It just works! Работает так как хочет пользователь Не раздражает Не унижает – Приписывание проблем системы себе Не оставляет в беспомощном состоянии –боязнь монстра – User in control Люди не артикулируют свои ожидания – не значит что их нет

Что может раздражать Невозможность работать – Падения системы – Ошибки без возможности их обойти Постоянно нелогичное с точки зрения пользователя поведение Медленная реакция на действия Визуальные артефакты – Это рабочее место человека Невозможность полагаться на систему – Недостаточная обратная связь – Введение пользователя в заблуждение

User-oriented development

UI Refactoring – Try/discard – Выбрасывание функциональности – Как сделать еще проще? – Сложности с автоматическим тестированием Не все программисты подходят – Вопрос психологии нежели компетенции – Чем-то похожи на business-people и support

User-oriented development II При тех же затратах ресурсов user-oriented development приведет к меньшему количеству функциональности – Если исключить клинические случаи неюзабельных системы Большая необходимость фокуса (не делать Word) – Разграничения функциональности – Editions

Questions?

The End