1 Usability-проектирование Dark Side of the Source Артем Мошков Технический директор SPBNET

2 Срез Веб-студии Интернет-компании Те, кто сегодня создает Корпоративные сайты; Каталоги и магазины; Новостные сайты Сюда относятся и поставщики коробочных решений. 2из 15 слайд

3 Ситуация на рынке Usability, несмотря на широкую известность, до сих пор не стала регулярной дисциплиной при разработке интернет-систем. Основное приложение – публичная часть сайтов, нацеленная на потребителей. Часто без внимания остаются: Административные разделы Внешние программные интерфейсы (API) Служебные экраны …и растут, как сорняки. 3из 15 слайд

4 Место встречи 3: служебные экраны Служебные экраны Вход/регистрация; Восстановление пароля; Корзина; Оплата; Поиск и т.д. *По важности приравниваются к административным разделам. *Это еще не административная, но уже и не публичная часть сайта. *Исполнение этих экранов критично настолько же, насколько вы оцениваете важность своей услуги. *Насколько часто служебные тексты пишут программисты и насколько часто это смешно? 4из 15 слайд

5 Место встречи 2: Внешние программные интерфейсы (API) Иногда на исполнителя нападают другие исполнители, но их взаимоотношения, равно как искусство проектирования API, мы обсуждать не будем. Да, вы знаете, программисты тоже потребляют ваш продукт. Ну хотя бы опосредованное потребление при помощи поисковых роботов и прочих агрегаторов. Могу заметить, что при нынешних тенденциях развития сети, качественное API продукта вскоре будет конкурировать с его клиентской частью. Особенное внимание стоит уделять коробочным продуктам, которые вы уже поставляете или только собираетесь. 5из 15 слайд

6 Место встречи 1: Административный интерфейс Типичные функции административных разделов: *Это едва ли не все места, в которых ЦА и есть заказчик, точнее его работник. *Место пересечения заказчика, как ЦА (со всем его спектром требований), и исполнителя. Место встречи изменить нельзя… Управление содержанием; Управление структурой; Управление дизайном; Мониторинг/SEO; Взаимодействие с аудиторией, управление; 6из 15 слайд

7 Так в чем же проблема? Заказчик выбирает продукт с его interaction одновременно с выбором исполнителя. Т.е. принимает и покупает usability в составе продукта. Нужно ориентироваться на рынке, но что происходит после приобретения? Получая экраны as is, заказчик предпочитает потратить деньги не на их адаптацию, а на учебный курс. Неудобный или нетривиальный интерфейс – отличный аргумент для ежемесячного обслуживания. А мы и рады. Такое паразитное существование процветает и тормозит прогресс обеих сторон. 7из 15 слайд

8 …Usability формируется исполнителями! Вы можете ответить себе, кто на самом деле заказывает продукт? Кто пользуется продуктом? Пользуются им как раз не исполнители, а контент- менеджеры, работники склада, служба поддержки и т.п. Насколько бы радостным и плодотворным не было сотрудничество первых, без прямого привлечения пользователей и аналитиков, качественным такой продукт будет лишь на бумаге. Пестовать usability продукта могут графические дизайнеры, программисты, менеджеры всех мастей, сам заказчик (ориентируясь на свой опыт или просто эмоции)… 8из 15 слайд

9 Решения поставки интерфейсов Реализация на базе шаблонного решения На базе коробочного решения На базе чужого решения Индивидуальная разработка Экспертное улучшение проблемных мест. Как правило, универсальные и коробочные решения ориентированы на конвейер и содержат универсальный interaction. Это выгодно для вас. Редко – для клиента. Клиенты приводят клиентов. Выводы? Все обобщенные разработки – это сочетание best practices, в которые мы свято верим. :-) Настолько ли общим является бизнес всех ваших клиентов? 9из 15 слайд

10 Контролируемые мутации При адаптации/изменении подсистемы, внесении несущественных изменений, интерфейс проявляет свою инертность. Это проблема пользователей, это также проблема исполнителя. Растет энтропия системы вообще, и интерфейсов в частности. Индивидуальные проекты – самый полный контроль. Если вы не эксперт, привлекайте. Вы отвечаете за продукт. Если вы хотите создать вокруг себя плотную сеть клиентов, вы должны отвечать. 10 из 15 слайд

11 Организация процесса/сопровождение продукта Часто проектная группа успевает все сделать только в публичной или административной части. Почему? Одни из самых ощутимых причин потери целостности продукта: Дисциплина разработчиков; Гегемония заказчика; Дефицит ресурсов (время, деньги, нервы) Объясните заказчику, как лучше решать его задачу. Вы должны это сделать, если вы цените этого клиента и дорожите будущими. Сохраняйте и закрепляйте целостность своих продуктов. 11 из 15 слайд

12 Аналитика Откуда брать данные для анализа? Вовлекайте в процесс закрепления interaction/usability не заказчика с деньгами, а будущих пользователей – для разведки боем, выявления существующих проблем и формирования карты потребностей. Учитывайте расширение продукта, увеличение объемов данных (степени свободы бизнес-модели). В пределах естества вашего продукта, разумеется. 12 из 15 слайд

13 Прототипирование Элементарное прототипирование на бумаге и карточки. Это экономит ресурсы. Создавайте и тестируйте кейсы по контракту и их отклонения (personas). Контролируйте и протоколируйте все метаморфозы: требований, программные изменения, адаптации к операционной среде. Накапливайте статистику. Не отдавайте процесс на откуп замкнутой группе разработчиков. Везение не бывает систематичным. 13 из 15 слайд

14 На ком тестировать? Начните с себя. Совсем не фееричный, но эффективный комплекс простых и дешевых методов (больше одного): Замер времени работы/числа ошибок Успешность обучения Отзывы/констатация результатов (осторожно, пожелания! будьте объективны) Практикуйте тестирование коробочных решений. Чем более дистанциирован/распространен продукт, тем дотошнее должно быть тестирование. 14 из 15 слайд

15 Артем Мошков Негенеральный (технический) директор Тел.: +7 (812)