Хотелось бы разобраться в каких случаях имеет смысл отказаться от User Story в пользу Jobs Story. На последней конференции World Usability Day Russia, которая проходила в Санкт-Петербурге, в секции открытых докладов я предложил такую очень дискуссионную тему. Получив обратную связь и пообщавшись с коллегами, я понял для себя 3 ситуации, когда можно \ хорошо \ лучше (нужное подчеркнуть) использовать JB:
- Отсутствует описанная персона или роль
- Не определено для какой персоны история
- История начинается с одной персоны, а заканчивается другой
Напоминаю, что User Story строится следующим образом:
Я как (персона \ роль), хочу (действие \ цель), чтобы (результат)
Вводная
У многих, кто заказывал что-либо на фрилансе (дизайн, код или текст) или на аутсорсе, негативное отношение к такому сотрудничеству. Уж очень много недобросовестных работников, которые постоянно задерживают сдачу, подолгу не отвечают и уходят в игнор. Сроки горят, приходиться обращаться к другому фрилансеру, который может быть не лучше.
Я не буду никого оправдывать в статье. Я сам не занимаюсь фрилансом и аутсорсом уже давно, все наблюдения за коллегами. Моя задача рассказать как и почему это происходит с психологической точки зрения у обеих сторон. Что влияет на такое поведение и как его в дальнейшем избежать или исправить. …
Что это за компонент
История потребности в компоненте
Для проекта, над которым я работаю понадобился компонент календаря. В разработке был использован фреймворк Material-UI, календарь которого не отвечал потребностям пользователей. Пользователям необходимо постоянно работать с периодами, заполняя различные формы с большим количеством полей.
Разработку собственного компонента нам не позволяли сроки (как всегда). После рассмотрения около десяти вариантов различных компонентов фреймворков, выбор пал на airbnb React-Dates.
Почему airbnb React-Dates
- Подходил под потребности пользователей
- Хорошо спроектировано взаимодействие календаря
- Имеет управление с клавиатуры (в том числе, при переходе на текстовое поле календаря с помощью tab, календарь открывается автоматически — очень полезно, если форма с большим количеством полей)
- Отлично кастомизируется под необходимые нужды (заметно, что оригинал…
Желание структурировать и стандартизировать все, привело меня к своей рабочей области. Ведь чтобы прививать структуру другим людям — необходимо структурировать все у себя.
В первых прототипах (сейчас и далее под «прототипом» речь пойдет о комбинации Sketch+Invision, или Sketch+Principle, или другие альтернативы) артборды получаются с простыми названиями:
Предыстория
Я работал в компании DEVIM в качестве продуктового дизайнера. Первый заказ мы получили на разработку системы из веб-приложений для одной известной кредитно-финансовой организации. В команде дизайнеров нас было трое. Процесса проектирования не было. Все старались продвигать дизайн-процессы, как могли, но потом поняли, что надо взяться за это и структурировать наши действия.
Проблема
Команда дизайнеров одновременно работала над одним проектом, разделяя между собой функций проектирования и работая совместно над общей концепцией продукта.
Проектирование начиналось со спонтанно выбранных артефактов: карта взаимодействия, пользовательские сценарии, пользовательские истории или сразу приступали к формированию гипотез. Без очевидного понимания требований проектирование переходило на стадию формирования гипотез. Гипотезы не…
Набор из кнопок и текстовых полей в виде символов Sketch-а, которые загружены в библиотеку CRAFT. Разработан для быстрой работы с макетами в Sketch-е.
Кнопки
Внутри можно написать любой текст. Изменять размер кнопки придется вручную. Но можно делать это на глаз — отступы в кнопке все равно будут правильные.
Sergey Krivoy
UX Designer at SEMrush
