Кейс Digital команды домашнего интернета от Tele2.
Думаю, что все, кто работает с потоком лидов, понимают, как это: маневрировать между количеством заявок, их качеством и нагрузкой на контактный центр. В этой статье поделюсь, как с помощью интерфейсов мы научились управлять органическим трафиком, конвертируя его в реальные подключения, при этом эффективно расходовать ресурс контактного центра. Погнали!
Задача разработки простого и понятного UI для непростого функционала каждый раз требует определенной доли смекалки, но даже при этом удачного решения не гарантировано. Нам кажется, что в этот раз у нас получилось, и поэтому мы хотим поделиться, ведь чем больше качественных решений видел разработчик, тем больше шанс, что в следующий раз у него тоже получится хорошо.
Метод схематизации вариативности данных в точках их преобразований в информационной системе
В статье описан подход к схематизации движения данных в цифровом сервисе. Он основан на таблицах решений, понятиях преобразователя и предохранителя, категориях причина—следствие и смысл—форма.
Метод будет полезен дизайнерам интерфейса, аналитикам, разработчикам и инженерам качества и всем, кто детально проектирует работу цифрового сервиса. Подобные схемы выступают на проекте инструментом проектирования и коммуникации о вариантах решений на уровне процесса и данных. Вижу пользу в них во взаимодействии разработчиков, инженеров качества и дизайнеров.
Проанализировал более 100 резюме и портфолио российских и зарубежных дизайнеров. Здесь поделюсь их структурой, описанием, слабыми местами и фишками
Статья про приёмы, упрощающее восприятие текста игроками и про особенности работы с текстом на игровых проектах.
На просторах сети частенько можно наткнуться на споры про то, что же лучше - стрелочные приборы или цифровые.
Что же лучше? Предлагаю проверить на практике c помощью программы-теста, которая измеряет время, необходимое на считывание значений со стрелочного индикатора и цифрового.
В начале карьеры проектирование любой формы казалось мне очень простой и понятной задачей. Особенно когда речь шла о чём-то банальном и незначительном, вроде обратной связи на сайте. А что — выяснил, какие нужны данные и для чего, накидал поля с подписями, приделал кнопку — и готово! На всё про всё — пять минут. Пустяки! Или нет?
Поиск помогает пользователям быстро находить то, что им нужно. Но как создать такой поиск, а главное — сделать его полезным инструментом?
В статье:
— проанализируем, какие варианты паттерна поиска есть,
— заглянем в гайдлайны,
— рассмотрим UX-ошибки.
Как же выбрать оптимальный вариант поиска для вашего мобильного приложения?
«А зачем платить за курсы? 99% материала, который там дают, можно найти на ютубе. Покупай, если не найдешь нужный материал. Но сначала попробуй бесплатно!» — сказал мой брат после того, как я поделился идеей пойти учиться на дизайнера.
Я так и сделал. Но вскоре понял, что самый сложный вопрос «какие навыки мне важнее развивать именно сейчас», а не «найду ли я нужный материал». Новичкам проще — им нужна база. Но какие навыки надо развивать когда ты middle или senior?
Привет! Я Дима, автор телеграм канала Дизайн тусовка. Я собрал полноценный гайд для всех грейдов на основе своего опыта и недавнего поиска работы в топ IT компаниях России, вот мой результат:
У меня было хорошее настроение: я опубликовал свою статью об RSS, и она оказалась довольно популярной.
Я решил, что лучше всего отпраздновать это, зайдя на Feedly и почитав что-нибудь. Нажал на фид блога разработчиков, чтобы просмотреть там пару последних постов. Посередине фида я заметил рекламу. Вполне справедливо: я пользуюсь бесплатной версией Feedly, поэтому вполне логично, что мне показывают баннеры.
Я нажал на крестик в правом верхнем углу рекламного блока. И именно тогда всё пошло не так.
Вместо того, чтобы закрыть рекламу, Feedly показал мне всплывающее окно, сообщающее, что единственный способ удаления «этого модуля» (читай: рекламы) — «напрямую поддержать Feedly, купив Feedly Pro».
Повторюсь, я не против, что Feedly показывает рекламу бесплатным пользователям, но неработающая кнопка закрытия — это тёмный UX. Я почувствовал себя обманутым: я не буду платить за ваш сервис, я не буду нажимать на рекламу.
У меня было хорошее настроение: я опубликовал свою статью об RSS, и она оказалась довольно популярной.
Я решил, что лучше всего отпраздновать это, зайдя на Feedly и почитав что-нибудь. Нажал на фид блога разработчиков, чтобы просмотреть там пару последних постов. Посередине фида я заметил рекламу. Вполне справедливо: я пользуюсь бесплатной версией Feedly, поэтому вполне логично, что мне показывают баннеры.
Я нажал на крестик в правом верхнем углу рекламного блока. И именно тогда всё пошло не так.
Вместо того, чтобы закрыть рекламу, Feedly показал мне всплывающее окно, сообщающее, что единственный способ удаления «этого модуля» (читай: рекламы) — «напрямую поддержать Feedly, купив Feedly Pro».
Повторюсь, я не против, что Feedly показывает рекламу бесплатным пользователям, но неработающая кнопка закрытия — это тёмный UX. Я почувствовал себя обманутым: я не буду платить за ваш сервис, я не буду нажимать на рекламу.
Привет всем. Помните, в прошлом году Figma представила значительное обновление, благодаря которому стало возможным создавать полезные переменные для реализации темной и светлой версий интерфейса. В этом руководстве я поделюсь, как это сделать просто и эффективно. Для наглядности я специально использовал несовершенный подход, чтобы показать потенциальные ошибки, на которые вы могли бы нарваться. Начнем.
Хочу поделиться своим опытом и рассказать, как я прокачиваю насмотренность в ux (не ui). Надеюсь, это кому-нибудь поможет.
Figma Branch (или «ветка») — это функционал, который позволяет создать копию проекта и изменять его независимо от основной версии. Когда работа завершена и нужно внести изменения в основной проект — ветка сливается с master-версией. Всё как у разработчиков. Но чтобы использовать Branch, ваш тариф должен быть Organization или Enterprise.
Предпосылки
При коллективной работе над проектом, всегда встречаются классические проблемы: что/когда/кем было добавлено в проект и почему компоненты сломались. Я часто видел костыльное решение — складывать готовые экраны и компоненты куда-то в угол канваса, тегать лида комментом, а после ревью — чистить за собой, мрак. Проще, быстрей, дешевле использовать функционал Branch, тем более они идеально подходят для следующих сценариев:
Правильное расположение элементов игрового интерфейса помогает людям решать задачи, которые мы перед ними ставим
В статье примеры подходов и решений, которые упрощают жизнь игрокам =)
Привет, я Егор Камелев, проектировщик интерфейсов (UX-дизайнер). За последние 20 лет я поработал с командами десятков агентств, IT-отделов, действующих проектов и продуктов, стартапов (и запущенных, и незавершённых). Я знаком с сотней команд, не меньше. И среди них не нашлось и двух, использующих одинаковые подходы к работе. Верно говорят: «У каждого додика — своя методика!».
У всех свои названия должностей, артефактов, процессов. Свои требования и наборы компетенций. Где-то проектированием занимается маркетолог и разработчик (потому что в команде больше никого и нету), а где-то эта задача распределена между десятью разными специалистами (системные- и бизнес-аналитики, технические писатели, UX-дизайнеры, продакт оунеры и так далее).
Поэтому в этой статье я не буду заявлять, что мой подход к работе — единственно верный. Он один из тысяч и в моём случае прекрасно работает: клиенты не заваливают меня правками, платят 100% предоплату и рекомендуют окружающим. Я распишу во всех деталях свой процесс предоставления услуги проектирования (создания интерактивного прототипа информационной системы на заказ). Уверен, что многим пригодятся мои знания. Погнали!
Речь идёт о функциональных спецификациях к сайтам, приложениям и прочим информационным системам.
В начале карьеры UX-дизайнера я просто делал интерактивные прототипы, а документацию предпочитал не писать. Почему так:
Во-первых, сложно. Этому навыку никто не обучал, а написать 100 и более страниц текста по проекту — это как диссертацию накатать. Поэтому я говорил клиентам, что, мол, и так справитесь.
Во-вторых, у меня не было опыта в роли заказчика. И только после того, как я на собственном проекте увидел, сколько денег экономит этот документ, стал предлагать его каждому новому клиенту.
Продавать это было легко. Достаточно было рассказать о том, как я, заплатив несколько десятков тысяч за документ, экономил несколько сотен тысяч на разработке. И подкрепить рассказ конкретными цифрами и примерами. Чаще всего я рассказываю о том, как пожалел 50к на функциональную спецификацию на участок собственного проекта, и разработчики делали его два с половиной месяца вместо привычного одного. А месяц их работы обходился моей казне почти в 300к рублей. И если бы я не сэкономил на функциональной спецификации, то задача обошлась бы на 400к рублей дешевле.
