Поясни за UX. Страница 7
6449
@Poyasnizaux
Интерфейсы здорового человека
-
Поясни за UX
Почему джуны не должны собирать UI kitы Казалось бы, разве может быть упражнение лучше для новичка? Сажаешь его собирать компоненты, он там и систему изучает, и крафтить учится и в прод херни не тащит. Дорогие лиды, артдиры ну или как вам приятно себя называть! Не надо так. У начинающих очень медленно отрастает понимание того, что такое шаблон и что такое компоненты интерфейса, какие у них могут быть состояния и как они должны выглядеть, что есть атом, а что молекула, как это все связано с разработкой, что важно, а чем можно пренебречь. Скинув на джуна сборку UI kitа, вы обрекаете себя и команду на вечные доработки и переделки, на рассинхрон с разработкой и странные технические решения (вроде групп вместо фреймов, невменяемых названий, лишних контейнеров, отсутствия автолейаутов и ресайза). Привлекать новичка можно только в рамках сборки простых компонентов вроде кнопок/чекбоксов. При этом надо четко прописывать состояния компонента, их поведение и ревьюить результат, примеряя его на разные разрешения и макеты. Хорошее упражнение для джуна - написание гайдов по применению собранных старшими компонентов. В рамках этой активности они будут вынуждены общаться с разработкой (чтобы тем все было понятно), другими дизайнерами и просматривать уже существующие экраны, чтобы найти все кейсы применения и обнаружить среди них закономерности. Обязательно при этом разобраться с атомарным подходом (прям разобраться а не чисто полистать), научиться мыслить тупыми компонентами и набить голову общепринятыми UI-паттернами. -
Поясни за UX
Когда порядок слов имеет значение. Афиша просит ваш телефон для обратной оперативной связи. С товарищем майором, видимо 
-
Поясни за UX
Ушла эпоха Ожидаются осадки в виде крушения фигмы и пожирания операционки www.figma.com/blog/a-…th-adobe -
Реклама
-
Поясни за UX
Кто забыл, что сегодня среда - тот лохя Слава б-гу дорогие папичики присылают смешные картинки! "А/Б-тесты риаллайф эдишн" #мемнаясреда
-
Поясни за UX
На днях начала смотреть сериал Советский дизайн. Всем, кстати, советую, оч занятно и полезно для общего художественного развития так сказац! В первой же серии рассказывается про советские панельки (хрущебы) и снова я нахожу кучу корреляций между проектированием интерфейсов и зданий. Прикольные цитаты, которые хорошо ложатся на нашу UX-действительность: Отсылка к тому, что любой общепринятый "стандартный" компонент кто-то когда-то задизайнил: "Если понимать дизайн как искусство изготовления предметов индустриальным способом, то, безусловно, панель - предмет дизайна. Ведь некий дизайнер или архитектор должен был придумать эту панель, ее пропорции, отделку..." Отсылка к разнице между визуальным дизайном и проектированием интерфейса: "Дизайн - это повышение потребительских качеств продукта. Архитектура - это искусство, имеющее дело с пространством." Отсылка к сути нашей работы: "Архитектор проектирует пространство: внутреннее и внешнее. Он выступает как демиург по отношению к пользователям этой архитектуры" Отсылка к JobsToBeDone: "Дом можно воспринимать как машину для жилья, в нем все рационально и целесообразно" Отсылка к тому, что не все зависит от дизайна: "Главная проблема хрущеб - это качество строительства, качество реализации проекта. Но это не проблема самого проекта, архитектурной формы. Если бы Микеланджело собор Святого Петра построил плохо и тот бы рухнул, он бы тоже никому не нравился." Отсылка к внешним органичениям: "Архитектура создается всегда как компромисс между волей архитектора, бюджетом, сроками и ресурсами. Чем интереснее и красивее ты будешь делать дом, тем очевидно дороже он будет стоить" -
Поясни за UX
Меня спросили: JTBD = Job Stories + интервью? Ну а я что, я человек простой. Поясняю. Ответ на вопрос: нет, это неверное уравнение. Чтобы разобраться, надо сделать шаг назад. Есть такой чел, Клейтон Кристенсен. Я упоминаю его на лекциях по VPC, потому что его цитата отлично иллюстрирует ценность VPC: Успех приходит не от понимания пользователя, а от понимания того, какую работу он хочет выполнить. Кристенсен - мегатоповый менеджер наших дней, работал с кучей корпораций, поднимал свои компании, придумал классные менеджерские подходы и написал кучу книг. Он является автором методики Jobs To Be Done. JTBD - это фреймворк, подход, способ мышления. Это не просто один инструмент или практика. Ключевая идея JTBD - клиенты нанимают сервис или продукт для выполнения какой-то работы. Чтобы делать классно, инновационно и двигать дело вперёд, надо понимать какая это работа. При этом абсолютно не важно как ваша аудитория делится по полу, возрасту или месту жительства. Разных людей может объединять одна цель. В одной из книг Кристенсена есть легендарный пример про молочный коктейль: владельцы кафе никак не могли понять как повысить продажи коктейлей. Задавали вопрос «что нам улучшить в коктейле» покупателям (спойлер: эта инфа не помогает повысить продажи). А потом Кристенсен такой «а на какую работу люди нанимают коктейль? Зачем?» Стали наблюдать и выяснили что есть несколько сегментов: 1. Офисники, которые хотят чето перекусить по пути на работу. Они заезжают в кафе утром и берут коктейль, потому что он долго и удобно пьётся пока ты за рулём. 2. Родители, у которых коктейль клянчат дети. Они хотят порадовать малых без ущерба для их здоровья. В обоих сегментах есть люди совершенно разного пола, возраста. Единственное что их объединяет - работа, на которую они нанимают коктейль. И работы эти разные в обоих случаях. Соответственно, и подходы к росту продаж тоже будут разные и направлены на быстрое, дешевое и радостное выполнение работы молочного коктейля. Если вы работаете по JTBD, вы фокусируетесь на работах клиентов. Для этого используются наблюдения, интервью, практики типа 5 почему и WWYSYDH и пр. ——- Минвайл в аджайл появляется User Story - короткая формулировка для описания того что надо разработать проектной команде. Подробно писала про это тут. И кто-то решает наложить подход JTBD на формат сторей. Так рождается Job Story - короткая формулировка, в которой описывается работа (задача), которую надо выполнить пользователю. 💪 Итого: Job Story - инструмент описания работы (или ее части). Помогает систематизировать работу команды и сфокусировать всех на задачах пользователя. JTBD - это подход, способ «думать» о своей аудитории. Это как религия, я не знаю. Это не конкретный метод или инструмент, а набор методик, подчинённый одному: фокусировке на задачах пользователя (а не на демографии) и выявлению работ, на которые ваш продукт может быть нанят пользователями. -
Поясни за UX
А еще я сняла видео с ответами на ваши вопросы, хотела вчера выложить, но ютаб никак не желал его обрабатывать. Так что выкладываю сегодня. Спасибо за ваши вопросы и поздравления махарошикиииии❤️ https://youtu.be/z8RsywMmhdg -
Поясни за UX
Подгон для рубрики #мемнаясреда от коллеги: «Пояснили за UX» 
-
Поясни за UX
Махарошики, осень наступила падают листы, завтра будем переворачивать календарь, а сегодня мне исполняется очередное количество лет 🎂 Стараюсь в этот день сделать для вас что-то интересное. Подборка книг и навигация по каналу уже были, в этот раз вот что: Присылайте свои вопросы о дизайне, обучении, работе и т.д. в форму, а я на следующей неделе запишу для вас видео с блиц-ответами. Пошумим! -
Поясни за UX
#мемнаясреда Accessibility: существует Контрастность в твоих макетах: 
-
Поясни за UX
Как добавлять NDA-проекты в портфолио Этот вопрос мне задают практически на каждой консультации. Давайте для начала разберёмся шотакое этот ваш NDA. Non-disclosure agreement, соглашение о неразглашении - это юридический документ, за нарушение которого вас можно схватить за жопу. Сила хвата ограничивается лишь отбитостью работодателя: от увольнения до тюрьмы на 4 года (прикиньте да) Составляются все NDA по-разному, но, что любопытно, на всю компанию делается одна формулировка. То есть и у вас и у бэкендера вашего NDA одинаковые. Первое что надо сделать: собственно в ваш документ заглянуть. Как правило, формулировки там размытые (в силу предыдущего пункта) и в духе «хорошо делайте плохо не делайте». Чаще всего однозначно сказать что можно а что нельзя по NDA тяжело. Поэтому, по умолчанию считаем что нельзя ничего. А портфолио оч хочца. Что делать: 1. Спросить напрямую у работодателя можно ли выкладывать макеты в сеть и в каком виде. Вероятно, вас отправят в юр. отдел. Иногда там соглашаются на простое сокрытие лого, иногда просят что-то ещё сделать, а иногда советуют забыть про эту идею. 2. В кейсе описывать рабочий процесс, прикладывать артефакты, а макеты блюрить со словами «тут все под nda». В этом случае работодателю будет тяжело оценить уровень ваших визуальных навыков, поэтому добавьте в портфолио учебные кейсы с упором на UI. 3. Прятать кейс в закрытую ссылку. Можно запаролить фигму, можно сделать закрытый раздел в Notion. В сопроводительном письме указывать, что откроете доступ по запросу на определенное ограниченное время. 4. Закрытые проекты полностью скрывать, помечая как nda. В превью лишь описать вашу роль, основной челендж и результат. В сопроводительном письме указывать, что готовы пошарить экран на собеседовании без записи встречи. Каждый из этих выходов: 1)все равно может аукнуться, если вам выпадет джекпот из предыдущего работодателя-параноика и собеседователя-крысы 2) ограничивает работодателя в принятии решения и понимании вашего уровня. Поэтому обязательно делайте волонтерские/учебные/конкурсные проекты, которые помогут работодателю понять ваш уровень хотя бы примерно. Подняла, обняла❤️ -
Поясни за UX
Сегодня мне пришло очень приятное сообщение от папищика о том, что ему понравилось смотреть мои видосы на ютубе (счастливые всхлипывания) Короче да, у меня есть ютуб-канал! Он маленький и слегка покрылся пылью, но там много разборов кейсов, это очень полезное зрелище. А ещё я периодически выступаю с докладами на разных митапах, собрала самые полезные: Как проектировать когда и так все понятно 🔥 Тупые и умные компоненты Мой путь в дизайне Проходим собеседование: воркшоп 🔥 Сетки в дизайне и респонсив -
Поясни за UX
Swimlane Представьте, что вы - птица (пятничные аффирмации какие-то), и пролетаете над бассейном. В каждой дорожке плывет кто-то один. Поздравляю, вы увидели работу swimlane-диаграммы. Эта диаграмма нужна, чтобы графически описать действия разных ролей и персонажей в рамках одного сценария. Действия могут быть последовательными или параллельными, зависимыми и не очень. Swimlane буквально так и переводится - «дорожка в бассейне». Это своеобразный апгрейд userflow, который отражает действия не просто одного пользователя, а нескольких. Одной из дорожек также может быть система (или даже несколько систем), благодаря чему мы увидим, что она делает в ответ на действия того или иного персонажа. Swimlane, как и userflow, помогает продумать действия пользователей в жизни/интерфейсе ещё до перехода к макетам. Это важно, чтобы не потерять разные разветвления сценария, продумать оптимальный порядок действий. Если пытаться это делать сразу на макетах, высок риск залипнуть в пиксели и выдумывание компонентов, потерять при этом важные сценарные детали. Если у вас четко один тип пользователя, работающий с сервисом в изоляции - используйте обычный userflow. Если же результат выполнения задачи связывает несколько пользователей (например, покупатель создаёт заказ, админ магазина у себя в админке его видит, звонит покупателю и подтверждает) и/или вы хотите продумать ответ одной или нескольких систем - Swimlane сработает лучше. Такая вот нехитрая наука. Пользуйтесь! 
-
Поясни за UX
POV: как я попала в UX #мемнаясреда -
Поясни за UX
Продолжение истории про Discovery для Лиза Алерт (наконец-то) Начало тут Мы остановились на том, что составили 4 канваса ценностного предложения для каждой из основных ролей в мире поисков пропавших: - инфорг (управляющий поисками) - координатор (помогающий поисковикам доехать на место и сориентироваться) - регистратор (который следит за количеством людей на поисках) - поисковик (который занимается непосредственно поисками пропавших, зачастую в сложных условиях) Все эти ребята по очереди или одновременно взаимодействуют друг с другом в рамках сценария, который мы смогли описать в виде Swimlane-диаграммы. В схему уже включен будущий сервис, то есть это все как бы 'to-be'. Основные этапы такие: 1) Получение и регистрация заявки 2) Объявление о поиске, прием заявок на участие 3) Организация команд 4) Прибытие на место и ведение поиска 5) Закрытие заявки А вот как выглядит эта схема без деталей. По горизонтали - роли, по вертикали - шаги, в середине - действия в нашем будущем интерфейсе. Мы эту схему обсудили с командой и с ребятами из ЛА, поправили. ⚠️ По традиции, если хотите отдельный пост про SwimLane - пишите в комментарии На этом этапе уже было понятно, что всем, кроме поисковика, нужен веб-интерфейс. А вот поисковик, который носится с фонариком в лесу по колено в болоте и без сети, явно захочет мобильное приложение. Поэтому в нашем сервисе планируется отдельно веб-интерфейс и приложение поисковика. Но начали, конечно, с первого, оно попроще. Надо было понять, что и в каком порядке разрабатывать. Тут нам помогла карта сторей. Напомню, что на руках у нас были 4 VPC с фичами, потребностями юзеров и приоритетами. Мы начали с самой объемной роли - инфорг. Каждую карточку с VPC инфорга мы легко превратили в User Story и "замапали" все на сценарий из Swimlane, распределив стори по релизам в порядке приоритета. Фрагмент user story map (первый релиз) можно посмотреть вот тут. А дальше началась работа над дизайнами, про это, есесна, в следующей серии 🏃♀️ -
Реклама
-
Поясни за UX
Когда учёл все ментальные модели #мемнаясреда 
-
Поясни за UX
Нейронка Теслы не знает о существовании гужевого транспорта и судорожно пытается понять, что за неведомая ёбаная хуйня перед ней -
Поясни за UX
Я не читала книгу «Спроси маму», потому что считала, что она для новичков в интервьюировании. Но она попалась мне в фикспрайсе (там кстати клевые книги продают, прикиньте да) и я решила, что это судьба. Вобщем, книга реально для самых маленьких, а ещё она сама маленькая и читается за 3 часа. Короче, вот основные тезисы (но прочитать стоит целиком ради смешных примеров): ⭐️ говорите с людьми об их жизни: проблемах, заботах, целях, ограничениях ⭐️ не пытайтесь продать свою идею, вообще о ней не говорите, просто задавайте вопросы о жизни респондентов ⭐️ начинать интервью с фразы «мы разрабатываем приложение для N и хотим задать вопросы об этом» - такое себе. ⭐️ люди начинают врать, чтобы вас не обидеть, как только вы даёте повод (выпрашиваете похвалу, спрашиваете о будущем или продаёте им идею) ⭐️ спрашивайте о фактах в прошлом, а не мнение о будущем ⭐️ мнения бесполезны ⭐️ люди знают о проблемах но не знают как их решать ⭐️ некоторые проблемы фактически не являются проблемами, а люди просто ноют. Уточняйте насколько важна проблема. ⭐️ наблюдая мы видим реальные проблемы, а не то как люди о них говорят ⭐️ если потенциальные клиенты не пытались найти решение проблемы самостоятельно, они не обратят внимания на ваше решение ⭐️ люди не будут вам помогать без понятной на то причины ⭐️ комплименты вашей идее ничего не стоят. Комплименты ещё не гарантируют, что человек воспользуется вашим продуктом ⭐️ переходите к конкретике и уточняйте ответы вида «я всегда…», «я бы поступил так…», «я бы мог…» ⭐️ если вам предлагают решение, копайте зачем оно и как без него сейчас. Возможно, вполне неплохо. ⭐️ спрашивайте об эмоциях ⭐️ не надо быть воодушевлённым своей идеей, вас будут жалеть и врать ⭐️ меньше говорите ⭐️ задавайте вопросы, которые могут до основания разрушить вашу идею ⭐️ идея может оказаться 💩, но это хорошая новость ⭐️ интервью - не панацея от рисков выпустить 💩 ⭐️ отбросьте формализм: пусть интервью превратится в «случайную» беседу в рандомном месте (в курилке, после собрания, на кухне) ⭐️ «добро пожаловать на интервью, спасибо что согласились уделить нам время» - такое себе. Не душните ⭐️ в живую всегда лучше Ещё там кучка советов для стартаперов, но нам-то до них какое дело, правильно, мы тут пиксели двигаем