Дизайнер на всю голову

Напомню, что я работаю в команде, задача которой разработать общий визуальный язык для двух разных продуктов. Каждый продукт ведёт своя подкоманда. Один проект – платформа с видео-лекциями Teach In, второй – интерфейс с более сложной логикой, над которым работаю я – платформа управления обучением (LMS). В качестве основы взята компонентная библиотека Hero-UI. Задача поставлена так, что визуальный язык должен задаваться через Teach In, а его переиспользую в LMS. После переработки командой Teach In визуального стиля я импортировала обновлённые компоненты в свой проект. И вот здесь начались сложности. Продукты сильно отличаются по функционалу и сценариям. То, что хорошо работает в одном, например, увеличенные отступы или минималистичные карточки в Teach In, в LMS приходится адаптировать под более насыщенную структуру. Возникает постоянная необходимость искать компромиссы: переделывать, настраивать, уточнять, что увеличивает время работы и усложняет процесс в целом. Эта проблема показала мне, что логичнее было бы отталкиваться от более сложного продукта, чтобы сразу предусмотреть крайние кейсы, а уже потом адаптировать стиль под более простой. Тогда общая система была бы стабильнее и универсальнее. Найти все посты о работе над проектом можно по тегу #обучение #LMS #проект Дизайнер на всю голову

Первые впечатления такие. Не буду пока высказываться по поводу версии рестайлинга Aqua, само по себе возвращение тенденций ничего не значит, если они применяются корректно. Но. Баланс между красотой и читаемостью отсутствует. Контраст крайне не нравится, ощущения хаоса, некомфорта для глаз. Пока не вижу для себя того, что могло бы улучшить взаимодействие с интерфейсом. Все "внешнее" давно не вызывает у меня удовольствия только своим фактом появления: я сразу начинаю думать как это отразиться на использовании и изменениях в работе. Но больше всего у меня вызывает опасения применения Liquid Glass в b2b. Корпоративная аудитория ожидает стабильности, удобства, относительной простоты применения, а не подвижности и внешних эффектах. Стеклянные элементы могут вести себя непредсказуемо при высокой плотности данных. Финальная оценка была бы корректна после финального релиза iOS 26, которая планируется в сентябре и тестирования приложений, подстроенных под . Кто тестировал? Какие у вас мнения? #дизайн #тенденции #ios Дизайнер на всю голову

На freelance.ru можно увидеть как отвечают на проекты некоторые фрилансеры, так как ответы не скрыты. И что меня поразило: до сих пор люди отвечают просто в пустоту. Есть запрос клиента, где указано что нужно сделать, указано что за интерфейс, какая тематика, какой примерно объем работы. Что сложного в том, чтобы создать шаблон, который дополнять деталями в зависимости от проекта? Показать примеры со схожим функционалом, указать примерную стоимость, хотя бы что-то, что поможет клиенту зацепиться, заинтересоваться опытом. Большая часть ответов вообще не по теме. Суровый и безжалостный мир фриланса. Я в недоумении #лирическое Дизайнер на всю голову

UX-сценарии авторизации и регистрации На этой неделе я занимаюсь проектированием блока авторизации. Он нужен не только для входа в LMS, но и для доступа ко всей экосистеме: Teach-N, личному кабинету, сервисам администрирования. Поэтому в основу положен SSO – единый вход, который позволяет пользователю использовать одну учётную запись во всех связанных продуктах. Один из ключевых блоков LMS – сценарии входа, регистрации и сброса пароля. Я начала с проектирования логики SSO, авторизации через почту и формы регистрации, чтобы обеспечить единый путь входа в систему. У LMS два типа пользователей: студенты и преподаватели. Для обеих аудиторий важно, чтобы процесс входа был простым, безопасным и не прерывал основной сценарий: просмотр курсов, работа с материалами, сдача тестов. Я уточнила и собрала все экраны, связанные с этими сценариями: — форма логина и регистрации, — подтверждение почты через OTP-код, — сброс пароля, — выбор аккаунта и выдача разрешений в потоке SSO. Работа шла параллельно с обсуждением поведения этих экранов: что происходит после отказа от разрешений, как обрабатываются ошибки (например, просроченный код), нужно ли авторизовывать пользователя автоматически после сброса пароля. Каждое решение фиксировалось сразу, чтобы не потерять ни одного условия, влияющего на поведение интерфейса. Было много внимания к деталям. Например, обсуждали с командой, как отображать ошибки: они группируются по-разному. Какие-то обрабатываются на фронте, какие-то приходят с бэка, а некоторые вообще всплывают только при интеграции с внешним провайдером. От этого зависит, как будет выглядеть ошибка. Она появится при валидации рядом с полем ввода, или мы покажем её через toast, или это будет отдельный экран. Для полей с ошибками зарезервировала определённую высоту, чтобы то, что под полем, не "прыгало". Решила унифицировать единые названия для кнопок: "Продолжить" или "Подтвердить", чтобы пользователь не терялся. Синхронизировались по схемам flow, проверяла согласованность переходов и продумывала, как будет работать форма с точки зрения компонентной библиотеки. Использую библиотеку Hero UI, учитываю её ограничения и возможности, чтобы не проектировать в пустоту. Сейчас собраны макеты всех ключевых состояний, сценарии описаны, поведение зафиксировано. Следующий шаг – подключить макеты к логике LMS и проверить сценарии на первых пользователях. На этом этапе собрала такие экраны: — схема flow авторизации и регистрации (SSO + почта); — экран логина; — экран логина через SSO; — выбор аккаунта; — выдача разрешений (permissions); — форма регистрации; — форма регистрации с капчей; — подтверждение кода (enter code); — сброс пароля; — ввод нового пароля; — подтверждение регистрации; — ошибка при регистрации; — ошибка при изменении пароля. Этап занял около 12 часов: обсуждение сценариев, макеты, фиксация логики и синхронизация с командой. На скриншоте: flow авторизации в сервисе. #проект #обучение Дизайнер на всю голову

Лучше всего страхи и боли решают факты. Вот факт. Это проект, о котором я периодически пишу (Planum), над которым работаю в команде заказчика с 2023 года. Я на связи с командой, мы обсуждаем текущие и планируемые задачи, встраиваем их в график. Я делаю, поддерживаю и развиваю продукт. Это абсолютно гармоничная работа в команде. Таких проектов у меня несколько. Мне интересно принимать участие в развитии проекта после запуска основного функционала. Это больший опыт, как мне кажется, нежели ты отдаешь проект, получаешь какую-то разовую обратную связь и на этом все. Ты видишь как твой проект развивается, получаешь и видишь обратную связь по своей работе, видишь микро улучшения, ты непосредственно влияешь на детали и работу. Разве мы не хотим этого в итоге?) #поддержка

В ней собраны все инструменты для создания программ, курсов, тестов и управления процессом обучения студентов. Сейчас пришло время сфокусироваться на интерфейсе для студентов — личном кабине. Здесь появляется много новых сценариев: как студент выбирает курс и записывается на него, каким образом знакомится с материалами, как проходит обучение, тестирование, как получает обратную связь. Параллельно перед командой стоит задача объединить два направления: личный кабинет для студентов и отдельный контентный продукт — платформу с видеоматериалами, которые доступны независимо от курса и позволяют расширять знания по выбранной теме. Работаю сейчас над UX-дизайном этих решений: уточняю сценарии, обсуждаю логику переходов между блоками, формулирую приоритеты для первого релиза. Фокус на том, чтобы студенческий интерфейс был не просто витриной курсов, а рабочей средой, где понятно, что делать дальше, и нет перегруженности функциями. Здесь многое завязано на деталях: как построить структуру главной страницы, как показать прогресс, как сделать быстрый доступ к нужным материалам и при этом не запутать пользователя. Собираю всё это в стройную и удобную систему, чтобы процесс обучения был максимально понятным и прозрачным. Несколько слов о команде и о том как строится процесс работы. Всего в команде 12 человек, включая меня. Заказчики со стороны МГУ, со стороны студии технические специалисты (разработчики), дизайнер, менеджер по проекту, продакты, мой непосредственный заказчик. Все небольшие вопросы обсуждаются в рабочем порядке на лету, более глобальные вопросы на созвонах. Есть понятный всем план разработки с этапами и сроками, которым следуем. Детали буду рассказывать уже в ходе отдельных постов #проект #образование Дизайнер на всю голову

Это не отменит ведение проектов в сервисах, но ускорит работу с быстрыми задачами, которые возникают в течение дня и которые могут прилететь как от клиента, так и от себя самой Что будет: — Списки можно создавать в личных чатах или в группах — удобно для ведения задач внутри команд. — До 30 пунктов в одном списке — У каждого выполненного пункта показывается аватар исполнителя. — Совместное редактирование: можно создать список задач и дать доступ участникам добавлять задачи и отмечать их выполнение Ждем? 🔥 #менеджмент Дизайнер на всю голову

👉🏼 Мимо: один по цене двух В сервисе Альфа Тревел при покупке билетов для двух пассажиров отображается сумма за двоих. Это неожиданное решение, так как обычно показывается стоимость 1 билета, а потом уже сумма за два. При этом в системе может быть в наличии только один билет и стоимость все равно будет указана за двоих пассажиров. Такая реализация вводит в заблуждение #мимо #интерфейс Дизайнер на всю голову

После списка ресторанов пользователь переходит в "карточку конкретного ресторана". Это основной рабочий экран, где происходит выбор и заказ блюд. 🍴 Экран ресторана Интерфейс включает: — категории меню, — список блюд с ценами, названиями и описаниями, — возможность перейти в карточку блюда для подробностей. Дополнительно на экране реализован функционал бронирования столика — так как приложение рассчитано и на заказы на вынос, и на офлайн-посещение ресторана. Мы стремились объединить эти два сценария в одном потоке, не перегружая интерфейс. 🍲 Экран блюда Карточка блюда содержит всю основную информацию: состав, калорийность, время приготовления. Отдельно реализован блок "дополнительных опций" — пользователь может докупить ингредиенты к блюду. Например, добавить сыр, грибы или ветчину к пицце. Выбранным блюдом можно поделиться с другом или отправить в соц. сеть, чтобы завидовали ;) Мы обсуждали с клиентом, как показать эти допы максимально ненавязчиво, но при этом не упустить возможность апсейла. Сейчас тестируем разные варианты расположения и поведения этого блока. Тайминг проекта: на данный момент на работу ушло около 70 часов. #проект #приложение #ресторан #instant Дизайнер на всю голову

Это стартовый экран, который отображает список ресторанов. Помимо стандартного списка, я предусмотрела альтернативный режим "отображение на карте", чтобы пользователь мог сразу видеть ближайшие локации. На этапе проектирования мы с командой обсуждали, как обеспечить максимально удобный переход между режимами и какие данные должны быть видны сразу на карточке ресторана. Сейчас прорабатывается логика "фильтров" — хотим дать пользователю возможность находить заведения по релевантным параметрам (тип кухни, расстояние, уровень цен и т.п.). Но пока ведём обсуждение, какие фильтры будут действительно полезны, а какие перегрузят интерфейс. Это живой процесс — тестируем, спорим, перебираем сценарии. #проект #приложение #ресторан #instant Дизайнер на всю голову

Чем отличается это приложение от других QR-решений? Обычно, когда мы приходим в ресторан с QR-меню, всё ограничивается сессией: — сканировали код, — сделали заказ, — поели — и забыли. Часто это просто веб-обертка с минимумом функций. — нет сохранённой истории, — нет программы лояльности, — нет причины вернуться. В Neon Alisa (Eat Me Alisa) эта проблема решена так. Instant-версия работает так же — быстрое сканирование и заказ. Но при этом мягко подталкивает к установке: — чтобы сохранить бонусы, — чтобы не терять историю заказов, — чтобы в следующий раз всё было уже внутри приложения. Таким образом, пользователь получает одну экосистему, которая работает сразу в нескольких ресторанах: — не нужно устанавливать новое приложение под каждый ресторан, — все заказы, скидки и брони — в одном месте. Это и есть ключевая идея: удержание, а не одноразовый заказ. И насчет названия. Наверное, заметили, что я называю приложение двумя разными названиями. Пока именно так, конечное название еще не утверждено :) #проект #приложение #ресторан #instant #мобильноеприложение Дизайнер на всю голову

В прошлых двух пастах рассказывала о работе над логикой. Сегодня перейдем к дизайну. Обсуждение стилистики Собрала референсы и предложила клиенту выбрать понравившиеся стилистически. Евгений и команда выбрали 3 варианта (обычно это рекомендуемый мною максимум). Выбранные референсы задали направление по визуалу: сочетание светлого минимализма, крупных карточек и акцентной типографики. Дизайн-концепт После финализации user-flow я подготовила первый концепт. Отразила в нём основные UX-принципы: быстрый доступ к ключевым действиям, крупные кнопки, визуальные разделители между блоками, прогресс-индикаторы.  Отдельно обсуждались: — кнопка «позвать официанта» — как визуализировать её так, чтобы не вызывала случайных нажатий, но была доступна всегда; — поведение элементов в instant-версии и полной версии (например, доступность истории заказов); — система уведомлений внутри приложения (предложила встроить ненавязчивые снэкбары для статусов заказа и действий персонала); — отображение времени ожидания и статуса кухни. Дизайн-концепт утвержден с первого раза без доработок на основе главного экрана.  Теперь делаю экраны: список ресторанов, карточка ресторана, меню ресторана, карточка блюда. Дальше по списку экраны оформления заказа, регистрации, бонусные карты и так далее. Двигаюсь по основным экранам flow, сразу делаю и состояния. Потом буду делать второстепенные экраны. Параллельно делаю дизайн-систему.   Коммуникация и передача Все ключевые решения фиксируются в Figma — я оставляю аннотации, пояснения и маркирую логические ветки. Рабочие обсуждения в Telegram-группе и на Zoom-созвонах. Команда заказчика активно принимает участие в процессах. После каждого ревью я актуализирую Figma-документ, фиксирую все правки и веду историю итераций. Общий результат и статус проекта На текущий момент завершены сценарии, собран user-flow, выбрана стилистика, утверждён первый концепт, делаются основные экраны. Тайминг На данный момент по таймингу на работу по проекту ушло 50 часов. #проект #приложение #ресторан #instant Дизайнер на всю голову

Провела декомпозицию всех функциональных блоков: какие экраны нужны, какие права должны быть, как пользователь перемещается от QR-кода до финальной оплаты. Особое внимание уделила логике работы instant-приложения: важно было, чтобы путь пользователя был максимально коротким и понятным. Основная бизнес-цель — побудить пользователя установить приложение, однако важно учитывать, что многие делают заказ и оплачивают его, не устанавливая его вовсе. Особенно это актуально для гостей, которые сканируют QR-код за столом и не готовы к дополнительным шагам вроде регистрации. Поэтому instant-версия должна давать максимально быстрый доступ к меню, заказу и оплате без лишних барьеров, сохраняя при этом возможность конверсии в установку приложения при повторных визитах. Я предложила разграничить доступ к функциям в зависимости от того, входит ли пользователь в систему или просто сканирует QR. Это позволило облегчить instant-опыт, не перегружая его функциями, доступными только после логина. Также я предложила добавить метки состояния заказов и сообщений (например, «новый заказ», «ответ официанта»), чтобы пользователь не терялся между экранами. Вопросы по логике и переходам я фиксировала в комментариях Figma: например, обсуждали, стоит ли объединять экран с выбором блюда и экран корзины, или это перегружает интерфейс; нужен ли отдельный экран подтверждения оплаты, если она уже завершена через систему; как отображать статус заказа в instant-режиме без пушей. Эти спорные решения мы прорабатывали на созвонах и в Telegram-чате с разработчиком — тестировали на примерах, рисовали альтернативные flow и принимали решения исходя из простоты для пользователя. На скрине финальная user-flow проекта со всеми экранами, сценариями, переходами. Не для детального рассмотрения, а скорее, для понимания объема проекта #проект #приложение #ресторан #instant Дизайнер на всю голову

Основная цель — создание гибридного мобильного решения, которое будет объединять: — просмотр и заказ блюд по QR-меню; — систему лояльности; — бронирование столов; — регистрацию и работу с историей заказов; — систему отзывов, оплаты и — коммуникации с официантом. Ключевая особенность — приложение должно работать как в формате instant-приложения (без установки), так и в установленной версии. Это требовало продуманной архитектуры и UX, учитывающего разные пользовательские сценарии. Клиент предоставил действующий прототип, QR-ссылку на демо, а также Figma-ссылка на старые наработки. Я задала уточняющие вопросы о логике, роли instant-версии и объеме редизайна. Быстро прояснилось, что в основе проекта лежит желание объединить три направления в одном продукте. На старте выстроила структуру пользовательских потоков (user-flow), которую отправила команде в Figma. Зафиксировала вопросы, спорные места и гипотезы. Например: стоит ли выводить блок с лояльностью сразу после первого заказа или только после авторизации; как реагировать на закрытие instant-приложения — сбрасывать ли прогресс заказа или сохранять его при повторном сканировании; как минимизировать путь пользователя от сканирования QR до оплаты. Мы несколько раз проходились по flow на звонках, уточняли сценарии, пересобирали порядок экранов и логику переходов, потому что по ходу обсуждений стало ясно: пользователи путаются между действиями — например, где оставить отзыв, а где посмотреть статус заказа. Некоторые функции (как, например, бонусы или история) лучше располагать в профиле, а ключевые действия — ближе к текущему заказу. Также появлялся новый сценарий использования, когда клиент оформляет  заказ без оплаты через приложение. Поэтому, нужны экраны оформленного заказа без авторизации. На скрине часть user-flow, о которой продолжу в следующем посте #проект Дизайнер на всю голову

Рабочий стол оператора. Заказ попадает в систему двумя способами: Звонит заказчик и оператор вносит его в CRM. Если заказ приходит с сайта, он автоматически появляется в СRM и его нужно подтвердить. Нюанс. Есть те, кто звонит и не знает что ему заказать. Оператор советует блюда, исходя из вкусов заказчика. Чтобы оператор быстрее сориентировался в меню, добавила иконки основных характеристик блюда, например, перчик, мясо, веган и так далее. Есть клиенты, которые хотят повторить заказ. К CRM будет подключена IP телефония. Оператор сразу увидит уже постоянного клиента, его данные, статус, его последний заказ и комментарии к заказу, если вдруг что-то пошло не так. Например, отправить с заказом блюдо в подарок. Добавила функционал исключения ингредиентов как фильтр, например, убрать все блюда с луком. И функционал исключения ингредиента из самого блюда, например, сделать шаурму без лука. Эта информация отправляется на кухню. Всего в системе 3 комментария: адрес, общий комментарий на заказ и комментарий исключения ингредиента в блюде. Новая фича. Раньше в комментариях нужно было ручками писать с какой суммы нужно привезти сдачу, если клиент рассчитывается налом. Я предложила автоматизировать процесс. Теперь оператору достаточно указать какая сумма у клиента, какая должна быть сдача показывается автоматически в система и у курьера. Появилась панель с списками заказов и список сообщений из бота. Спроектировала функционал распределения заказов по цехам в зависимости от адреса заказчика. Клиент захотел сделать систему светофора. Это цветовая система идентификации для оператора. Если чек небольшой или невыгодные блюда, цвет покажет это и оператор попробует допродать какие-то позиции. Как работает. Когда заказ заполнен и оформлен, появляется окно с рекомендациями. Оператор может предложить что-то добавить в заказ, например, напитки, блюдо дня. Есть еще дополнения к блюду, например, рис к том яму. Оператор видит какие дополнения можно предложить к блюду. Сделала этот функционал и поставили проект паузу, чтобы разработчики реализовали то, что готово. #проект #crm Дизайнер на всю голову

Номенклатура это список категорий (роллы, пицца, суши). В категориях размещаются конкретные блюда. Здесь есть спецификация (технологическая карта блюда, бжу, ккал, кол-во штук в порции и т д.) и описание (технология приготовления, фотографии). Есть раздел Цены и дополнения. Тут мы устанавливаем цену за блюдо, смотрим изменение цены и динамику продаж в зависимости от изменения цены. Еще есть дополнения — то, что мы можем допродать с этим блюдом, например, еще колбаску к пицце. Есть еще дополнительные разные настройки, например, то, как это блюдо будет отображаться в мобильном приложении и на сайте. Как правило, большая часть номенклатуры у филиала одна и та же (те же роллы Калифорния, суши с креветкой, пицца Маргарита). Технологическая карта тоже практически одинаковая. Я сделала возможность администратору копировать эту номенклатуру, чтобы филиал мог быстрее начать работу и менять номенклатуру при необходимости. Сделала привязку номенклатуры к филиалу, которой раньше не было, чтобы администратор мог посмотреть цену на какое-то конкретное блюдо по всем или интересующим его филиалам, чтобы анализировать уровень цен и продажи. #проект #crm Дизайнер на всю голову

Чтобы не нагружать большим количеством информации буду рассказывать об отдельных элементах, экранах, функционале. У каждой компании есть должности: руководитель, менеджер заказов, колл-центр и любая роль, которая будет заведена. У должностей может быть рабочий стол — персональный экран с оперативной информацией: текущие заказы на кухне, курьера на смене, обращения в колл-центр, отчеты и так далее. Самая большая сложность тут — правильно структурировать блоки, выставить приоритеты, так как рабочие столы будут визуально сильно нагружены. На скрине скриншот текущий системы, который я сейчас переосмысливаю и покажу результат чуть позже. #проект #crm #erp Дизайнер на всю голову