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

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

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

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

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

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

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

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

8 User Interface

9 User Experience

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

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

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

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

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

15

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

17 Employee by Function

18

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

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

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

22 Featuritis vs. the Happy User Peak (

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

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

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

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

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

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

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

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

31 Tree maps

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

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

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

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

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

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

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

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

40 User-oriented development

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

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

43 Questions?

44 The End