Рэйчел Краузе и Аврора Харли написали о шорткатах.

— Любой интерфейс — компромисс между простотой освоения и эффективностью взаимодействия. Если система предназначена для многократного использования, надо учитывать интересы и новичков и опытных пользователей;
— Шорткаты — функции, которые ускоряют взаимодействие или процессы и дополняют основные способы взаимодействия, делая систему более гибкой;
— Например: горячие клавиши, жесты (двойное нажатие для реакции), голосовые команды;
— Вопрос в том, когда именно знакомить с ними пользователя;
— Можно показывать лаконичные подсказки после того, как пользователь выполнил действие стандартным способом;
— Горячие клавиши можно подписать прямо в интерфейсе. В меню со списком действий — напротив действий, выровняв по правому краю и оформив их как второстепенную информацию. Для иконок-кнопок — в тултипе (не подойдёт для тач-интерфейсов);
— О возможности свайпа в списке карточек можно подсказать анимацией;
— Список всех шорткатов можно разместить в разделе «Справка»;
— Шорткаты добавляйте только для повторяющихся рутинных задач;
— Опытным пользователям можно дать возможность настраивать их самостоятельно;
— Шорткаты должны работать одинаково на всех платформах (веб, iOS, Android);
— При использовании шорткатов ещё важнее становится обратная связь. Информируйте о выполнении действия анимацией или всплывающими сообщениями. Предусмотрите возможность отменить такие действия.

In English. #power_users

В погоне за метриками компании разрушают сами себя

Это заметка не очень внятная, такой черновик с мыслями, но я пока не в силах лучше написать, так что пусть так.

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

Если поговорить с корпоративными всякими продуктовыми дизайнерами, у них очень большое самомнение, потому что у них всё научно обосновано, везде исследования, графики, цифры. Они говорят всякие умные слова про то, что у них все решения неслучайны. Они обязательно считают себя в иерархии дизайнеров выше, чем «непродуктовые» дизайнеры, которые не смотрят на метрики с утра до ночи. Типа, те всё делают на глазок, а мы — по уму. Хотя их работа чаще всего сводится к тому, чтобы сидеть и не дышать на работающий продукт, который они ещё и не сами придумали.

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

Недавно у Грубера (daringfireball.net/2024/12/andy_grove_was_right) была заметка про Интел, который всё просрал за последние годы, очень показательно. Или вот Гугль. Когда-то был лучшим поиском, а сейчас — в основном рекламная помойка. Долгое время они не замечали, что занимаются фигнёй, потому что это приносило кучу денег. А сейчас, когда появился ЧатГПТ, вдруг поняли, что отстали от потребностей людей на десятилетие. Просто некому было сказать: «Ребята, у нас вроде как поиск, но мы занимаемся не повышением качества поиска». Люди, способные это сказать, не становятся ведущими менеджерами продукта. Потому что если кто скажет, его на смех поднимут с такой аргументацией.

Можно предположить, что вся эта ситуация — не ошибка, а нормальный, прагматичный бизнес-подход: сначала мы делаем могучий продукт, а потом выжимаем из него максимум бабла, пока можем. Какой смысл пытаться делать хорошо и зарабатывать на этом X, если можно делать кое-как и зарабатывать на этом 2X, пусть даже это и ведёт к гибели через сколько-то лет? В сумме-то всё равно поди больше заработаем!

Но у меня большие сомнения в том, что это осмысленная стратегия. Мне кажется, обычно невозможно заметить конкретный момент, когда всё начинает идти не туда.

Взять вот Эпл. Сейчас они совершенно не стесняются рекламировать свои дурацкие сервисы во всех дырах, а ведь когда-то это было невозможно представить. Я думаю, когда-то кто-то робко сказал, что рассказать об Эпл-музыке в приложении Айтюнса вполне «полезно» и «уместно». Или что рассказать про увеличенное место в Айклауде, когда кончается память, «релевантно». Не прорекламировать, боже упаси, а просто рассказать! Нет такого, что Эплы однажды приняли решение «ну всё, дальше вместо работы над качеством мы доим нашу корову». Скорее оно как-то само получилось, потому что все себя убеждали, что так можно. Ну и вот.

В больших компаниях нужен какой-то отдельный человек, который не будет смотреть на метрики, а будет смотреть на суть. Мне было бы суперинтересно поговорить со всякими успешными основателями и верховными менеджерами, чтобы понять, как они смотрят на это, как принимают такие решения.

Станислав Хрусталёв написал, как с помощью Action button создать ещё одну точку контакта с продуктом.

— Action button заменила переключатель бесшумного режима в iPhone 15 Pro и всех версиях iPhone 16;
— Пользователь может привязать к ней любое действие. Например: то же переключение бесшумного режима или быструю команду (шорткат);
— В приложении «Команды» (Shortcuts) пользователь может создавать команды, запускающие разные последовательности действий в приложениях. Например: открыть музыкальное приложение и запустить любимый плейлист;
— Какие команды в каких приложениях доступны, зависит от разработчиков, всё это надо разрабатывать;
— В сегменте электронной коммерции в России команды в приложениях встречаются редко (ВкусВилл, Золотое Яблоко, AliExpress). Они не были популярны, так как запускать шорткаты можно было через Сири и Поиск;
— Разработчики могут создавать команды (намерения) на основе ключевых действий в своих приложениях, а клиенты — выбирать их в качестве быстрой команды и запускать выделенной физической кнопкой;
— Например, для банковского приложения таким намерением может быть открытие камеры для оплаты по QR-коду через СБП;
— Для такси — заказ такси на работу, когда ты дома, и обратно, когда на работе.

#mobile

20 самых популярных постов UX Notes в 2024 году в Телеграме:

1. Ирина Сильянова рассказала, как писать интерфейсный текст. 68 лайков (очевидно позитивные реакции минус очевидно негативные)

2. Я выписал тезисы из книги Скотта Беркуна «Дизайн всего». 67 лайков

3. Юля Кондратьева написала, зачем и как читать научные исследования по дизайну. 62 лайка

4. В Контуре подготовили гайд, как навести порядок в макете. 60 лайков

5. Александр Букин написал, с чем сталкивается дизайнер, которого повысили до лида. 60 лайков

6. Таня Юдина написала о найме дизайнеров с точки зрения нанимающего лида. 59 лайков

7. Илья Бирман написал, что ответить заказчику, который спрашивает, за что он платит, если он всё придумал за дизайнера. 52 лайка

8. Илья Полянский рассказал, как делать чистые градиенты. 50 лайков

9. Майя Азарова написала о хоторнском эффекте. 49 лайков

10. Дмитрий Якушин написал о тактильной обратной связи в мобильных приложениях. 48 лайков

11. Илья Кретов написал об интерфейсном тексте и типографике. 46 лайков

12. Я написал, как быстро сделать в Фигме прототип формы, поля которой можно заполнять в любом порядке. 45 лайков

13. Слава Соколов написал об основах BDUI для продуктовых дизайнеров. 44 лайка

14. Дарья Хуторянская написала, что проверить при передаче макетов разработчикам. 44 лайка

15. Михаил Озорнин поделился внутренним гайдом, как писать дату и время в интерфейсе. 44 лайка

16. Юля Кондратьева поделилась исследованиями тёмных паттернов из научных статей. 43 лайка

17. Маргарита Романова написала об управлении доступом к платным возможностям Фигмы. 43 лайка

18. Маргарита Романова написала первую статью из серии об эффективном прототипировании в Фигме. 42 лайка

19. Дмитрий Якушин написал о дизайн-токенах. 42 лайка

20. Исследователи из ВК рассказали о немодерируемых исследованиях. 41 лайк

При равном количестве лайков выше — более вовлекающие посты.

Роман Шамин написал о дробном кегле — одной из важнейших составляющих дизайн-системы Evil Martians.

— Проблема в том, что указанный размер шрифта (если взять, например, 16 px) не совпадает с видимым размером символа в реальных пикселях;
— Из-за этого текст слегка размывается. Эффект заметен даже на экранах с высокой плотностью пикселей;
— Чтобы проверить это в Фигме: View → Pixel Grid; View → Pixel Preview; и зум побольше;
— Дробный кегль помогает сделать текст чётче и поправить внутренние отступы;
— Например, если для Inter вместо 16 px установить кегль 16,5 px, строчная x займёт ровно 9 px, а прописная T — 12 px. Они идеально встанут в пиксельную сетку;
— Также ровным станет отступ от текста до, например, краёв кнопки, что упростит его позиционирование по вертикали;
— Потом легко один шрифт поменять на другой, если подогнать его размеры под те же пиксели;
— Как подобрать размер? 6400% зум и увеличивать и уменьшать кегль с шагом в 0.1 px, а потом с шагом в 0.01px, пока текст не станет попадать в пиксели.

Яна Георгиева написала о налаживании взаимодействия с разработчиками.

— На встречах по оценке задач в спринте (ПБР) было недопонимание, на работу с обратной связью уходило много энергии и времени. Встречи затягивались, задачи переносились из спринта в спринт;
— Часто разработчики плохо представляют себе дизайн-процесс (этап Discovery в модели Double Diamond);
— Проведите небольшую фичу по эталонному процессу и презентуйте команде, чтобы они увидели, как вы приходите к результату: от понимания задачи до изменения макетов на основе обратной связи;
— Презентацию можно потом показывать новым участникам команды;
— Договоритесь (и зафиксируйте это текстом) об интерфейсных паттернах, чтобы не обсуждать их каждый раз. Например, что любой сокращённый текст должен полностью отображаться в тултипе;
— Договоритесь о правилах коммуникации. Например, что если дизайнер не может сразу объяснить, почему предложенная идея не сработает, он берёт паузу, пробует приземлить её и возвращается с обратной связью;
— Или что надо обратиться к дизайнеру за недостающими макетами состояний, а не делать без дизайна;
— И в целом: как оформлять задачи, где источник правды, критерии приёмки, что если реализация отличается от макета;
— Поставьте командную встречу «Презентация финальных макетов» до ПБР, на которой расскажите о целевой аудитории, какую проблему решаете, какие провели исследования и сделали выводы;
— Раз в полгода запрашивайте у команды обратную связь о взаимодействии с вами, внедряйте необходимые изменения, например, через цель в индивидуальном плане развития;
— Если разработчики неравнодушны к продукту и хотят влиять на решения, показывайте им неидеальные макеты (или несколько вариантов решений) и спрашивайте обратную связь. Можно получить экспертную оценку по технической реализации и расширять диапазон решений;
— Если у команды особое восприятие дизайна, повышайте уровень её экспертизы в дизайне. Рассказывайте о психологических принципах, эвристиках, трендах;
— Подскажите, как давать обратную связь: не спешить делать выводы, сначала задавать уточняющие вопросы, отмечать хорошие моменты, без субъективных суждений и перехода на личности;
— Научитесь в какой-то момент завершать обсуждение и принимать решение о судьбе задачи.

#handoff

Захар Бернадский написал о передаче цветовых токенов разработчикам приложений и базовом наборе токенов.

— Базовые группы цветов: Primary, Secondary, Error, Success, Surface (поверхности и объекты на них), Disabled;
— В первых 4 группах базовый набор на примере Primary: primary, active_primary, on_primary, primary_container, active_primary_container, on_primary_container;
— Его можно расширить: primary_stroke только для обводок, primary_variant для варианта цвета без конкретного применения;
— Если нужен токен с прозрачностью, добавьте к названию токена суффикс _xx со значением прозрачности в процентах;
— В каждой группе будут оттенки цвета с одинаковыми Hue и Saturation, но разными Lightness;
— В Фигме в Variables создайте коллекцию color/semantics → в ней базовые группы → в них токены;
— Можно добавить коллекцию color/components и хранить в ней группы токенов для отдельных компонентов вроде цвета текста и дефолтного фона праймари кнопки (значениями будут токены из коллекции color/semantics);
— Но это если есть время и желание гибко настраивать цвета отдельных компонентов, почти не задействуя разработчиков;
— Следите за длиной названий. В Фигме токены выглядят красиво за счёт древовидной структуры, в коде название токена станет одной строкой;
— Если организовать передачу токенов разработчикам, это уменьшит вероятность ошибки и упростит дальнейшие изменения;
— С помощью плагина variables2json можно экспортировать переменные в текстовом формате. Цвета с прозрачностью будут в формате 00000080;
— Уточните у разработчиков формат строки для стиля цвета с hex-значением для семантики и alias-значением для компонентного уровня;
— Преобразуйте экспортированный текст в строки в нужном формате (например, с помощью нейросетей).

#color #handoff

Илья Бирман написал о радиокнопках. Можно дополнить статью Якоба Нильсена 2004 года советом 2025 года.

— Классический вид радиогруппы — список подписей с кругами слева, где выбранный вариант обозначен залитым кружком внутри круга;
— Обычно у группы есть общая подпись, помогающая понять, что именно выбирается радиокнопками;
— В качестве подписей радиокнопок не используют «Да» и «Нет», «Вкл.» и «Выкл.» и подобные пары — здесь лучше подходит чекбокс;
— Не стоит располагать их в строку, так как можно перепутать, к каким кружкам какие подписи относятся. В таких случаях лучше подойдут переключатели или раскрывающиеся списки;
— Если ваши радиокнопки действуют мгновенно, без нажатия на кнопку подтверждения, убедитесь, что действия обратимы и что кнопки не запускают процессы (даже обратимые);
— Обычно первым располагают основной вариант, но если список образует логичную последовательность, её не ломают, а по умолчанию выбирают основной вариант;
— В радиогруппе один из вариантов всегда должен быть выбран. Но иногда нежелательно показывать вариант по умолчанию (например, в тестах, исследованиях, при выборе пола). В таких случаях добавляют вариант «Не выбрано»;
— Либо можно отступить от классической реализации и не выбирать ни один из вариантов по умолчанию. В этом случае для возвращения к исходному состоянию после выбора одного из вариантов потребуется кнопка «Сбросить».

#radio_button

Сергей Проценко написал, как анонимность создателей влияет на восприятие продукта.

— Фокус внимания смещается с личности создателя на сам продукт;
— Люди склонны идеализировать анонимных авторов и приписывать им качества, которые хотят видеть в лидерах: бескорыстие, гениальность, революционное мышление. Это почва для формирования мифа;
— Эти качества могут проецироваться на сам продукт. Например, работы Бэнкси воспринимаются как выражение универсальных идей, а не личные манифесты;
— В случае неудачи автор избегает публичной критики, которая могла бы подорвать его самооценку;
— Проект не воспринимается как продолжение личности создателя, что снижает зависимость его успеха от репутации конкретного человека;
— Анонимность может вызвать недоверие, особенно если продукт подразумевает значительные финансовые или социальные вложения. Она может порождать конспирологические теории;
— Надо балансировать её элементами, укрепляющими доверие;
— Например, в случае биткоина анонимность Сатоши Накамото компенсируется прозрачностью самой технологии блокчейна.

Фёдор Миронов написал, как ускорить подготовку макетов мобильного приложения под вторую платформу с помощью переменных в Фигме.

— Создайте коллекции переменных, которые будут отвечать за параметры интерфейса;
— Коллекция Platform: стиль шрифтов, размеры устройств, пропорции картинок;
— Например, переменная Device width для iOS может иметь значение 393, для Android — 412. А переменная Font: SF Pro и Roboto;
— Коллекция Typography: размер шрифта, межстрочное и межбуквенное расстояние, вес;
— Чтобы создавать дизайн с учётом доступности и масштабировать шрифты, основные параметры можно подтягивать из коллекции Dynamic typography (достаточно базового и максимального значения размера шрифта и межстрочного расстояния);
— Для названий цветов удобно использовать токены из Material Design 3, так как цвета на обеих платформах называются одинаково и есть их контекстные названия;
— Универсальные компоненты вроде кнопок выглядят одинаково на разных платформах, меняется только текстовый стиль;
— Платформенные компоненты вроде Navbar, которые сильно отличаются, лучше сделать вариантами одного компонента;
— Вложенными компонентами легче управлять по отдельности при большом количестве вариантов. Важно одинаково называть их параметры для iOS и Android, чтобы при смене платформы сохранялся контент.

#mobile #figma

Илья Бирман написал о замедлении интерфейса.

— Иногда для вычисления нужно время или тормозит сеть. Тогда дизайнер может попробовать сделать это менее заметным с помощью анимаций, прогресс-баров и так далее;
— С другой стороны, если по ошибке перемудрить с анимациями, быстрый продукт будет казаться медленным;
— Также ошибкой будет замедление интерфейса для большего соответствия пользовательским ожиданиям или для солидности, показывая, что компьютер выполнил большую работу;
— Респонденты на исследованиях действительно могут говорить, что не доверяют результатам, так как получили их слишком быстро, но это не значит, что надо медленнее их отдавать;
— Повысить доверие результатам можно иначе. Например, рекомендуя тариф, можно показать сводку о том, как абонент использовал мобильную связь последние несколько лет, которая обосновала бы выбор предлагаемого тарифа;
— Бывает, что люди привыкли ждать ответа на определённые запросы. Например, ища авиабилеты в агрегаторах;
— Не стоит ориентироваться на эти привычки, если технически есть возможность сделать быстро. Люди легко привыкают к хорошему. Если однажды показать, что что-то быстро, они перестанут ожидать, что это долго.

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

— Big nudge — значение, на которое с зажатым Shift сдвигается элемент на холсте или изменяется значение в поле. По умолчанию 10. Поставьте его равным основному модулю, часто это 8;
— Что можно сделать свойством, не должно быть отдельным слоем. Например, заливка кнопки должна быть свойством Fill, а не отдельным слоем с цветным прямоугольником;
— Функция Select all with позволяет на всей странице выбрать все слои, например, с такой же заливкой или свойствами текста;
— Чтобы раскрыть все слои внутри выбранного, можно нажать на находящийся рядом с ним шеврон с зажатым Option;
— Свойство Canvas stacking регулирует, какие слои внутри автолейаута находятся визуально выше. Может пригодится, когда на одном из слоев окажется выходящий за его границы дропдаун;
— К свойствам Fill container и Hug contents можно добавить минимальную и максимальную ширину, на которые автолейаут может растягиваться;
— Если цветовые стили разделены на категории (Text, Background, Stroke и так далее), в выбранном элементе интерфейса можно быстро изменить цвета, например, только текста;
— Если в текстовом слое написать «:» и первые символы слова, появится список эмодзи;
— Атомарный подход: внутри одного компонента (молекулы) могут находиться другие (атомы). С помощью Nested instances свойства атомов можно вынести на панель молекулы, чтобы не проваливаться каждый раз до атомов для настройки.

#figma

Павел Шерер дописал цикл о функциональной архитектуре: о детальном проектировании и подводных камнях.

— У каждой функции и функционального раздела должно быть уникальное название: конкретное и максимально понятное, чтобы сразу уловить суть, на английском;
— Название функции должно отражать действие. Например: AddUser;
— Функциональные сценарии прорабатываются итеративно: от простых к детализированным, чтобы успевать накопить достаточно данных для глубокой проработки;
— Описать функцию с помощью схем не всегда возможно, иногда поможет только текст;
— Описание должно включать назначение, входные и выходные данные, зависимости (например, confirmPhone нельзя реализовать, пока не заработает sendSMS), пример использования;
— Сюда можно добавить User Stories, Use Cases и всё, что посчитаете нужным;
— Если названия макетов будут соответствовать документации, это упростит жизнь разработчикам. Например, ShoppingCart — корзина, ShoppingCart.empty — её пустое состояние;
— Нужен баланс в уровне проработки. Слишком общая проработка отрывает архитектуру от реальности. Слишком детальная перегружает, усложняет восприятие и развитие;
— Если рано детализировать одну подсистему, не получится учесть нюансы других (которые ещё не проработаны), и работа может отправиться в мусорку;
— Невозможно задизайнить сложную систему, не понимая, как она будет работать. Но нельзя знать всё. Чем раньше вы «обстучите» свои решения об коллег, тем надёжнее они станут;
— Отдельная задача — убедить бизнес не начинать разработку слишком рано, недостаточно проработав проект;
— Будьте готовы в процессе детальных изысканий возвращаться на высокий уровень на существенно его изменять.

#functional_architecture

Ира Моторина написала о формировании тональности голоса продукта с помощью Emotional journey map.

— Простота, полезность и понятность не могут быть особенностью голоса продукта, это общие принципы коммуникации. Кто будет читать сложный, бесполезный и непонятный текст?
— Голос зависит от легаси (визуальный стиль и так далее), аудитории и ценностей (ради чего продукт выбирают);
— Пример ценностей продукта, связанного с безопасностью: спокойствие и своевременность;
— Текст может не отражать все ценности, но не должен им противоречить;
— Уникальный голос повышает узнаваемость продукта;
— Тональность голоса зависит от сценария. Ради основных сценариев люди используют продукт (заказ такси). Второстепенные не обязательны (оценка поездки, оплата бонусами);
— В Bolt на экранах заказа такси текст нейтральный, короткий и безличный, чтобы не отвлекать. На карточках в магазине приложений — эмоциональные глаголы, сильные прилагательные, которые призваны заинтересовать;
— Предложите пользователям выполнить задачи в продукте и оценить свои эмоции (можно предложить варианты из исследования Пола Экмана);
— Эмоции людей должны определять реакцию продукта, не наоборот. Случилось что-то хорошее — радуемся вместе с пользователем, возникли проблемы — проявляем сочувствие;
— Естественный тон голоса повышает вовлечённость, конверсию и удовлетворённость пользователей.

#tov

Илья Бирман написал о чекбоксах.

— Классический вид — квадрат с опциональной галочкой, обозначающей включённость;
— Группу чекбоксов, как и радиогруппу, лучше не располагать в строку, чтобы не путать, к какому квадрату относится подпись;
— Если смысл выключенного чекбокса неочевиден (☑️ Подключить демо-доступ прямо сейчас), лучше использовать радиогруппу с явно названными вариантами (Подключить демо-доступ: 🔘 Прямо сейчас, 🔘 Позже в личном кабинете);
— Для удобства прицеливания кликабельным делают обычно не только чекбокс, но и текстовую подпись. Поэтому лучше не вставлять ссылки в подпись;
— Если ваши чекбоксы действуют мгновенно, без нажатия на кнопку подтверждения, убедитесь, что действия обратимы и что кнопки не запускают процессы (даже обратимые);
— Для мгновенных действий лучше подходит тумблер;
— Чекбокс может управлять группой дочерних чекбоксов: включение родительского включает все дочерние и наоборот;
— У родительского чекбокса может быть дополнительное состояние, когда включена только часть дочерних. Его обозначают точкой или прочерком;
— Тогда нажатие на родительский чекбокс последовательно переключит группу: все включены → все выключены → включены только те, что были включены до нажатия на родительский чекбокс (то есть надо сохранять исходные состояния дочерних чекбоксов).

#checkbox

Роман Шарай написал, как говорить о повышении зарплаты.

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

Копия в Виси. #career

Канал Bad Mobile посвящён дизайну мобильных приложений.

Подписчики обмениваются опытом, узнают о тенденциях в мобильном UX/UI-дизайне и находят вдохновение для своих проектов.

Команда администраторов включает продуктовый дизайнеров и лидов с опытом работы в Сбере, Т-Банке, Альфа-Банке, Райффайзен Банке, Uzum и IBM. Они делятся знаниями, кейсами, инсайтами и опытом, а также приглашают спикеров из других компаний, чтобы те поделились статьями и советами и разобрали портфолио.

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

Реклама. Комаров Алексей Олегович, ИНН: 772794718380, erid: 2VtzqurJgqt