Odokienko Design - designer's experience

Однажды на собесе мне задавали вопросы типа: - Есть ли ипотека? - Дети? - Кредиты? и т.д. Я понимаю, что человек просто хотел знать, есть ли у меня что-то, что создает ответственность. В его картине мира наличие таких факторов заставит работника держаться за работу Но многих такие вопросы могут очень раздражать. «Чувак, просто сделай свое место таким, откуда не захочется уходить и не суйся в мою личную жизнь» Как вы считаете, ок ли задавать такие вопросы на собеседовании? 👍🏻 — ок 👎🏻 — не ок

Во многих командах, где я работал — и клауде, и в райфе, и в пинкмане — почти всегда возникала одна и та же проблема: согласование дизайна внутри команды или направления Вроде бы у дизайнера есть зона ответственности: он получает задачу от продакта, исследует, проектирует и приходит с решением. Но случается, что на грумингах кто-то из твоей или смежной команды решает внести свой вклад - А давайте вот так - А почему не иначе Такие комментарии бывают по делу. Например, продакт глубже понимает контекст продукта, аналитик знает метрики, или кто-то просто подмечает деталь, которую дизайнер упустил Но бывает, что это просто мнение человека, который видит задачу впервые, и у него есть внутренний зуд предложить «как лучше» Эта грань между релевантным фидбеком и просто шумом — очень тонкая. У дизайнера должна быть своя система: как отличить комменты, которые стоит учитывать, от тех, которые можно смело пропускать Дима предложил инструмент для этого — матрицу согласований. Суть простая: разделяешь всех участников по категориям: 1. Кто принимает решение 2. Кого просто держишь в курсе 3. Кого можно вообще исключить из процесса В итоге экономится куча времени, а дизайнер может не «отбиваться» от комментов, а осознанно принимать решения Подробнее об этом Дима написал у себя в блоге и выложил файл в Figma, где всё собрано по полочкам. Рекомендую изучить (особенно лидам, которые помогают своим дизам наладить процессы внутри их команд)

Проект, который я почти полностью редизайнил в этом году, запустился на Product Hunt 2pr.io — это помощник для создания успешного/вирального контента на LinkedIn Фаундер попросил меня поддержать, а я прошу вас! Поставьте up-vote, если не трудно 🥰 ссылка для голосования Ссылка скрыта в комментах сложу скрины до/после

Про nature tech Словил себя на мысли, что мне очень нравится такой стиль (раньше тоже нравился, я просто название не знал). Произошла какая-то гиперфиксация, и теперь хочется подизайнить какой-то такой проект В визуале часто можно встретить: - материалы вроде камня, мха, песка, стекла, растений - бежево-зелёные, черные, серые палитры с плавными переходами - шум вместо блеска, глубина вместо контраста - сочетание 3д/2д - частички, макро, depth of field - пиксели, тонкие линии - моношрифты (и еще всякие display-future) Нравится во всем этом, как получается примирить цифровое и живое. Так, чтобы технологии чувствовали себя естественно среди природных форм Я себе даже на столе подобие организовал, когда собирал сетап, в комменты положу фотки

Огромная база портфолио дизайнеров со всего мира (3.5к ссылок) Ссылка скрыта Там и студии есть, и люди Полезно иногда посмотреть, кто как подходит к самопрезентации в комментах еще скинули 300+ Ссылка скрыта

База про юзабилити-тестирование Меня читают не только дизайнеры, но и другие роли из команд продукта, поэтому хочу сделать в этом посте небольшой ликбез Юзабилити-тесты помогают понять, насколько интерфейс продукта удобен для конечных пользователей. Главная цель тестов — выявить проблемные места, где люди сталкиваются с трудностями, и улучшить опыт взаимодействия с продуктом Тесты бывают модерируемыми — это когда есть господин-ведущий, и само исследование скорее качественного формата. А бывают немодерируемыми — это когда весь сценарий собирается на платформе (например, фабрика юзабилити / pathway / maze), и юзеры сами там все проходят по ссылке Кто проводит: Обычно дизайнеры и исследователи, но я сторонник подхода, когда любой человек из команды продукта подключается к тестам. Это дает совсем другое понимание того, как юзеры себя ведут Даже самый восхитительный (и награждаемый) дизайн не гарантирует, что юзеры смогут легко выполнять нужные действия в интерфейсе. И своевременные тесты очень помогают сэкономить ресурсы на исправление проблем после запуска или внедрения дизайна Процесс исследования обычно выглядит так: 1. Определяем цели (что хотим проверить) 2. Формулируем интерфейсные гипотезы 3. Подбираем юзеров (очевидно, подойдет не любой человек) 4. Готовим прототип 5. Проводим тест (даем задания и наблюдаем) 6. Анализируем результаты 7. Делаем выводы и внедряем улучшения Количество пользователей: Стандартно 5 человек для модерируемых тестов. Обычно тут начинается срач: «а как вы решили, что нам надо 5 человек?!». Тут все ссылаются на Nielsen Norman Group, где говорится, что при тестировании с 5 пользователями обычно выявляется около 80% проблем. На практике все берут от 5 до 10 человек на сегмент. Это значит, что если мы хотим провести тест на новой аудитории и на текущих пользователях, то нам надо хотя бы 5 человек там и там Для немодерируемых чуть сложнее. Надо учитывать общее количество пользователей и погрешность, с этим помогают специальные калькуляторы. Но можно сказать 70-100, и это в целом норм (с оговорками) Как устроен сам тест: На встречу приходит модератор (тот, кто проводит) и юзер. Модератор говорит вводное, дает задания юзеру, наблюдает и фиксирует. Юзер пытается выполнить задания и комментирует свои действия. Я тут предпочитаю донасыщать тест до и после вопросами, чтобы вытащить что-то полезное. Встречу лучше не делать дольше 1 часа, т.к. юзер устает + вовлеченность снижается Гайд и задания Каждая встреча строится на гайде, который готовится заранее. Гайд содержит в себе цели, критерии выборки юзеров и гипотезы Практический пример Пусть это какой-то сервис с видео Гипотеза: пользователь понимает, где находится история просмотра и может в нее зайти Вопрос (задает модератор): представь, что ты смотрел пару недель назад то-то...как бы ты вернулся к этой записи? По сути вопрос и есть задание, просто он сформулирован так, чтобы не давать юзеру подсказку Отчет: Провели все интервью? Ура, теперь надо свести все воедино Ищем паттерны (повторы) в проблемах и анализируем все совокупно. Для каждой проблемы полезно фиксировать встречаемость и критичность для пользователя Метрики Даже тут есть метрики, да! Часто используют: - Task Success Rate - Time on Task - Error Rate - Satisfaction (субъективная оценка от юзера) Есть еще Eye-tracking/heatmap, которые показывают, как распределяется внимание, но это скорее карты, чем метрики В зрелых командах юзабилити — это стандарт дизайн-процесса, как утром зубы почистить. Ну и напоследок — дизайн не должен рисоваться в вакууме. Проверяйте свои решения! - - - - - Я хочу сделать закрытый воркшоп узким кругом для тех, кто хочет научиться проводить юз.тесты или систематизировать знания. Всего 2/6 мест осталось (5к за место) Формат такой: встреча в онлайне на пару часов, на которой пройдемся подробно по всем этапам, там же дам домашку + отдельная встреча с разбором всей домашки тоже на пару часов Это очередной эксперимент (они у меня удачные в последнее время, кстати!) Если хочешь разобраться с юзтестами, напиши мне в личку @odokienkoan

Всем, кто работает в офисе, посвящается Альбом с ai делаем?