Шейн Дойл написал о неидеальных состояниях интерфейса.
Многие дизайнеры проектируют только идеальное состояние, когда всё отображается корректно и контент идеален. Но есть ещё состояния:
- Пустое: контент ещё не добавлен, нулевые результаты поиска, пользователь удалил контент.
- Загрузка: когда загружается контент или выполняется какое-то действие. Важно донести до пользователя, что программа не зависла.
- Частичная наполненность: когда есть только часть контента. Подумайте, как помочь пользователю сделать так, чтобы получить идеальное состояние.
- Неидеальное: слишком длинный или короткий текст, изображения в неправильном формате или отсутствуют, нет части контента. Пользователь не должен думать, что программа сломалась.
- Интерактивное: фокус на элементе, заполнение поля и другие изменения интерфейса после взаимодействия с пользователем.
- Ошибка: нет подключения к сети, пользователь сделал что-то не то, системная ошибка. Важно, чтобы пользователь понимал суть ошибки и что ему делать.
- Выполнение действия: когда пользователь справился со своей задачей. Состояние может отличаться для разных пользовательских задач.
https://ux.pub/proektirovanie-razlichnyh-sostoyaniy-interfeysa/
О гибком мышлении.
В любом процессе работы, обучения, выстраивании жизни важно научиться иметь гибкую точку зрения. Сила мышления в гибкости. Есть у меня знакомый Вася, вообще не гибкий в размышлениях и всех поучает как жить, больно мозгу от его прямолинейных размышлений и однозначных выводов. Вообще умение смотреть на события, факты, людей с разных позиций это определенный и талант и практика и пожизненный плюс в карму. Обычно самыми принципиальными и несгибаемыми в споре оказываются аргументы самого, ну скажем, не умного человека. Учиться гибкости мышления — это навык. Натренировать себя быть гибче, не упираться в стены стереотипов и навязчивых мнений других людей не просто. Есть три приема:
— Первое. Возьмите любой ваш личный конфликт и подумайте о пяти любых, самых разных способах примириться. Любые уступки, любые смелые шаги навстречу соперникам, врагам, конкурентам. Поменяйте ролями в вашем воображении, ведь и у ваших оппонентов есть причины не искать примирения, поймите их мотивы, причины и условия для конфликта. Любой исторический конфликт попробуйте осмыслить с позиции проигравшей стороны, а затем с позиции любых соседних сторон, которые могли в этом конфликте участвовать.
— Второе. Возьмите любимую картину. Внимательно на нее посмотрите и запишите 5-10 причин почему она вам нравится, чем близка, что вы знаете о ее написании. Теперь напротив ваших соображений запишите абсолютно противоположные мнения, какими бы безумными они не казались, поверьте есть масса людей, которые согласятся с этим списком. Возьмите любую поговорку и постарайтесь доказать себе почему это утверждение глупо, устарело, не имеет рациональных оснований.
— Третье. Возьмите несколько видов спорта, например бокс, плавание, шахматы. Представьте, как изменится этот вид, если удалить полностью соперничество и агрессию. Если соперники будут помогать, скорость будет не важна, двое будут играть против более сильного соперника. Представьте любой агрессивный вид спорта без насилия и соперничества. две команды вместе закидывают мячи в одни ворота, пара борцов вместе на скорость пытаются связать, сложить из кимоно зайчика.
Гибче Вас!
Андрей Шапиро написал серию статей о методологии сбора требований и планирования релизов программного продукта User Story Mapping
Часть 1. Пользовательская история: https://medium.com/xraizor/b0b0d724d77e
Карта историй создаётся для нового продукта или когда существующий продукт надо частично или полностью переделать, и требуется описать объём имеющейся функциональности.
На входе метода: гипотезы состава стейкхолдеров, их интересов и основных планируемых эффектов ближайшего релиза. Хорошо, если есть картирование процессов в форматах Customer Journey Map или Service Blueprint.
На выходе: набор задач на проектирование и разработку, привязанных к пользовательским историям.
Методика предлагает фиксировать требования в виде двухмерной карты, где карточки с пользовательскими историями располагаются в хронологическом порядке, а соответствующие им задачи расположены под ними по мере роста глубины проработки.
Любая пользовательская истории записывается для действующего лица: персоны или функциональной роли в системе. Близкая методика Use Cases лишена эмпатии к человеку, для которого создаётся программа.
Важно:
— Чтобы в истории было и действие, и его ценность для действующего лица;
— Не фиксировать определённый образ достижения полезного действия, чтобы не мыслить готовыми решениями. Избегайте названий интерфейсных элементов и паттернов.
Часть 2. Алгоритм проведения и рекомендации для ведущего: https://medium.com/xraizor/9a90beb2ff57
Часть 3. Чистка историй от ложных требований. Критика метода: https://medium.com/xraizor/2f7bd967a54a
История одного дня пользователя
Еще один метод, способный проиллюстрировать флоу взаимодействия пользователя с будущим продуктом с учетом контекста. Этот метод помогает понять мотивы и примерный бэкграунд в котором находится пользователь — что было до того как у него возникла потребность в продукте? Что он делал после, почему поступил так, а не иначе?
Итак, история про Алексея:
«Алексей офисный работник, который проводит на работе с 9 до 19. У него нет свободного времени. Алексей женат, но жена, также, все время проводит на работе. Они живут в старой квартире, которая досталась от бабушки. Жена, периодически пилит Алексея, что он никак не может сделать хотя бы косметический ремонт. В конце концов, Алексей накопил денег и решил для начала поменять старый паркет. Он задумался над тем, что ему нужен хороший специалист, который выполнит конкретную работу. Но он не знал как отобрать нужного кандидата, чтобы и по цене не обманули и по качеству не кинули. На работе Алексей поделился проблемой со своим коллегой Леонидом, и тот посоветовал сервис профи.ру.
Алексей дождался обеденного перерыва и зашел на сайт с мобильного телефона. Он увидел строку поиска, а так же возможность воспользоваться умным помощником. Он выбрал помощника, который в виде чат бота шаг за шагом помог Алексею ответить на конкретные вопросы касающиеся этого вида работы.
В итоге, Алексей получил список подходящих специалистов. Он выбрал лучшего по соотношению рейтинга/цены/отзывов. Оставил заявку. Приложение потребовало сделать оплату, Алексей воспользовался Apple Pay. Оплата прошла. Через какое-то время мастер ответил согласием и взялся за заказ.
В назначенное время он приехал к Алексею и принялся за работу. После успешного завершения мастер отметил в своем приложении, что работа сделана. Алексею пришло уведомление о том, что работа выполнена и он должен ответить на несколько вопросов:
-сделана ли работа полностью?
-производились ли дополнительные работы?
Приложение просит оценить специалиста и его работу, он ставит 5 звезд.
После чего Алексей видит, что заказ закрыт и деньги за работу списаны.
В этот вечер у Алексея был секс».
Как видите, мы также в первую очередь стремились показать особенности сервиса глазами клиента — но, я думаю, подобное проговаривание сценариев на ранней стадии помогло нам понять в какую сторону стоит двигаться.
Я тут снова думал про коммерческое писательство, и опять мысли по кругу.
Когда человек создаёт что-то художественное, он делает это для себя. Даже не писатель, просто человек может набирать на клавиатуре пост в свой дневник. Ему нужно выговориться, он делает это, молодец. Если жаждет публичности, то выкладывает запись для друзей и фолловеров. Но всё равно это для себя и всё сам.
Когда пишешь по заказу для продукта, ты вроде теряешь эту самостоятельность, становишься кем-то вроде актёра и сценариста в одном лице. Сначала тебе надо придумать или принять уже готовый образ и написать роль, а после — примерить и проговорить её для себя, сыграть для самых близких и каких-нибудь бугров. Ну знаете, тех продюсеров, которые решают, понравится ли пьеса людям, много ли получится заработать на этом фильме и так далее.
И вот тут очень важно, чтобы роль нравилась и подходила писателю. Иначе писать будет невыносимо, а сыграть ту роль окажется невозможно.
То есть для успешной работы коммерческому писателю должно нравиться то, чем он занимается? Наверное, да. И если продукт «не его», то писатель не сможет примерить на себя эту роль, из-за чего все его тексты станут выходить плохими? Он ведь не сможет оценить степень их дурноты и изменить как надо. Пожалуй, так. Выходит, что и в коммерческом писательстве для самых скучных продуктов есть место творчеству? Ага.
Юлия Кожухова написала о разных инструментах, с помощью которых можно оформить результаты исследований.
Ещё перед началом исследования важно понять, что вы будете делать с результатами. От этого зависит, какие инструменты выбрать для составления отчёта, и сколько на него тратить времени.
Выбор зависит:
— От запроса команды. Какую потребность исследование должно закрыть?
— Отношения к исследованиям. Надо ли убедить команду в надёжности выводов?
— Особенностей продукта. Это прототип или готовый продукт?
— Связи исследователя с командой. Продолжите ли вы работать вместе после окончания исследования?
Юлия рассмотрела плюсы и минусы 4 основных инструментов и сделала выводы, для каких исследований они подходят:
1. PowerPoint. Подходит для результатов интервью, фокус-групп, юзабилити-тестов, а также если надо показать много скриншотов. Скорее подходит для крупных проектов, когда есть время на оформление слайдов, которые увидит много людей.
2. Miro. Можно представлять результаты глубинных интервью, фокус-групп. Подходит для проектов, где надо строить большие схемы, и когда необходимы частые правки и дополнения.
3. Excel или Google Таблицы. Подходит для любых количественных данных. На одном листе могут быть исходные данные, а на других — результат их обработки. Можно делиться с командой промежуточными результатами с дополнительными гипотезами и инсайтами.
4. Word или Google Документы. Подходит, когда не нужны рекомендации по изменениям, а нужны только факты по результатам исследования (например, перечень проблем, с которыми столкнулись пользователи). Отчёт в таком формате легко оформить.