UX Notes

2021-03-23 22:01:58 Рассказал о своём подходе к прототипированию, который позволяет быстро создавать прототипы и вносить правки:
— Почему это важно для проектов с высокой долей неопределённости (стартапов);
— Где заканчивается прототипирование и начинается проработка дизайна;
— Что показывать в прототипе, а что уже лучше описывать в функциональной спецификации;
— Какие состояния системы показывать;
— Какие визуальные средства использовать для компоновки страниц;
— Насколько интерактивным делать прототип;
— Что с текстом.



Открыть/Комментировать

2021-03-22 10:01:22 Открыть/Комментировать

2021-03-22 10:01:21 Банк ВТБ ищет героев для создания сервисов, которыми будут пользоваться миллионы людей!

Программа ВТБ «600 дней» продолжается. Цифровизация клиентского опыта и ускоренное развитие продуктов идут полным ходом, над этим трудится уже более 200 кросс-функциональных команд. Но ВТБ нужны ещё герои, которые будут создавать продукты и сервисы нового поколения для миллионов людей! Никаких длительных согласований — ответственность за продукт перед клиентом и руководством полностью несут команда и её лидер. Дебюрократизация процессов позволяет реализовывать смелые проекты в кратчайшие сроки! Классный коллектив и отличные условия гарантированы.

Сейчас ВТБ ищет:

UI/UX-дизайнер

— Вы будете разрабатывать интерфейсы;
— создавать: скетчи, макеты, интерактивные прототипы с учетом целей бизнеса и пользователей (Sketch/Figma/Invision/Marvel/Zeplin);
— сотрудничать с графическими дизайнерами при подготовке визуального интерфейса и с разработчиками для повышения качества UX;
— проводить качественные и количественные исследования;
— анализировать разработанные продукты/сервисы и мониторить результаты с точки зрения удобства использования.

Оставляйте отклик по ссылке!

Публикация оплачена Открыть/Комментировать

2021-03-22 01:05:53 Вадим Митякин опубликовал 6-ю главу книги «Метод параноика». Глава посвящена принципу динамических команд.

— Для работы над сложным цифровым продуктом команда должна соответствовать конкретным требованиям (тип проекта) и представлять собой уникальное сочетание специалистов;
— Участники фиксированной команды успевают притереться, эффективно работают, накапливают знания о продукте и могут пренебрегать документированием. Изменение в команде приводит к потере знаний. Сложно принимать решения, касающиеся разных аспектов продукта;
— Развитие бизнеса приводит к череде проектов разных типов, проектная команда не может зафиксироваться надолго;
— «Проклятие инструмента»: когда есть несколько инструментов, велико искушение воспользоваться каждым, не важно, требует того задача или нет. Участники сработавшейся команды, переброшенной на новый проект, — инструменты;
— Понимание, какие специалисты потребуются для реализации, появляется по мере создания модели продукта;
— Если проект не укладывается в сроки, добавление рабочей силы задержит его ещё больше (Брукс);
— Несколько человек, долго работающих друг с другом, могут рассматриваться как самостоятельная проектная единица;
— «Железобетонное» правило: с самого начала формировать команду вокруг «несущих конструкций», то есть специалистов, ориентированных на техническое лидерство и координацию работы группы;
— Требования к ролям участников проекта определяются природой тех частей, из которых состоит система, над созданием которой они работают;
— Если у участника проекта есть возможность принимать решения без последствий для себя, это негативно отразится на качестве проекта;
— Можно рассматривать ограничения бюджета в качестве такого же фактора как функциональные или технические требования, которые нужно учитывать при принятии проектных решений;
— Кризис управления: руководителю не хватает знаний для принятия решений, а специалистам — полномочий. Управление вырождается в администрирование;
— Специалисты в инженерных и креативных компаниях не должны быть «подчинёнными» по отношению управленцам, выступая в роли исполнителей;
— Артефакты проектирования (проектная документация) — модель будущего продукта и способ коммуникации между участниками проекта.

https://paranoidmethod.org/paranoid-method-book-06 Открыть/Комментировать

2021-03-19 15:32:31 Ира Моторина, автор канала @redachredach, написала, как планировать и писать пуш-уведомления.

Это агрессивный формат коммуникации. Чтобы пуши не раздражали, они должны приходить не слишком часто и быть полезными. Если приложение при установке обещает «приятные новости по заказам и скидкам», нельзя потом заваливать пользователя нерелевантными скидками.

Типы уведомлений:
— Сервисные: изменение статуса заказа, запрос пользовательского действия в приложении;
— Маркетинговые: вовлечение пользователя на разных этапах взаимодействия с продуктом.

По этапам взаимодействия:
— Онбординг: подталкивание пользователя к выполнению целевого действия, например, первому заказу;
— Вовлечение и удержание: формирование привычки, подталкивание к повторению целевого действия. Можно предложить скидку, напомнить о себе в связи с праздником или новостью;
— Реактивация пользователя, который перестал выполнять целевое действие. Если причина в негативном опыте, маркетинговые пуши не помогут. В остальных случаях можно просто напомнить о себе или сделать спецпредложение.

Если пользователь не выполняет целевое действие и не реагирует на уведомления, можно написать, что больше не будете их отправлять (Duolingo).

Триггерные уведомления отправляются в ответ на определённые пользовательские действия. Например, он добавил товары в корзину, но не сделал заказ за заданное время.

Если приложение работает на старых телефонах, текст уведомления лучше уместить в 40 символов. Если работает только на новых, можно использовать 120.

https://skillsetter.io/blog/how-to-push-notification Открыть/Комментировать

2021-03-14 14:01:35 Пранава Тандра написала об автоматических подсказках в полях поиска.

8 тезисов с примерами из реальных продуктов.

— Позволяйте фокусировать поиск, указывая, где именно искать (если это возможно и необходимо);
— Группируйте варианты подсказок, если они неоднородны;
— Если есть прямое совпадение и можно предоставить информацию прямо в подсказке, сделайте это;
— Не перегружайте список подсказок, 7−9 вариантов вполне достаточно;
— Добавьте продвинутый поиск с параметрами, если в продукте много информации (или функциональности) и есть отдельная страница для результатов поиска;
— Запоминайте, что пользователь искал раньше. Показывайте этот запрос по активации поля поиска, когда оно ещё пустое и подсказывать нечего;
— Сортируйте список подсказок по релевантности, но и популярность сгодится на худой конец;
— Пробуйте угадать, что пользователь имеет в виду, и исправляйте ошибки. Но только оставьте возможность отменить коррекцию и искать с ошибками.

[English] https://blog.prototypr.io/9c3394774519

Заметка подготовлена совместно с @vanillatime. Открыть/Комментировать

2021-03-09 22:59:42 Сделал конспект книги Майкла Джанда «Сожги своё портфолио» о самоорганизации и работе с клиентами.

Работа в команде, навыки общения, в том числе с клиентами, производительность труда и деловая смекалка не менее важны, чем портфолио и дизайнерские способности.

Некоторые тезисы о клиентах:
— Клиенты отличаются от дизайнеров. Дизайнер хочет сделать круто и хорошо этим заработать. Клиент хочет получить возврат от инвестиций, хорошо выглядеть перед руководством, чтобы кто-то взял на себя ответственность за решение задачи, выгодных условий, долгосрочных отношений, хорошего дизайна (да, на последнем месте);
— Длительные отношения значат больше, чем одна выгодная сделка. В них вы накапливаете репутацию. После нескольких успешных проектов ошибку могут простить. Если она случается на самом первом проекте, скорее всего, второго не будет;
— Клиент нанял вас, чтобы облегчить себе жизнь, не нагружайте его домашней работой. Упрощайте предоставление вам материалов, ответов на вопросы и так далее. Подготовили бриф с вопросами — предзаполните его имеющейся у вас информацией;
— Странности в начале чреваты странностями в середине и конце проекта;
— Иногда советуют завысить цену, чтобы не брать проект. Лучше просто отказаться, чем провоцировать возмущение и конфронтацию. Если вы с этим клиентом работали, он может порекомендовать вас или принести более интересный проект.

https://vandergrav.ru/burn-your-portfolio-book-summary/ Открыть/Комментировать

2021-03-07 20:53:44 В лаборатории дизайна Pragmatica запустили новую рубрику видеоблога — «Артефакты». Минус: срачи, хейт и оружие второго удара. Плюс: темы, которые формируют насмотренность, кругозор и креативность дизайнеров.

Уже есть 3 выпуска:

1. Дизайн в Российской империи, музей дизайна в Хельсинки (Финляндия), премии в целом и премия D&AD, виниловые пластинки




2. Итоги 2020 года (важность шрифта и «Доброшрифт», скорость создания сайтов, национальный флаг РБ), тренды на будущий год, артефакты из бананового бункера, пост-интернет искусство Кати Новиковой, концепция и дизайн iMac G4, история Snapchat




3. Приложение «Помощь» Никиты Кукушкина, ажиотаж вокруг Clubhouse, выставки самоизоляции, Malofiej Awards, цифровые образы Данилы Криворучко, соковыжималка Филипа Старка


Открыть/Комментировать

2021-03-04 14:03:25 Шейла Шейх и Кирилл Улитин написали о новой панели инструментов в редакторе документов МойОфис.

В прошлой версии инструменты были сгруппированы по вкладкам, которые отображались в зависимости от контекста. Если пользователь редактировал текст в таблице, появлялись вкладки «Текст» и «Таблица». Изменение цвета заливки ячейки и цвета текста было на разных вкладках, что плохо, так как пользователи часто меняют эти цвета вместе.

«По ходу исследования мы снова обнаружили знакомые ситуации, когда люди не видели контекстные вкладки и тратили время на их поиск. И обнаружили новую проблему — напрасное переключение, когда человек зря переходил на неправильную вкладку, уже находясь на нужной.

Тестирование «риббона» показало, что чем больше вкладок, тем больше времени человек тратит на их перебор, если не может найти нужную кнопку.

Интересно, что некоторые участники теста говорили о том, что им нравятся вкладки. Тестирование было модерируемым, и мы смогли выяснить основную причину такого заключения: пользователям нравится группировка кнопок, при этом необходимость переключения они всё же рассматривали как недостаток».

В итоге отказались от вкладок, перегруппировали и разместили все инструменты на одной панели, проработали её поведение при изменении ширины окна. Скорость работы выросла.

Ещё интересно, что все свойства панели собраны в Airtable и могут быть экспортированы в XML. Дизайнеры правят конфигурацию панели инструментов независимо от разработки, и корректировки автоматически применяются при сборке продукта. Это позволило удешевить процесс внесения изменений и исключить человеческий фактор.

https://habr.com/ru/company/ncloudtech/blog/541970/ Открыть/Комментировать

2021-03-03 10:30:31 Дейв Акин сформулировал законы проектирования космических кораблей. Некоторые из них:

3. Проектирование — итеративный процесс. Необходимое количество итераций всегда на единицу больше, чем то, которое вы сделали в данный момент. Это верно в любой момент времени.

4. Ваши лучшие конструкторские разработки неизбежно окажутся невостребованными в итоговом проекте. Научитесь жить с разочарованием.

12. Не существует единственно правильного решения. Но всегда есть несколько неправильных.

13. Проектирование основано на технических требованиях. Нет никаких оснований делать что-то хоть немного «лучше», чем предписывают эти требования.

15. (Закон Ши) Талант к конструктивным улучшениям проявляется в первую очередь в интерфейсах. И это также лучшее место для того, чтобы всё испортить.

16. У людей, которые проводили аналогичные исследования до вас, не было прямого доступа к извечной мудрости. Следовательно, нет никаких оснований доверять их расчётам больше, чем своим. И в особенности нет никаких оснований представлять их как свои.

20. Плохой проект при хорошей подаче в конце концов обречён. Хороший проект при плохой подаче — обречён сразу.

31. (Закон эволюционного развития Мо) Вы не сможете добраться до Луны, взбираясь на всё более высокие деревья.

36. Любой рядовой инженер может спроектировать что-то изящное. Хороший инженер проектирует работоспособные системы. Опытный инженер — эффективные.

38. Возможности определяют технические требования, независимо от того, что говорится в учебниках по системной инженерии.

41. (Закон Макбрайана) Вы не сможете сделать лучше, пока не сделаете, чтобы работало.

https://zamesin.me/akins-laws-of-spacecraft-design/ Открыть/Комментировать