Поясни за UX. Страница 5
6449
@Poyasnizaux
Интерфейсы здорового человека
-
Поясни за UX
Привет, махарошики, сегодня немножко ссылок: 1. Ира присоединилась к моей команде чуть меньше 4 месяцев назад. Я спросила ее "Ира, что тебе интересно, чем ты хочешь заниматься?". Один из ответов был "доступность". И мы стали разматывать этот сложный клубок. Ира выложила первую статью (будут еще), которая посвящена плагинам. Бонус: почитать на канале про доступность можно в этом посте, вот тут рассказываю про Android Accessibility, тут как тестировать, а тут список плагинов ---- 2. Мамкин Дизайнер нашел в твитстере слив про обновления в фигме. Кажется, нас ждет автоперенос на новую строку 🙏 ---- 3. Чюваки из альфабанка написали балдежную статью про корреляцию между результатами опросника SUS (я часто его использую и даю студентам) и эмоциями. Спойлер: ее нет. И еще они описали как оценивать эмоциональность богатым (с нейросетью) и бедным (с опросниками). С опросниками, разумеется, хуже. -
Поясни за UX
Предположения и продуктовые гипотезы В бытовом смысле гипотеза – это наше "наверное" по поводу чего-либо. И многие проектировщики и исследователи любое свое ожидание/предчувствие/рассчет называют гипотезой. Перед началом какой-нибудь микроскопической коридорки торжественно пишут в документик заголовок ГИПОТЕЗЫ, за которым следует список формулировок по типу: - пользователи поймут куда нажимать чтобы купить товар - пользователям будет легко выполнить задачу - пользователи захотят пользоваться нашим приложением Как проверять такие "гипотезы" (особенно последнюю) – тема отдельного поста. Сейчас давайте примем тот факт, что это не то чтобы очень гипотезы в продуктовом смысле. Такие формулировки лучше назвать предположениями, ожиданиями или как угодно еще, но не продуктовыми гипотезами. Продуктовая гипотеза – это специфичная конструкция, важное свойство которой - достоверная проверяемость. Спросить 3 человека на коридорке, получить разнородные ответы и сидеть довольным ≠ проверить продуктовую гипотезу. 1. Продуктовая гипотеза проверяется цифрами. Их можно получить разными способами: дата-аналитика, количественные исследования, конвертация качественных данных в количественные. Поэтому мы всегда думаем о том, какую метрику будем измерять, чтобы проверить гипотезу. И мы всегда сравниваем метрику нового решения с тем, что есть сейчас. 2. Продуктовая гипотеза состоит из 4 кусков: 🍓наше действие (что меняем) 🍓ожидаемый результат (изменение метрик(и)) 🍓цифра/процент изменения метрик(и) 🍓срок (время исследования гипотезы) Это делает понятным что делать, как понять что гипотеза проверена, сколько по времени будем проверять. Шаблон формулировки у меня лично такой: "Если мы... , то получим ... на... за...". Если мы поменяем визуал в карточке товара, то получим рост конверсии в покупку на 2% за 2 недели Если мы закрепим первую колонку в большой таблице, то получим рост скорости выполнения задачи на 5 минут за неделю. Если мы добавим геймификацию, то получим рост ретеншна пользователей на 10% за 3 месяца. Клубнички 3 и 4 не берутся с потолка, на самом деле. Чтобы их сформулировать нужно выбрать уровень статистической значимости (насколько вероятно, что новый вариант не херня) и мощности (насколько вероятно, что текущий вариант не херня). От этого зависит длительность эксперимента и количество респондентов. Калькулятор даже для этого изобрели. -
Поясни за UX
Вайб оператора фигмы #мемнаясреда -
Реклама
-
Поясни за UX
Личный кабинет СМ-клиники как апофеоз бессмысленности контента на главной, гигантизма, ужасного подбора иконок и цветов 🫰 
-
Поясни за UX
Хотела написать для вас умный пост про гипотезы, но вместо этого истерично смеюсь над пьесой Ильяхова, которую запостила моя подруга в своем пабличьке. Конец года, что вы хотели -
Поясни за UX
POV: дизайнер сделал CJM и презентует ее команде #мемнаясреда -
Поясни за UX
Лид Пост филасафский и строго субьективный. Возможно, эти рассуждения помогут вам осознать себя как лида (если вы уже) или то, к чему вы хотели бы стремиться (если вы еще не). А может, понять, что к вашему лиду есть вопросики. Или ко мне, кек. Лиды бывают разные: чёрные, белыепродукта, дизайна, разработки, редактуры и всякого еще, что требуется сервису для успешного развития. Получается такая кросс-функциональная команда из ведущих. И первое важное: эта команда должна работать как команда. Мало просто обмазаться подчиненными и принимать решения в рамках своей зоны ответственности. 🔔 если ты-лид или твой лид не коммуницирует с лидами других команд, это звоночек. И да, Lead переводится как «вести». Слово «вести», в первую очередь, навевает вопрос «куда». И лид должен давать на него ответ. Куда и почему идем (как в рамках спринта так и в долгосрок) - это плоскость стратегии. Чтобы сформулировать стратегию, надо много чего знать и много за чем следить (спасибо кэп). 🔔 если ты-лид или твой лид не думает про стратегию и не объясняет команде в рамках каких долгосрочных целей они делают ту или иную задачу и куда двигаются в целом, это звоночек. Вести надо не только команду, но и продукт. То есть зона ответственности лида делится на 2 куска: продукт и команда. Продукт - как помогать пользователю, как приносить больше прибыли бизнесу. Команда - как сделать так, чтобы людям было комфортно работать. И вот тут, пожалуй, ключевая мысль этого поста. Несмотря на то, что моделей лидерства много (в том числе авторитарных), моя позиция такова: лид/менеджер/руководитель нужен, в первую очередь, для того, чтобы создать лучшие условия для работы команды. А это куча аспектов от стратегии и планирования до помощи с решением конфликтов и заменой оборудования. Лид – это не учитель, злой начальник или любимый старший брат. Я бы сказала что это (обоже😱) персонал, обслуживающий свою команду. Безусловно, лид должен не пропустить лажу в прод. Но это не значит, что инициативы команды должны жестко резаться и что у членов команды атрофируется мышца принятия решений. 🔔 если ты-лид или твой лид склонен "царствовать", единолично принимать решения и использует субьективное мнение как аргумент, это не просто звоночек, это колокол. -
Поясни за UX
В одном из отелей Исландии есть кнопка — разбудить, когда начнётся северное сияние. Вот что бывает, когда сервис проектирует решение, опираясь на потребности пользователей, а не на свои влажные фантазии. Будь как отель в Исландии: думай, с какой проблемой/желанием пользователей помогает твой интерфейс. 
-
Поясни за UX
Джун, залетевший в стартап после курсов vs сеньор, который там уже три года #мемнаясреда -
Поясни за UX
Я, может, слоупок, но буквально вчера в чятике узнала, что есть сервис, где много реально годных тестов на знание UX, accessiblity, типографики, визуального дизайна, исследований и даже UX-райтинга. Куча короче. И тесты такие, скажу я вам, не самые простые. Даже я, пока проходила, пару новых слов узнала. Короче, совет такой: берите блокнотик, проходите тесты, выписывайте все, чего не знаете и изучайте потом. Если што, там все на английском. -
Поясни за UX
Фичеризм - это, например, когда на диспенсере мыла за каким-то чертом есть датчик температуры воздуха. В какой момент жизни, намыливая руки, я такая: «как-то холодно в ванной, интересно сколько градусов?» Я прям вижу это собрание на производстве: «диспенсеру не хватает изюминки… что можно сделать, давайте ПОШТУРМИМ» 
-
Поясни за UX
Жизнеутверждающая #мемнаясреда -
Поясни за UX
User flow и Information architecture diagram В субботу я проводила разборы портфолио в прямом эфире и в очередной раз встретила супер-частую ошибку: путать юзерфлоу и схему информационной архитектуры. Давайте договоримся: я рассказываю о разнице и почему это важно, а вы больше никогда не путаетесь 🤝 ☝️Userflow - блок-схема, состоящая из прямоугольников (действия пользователя), ромбов (условия для переходов) и стрелок (переходы). Нужна чтобы показать какие шаги пользователь совершает в рамках определённого сценария для выполнения какой-то задачи. То что подчеркнуто - принципально важно. Юзерфлоу помогает описать последовательность действий пользователя, у которых есть начало (старт) и конец (выполнение задачи). Если есть вариации что человек сделает, мы обязательно пишем условие, чтобы понять в каком случае каким путем юзер пойдёт в рамках своей задачи. Схем юзерфлоу может быть много, так как задач у пользователя бывает множество: получить новый паспорт, подать документы, заплатить штраф - это все разные задачи, а сервис для них один (тут могла бы быть контекстная реклама, но мне за нее не платят). ✌️Карта (диаграмма) информационной архитектуры - «слепок» структуры разделов, фактически карта сайта. Никакого сценария она не показывает, потому что: 1. Не живет в рамках конкретной задачи пользователя 2. Не содержит переходы и условия, т.е. не описывает действия пользователя Это просто древовидная (как правило) схема структуры интерфейса. Помогает понять какие есть разделы и подразделы, как они называются. Является основой для навигации (меню, хлебные крошки, поиск). Схема ИА всегда одна. 🤞 Два этих артефакта решают принципиально разные задачи, поэтому их нельзя смешивать. Вот в этом фрагменте разбираю данную ошибку и объясняю разницу на примере ❤️ -
Поясни за UX
POV: ты предложил провести опрос, но не понял как сделать зависимости в google forms #мемнаясреда -
Поясни за UX
На Хабре написали почему курсор мышки во всех операционках такой маленечко кривой. Я думала, там глубкая эргономика иконки-как-продолжения-руки, и еще чтобы меньше загораживать контент, но… прост на заре GUI пиксели невозможно было ровно поставить в ряд, поэтому решили наклонить под 45 лол Обожаю это, конечно. Дизайнеры такие: «интуитивно понятные интерфейсы удобны потому, что попадают в ментальную модель пользователей…», а на деле куча этих самых «интуитивно понятных» – просто залепа, которая прижилась и все привыкли -
Реклама
-
Поясни за UX
Устала пока читала требования к паролю 
-
Поясни за UX
Мммм #мемнаясреда собственного производства -
Поясни за UX
Продуктовая vs проектная работа Как дизайнер, 5 лет проработавший в аутсорсе а затем перекатившийся в продукт, хочу немного развеять туман непоняток вокруг этих двух формаций. На первый взгляд разница не то чтобы большая. И продукт и проект - это длительная работа (год+) над сервисом. То есть, на студию/фриланс, где задача «сдать как можно больше как можно быстрее», это не похоже. Но. 1. Проектная работа подразумевает наличие клиента. И многое (порой даже слишком) будет зависеть от него. Цели, задачи, приоритеты, утверждения вы получаете от клиента. И, если клиент не эволюционировал из заказывателя в более высокую форму жизни, то вас постоянно будут склонять к роли оператора фигмы, а круг вашей ответственности и возможностей будет довольно узким. Даже если вы синбор или лид. 2. Проектная работа конечна. Да, она может длиться годами. Но все равно клиент рано или поздно поставит точку в ваших отношениях . 3. В проекте другие исследования. Часто думают, что в проектной работе исследования это вообще какая-то утопия, а вот в продукте ими можно обмазаться. Но на деле исследования можно настроить везде. Они просто будут разными. В проекте, как правило, ограничено время и нет большой аудитории. Поэтому упор делается на качественные исследования и коридорные тесты. После каждого такого дискавери выгребается куча инсайтов и делается новый дизайн и собирается обратная связь. В то время как в продукте исследования, в первую очередь, количественные, а изменения более точечные. Чаще используются быстрые методы типа SBS, Ask the crowd, A/B и опросы. За счёт большой аудитории есть возможность обмерять ключевые фичи и наблюдать за динамикой. На основе цифр формулируются гипотезы, под которые делается дизайн. Далее все это уходит в эксперименты (на проде несколько дней-месяцев катаются варианты дизайна и сравниваются метрики). По итогу, в продукте часто имеем причинно-следственную слепоту, когда вопрос «почему такие цифры» не задается или задается плохо. А что общего? Общие, какая неожиданность, проблемы. 1. Задачи могут приходить в виде «подвинь кнопку». Мы все очень ждём задач в виде проблем (писала об этом тут), над которыми можно подумать. Но бывает, что клиент или продакт не видит вас «частью корабля» или не может в формулировку проблематики. Этому надо обучать и в продукте и в проекте. Я вот, собсна, этим успела позаниматься и в ЕПАМ и в Яндекс 2. Нужно строить дизайн-процесс. Он может выглядеть по-разному, но процесс планирования, получения задачи, исследований, дизайна, валидации и передачи в разработку нужно продумывать и улучшать. И никогда он не бывает одинаковым. 3. Нужно много общаться. Рассказывать о себе и своей ценности. Показывать что ты можешь сделать. Быть проактивным и не бояться, что предложение не примут. Бытует мнение, что в продукте можно больше влиять, и это да (за счет отсутствия клиента). Но порой попадается авторитарный продакт. Или в проекте может быть крутой клиент, который рад предложениям. Всякое бывает. Везде надо лезть и предлагать. Брать и делать. —— А еще у меня есть статья про разницу аутсорса, фриланса и продукта с цитатами моих прекрасных коллег. Поясни за UX Стартапы и исследования Кажется, что попасть в стартап – очень круто. Мало народу, много амбиций, все с нуля, есть возможность влиять. И вот вы, мечтающий запустить дискавери, построить CJM и сделать доброе вечное с нуля, встречаете стену. Давайте разберемся почему. Заходя в стартап, вы неизбежно сталкиваетесь с его владельцами и руководителями. И тех, кто вас нанимает, бывает два типа: 1. Заказыватели дизайна. Это люди с четким видением, идеей, часто с набросками интерфейса. У таких ребят есть какие-то исследования аудитории (чаще всего маркетинговые), они поспрашивали потенциальных пользователей (чаще всего вопросы-предсказания вида "а стали ли бы вы пользоваться сервисом") и они убеждены в правильности и актуальности своей идеи. Они в свою идею влюблены. Такой команде не нужно исследование, им нужны экраны, отрисованные в соответствии с задумкой. Они привлекают вас на поздней стадии, когда уже и ТЗ написано, и аудитория сегментирована и план готов. Интересность вашего мнения для заказывателей находится…
