Дизайн Домашка

⚡️Домашка декабря. Большой разбор. [47 min] #edu Надеюсь, вы хорошо отдохнули и как раз мозг готов переварить новый разбор. Прошелся по работам участников и дополнительно пояснил особенно важные детали. Очевидно, самое слабое место в задаче — абсолютно непонятная система карточек: не ясно, что будут за задания, нет возможности сравнить их друг с другом, дополнительные задания не отличаются от остальных, но почему-то скрыты в отдельном списке. Вместе разберемся, как пофиксить. Другие сложности — копирайт и запутанная система прохождения заданий. Неочевидно, что будет на следующем шаге, можно ли его прерывать, менять задания и проходить другие. Кто разобрался, тот разобрался. Решения участников в FIGMA. ❤️ Всем кто качается на праздниках — отдельный лайк!

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

§ UX. Про сценарии, которые "ломаются". SPOF и CFP. Если раньше на рынке было много проектов, которые только стартовали, то в последнее время приходится работать с проектами, которые уже работают, пусть и были запущены на коленке. Кстати, куча историй, что запущенный на вайбкодинге MVP дорос до нормального продукта и теперь надо сделать сценарии уже нормально, а не из палок и желудей. Вот тут, на старте, уже можно купить бутылочку красного и глянуть, что там пишут юзеры в отзывах, а потом уже и самим пройтись по сценариям. Однако, всегда есть то, что сразу не увидишь. Сейчас расскажу... В UX есть два важных термина, которые часто объясняют, почему сценарии «ломаются» там, где всё вроде сделано правильно. Это Critical Failure Point / Critical Breakpoint и Single Point of Failure (SPOF). Critical Failure Point - это шаг в сценарии, на котором любой сбой делает дальнейшее выполнение невозможным. Пользователь может всё сделать идеально: приложить билет, нажать кнопку, пройти авторизацию, но если турникет не считывает код или API отвечает с задержкой, сценарий просто не может завершиться. SPOF - ещё более жёсткий термин: единственная точка отказа, при падении которой весь путь рушится полностью. Один элемент, от которого зависит всё. Почему это важно? Потому что в реальных продуктах большинство «провалов конверсии» происходит не из-за плохого UI, а из-за скрытых точек отказа. В нашей практике очень часто именно с проверки SPOF и Critical Breakpoints начинается исследование. Анализируем, почему часть пользователей не может завершить сценарий, откуда берутся отказы, где фактически «рвётся» путь. И обычно уже на этом этапе появляются первые рабочие гипотезы, которые можно проверить без дорогостоящих переделок. Чтобы выявлять такие места системно, используем упрощённый набор проверочных вопросов: — Может ли этот шаг не сработать? — Если он не сработает — сможет ли пользователь продолжить? — Есть ли альтернативный путь? — Понятна ли пользователю следующая инструкция при сбое? — Есть ли в шаге физическое устройство или внешняя зависимость? — Есть ли зависимость от сети, API или стороннего сервиса? — Понимает ли система сама, что произошёл сбой? Ответы на эти вопросы помогают нам сформировать бэклог для проверки сценариев, собрать «карты отказов», провести ревью ключевых точек и выдвинуть гипотезы улучшений. Часто даже небольшие доработки — улучшение сообщений об ошибках, добавление fallback-пути, кеширование данных, локальное сохранение билетов — позволяют резко снизить количество незавершённых сценариев. По сути, работа с Critical Failure Points и SPOF - это быстрый и очень прикладной способ понять, что за дичь творится, не только глазами пользователя, но и глазами системы, и понять, где на самом деле возникают настоящие барьеры. Лайк, если соскучались по замороченным постам) #edu

⚡️Задача октября. Большой разбор. Часть первая, в которой Саша и Тася исследуют варианты решения и подходов, разбираются с копирайтом, акцентами и фактчеками, чтобы подсветить как вообще можно работать с похожими задачами. [47 min/90 mb] #edu Конечно, от проекта к проекту очень меняется контекст и аудитория, но подходы редко настолько же вариативны. Как обычно, перед просмотром видео очень советую открыть задачу и попробовать покрутить в голове что и как бы тут меняли, а потом уже в видео сравнить свой подход с тем, что на разборе. Спасибо дизайнеру Тасе Попелушко, которая делала задание и согласилась со мной постримить. Думаю на следующих задачах можно будет повторить формат разбора с кем-то из частников. Во второй части (скоро выложу) мы с ней посмотрим на работы участников и дополним на их примерах основной разбор. ❤️ Поставьте Тасе лайк!

§UX. Reducing cognitive friction — снижение когнитивного трения. Как превращать факты в понимание, которое помогает пользователю принимать решения. #edu [16 min] На примере июльской Домашки было отлично видно: грамотная работа с информацией в макете — это 90% всей работы с дизайном интерфейса. От этого зависит, поймёт ли пользователь, что ему нужно сделать, какие выводы он сделает и какие действия предпримет. В такой модели особенно важно снижать количество усилий, которое пользователь тратит на понимание данных. Чем меньше ему нужно думать и вычислять — тем лучше. Чем больше когнитивной нагрузки — тем медленнее и тяжелее пользователь справляется с задачей. Если слишком сложно — он может вовсе отказаться. Например, если в интерфейсе есть текущее время, а в приложении есть расписание электричек, можно не заставлять пользователя самому считать разницу, когда именно отправится ближайшая... а сразу добавить "вывод" — «отправление через 12 минут». Этои есть reducing cognitive friction — снижение когнитивного трения. Когда система делает вывод за пользователя, ему проще принять решение. Иногда, даже без необходимости анализировать исходные данные. А если всё же потребуется — пользователь сможет изучить факты уже с пониманием, зачем ему эти детали. Разобрал в видео на примерах, как это работает и как на этом можно строить изменения в сценариях. 👍 Вспомните, какие приложения таким типом информации помогают вам экономить время и быстрее принимать решения.

🤑 Разбор UX минизадачи мая. [25 min] Дробим экран на инфоблоки, и каждый анализируем: — задаем вопросы к каждому слову и компоненту, — проверяем UX-копирайт на понятность без контекста — проверяем зависимость элементов друг от друга — задаем вопросы, которые возникнут в голове пользователя и пробуем найти на них ответы в рамках макета по принципу "чего не написано — того нет"(с) Отдельно выложи комментарии к вашим работам, но думаю каждый узнает себя в этом разборе: что совпало, а что пропустил. Тем кто не сдавал Домашку мой отдельный совет: начните смотреть, прочитайте задание и поставьте видео на паузу на 3 минуты — покрутите в голове задачу, подумайте как бы вы улучшили и что вас смущает, и потом запускайте видео разбора дальше. Очень рабочий способ сравнить свои варианты. 👍 Ждем следующую Домашку. Уже скоро. #edu

👑 Разбор Домашкипро новостные карточки. [30 min] #edu#razbor А вот и второй разбор для просмотра на выходных. В задаче про карточки новостей есть много хитростей, от обязательной проверки любого решения на большом количестве блоков в ленте... до конкуренции блоков между собой. Что внутри блока тоже рассмотрели: там есть куча сложностей с тегами, логотипом и последовательностью информации. С адаптивностью строки, в которой много блоков (и у всех разные по размеру заголовки) — тоже сложности. Все это легко использовать для ваших гипотез, что и как тут улучшить, если знать на что смотреть в первую очередь. Поверьте, я видел кучу мидлов, которые не справились с этим заданием на тестовых. Хотя казалось бы... Все решения можно глянуть в Figma. 👍 Лайк, если разбор полезный. И.... уже пора уже выдавать Майское задание? 😃

🧟‍♀️ §UX Proxy User. Это тип пользователя, который выполняет действия не для себя, а от имени или в пользу другого человека. Вы точно сталкивались с чем-то подобным. [16min/100mb] #edu В проектах, мы встречаем PU обычно в двух вариантах: это либо пользователь, который тестирует систему, либо самостоятельный Субъект, который выбирает такую особую стратегию взаимодействия с сервисом. Кто эти люди? Их гораздо больше, чем вы думаете: — сотрудник покупает что-то для компании или коллег — кто-то покупает подарок или карточку на которую этот подарок можно купить — помощники делающие что-то за вас — родители — ... В любом случае, когда Proxy User действует в чужих интересах, он закрывает какую-то свою потребность (например, его задача - купить подарок) — и вот тут есть куча вариантов для повышения конверсии, манипуляций, причинения добра и темных паттернов 🤌 В ГК есть такая конструкция - "агентский договор" и это тоже действия в пользу третьих лиц. Но там все сложно, а нам проще — пользователь не связан формальностями: не несёт юридической ответственности, не формализует отношения — не нужен договор. Ему просто хочется уже наконец выбрать этот несчастный букет 💐таким, чтобы он точно понравился девушке — этому Субъекту просто нужна ваша помощь 🤳 ❤️ героям, которые делают все за вас ⚡️

Решения участников Задачки апреля. #edu Начинаем выкладывать результаты. Первый шаг: в фигме примеры работ участников. По UX/UI задачке апреля про "Загрузку документов". Решения как обычно все рядом, но каждый подходит по-своему. Почему так, и кто что пропустил — разберем в видео. На что стоило точно обращать внимание: Неочевидный контекст использования: Непонятно, какие именно требования к документу — просто загрузить файл (?), сделать фото через камеру (?), или, например, сфотографировать с лицом (?). Для всех докумеентов требования будут совпадать или они будут разные в зависимости от типа. Статусы сильно повлияют на успешность всего сценария, а не только загрузку отдельного документа: Не загрузился / принят / загрузился, но не принят и др. Были и проблемные части, которые стоило пофиксить. Например, стоило устранить дублирование (два паспорта в примере) и доработать UI с PDF (зачем там вообще PDF 😪). Ну и много другого интересного, но это уже лучше я расскажу голосом. 😏

📗UX/UI Задача апреля. #edu В прошлый раз короткая домашка по UX хорошо зашла: не так пугает масштаб и позволяет быстро размять мозги. Сделаем такую же и сейчас. Рекомендуемое время на реализацию — 59,99 минут. ======================= Задание: Вы — дизайн-лид, которому попал в руки вариант вашего дизайнера. Ваша задача предложить улучшения. Опишите текстом свою версию и обязательно покажите новый вариант прототипа (можно с разными состояниями блока). Пока вы не знаете, какие именно документы нужно будет предоставлять — можете предложить свою версию. Проект международный, так что здесь может быть не только паспорт. Уточнение: Вам показана часть прототипа раздела «Информация о клиенте». Этот инфоблок должен: - быть понятным юзеру, - закрывать все сценарии, связанные с подтверждением личности пользователя, - учитывать предоставление разных видов документов, - покрывать возможные микросценарии. Что находится еще на странице (за пределами этого инфоблока) для решения данной задачи — не важно. ======================= Дедлайн — четверг 17 апреля (до полуночи). Ссылку на анкету для приема работ опубликую ближе к дедлайну. Ставим ❤️ если задание интересное и хочется посмотреть какие идеи предложат участники. Не подсказывайте другим в комментариях, пусть каждый сделает свой вариант.

§UX Preventative UX. Неожиданно, но вместо планирования сценария делаем всё, чтобы он НЕ состоялся. [16min/100mb] #edu Обычно мы проектируем сценарий, который ведёт пользователя к определённому результату и его последствиям. Но есть и другая модель — когда пользователь предугадывает вероятность наступления события или негативных последствий и проходит сценарий, который помогает их заблокировать. Похожий принцип используется в страховании: человек оценивает вероятность наступления нежелательного события и действует заранее, чтобы снизить урон или избежать последствий. Здорово, что таких сценариев становится всё больше. Хороший пример: на сайте госуслуг пользователь может заранее запретить выдачу кредита на своё имя, опасаясь, что мошенники оформят заём без его ведома, используя паспортные данные. В этом случае он исходит из предположения, что подобное действие возможно, и заранее принимает меры для его блокировки. Это пример предиктивного поведения: пользователь не ждёт, когда возникнет проблема (например, мошенническое оформление кредита), а защищает себя заранее. Такой паттерн связан с: — Профилактическим дизайном (Preventative UX) – созданием интерфейсов, которые помогают пользователям предотвращать нежелательные последствия. — Анти-фрод-паттернами (Anti-Fraud UX Patterns) – механиками, защищающими пользователя от мошенничества. Например, система предлагает установить сложный пароль или добавить телефон для двойной аутентификации, исходя из того, что негативный сценарий возможен, и сразу снижает вероятность его наступления. Как мы действуем? — Блокируем саму возможность нежелательного сценария (например, вводим прямой запрет). — Делаем сценарий невозможным без участия пользователя (например, для оформления кредита необходимо личное присутствие в банке). — Ограничиваем возможные потери (например, устанавливаем лимит на операции). — Минимизируем последствия. — Создаём «сценарий отмены» (например, если деньги были отправлены, пользователь может отменить перевод в течение суток). ❤️ Лайк, если считаешь такие сценарии полезными для людей.

👵👨‍🦳 § UX для людей в возрасте. Почему и откуда взялось заблуждение, что эта категория пользователей не может отличить смартфон от булыжника. Разбираем в чем их особенность и как учитывать это в своих проектах. И как так вышло, что даже Норман Нильсон живет все еще в парадигме нулевых, когда смартфон был чем-то новым для всех, а не только для бабушек и дедушек. #edu [15 min] Выбор темы не случайный. Сейчас как раз делаем интерфейс, которым активно пользуются пожилые люди + очень для разбора помог предыдущий опыт интерфейсов для этой аудитории. Никогда не знаешь, с чем придется столкнуться в работе. Хотя, доп. специализация на Medtech как бы намекает... Что можете погуглить на эту тему: Gerontechnology (Геронтотехнологии) – это направление, изучающее технологии, адаптированные под возрастные изменения. Age-Inclusive Design (Возрастной инклюзивный дизайн) – методология, учитывающая когнитивные и физиологические изменения у пожилых пользователей. Из книг, обратите внимание на "Designing User Interfaces for an Aging Population" – Jeff Johnson, Kate Finn. В ней подробно разбираются когнитивные и физические изменения, связанные со старением, и даются рекомендации по UX/UI. С вас лайк ❤️ если удивил с темой параграфа 😊