Показаны сообщения с ярлыком usability. Показать все сообщения
Показаны сообщения с ярлыком usability. Показать все сообщения

среда, 16 ноября 2011 г.

Мини-отчет по #wudru.

В прошедшие выходные прошел World Usability Day по русски то-бишь wud.ru.

Прошло вполне себе живенько и в целом не плохо)
Заметил за собой, что не хотелось слушать всего лишь пару докладов - большое достижение для любой конференции)
Организационно устроились хорошо в принципе 1 большой класс + комнатка для мастер-классов - интересный формат, во время мастер классов в нее забивалось больше, чем нужно людей, поэтому она могла быть еще помельче =)

Первый доклад помню вобще плохо (искренее соболезную докладчику, т.к. все еще наверно сонные были пока пришли =)), ну и да ладно - не запомнилось - значит было не интересно =)

Юра Ветров рассказал ОЧЕНЬ быстро, я хоть в теме и до этого был про design thinking (т.к. участвовал в мастер-классе на ЛАФе) доклад было слушать довольно сложно, и думаю стороннему человеку услышавшему его в первый раз было б вобще не понятно о чем это.

Доклад Максима Ткачука вроде был и интересен хотя бы тем, что в нем был новый для меня экскурс в историю развития дизайна с его цвет-форма-добавочная стоимость).
Но решил, что в принципе лучше послушаю, как Дима Зимин и Мельников Владимир проведут свой мастер-класс по Design Thinking. В принципе их формат слегка отличался от того в чем уже участвовал ранее потому все равно было интересно освежить в памяти что, к чему и зачем. Шли бодро по таймеру и даже в меру понятно для участников, заодно заставили всех участников там еще и перезнакомиться, что несомненно тоже плюс) 


Убег от них на 4 шаге великой эпопеи изобретения телевиденья будущего, и ушел послушать Алишера Якупова из Одноклассников с его "Эффектом модерации". 


Алишер рассказывать умеет и видимо любит: весело, задорно с объяснением -  что и почему, и с прокачанным скиллом "Dress your numbers" прям, как по книжке про секреты презентации Джобса =) 
Рассказывал как создали игру-модерацию фоток с очками-деньгами, на покупку подарочков\сервисов "5+" и etc., что в итоге это дало еще больший положительный эффекта, т.к. модеры, что дали подарочки, в ответ тоже получали подарочки, т.к. подарки обязывали отвечать взаимностью - получался двойной профит - отмодеренные фотки и увеличение покупок подарков и сервисов, сливали они эти очки, через аукционы чтоб людям было на что их тратить + не было особой инфляции этой самой внутренней валюты, в общем один из полезнейших и интереснейших докладов был)


После Денси Бесков рассказывал о том, кто есть продукт менеджер, откуда он берется, что делает, и какими KPI измеряется и почему юзабелист хорошая кандидатура на его становление) С одной стороны он конечно слайды читал, за что самой презентации я бы сказал "ни зачет" =) С другой стороны тема участникам была интересна и потом вызывала много вопросов. Денис рассказал про широко известный в узких кругах "Pragmatic Marketing Framework" и что чтоб вырастить продукт менеджера говорят надо лет 10, но в принципе сам считает, что лет 3х достаточно) В общем тоже послушать интересно было) 


Потом был обед в результате которого пропустил доклад Стаса Фомина о чем жалею, т.к.вещи по всему собирался рассказывать интересные)  С обеда вернулся на Андрея Бибечева с Его "NUI(Natural User Interface)" было смешно и весело  вживую показывал интерфейс на Кинекте, листал слайды руками, показывал скелет человека, которым управлялся компьютер. Пытался голосом управлять но зафейлил, да и так смешно было =) За ними наверно будущее интерфейсов и думаю тема еще наберет популярность, но пока технологии не сильно развились еще можно расслабиться и не париться, над созданием гайдлайнов к Кинекту =)

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

Потом был доклад Маргариты Титовой про опыт использования удаленных пользователей(т.е. сервисов с ими ссамыми) для тестирования интерфейсов, слушал правда в пол-уха,т.к. иногда
бегал в зал мастер-классов послушать о чем там говорят: а там тоже говорили от "о дизайне, как маянезике" до "приорететы - `фичи` версус `простота`". У Маргариты, что понравилось доклад был о реальном опыте и с картинками из Большого Взрыва(как ни странно достаточно удачно подобранными) и хоть наверно и без откровений (а может и с ними, но я пропустил), но тоже интересный =)

Предпоследним был доклад Константина Кичинского про дизайн Windows Phone 7, как ни странно, хотя доклад и был так сказать "евангельский" наверно один из немногих докладов про действительно интерфейс и те или иные решения, к которым пришла команда разработки телефона по мере его эволюции. О том, как надо и как не надо делать приложения под виндовс-фон (хинт - айфоновский дизайн копировать не надо). Привел примеры как хорошо, и как плоха, и обьяснил почему это так. Думаю виндовс-фон тоже найдет своих любителей, как айфон с андройдами т.к. интересные идеи и решения у них есть. Самый "интерфейсный" доклад из всего потока, если так подумать =)


Последний доклад и афтерпати к сожалению пропустил, т.к. пришлось бежать по своим делам. 


Но в целом не жалею, что пошел и провел время с пользой =) В отличии от некоторых конференций, в которых уже удалось поучаствовать. 


Надеюсь увидеть всех вас в следующем году в тоже время в каком-нибудь месте =) 

среда, 18 мая 2011 г.

Психбольница и ты %username%!

Не далее, как в прошлые выходные осилил прочесть "Психбольница в руках пациентов" Алана  Купера. Замечательное чтиво по поводу простоты, сложности и создания именно того, что нужно пользователю.
Чтиво написано простым и понятным языком, и хотя Автор усиленно кроет программистов-пациентов (к коим и я себе причисляю) все равно оставляет неизгладимое впечатление собственного просветления.

Attention! Многа букав!

О чем же оно:
Понял, как жестоко я был не прав всю свою программерскую жизнь=)

Вкратце книгу можно бы  изложить так : за забором функций и ограничения реализации мы теряем из виду конечную цель производства самого продукта.

Для подтверждения хочется привести пример из книги:
Для нашего зациклившегося на функциях мира мысль, наверное, непривычная - вы не достигнете своих целей, используя набор функций как инструмент. Можно замечательно реализовать все функции из утвержденного набора и все равно попасть в беду. 
Для доказательства этого тезиса проектировщик взаимодействий Скотт Мак-Грегор на своих занятиях использует вот такой замечательный тест. Он описывает продукт с помощью перечня функций и просит слушателей записать, что это за продукт, как только они догадаются. Он перечисляет:
1) двигатель внутреннего сгорания;
2) четыре колеса с резиновыми покрышками;
3) трансмиссия, связывающая двигатель с ведущими колесами;
4) трансмиссия и Двигатель смонтированы на ходовой части;
5) рулевое колесо.

На этот момент времени каждый слушатель уже записал, что это автомобиль, но здесь Скотт перестает описывать особенности продукта и вместо этого называет пару задач потенциального пользователя:
6) быстро и легко срезает траву;
7) на этом удобно сидеть.
На основании пяти функций-подсказок ни один слушатель не может догадаться, что это минитрактор-газонокосилка. Очевидно, что цели пользователя намного более наглядны, чем набор функций продукта.
Читал и плакал! ;)
Плакаль
Уж настолько сильно книга пересекается с тем, что приходилось создавать самому или испытывать на собственной шкуре, как пользователю какого-нибудь доморощенного продукта.

Сам использую и зачастую создаю программное обеспечение с раздражающими интерфейсами (а ведь еще Скотт Беркун писал что раздражать людей - последнее дело).

Сам использую ПО, которое презираю - но приходиться терпеть, но т.к. я его использую для работы, смиряюсь и думаю, что так и должно быть и, что оно должно быть таким неудобным и мерзким.

Помимо казалось бы банальные советов не использовать неудобное ПО, которое вам не нравиться. Но его так же не следует Создавать, т.к. в итоге и оно выйдет боком, опять же процитирую:
Дороже разработки ПО обходится только разработка плохого ПО.
Программисты стоят дорого, а программисты, сидящие без дела в ожидании завершения проектирования, крайне раздражают руководителей.
Глупо же, думает руководитель, что программисты сидят и ждут, хотя могли бы программировать. Заставить программистов работать до завершения этапа проектирования - ложная экономия. Когда появляется программный код, процесс уже не остановить, поэтому проектировщики вынуждены реагировать на потребности программистов, а должно быть наоборот.
И вправду, глупо заставлять своих программистов ждать, а ведь очень просто сделать так, чтобы они не сидели без дела - надо, чтобы проектировщики взаимодействия планировали следующий продукт или релиз параллельно с созданием текущего продукта или релиза.

Ах, ну разве вам не знакомо: "Давайте еще одну фичу сделаем программисты\верстальщики\еще кто-то сидят без дела!". Так и хочется вот в этом месте передать привет, тем от кого я слышал эти фразы, но сдержусь)

Не только об интерфейсах:
Вот с чего бы юзабилисту рассуждать об архитектуре и дизайне ПО ? Ведь интерфейс - он от бизнес логики MVC отделен или еще как. Но нет и тему рефакторинга и переписывания заново затрагивают:
При каждом изменении программы - будь то исправление ошибок или добавление функций - появляются новые рубцы. Именно поэтому программы следует выбрасывать и полностью переписывать каждые пару десятков лет. Рубцовая ткань с течением времени становится настолько толстой, что препятствует нормальной работе.
Типичный представитель
 10 летнего ПО =) 
Читал и чувствовал боль и искреннее понимание.

Сейчас приходиться и в прошлом приходилось работать с 5-10 летними программными монстрами, которые имеют несколько слоев кода написанных в разных стилях, пару разных слоев абстракции Бд и ТЫСЯЧИ хаков, чтоб поддержать еще и вот эту логику.

Эдакий мясной рубцовый-мутант =)

То же самое относиться и к использованию прототипов в качестве основы для будущего по (ну жалко же выбрасывать!).
Только тут вы сразу начинаете с нежизнеспособного мутанта с 10ю поддерживающими его костылями.
Это кстати можно сказать обратная сторона ажайл-разработки, как только показана первая РАБОЧАЯ версия программы, выкинуть и переписать ее уже будет сложно.

Так что :
Скрытые издержки проекта по разработке программного обеспечения, даже при опытном руководстве, достаточно велики, чтобы даже Дональд Трамп задумался. Гонки на яхтах и пристрастие к наркотикам в долгосрочной перспективе обходятся дешевле, чем неконтролируемое создание программного обеспечения.
Все то, что я уже успел написать это одна двадцатая всех идей книги. Пока читал буквально разорвал ее на цитаты(честно-честно накопипастил себе десяток страниц цитат и мыслей )) 
Уж больно они точны и хороши. 

Лучший способ сделать программу дружелюбной к пользователя поставить на коробке штамп "USER FRIENDLY".
Зачастую в составляющей программы заинтересовано 3 стороны:
бизнес - "продукт овнер", тот кто заинтересован на ней навариться,
технари - "тестеры, бэкэндеры, фронтэндеры", те кто ее разрабатывают,
проектировщики\юзабелисты, те кто предоставляют голос пользователя.
Так вот для успешного продукта не достаточно только первых и вторых, такой продукт может продаваться и быть монополистом на рынке, но как только придет конкурент который позаботиться о пользователе, так и вашему продукту настанет крышка.


Как пример приводиться 3 компании: Novell, Microsoft & Apple.

  • Novell -  была монополистом на рынке локальных сетей, но как только появилось чуть-менее геморройное  для настройки по и оборудование для локальных сетей она стухла и ушла с доминирующих позиций.
  • Microsoft  - многие плюются на него но пользуются его продуктам, т.к. выбора - нет, но победить его пока не кому.
  • Apple - какое-то время переживала феерический кризис, но из-за ориентации на интерфейс и пользователей выжила благодаря поддержки лояльных пользователей и теперь снова на коне.


Programmers VS Users

Красной линией по всей книге идет черта: позволять программистам проектировать софт - не правильно. 
Так как программист это Homo logicus, а не обычный Homo sapiens.
Мы - программисты отличаемся от обычных людей по 4 важным пунктам:
  • Программисты пожертвуют простотой ради контроля. 
    • Мы предпочтем более но сложную, но понятную систему магическому "черному" ящику.
    • Для хомо логикус контроль - цель, тогда как сложность - просто цена, которую они готовы платить за достижение цели.
  • Обменяют успех на понимание.
    • Хомо логикус не может устоять перед тягой познания - он просто обязав узнать, как работают вещи. Хомо сапиенс же, напротив, стремится к достижению успеха.
    • Программистам знакомо желание добиться успеха, но они часто принимают провал как цену, уплаченную за понимание.
  • Они сосредотачиваются на исключительных ситуациях вместо того, чтобы сосредоточиться на типичных. 
    • Нужно обработать и этот возможный вариант! (с) Я, более 1000 раз за всю свою жизнь
  • И, наконец, ведут себя грубо и прямолинейно, как быки.
      Типичный программист

    • Мы смотрим свысока на тех, кто не способен разобраться в этом не совсем интуитивном функционале: 
      • Ну что за идиот! В мануале ж все написано!
    • Кто смотрел Футураму ?) 
      • Кому (из программистов) НЕ нравиться Бендер ?) 
      • Всем нравиться! 
      • Дык Бендер это сферический программист в вакууме!
      • Логичный (робот же), приямолинейный (честый =)) и грубый =)
Подпишусь под каждым пунктом!


Итого: mustread!

Чтение такой не совсем профильной литературы раскрывает чакры и мозг в нужную сторону и помогает взглянуть на то, чем ты занимаешься с другой стороны. 

Ладно пожалуй хватит пересказывать книгу, должна же быть у вас мотивация прочитать ее. В добавок о том, о чем я уже рассказал в ней раскрываются еще такие темы, как:
  • культура программирования 
  • повторное использование кода, и почему это плохо
  • как мотивировать разработчиков на создание простых и понятных для людей, но сложных в реализации интерфейсов.
  • почему программист не может быть хорошим проектировщиком (подсказка: противоречие интересов, см. пункт выше)
  • как сделать меньше, но лучше
  • личные и корпоративные цели пользователей при работе с программой
  • о тяжелой судьбе проектировщиков и факторе "это ж очевидно"
  • о юзабелити-тестировании, итерациях, документации, общем словаре и всех-всех-всех ... 
А так же главные фичи книги, средство избавление от всех болезней, ответ на главный вопрос жизни, вселенной и всего такого, работающие практики: 
Целе-ориентированное проектирование и Персоны
Если вы вы слышали краем уха про agile-проектирование продуктов для пользователя, так вот все это копи-паста с ЭТОЙ книги. 

Удачного чтения и спасибо за рыбу!