То пусто, то густо, ребята :) За пару дней много вкусноты подвалило, с чем и спешу разобраться. И так как на каждую статью разбор не попишешь, то снова придётся прибегнуть к формату дайджеста. Представляю вашему вниманию топчик за последние 4 дня:

👉 Если вы находитесь в фазе проверки продукта на соответствие рынку (модное market fit), то будет не лишним ознакомиться со статьёй, описывающей, как работать на этом этапе с OKR (objective key results). Обычно их ставят в уже работающих компаниях, где требуется конкретно очертить цели на год, но вот в условиях полной неопределенности, когда и продукта-то нет, что принимать за цель? Автор предлагает использовать OKR в качестве планомерного получения доказательств, что наш продукт находится в правильной позиции и на правильном рынке. А как это сделать — зацените внутри.

👉 Ретроспектива работника Google о том, как четыре его глобальные идеи провалились на этапе питча, и что важно, предполагает, почему это произошло. Навеяло на мысль, что мы тоже часто изобретаем «новый Uber» или открываем новый Голубой Океан, однако почему-то ничего не делаем для того, чтобы идею реализовать. Возможно это потому, что «нужно чё-та делать…», а может из-за недостатка поддержки. Если первое — это личное, то вот со вторым может помочь грамотный питч. Учимся на чужих ошибках.

👉 Офигенская статья от Tubik о пользовательском онбординге. Тут вам и цели, и классификация, и лучшие практики. Всё приправлено примерами и практическими рекомандациями, чтобы не передушить человека вводной информацией. Я кайфанул.

👉 И ещё одна статейка о том, как снизить когнитивную нагрузку форм оформления заказов. Выполнена в формате чек-листа, по которому можно идти и попутно улучшать вашу форму. К концу статья даёт несколько противоречивых советов. Например о том, что нужно заменить все селекты на инпуты, да и последний кейс с подтверждением скорее не про когнитивную нагрузку, а про удобство восприятия, но чего придираться — инфа годная.

👉 Для любителей особо жёсткого мазохизма представляю регрессивное тестирование компонентов в Figma. Этот особый сорт разврата предполагает, что вы будете сравнивать разные версии компонентов по каждому обновлению библиотеки. И не просто смотреть, что изменилось при помощи Visual Difference plugin, а смотреть, чтобы ничего не сломалось. А для этого используются отдельные проекты с тестовыми полигонами, где собраны кейсы тестов для всех компонетов. Чувствуете… О да! Зачем? Смысл в том, чтобы не нарушать работу дизайнеров и процесс разработки, вкрячивая баговые апдейты в ваш проект, чтобы тестировщики не заводили кучу багов, которые потом удалят. Но смысл этот появляется только при отлаженном дизайн-процессе, совместной работе и большом скейле.

👉 Очень крутое расширение для Chrome, которое отлавливает анимации на готовых сайтах, а за золотую монету, можно и самому их едитать. Значит разработчикам не придётся вырывать ногти, чтобы вы предоставили параметры анимации, а вы сможете посмотреть, как же работает та крутая свистоперделка, которую вы хотели реализовать и сами. Плагин работает с CSS, и может бажить с JS анимацией.

🍒 Вишенка на торте — решение позволяющее имплементировать в ваш проект «ускоритель чтения». Якобы визуальное выделение якорей для саккад (скачков вашего зрения), способно облегчить чтение и увеличить его скорость. Тема скорочтения спорная, космические цифры о 10 000 слов в минуту явне не вызывают доверия, и при этом прирост скорости в 30% без потери качества кажется реальным. Но куда это воткнуть… Я просто оставлю это здесь.

На этом всё. Спасибо, что читаете, ставите пальцы вверх и сердечки! 🛳❤️

Друзья, приветики! Если вам нечем заняться в этот чудесный вечер, я предлагаю вам окунуться в мир букв. Если вдруг для вас, как и для меня, новость прошла мимо, то спешите лицезреть. Google перерезала ленту в новый раздел Google Fonts, посвященный образованию в области типографики. Помимо теоретической базы о том, что такое глифы, начертания, пунктуация, Open Type и многое другое, внутри лежит практический раздел о том, как подбирать шрифты и использовать знания в работе. Приятным бонусом ко всему будет словарик непонятных терминов :) Приятного чтения. ⚡️

Когда препарируете конкурентов или просто проводите обзорное исследование, в вашей голове может возникнуть мысль сравнить рейтинги приложений, как количественные данные… как вы можете заметить, это не всегда хорошая идея. Данные нужно чистить :)

Буквально недавно я делал босяцкий обзор Framer Sites, где галопом по Европам обозрел некоторую функциональность и восхитился гибкостью создаваемых решений и простой публикации в web. Но к сожалению, всё это недоступно, так как функционал был в Бете... но теперь нет! ))

Сегодня было объявлено о том, что ныне каждый сможет попробовать, каков Framer Sites в деле. Подходите, берите, ни копейки не платите!

Есть правда, несколько «НО»: если вы хотите разблокировать весь спектр возможностей для вашего сайта, деньги на бочку придётся положить. Например, просто так кастомный домен не прикрутишь, количество записей в CMS будет ограничено, как и аналитика пользователей и поток трафика.

Но есть одно «НО» на прошлые «НО» — это вообще нисколько не помешает вам затестить новый инструмент и взмыть в небеса нового уровня возможностей :)

Ребята, срочно, пришла телефонограмма «⚡️Молния⚡️»: если кто хочет послушать про этику в дизайне, про этичный продукт, процесс и т.д. — милости просим на прямой эфир с Никитой Потапенко. Там можно будет и каверзные вопросики позадавать :) Начинается всё в 18:00. Буду рад вас видеть.

Мне очень зашла эта статья о том, как дизайнер с двадцатилетним стажем столкнулся с ностальгией: в век тачскринов с высоким разрешением перед ним стала задача собрать прибор используя только кнопки, сегментированные панели и переключатели. Это не те, которые Radiobuttons, а те, которые мы ласково называем «тумблерами».

И знаете что? Ему понравилось о он сформулировал плюсы аналогового проектирования:
Тактильная обратная связь. Благодаря осязанию вы точно будете знать, нажалась кнопка или нет, и насколько вы увеличили какой-то параметр покрутив такой приятный регулятор. Здесь я хочу добавить ещё улучшенную точность настройки из-за специфики самих контроллов.

👉 Супер-низкие цены. Для того, чтобы прифигачить кнопку достаточно её физически подключить, а вот чтобы запустить GUI нужны более сложные платы и чипы, что значительно увеличивает себестоимость.

👉 По тем-же причинам можно отметить сниженные затраты на написание програмного обеспечения: на аналоговых компонентах нужно писать только логику, в то время, как для цифровых компонентов нужно ещё заботиться об их отображении.

👉 Надёжность компонентов. Компоненты выполняют одну задачу, но делают это превосходно, что значительно снижает отладочные затраты, и увеличивает надёжность всей системы за счёт распределения рисков. Если одна кнопка перестанет нажиматься её можно либо заменить, либо выполнять задачи без её участия (помните джостики в Sega, где залипала кнопка блока в MK3?). Аналогично, если выйдет из строя тачскрин — тю-тю.

👉 Компоненты не могут быть перепрограммированы. Казалось бы — это ограничение, а не преимущество. Но вот вспоминаешь радиобатоны-чекбоксы или кнопки-ссылки и сразу не до смеха. Вдобавок это помогает не расслабляться и искать элегантные решения.

Однако, ради справедливости, стоит отметить и ряд недостатков аналогового проектирования:
— Низкая адаптивность к среде и пользователю,
— Сложность локализации,
— Предвзятость пользователей, и отношение как к чему-то архаичному.

В общем, лично я, в следующий раз подумаю при проектировании какого-нибудь прибора, нужно-ли полагаться только на GUI, или можно обойтись аналоговыми компонентами. И не только из-за вышеперечисленных преимуществ. Основная причина — это доступность, ведь любой прибор или продукт закрывает человеческую потребность. И для всего человечества будет выгодно, если эта потребность будет закрыта эффективно. И я говорю не только о дешевизне, скорее о балансе цены и качества и разумном потреблении природных ресурсов. К сожалению, с точки зрения маркетинга, это не всегда верный путь, но это не значит, что не нужно пытаться. 🛳❤️

Всё думал, о чём же написать ещё, чем порадовать. Уже было хотел поделиться отчетом о зарплате UX-копирайтеров (у них там всё хорошо, если вы волновались), но вдруг вспомнил, что у нас есть свежатина на канале: тот самый цикл лекций от Никиты Потапенко и Анны Бондаренко об этике в дизайне.

👉 В первой лекции, мы коснулись этичного процесса дизайна.
👉 Во второй узнали, что такое этичный продукт.
👉 Третья лекция поведала о том, что есть Diversity and Inclusion в формате воркшопа от Анны Бондаренко.
👉 Ну и конечно, не обошлось без вопросов-ответов с автором курса.
👉 А вот здесь, мы уже с другим Никитой, делились впечатлениями после закрытого показа лекции.

Приятного просмотра, надеюсь этот материал поможет нам стать более осознанными и с чистой совестью выполнять свою работу.

👍Отличный пример того, как информирование может менять поведение. Дизайнер из Яндекса представила кейс, в котором рассказала, как применяли новый алгоритм выявления агрессивных водителей. Благодаря ему, снизился процент такого поведения на дороге. К сожалению, остаётся за скобками причина таких изменений: толи водители начали видеть, где они лихачат, толи всех лихачей забанили к чертям. Но я предпочитаю верить в лучшее :)

Забавно, что меня больше захватил сам алгоритм, нежели процесс работы над его визуализацией. Процесс, к слову, ничем не выделяется и напоминает о ностальгической молодости. Тогда было просто: есть задача → вот решение → не подходит → повторим. Романтика.

Спасибо Сергею за подгон.

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

👉 Разберёмся с основными метриками,
👉 Узнаем, что не так с воронками и анализом кликов,
👉 Что делать, чтобы анализ не сбоил,
👉 Посмотрим, как правильно измерять успех, если ничего не понятно.

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

А вы помните о вашем дизайн-долге? Да, том самом, который вы любезно отложили в шуфлядочку и, под кивания головой команды разработки, благополучно забыли. А может и не забыли, и тот факт, что во взаимодействии есть дыры, костыльки и уступки заставляет вас просыпаться по ночам? Нужно, что-то делать.

А вот как раз и статейка в тему: «Платим по своим дизайнерским долгам». Это третья статья цикла о дизайн-долге в которой описан сам процесс оплаты.

Для начала, вам нужно чётко разделять 💸дизайн-долг и 💩дермово спроектированный опыт. Дизайн долг — это осознанная мера, компромисс, на который вы пошли, для того, чтобы не останавливать процесс разработки или чтобы нанести больше пользы в меньший промежуток времени. Зачастую, долг носит накопительный характер, и требует времени на поддержку, в то время, как дермовое взаимодействие «никому не мешает» и есть не просит. Оно просто плохое и единственный способ это исправить — полная переделка.

После того, как вы провели аудит вашей зоны ответственности, систематизируйте ваш долг и разбейте на стори. Например, вот какие атрибуты вы можете использовать:
👉 Название.
👉 Описание.
👉 Размер. Здесь можно обойтись T-shirt моделью или «Собаками», чтобы просто обозначить относительный объем задачи.
👉 Область продукта. Долг касается взаимодействия, внутреннего деливери, командных взаимоотношений или чего-то ещё.
👉 Зависимости. Долг может пускать метастазы в разные отделы и команды, потому так сложно оценить и объем и влияние и важность.
👉 Влияние. Можно определить по стандартной приоритизационной схеме «Усилия / Результат».
👉 Важность. Насколько решение «горит» для всех участников процесса.

А дальше дело за малым: определиться с тем, какую проблему решать. Здесь автор использует два критерия:

— Если расходы на текущее поддержание > расходы на разработку,

— И если выплата долга открывает нам значительные возможности для улучшения.

Ну и после всего этого, конечно, нужно построить краткосрочный и долгосрочный планы и их придерживаться. На каждом планинге отламывайте кусочек слона и жуйте весь спринт, делиться успехами и тем, как работа с долгом изменила жизнь продукта — фидбэки, цифры, шантаж, похищения, угрозы.

Обязательно зацените ещё 2 статьи из цикла:
— Что такое дизайн-долг?
— Как измерять дизайн-долг?

Не так давно я поделился в сообществе наскоро собранной базой знаний для дизайнера, но боюсь, что течение беседы унесёт ссылку в заоблачные дали. А чтобы её можно было найти, я увековечу её здесь. Внутри находится:
👉 Конечно, много материалов для прокачки, категоризированных по навыкам и типам,
👉 Несколько психологический упражнений на прояснение целей,
👉 Вопросы для самооценки уровня,
👉 Ожидания от этих самых уровней.

Если будут какие-то идеи и предложения — пишите мне. Всем замечательного четверга 🛳❤️

🤟Антон Григорьев, автор канала UX Notes растолковал за функциональную спецификацию интерфейса и поделился опытом создания этого артефакта.

Общаясь с командой разработки, мы часто отвечаем на вопросы о том, как что-то должно работать. На прототипе всего показать невозможно, а если и получается это сделать, то для команды не очевидно, куда нужно смотреть и на что нажимать. Приходится устраивать часовые сессии с обзорными экскурсиями.

🧽А если проект долгоиграющий, то и разработчики там меняются — «бери мочало, начинай сначала».

Проблему эту решают по-разному: тратить время на разъяснения, или обзаводятся источником правды и ссылаться на него, когда возникают споры, конфликты и понажевщина. Источник правды решает.

Мы на проекте использовали zeroheight для этих целей и проходило все гладко: если мы принимали какое-то решение, то оно сразу фиксировалось и у всех был к нему доступ.

Однако, когда речь идёт о заказчике, который не слишком-то желает вникать в тонкости использования современных технологий, гораздо проще и понятнее работать в формате, который предлагает Антон: создать документ с описанием основной логики продукта, дополняющего прототип.

📘Напомнило мою пояснительную записку к дипломной работе, где я рассказывал, как работает интернет-магазин :) Забавно, но именно такую записку мы и писали заказчику на проекте, чтобы зафиналить PoC и подписать контракт. Опус занял 120 страниц, зато вопросов потом было... Не было вовсе.

Так что однозначно советую ознакомиться с трудом Антона и подписаться на его канал :)

🤔 Что значит быть лидером? Это когда ты принимаешь все-все решения? Когда тобой восхищаются и хотят идти за тобой на край света? Или это когда ты можешь заставить людей делать то, что им не нравится? В моём понимании, лидерство — это ответственность, которую ты на себя берёшь и с каким настроением ты это делаешь. Основное отличие менеджера от лидера в том, что менеджер отвечает за продуктивность людей: рабочий процесс, сроки, инструменты и т.д. То есть делает так, чтобы людям ничего не мешало делать их работу максимально эффективно. В тоже время лидер подаёт пример собственным поведением, вдохновляя и мотивируя так, чтобы работу хотелось делать. Но если вдаваться в детали, то я тут набрёл на статейку с примерами того, кто такой лидер.

В ней, автор предлагает 6 рабочих обязанностей лидера:
💍Сваха — женит интересы человека с интересами бизнеса,
🛳Капитан — видят полную картину происходящего и направляют команду по лучшему курсу,
🤝Дипломат — представляет интересы всей команды за столом с большими дядями,
📣Болельщик — хвалит, когда нужно и вовлекает в процессы,
🪴Садовник — планомерно, шаг за шагом культивирует окружение и растит команду,
🏋️‍Тренер — каждый день улучшает показатели качества всей команды.

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

Но саму статью тоже обязательно прочитайте :)

Сегодня вечерком мы соберемся с ребятами, чтобы немного потрещать за дизайн, а заодно перемыть косточки кассам продажи билетов. Будет интересно, приходите 😊
Работы и предложения для разбора на следующих выпусках можно слать через такую форму.
А экспертом стать, через вот такую.

🎙Посидели душевно с ребятами на 2.5 часа. Понаразбирались зато! Для тех, кто пропустил стрим мы его аккуратно, не трогая, положили на ютюбчик, с таймкодами, и всяким описанием. А если не хочется смотреть 2.5 часа, то вашему вниманию выжимка некоторых выводов из нашей беседы.

В общем, если вам нужно создать кассу билетов, то:

1. Уделите внимание выбору языка. Хорошей практикой будет использовать локальные названия стран с имоджи их флагов.

2. Тестируйте выбор на разных платформах и устройствах. Возможно, использование стандартных контроллов не такая хорошая идея.

3. Формируйте правильные ожидания и используйте ментальные модели пользователей для проектирования.

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

5. Календарь — мощная штука, не нужно ограничиваться стандартным набором из двух календарей. Можно сделать его полезнее за счёт информации о наличии свободных мест или цен на билеты.

6. Не нужно использовать дополнительные связи календаря и выбора режима «в один конец»/«с обратным билетом».

7. Скрытые поля формы скорее занижают ожидания, нежели больше вовлекают пользователя (тем более, что на старте их не так много). Делите на логические шаги только большие формы, а маленькие оставьте открытыми. Так вы увеличите аффорданс.

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

9. Если куда-то полететь нельзя — не показывайте, зачем людям дополнительные надежды.

10. При выборе маршрута лучше сразу указывать количество пассажиров с дефолтным значением «1». Так мы сможем отсечь результаты, которые не подходят при путешествии с друзьями или семьёй, вместо того, чтобы проверять каждый.

11. Однозначно дифференцируйте полёты с пересадками, и обратные рейсы: можно просто написать лэйблы, развернуть самолётик или поставить стрелочки в нужных направлениях.

12. Использование ползунков в виде фильтров — грех. Для вас уже готовят котёл.

13. Также, если билетов по нужному маршруту нет, можно подписаться на обновления.

14. При отсутствии билетов на нужные даты предлагайте альтернативы: или даты или средства передвижения.

15. Время загрузки можно использовать с пользой, обучая человека тонкостям работы: рассказать про программу лояльности, отзывы, хотекеи. Главное дать достаточно времени на изучение, даже если страница загружается быстро, и возможность скипануть.

16. Выносите за скобки только не нужную информацию (год, секунды), а нужную оставляйте там (информация о рейсе, маршрут).

17. Будьте лояльны к ошибкам пользователя — «Ну забыл переключить раскладку, ну что такого?»

18. Однозначно показывайте разницу в классах билетов: если получится, опишите различия в виде сравнительной таблицы (feature list) или покажите разницу визуально, используя фотографии.

19. При выборе мест, используйте чёткую легенду мест, с указанием цен. Помните про доступность и выбирайте верные цвета.

20. Не нужно полагаться на выбор режимов (табы) для выбора мест на рейс. Лучше разделить на два шага.

21. Визуальные схемы самолётов, поездов и автобусов помогают выбрать правильное место и донести преимущества, но стоит быть аккуратными с данными и перепроверять, как это работает для разных самолётов/поездов/автобусов.

22. Для введения даты рождения гораздо эффективнее использовать три поля и механический ввод, чем календарь.

23. Продавая дополнительные услуги ваша задача сделать так, чтобы человек захотел это приобрести. И лучший способ здесь не лить воду в тексте, а показать, что из себя представляет услуга через визуальные образы.

24. В агрегаторах, во время выбора ресейлера (если вы не продаёте билеты сами) желательно формировать ожидание, что сейчас пользователь будет перенаправлен на другой сайт.

25. Не разносите кнопки сабмита и саму форму, а тем более не прячьте их за куки-баннер. Это же очевидно.

26. Потратьте немного времени на проектирование билета и композицию с учётом потребностей пользователя: ему не так важно видеть сколько он уже потратил и сколько мест купил, как то, когда отправление поезда, какие у него места.

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

Вот так вот :)

☀️Подгончик на выходные. Если будет желание почитать что-то клёвое и поэкспериментировать с чем-то интересным, то советую «Ультимативный гайд по дизайн-токенам». Не в том плане ультимативный, что «так и никак иначе», а в том, что обязателен к прочтению :)

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

Но кажется будет вторая часть, так как всех деталей работ с токенами не упихнуть в одну статью. А также не хватает комплексных конкретных примеров: как кнопку сделать и показать принцип — дело одно, но вот начнёшь делать что-то сложное, как, например ночную тему, где нужно не только с цветами работать, но и условиями — тут уже всё не так радужно.

И при этом, в копилочку полезных материалов эта статься отправляется однозначно.

Недавно впал в ступор стараясь определить, как правильно стирать новые шорты. Если думаете, что это легко, то попробуйте сделать это для одежды, в которую вы облачены, пока читаете эти строки. Посмотрите на этикетку. У меня для вас несколько вопросов. С утюгом всё понятно, а сколько точек там максимум? Что означает треугольник? А круг? А квадрат? Если вы давно в стирочном бизнесе, то, может, и без труда ответите на эти вопросы, но если вы, как и я — 🤯

Но мы такие не одни: автора следующей статьи тоже ставили в ступор эти пиктограммы, потому он и решил их переделать. Получилось, на мой взгляд, не совсем удачно, так как новый вариант изобилует мелкими деталями, что сделает их нечитаемыми на мелких ярлычках, а некоторые знаки так и остались непонятными. Хотя значительные сподвижки всё-таки есть: теперь есть чёткое различие машинной и ручной стирки, а также стало понятнее, что скрывал квадрат.

Хотите, проведём конкурс на переделку? Тогда собираем 100 лайков )

Ds rjulf yb,elm… Блин. Вы когда-нибудь писали сообщение, которое приходилось стирать из-за неправильной раскладки? А как насчёт пары матерных слов, которые вы выкрикивали, когда пароль «не подходит», хотя вы нажали Caps Lock?

Помню, как я подумал, что сломал фотошоп, когда какой бы цвет я не выбирал, кисть всё равно рисовала красным. Только потом я узнал, что это был режим создания маски. 🥲 С тех пор у меня пунктик по одной из эвристик Нильсена — явно обозначай режим работы системы… а лучше избегай как огня использования разных режимов. Хотя избавиться от них полностью никогда не получается.

Взять к примеру хоть режим работы сервиса без доступа к интернету. Если вы работаете над классическим веб-сервисом, то и проблемы нет — пользователь просто не сможет подключиться. Но если ваш сервис использует сеть только чтобы сохранять изменения, или это тот же PWA, то вам придётся сказать, что сейчас интернета нет, так что изменения не сохранятся сразу.

Если ситуация вам не чужда, советую ознакомится со статьёй о работе с режимами. Если кратко, то проблемы с ними можно разбить на 2 типа:

👉 Проблемы с нахождением переключателя режимов. Это когда вы во время презентации пытаетесь найти кнопку «Пошарить экран» в корпоративной туле заказчика и тянете это «Ooooooooooneeeeee seeeeeeeecoooooooond… Alrightcanyouseemyscreen?»

👉Проблемы нечёткой индикации, когда человек может «провалиться» в другой режим и так этого не заметить.

Лечатся эти проблемы простым набором действий:

1. Подумайте, нужен ли другой режим: нет режимов — нет проблем.

2. Если режимы неизбежны, то подумайте над тем, как пользователи будут переключаться между режимами, и где в этом процессе могут быть проблемы со случайными переключениями.

3. Формируйте ожидания от переключения режимов: хинты, типсы, видео-демо.

4. Чётко обозначайте в каком режиме находится система: нотификации, рамки, тосты — всё идёт в ход.

5. Чётко очертите «дорожку к выходу» из режима. Чтобы это не было дверью без возврата. Лучшим решением будет тоггл — где вошёл, там и вышел.

6. Будьте толерантны к ошибкам, давайте возможность отмены или поставьте «естественные ограничения» в виде подтверждений.

Вот так вот. Всем прекрасного xtndthuf… БЛИН!

Доброго вечера, ребята :) Завтра в это же время, только на час пораньше состоится наша вторая критик-сессия с моими коллегами Артёмом и Илоной (автор канала Поясни за UX).

Посмотреть можно будет по ссылке, а пока там забавный тизер, из которого узнаете, что критиковать-то будем :)

Всех жду, обещаю, что не затянем :)