Небольшая презентация о методе решения задач «Мозговой штурм» — как применять, какова процедура.
Small presentation on the tasks solving method of «Mind storm» — how to apply, what is the procedure.
У семи нянек дитя без глаза? Пара лет проблем и решений в UX зарубежного веб-...ПрофсоUX
Доклад рассчитан на создателей и руководителей продуктовых команд, проектировщиков, дизайнеров. Разработчикам тоже может быть интересно.
Последние два года я работаю в довольно интересном веб-сервисе. Хочу поделиться кейсами из опыта.
Как быть, когда в вашем портфеле несколько продуктов, каждый продукт развивает отдельный юзабилити-специалист, и у подразделения нет начальника?
Что делать, если каждым из этих продуктов пользуются «немного разные» люди, а навигация общая? (и вообще, продукты живут в едином веб-сервисе и должны между собой как-то дружить)
Как договориться, если все эти продукты — часть единого большого веб-сервиса с кучей общих мест?
Как решать общие проблемы?
Как синхронизироваться и быстрее внедрять лучшие решения из опыта коллег?
Как вообще работать без «арт-директора», «менеджера проекта» или другого начальника?
Доклад предназначен для проектировщиков и дизайнеров интерфейсов.
Что полезного дизайнеру может пригодится из мира программирования? Громкие термины про контроль версий, архитектуру, чистый код и т.д. это все чуждые слова или повод перенять опыт? Настолько ли суровы программисты чтобы испортить своими подходами творческую суть дизайнера?
Эвристическая оценка, или как решить проблемы в интерфейсе за часAlexey Ryakin
Моё выступление на Profsoux 2016: как полагается вести эвристическую оценку, и как это получилось в нашей компании. Сократили, ускорили, результат - весело и быстро.
Проектный анализ в разработке игр: давайте начнем сбор данных / Данил Денеко ...DevGAMM Conference
Игровую индустрию трудно представить без современного набора продуктовых метрик, анализа поведения пользователя. Аналогичный подход можно применить к процессу разработки игры – собирать данные о скорости производства единиц контента, производительности труда, разнице между плановыми и фактическими затратами.
В рамках этого доклада я предлагаю обсудить базовые понятия проектного анализа и их применимость в игровой разработке.
Как UX-специалист делился своими инструментами с agile-командамиNikita Efimov
Прошло 2 года. Семен повзрослел и возмужал (в профессиональном и жизненном плане). За это время он успел поработать с несколькими agile-командами и насмотреться разного скрама и срама, набить очередных шишек при внедрении процесса проектирования в гибкие процессы разработки. Но во всех случаях он видел, что некоторые инструменты проектировщика могут пригодиться и другим участникам процесса, командам, которые не имеют проектировщиков интерфейса у себя в штате. Ведь эти инструменты просты в понимании и не требуют много времени на проработку.
И Семен решил попробовать Сначала на своей команде, а потом и на кошках, т.е. на знакомых командах.
Каких тем коснулся Семён, куда и какие инструменты UX-специалиста он попытался внедрить:
- как ещё (кроме привычных инструментов) можно собирать и фиксировать требования касаемо планируемых фич;
- как можно проапгрейдить user story в сторону большей эмпатии пользователям и какие инструменты в этом могут помочь;
- как можно с большей эффективностью разбивать крупные user story на более мелкие (опять же, с большей эмпатией);
- как фиксировать общий опыт взаимодействия пользователя, чтобы в следующей итерации не наломать дров при реализации новых фич. Ведь всегда сложно держать в голове всю картину взаимодействия человека с продуктом. А когда ты добавляешь все новые и новые фичи, часто вместо помощи вставляются палки в колёса;
как можно использовать любимый многими impact map для проработки целей пользователя;
- как можно проверить необходимость фич (а точнее, ожидаемую удовлетворенность от наличия/отсутствия) перед тем, как их поместить в бэклог.
Небольшая презентация о методе решения задач «Мозговой штурм» — как применять, какова процедура.
Small presentation on the tasks solving method of «Mind storm» — how to apply, what is the procedure.
У семи нянек дитя без глаза? Пара лет проблем и решений в UX зарубежного веб-...ПрофсоUX
Доклад рассчитан на создателей и руководителей продуктовых команд, проектировщиков, дизайнеров. Разработчикам тоже может быть интересно.
Последние два года я работаю в довольно интересном веб-сервисе. Хочу поделиться кейсами из опыта.
Как быть, когда в вашем портфеле несколько продуктов, каждый продукт развивает отдельный юзабилити-специалист, и у подразделения нет начальника?
Что делать, если каждым из этих продуктов пользуются «немного разные» люди, а навигация общая? (и вообще, продукты живут в едином веб-сервисе и должны между собой как-то дружить)
Как договориться, если все эти продукты — часть единого большого веб-сервиса с кучей общих мест?
Как решать общие проблемы?
Как синхронизироваться и быстрее внедрять лучшие решения из опыта коллег?
Как вообще работать без «арт-директора», «менеджера проекта» или другого начальника?
Доклад предназначен для проектировщиков и дизайнеров интерфейсов.
Что полезного дизайнеру может пригодится из мира программирования? Громкие термины про контроль версий, архитектуру, чистый код и т.д. это все чуждые слова или повод перенять опыт? Настолько ли суровы программисты чтобы испортить своими подходами творческую суть дизайнера?
Эвристическая оценка, или как решить проблемы в интерфейсе за часAlexey Ryakin
Моё выступление на Profsoux 2016: как полагается вести эвристическую оценку, и как это получилось в нашей компании. Сократили, ускорили, результат - весело и быстро.
Проектный анализ в разработке игр: давайте начнем сбор данных / Данил Денеко ...DevGAMM Conference
Игровую индустрию трудно представить без современного набора продуктовых метрик, анализа поведения пользователя. Аналогичный подход можно применить к процессу разработки игры – собирать данные о скорости производства единиц контента, производительности труда, разнице между плановыми и фактическими затратами.
В рамках этого доклада я предлагаю обсудить базовые понятия проектного анализа и их применимость в игровой разработке.
Как UX-специалист делился своими инструментами с agile-командамиNikita Efimov
Прошло 2 года. Семен повзрослел и возмужал (в профессиональном и жизненном плане). За это время он успел поработать с несколькими agile-командами и насмотреться разного скрама и срама, набить очередных шишек при внедрении процесса проектирования в гибкие процессы разработки. Но во всех случаях он видел, что некоторые инструменты проектировщика могут пригодиться и другим участникам процесса, командам, которые не имеют проектировщиков интерфейса у себя в штате. Ведь эти инструменты просты в понимании и не требуют много времени на проработку.
И Семен решил попробовать Сначала на своей команде, а потом и на кошках, т.е. на знакомых командах.
Каких тем коснулся Семён, куда и какие инструменты UX-специалиста он попытался внедрить:
- как ещё (кроме привычных инструментов) можно собирать и фиксировать требования касаемо планируемых фич;
- как можно проапгрейдить user story в сторону большей эмпатии пользователям и какие инструменты в этом могут помочь;
- как можно с большей эффективностью разбивать крупные user story на более мелкие (опять же, с большей эмпатией);
- как фиксировать общий опыт взаимодействия пользователя, чтобы в следующей итерации не наломать дров при реализации новых фич. Ведь всегда сложно держать в голове всю картину взаимодействия человека с продуктом. А когда ты добавляешь все новые и новые фичи, часто вместо помощи вставляются палки в колёса;
как можно использовать любимый многими impact map для проработки целей пользователя;
- как можно проверить необходимость фич (а точнее, ожидаемую удовлетворенность от наличия/отсутствия) перед тем, как их поместить в бэклог.
Доклад рассчитан на ребят, которые какое-то время жили в веб-студии или небольшом агентстве, стартапе, увидели вакансию в чем-то монструозно-корпоративном и захотели попробовать.
Сейчас все больше компаний собирают или пытаются собирать UX-компетенции внутри себя. Часто компании нанимают людей, которые хорошо знают свое дело, но оказываются не готовы к реалиям работы внутри больших компаний. Чтобы быть полезным бизнесу и изменять продукты к лучшему недостаточно быть крутым специалистом.
Я бы хотел рассказать на своем опыте, что нужно делать одинокому UX-специалисту пришедшему в большую компанию, какие грабли бывают и как их лучше избегать.
Как и когда использовать айтрекер на юзабилити тестированииПрофсоUX
Доклад ориентирован на юзабилити исследователей, которые открыты к новым знаниям, и их не устраивает уровень данных, которые они получают сейчас. Так же доклад будет полезен руководителям проектов и дизайнерам, которые хотят повысить показатели в своих проектах, но не догадываются как это можно сделать с помощью юзабилити тестирования.
В последнее время технология айтрекинга стала доступне. Уже за 99 долларов можно купить не дорой айтрекер. И почти у каждого возникает проблема, как его использовать после покупки. Что означают эти точки и что с ними можно делать. Я расскажу, как использую я.
Ирина Томилова "Чего хотят тестировщики? или как после планирования жить хоро...Yandex
Конференция "План Б" в Санкт-Петербурге (17 декабря 2011)
Ирина Томилова "Чего хотят тестировщики? или как после планирования жить хорошо..." (DINO Systems)
Тезисы:
– тестировщики хотят того же, чего и все остальные – играть по правилам;
– правила игры не могут не меняться;
– готовность к изменениям закладывается при планировании;
– плановые риски требуют профилактики;
– планирование тестирования завершается не раньше, чем само тестирование.
Однодневный 8 часовой мастер-класс для начинающих проектировщиков интерфейса, графических и веб-дизайнеров, программистов, аналитиков и руководителей проектов.
Курс для всех, кто сегодня уже работает над интерактивными продуктами, но чувствуют, что делают это «по старинке», «на коленке», не используя лучшие практики и научный подход.
Мастер-класс дает первый опыт погружения в проектирование дизайна взаимодействия «по уму» и позволяет узнать на практике, что скрывается на модными словами user-centered design, rapid prototyping, wireframes и agile user experience testing.
Курс читают практикующие специалисты при поддержке Таллинского университета.
Повышение эффективности команды. Ретроспектива как инструмент.Natalia Zinovyeva
Хорошие команды не появляются просто так. Они формируются с течением времени. И ретроспектива может стать ключевым помощником в этом.
На основе собственного опыта расскажу о том, как провести эффективную ретроспективу. Как с помощью ретроспективы повышать эффективность команды. Как решать различные сложности, улучшать коммуникации и атмосферу, мотивировать команду на успех.
Гости из Москвы из компании USABILITYLAB расскажут нам про историю HCD и usability-тестирование (виды тестирования, требования, ограничения, обработку данных)
Доклад рассчитан на ребят, которые какое-то время жили в веб-студии или небольшом агентстве, стартапе, увидели вакансию в чем-то монструозно-корпоративном и захотели попробовать.
Сейчас все больше компаний собирают или пытаются собирать UX-компетенции внутри себя. Часто компании нанимают людей, которые хорошо знают свое дело, но оказываются не готовы к реалиям работы внутри больших компаний. Чтобы быть полезным бизнесу и изменять продукты к лучшему недостаточно быть крутым специалистом.
Я бы хотел рассказать на своем опыте, что нужно делать одинокому UX-специалисту пришедшему в большую компанию, какие грабли бывают и как их лучше избегать.
Как и когда использовать айтрекер на юзабилити тестированииПрофсоUX
Доклад ориентирован на юзабилити исследователей, которые открыты к новым знаниям, и их не устраивает уровень данных, которые они получают сейчас. Так же доклад будет полезен руководителям проектов и дизайнерам, которые хотят повысить показатели в своих проектах, но не догадываются как это можно сделать с помощью юзабилити тестирования.
В последнее время технология айтрекинга стала доступне. Уже за 99 долларов можно купить не дорой айтрекер. И почти у каждого возникает проблема, как его использовать после покупки. Что означают эти точки и что с ними можно делать. Я расскажу, как использую я.
Ирина Томилова "Чего хотят тестировщики? или как после планирования жить хоро...Yandex
Конференция "План Б" в Санкт-Петербурге (17 декабря 2011)
Ирина Томилова "Чего хотят тестировщики? или как после планирования жить хорошо..." (DINO Systems)
Тезисы:
– тестировщики хотят того же, чего и все остальные – играть по правилам;
– правила игры не могут не меняться;
– готовность к изменениям закладывается при планировании;
– плановые риски требуют профилактики;
– планирование тестирования завершается не раньше, чем само тестирование.
Однодневный 8 часовой мастер-класс для начинающих проектировщиков интерфейса, графических и веб-дизайнеров, программистов, аналитиков и руководителей проектов.
Курс для всех, кто сегодня уже работает над интерактивными продуктами, но чувствуют, что делают это «по старинке», «на коленке», не используя лучшие практики и научный подход.
Мастер-класс дает первый опыт погружения в проектирование дизайна взаимодействия «по уму» и позволяет узнать на практике, что скрывается на модными словами user-centered design, rapid prototyping, wireframes и agile user experience testing.
Курс читают практикующие специалисты при поддержке Таллинского университета.
Повышение эффективности команды. Ретроспектива как инструмент.Natalia Zinovyeva
Хорошие команды не появляются просто так. Они формируются с течением времени. И ретроспектива может стать ключевым помощником в этом.
На основе собственного опыта расскажу о том, как провести эффективную ретроспективу. Как с помощью ретроспективы повышать эффективность команды. Как решать различные сложности, улучшать коммуникации и атмосферу, мотивировать команду на успех.
Гости из Москвы из компании USABILITYLAB расскажут нам про историю HCD и usability-тестирование (виды тестирования, требования, ограничения, обработку данных)
Никита Ефимов Lead UX Architect, New Cloud Technologies Anton Anokhin
"Унификация взаимодействия: как мы проектируем интерфейсы нескольких приложений в рамках единого продукта."
"В своём докладе мы расскажем про то, как работает наша дизайн-команда:
- как организован процесс внутри команды
- как мы взаимодействуем с командами разработки
- как проверяем качество итоговой реализации
- как мы внедряем ux-культуру внутри компании (первые шаги, набитые шишки и наша стратегия)
Также поделимся опытом того, как мы прорабатываем один функционал сразу на несколько платформ."
Открывающая презентация на мастер-классе по проектированию в МИЭМ. В мероприятии участвовали сотрудники компаний UIDG и Mail.ru. Видео и фото с мастер-класса можно посмотреть здесь: http://miem.edu.ru/news/17-%D0%BC%D0%B0%D1%80%D1%82%D0%B0-%D0%B2-%D0%9C%D0%98%D0%AD%D0%9C-%D0%BF%D1%80%D0%BE%D1%88%D0%B5%D0%BB-%D0%BC%D0%B0%D1%81%D1%82%D0%B5%D1%80-%D0%BA%D0%BB%D0%B0%D1%81%D1%81-%D0%BF%D0%BE-%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8E-%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D1%82%D0%B5%D0%BB%D1%8C%D1%81%D0%BA%D0%B8%D1%85-%D0%B8%D0%BD%D1%82%D0%B5%D1%80%D1%84%D0%B5%D0%B9%D1%81%D0%BE%D0%B2.html
Мир меняется очень быстро. То, что казалось нормальным еще несколько лет назад, перестало быть таковым. Например, наши родители не считают, что работа должна приносить удовольствие. Они уверены, что работа должна приносить деньги.
Все поменялось. Теперь все уверены, что работа должна нравится. Если это не так, нужно немедленно эту работу сменить на другую, более развлекающую.
С этим можно спорить и несоглашаться, но победить это уже нельзя. Вопрос в том, можем ли мы это использовать и как это сделать?
Мы поговорим о геймификации, одном из способов этого добиться. Геймификация — это использование игровых подходов вне игрового контекста.
Вот и мы с вами посмотрим, как практики гейм дизайна использовать для улучшения процесса разработки ПО.
4. Список требований, пожеланий, историй, функциональности, которые упорядочены по степени важности. Бэклог— • Прозрачность • Приоритеты Инструменты: Основные принципы: • Вики • Google Docs
8. Научный подход Agile — это научный метод проверки гипотез. А раз научный, то это мне нравится! :) План итерации Итерация Анализ Ретро-спективы Гипотеза Тест Ревью Корректи-вы
9. Планирование и эстимейт: Блекджек и шлюхи planning poker Eсть онлайн версия: http://www.planningpoker.com/
10. Бэклог итерации доска задач Есть целый зоопарк онлайн: http://www.userstories.com/products
17. Архитектура и рефакторинг Синдром усидчивого чувака: когда чувак ошибается в дизайне, но у него хватает усидчивости написать кучу кода и пофиксить кучу багов. Ping-pong programming Т.к. у нас низкое тест ковередж, можно попробовать использовать.
18. Сложно построить что-то хорошее на прогнившем фундаменте! это юзабилити. Внешнее качество системы— это продуманность дизайна, покрытие тестами, читаемость кода, рефакторинг и т.д. Внутреннее качество— У системы с высоким внутренним качеством иногда и может быть довольно низкое внешнее. Но наоборот бывает крайне редко.
19. Пример из реального мира Адекватная иерархия джава-классов может вылечить юзер-интерфейсы. »
24. Роли Модель DISC: • D ominance (преобладание) • I nfluence (влияние) • S teadiness (уравновешенность) • C onscientious (сознательность)
25. D I S C Активность Пассивность Dominance Influence Steadiness Conscientious
26. Ориентированы на задачи Ориентированы на людей, открыты D I S C Dominance Influence Steadiness Conscientious
27. Соглашения • Naming conventions. • _________________ (Впишите свой вариант).
28. Групповая динамика Не знаю, что тут и сказать, забыла удалить этот слайд =) « Второй закон термодинамики менеджмента:Энтропия в организации постоянно увеличивается» Том Демарко, Тимоти Листер "Человеческий фактор"
29. Мотивация Сложная штука. Но в скраме это любят. Может быть самомотивацией . Но на нее влияют также другие факторы. Надо: • Мотивировать себя. • Мотивировать других. • Не демотивировать других. Кино Вино Домино
30. Team room Перестановка? Кстати говоря, должно быть много места, чтоб ходить и думать. Здесь должна быть еще одна сумасшедшая идея. Флипчарты! (скрам — это флипчарты, и много).
31. Спасибо за соучастие! Слайды доступны на локальной вики (ну или будут доступны, чтоб не спойлить).
Editor's Notes
Ура, мы будем играть в скрам Название в разработке
Ну тут еще майндмапа в разработке
Теперь я выделяю основные элементы, которые рассматриваю в скраме в качестве позитивных и рекомендуемых ко внедрению Ж))
Это основа скрама. С него все начинается И я вижу в нем у нас тоже реальную потребность Это может быть файл Excel в гугл доксах или страница в вики. Сюда пишутся все требования(юзер стори), которые запланированы к реализации , причем на понятном языке(не техническом)
Основным элементом беклога является юзер стори Т.е. элементы бэклога пишутся на человеческом языке, а не на техническом
Теперь я выделяю основные элементы, которые рассматриваю в скраме в качестве позитивных и рекомендуемых ко внедрению Ж))
- все мнения учитываются - более качественные оценки Можно использовать числа подряд: 1,2,3,4. Но, как показывается народная мудрость, начинаются мелочные споры, о том, что это 2 или 3, и опять в ход идут “метрические линейки” типа рабочих часов, минут, дней. Поэтому уже давно многие Agile-практики рекомендуют пользоваться последовательностью Фибоначчи (0,1,2,3,5,8,13…). Ее выгода в том, что она начинает резко расти вверх. Ведь если требование действительно сложное, то детали уже не так важны – слона лучше всего есть по частям, главное понять, что это слон Правила Planning Poker просты: Каждому участнику дается набор карт с цифрами Заказчик/Владелец Продукта читает историю, и команда кратко уточняет ее Каждый участник выбирает свою оценку и кладет карту рубашкой вверх Все одновременно открывают карты Если есть разница (большая), то обсуждается «Почему?» Делаем еще один раунд оценки, пока все не сойдутся на одном числе
- все мнения учитываются - более качественные оценки Можно использовать числа подряд: 1,2,3,4. Но, как показывается народная мудрость, начинаются мелочные споры, о том, что это 2 или 3, и опять в ход идут “метрические линейки” типа рабочих часов, минут, дней. Поэтому уже давно многие Agile-практики рекомендуют пользоваться последовательностью Фибоначчи (0,1,2,3,5,8,13…). Ее выгода в том, что она начинает резко расти вверх. Ведь если требование действительно сложное, то детали уже не так важны – слона лучше всего есть по частям, главное понять, что это слон Правила Planning Poker просты: Каждому участнику дается набор карт с цифрами Заказчик/Владелец Продукта читает историю, и команда кратко уточняет ее Каждый участник выбирает свою оценку и кладет карту рубашкой вверх Все одновременно открывают карты Если есть разница (большая), то обсуждается «Почему?» Делаем еще один раунд оценки, пока все не сойдутся на одном числе
Ну это уже пробовали, это хорошо, но всем лень Основные условие: 1) место(лучше не в рабочей комнате)
Исключение затрат . Затратами считается всё, что не добавляет ценности для потребителя. В частности: излишняя функциональность; ожидание (паузы) в процессе разработки; нечёткие требования; бюрократизация; медленное внутреннее сообщение. Акцент на обучении. Короткие циклы разработки, раннее тестирование, частая обратная связь с заказчиком. Предельно отсроченное принятие решений. Решение следует принимать не на основе предположений и прогнозов, а после открытия существенных фактов. Предельно быстрая доставка заказчику. Короткие итерации. Мотивация команды. Нельзя рассматривать людей исключительно как ресурс. Людям нужно нечто большее, чем просто список заданий. Интегрирование. Передать целостную информацию заказчику. Стремиться к целостной архитектуре. Рефакторинг. Целостное видение. Стандартизация, установление отношений между разработчиками. Разделение разработчиками принципов бережливости. «Мыслить широко, действовать мало, промахиваться быстро; учиться стремительно».
Ping pong Суть в том, чтобы писать тесты до того как будет написан сам код, при этом, выдерживая наименьшие шаги при написании кода. Т.е. один программист пишет один тест, который компилируется, но “падает”. Затем, второй программист должен написать код, который будет отвечать заранее написанному тесту, и, соответсвенно он же должен будет написать следующий тест, чтобы первый программист написал соответствующий код. Всё это весело и довольно эффектно, но без сомнения требует довольно высокой концентрации на поставленной задаче.
Теперь я выделяю основные элементы, которые рассматриваю в скраме в качестве позитивных и рекомендуемых ко внедрению Ж))
Рома, это тебе посвящается Я начиталась Питерса, и решила, чем больше будет безобразия - тем лучше :P Дальше неинтересно Здесь нарисована иерархия экшенов небезызвестного адверфейса Был проведен всестронний анализ(мной) после чего всячески перепроектирована эта самая иерархия
Что это пример доказывает:
ну пока непонятно какая-то модель диск зачем? все мы разные, это хорошо, надо думать, как это использовать
Теперь я выделяю основные элементы, которые рассматриваю в скраме в качестве позитивных и рекомендуемых ко внедрению Ж))