Дизайн мобильных приложений *

Худшая новость для многих SaaS‑команд в ближайшие годы (думаю, уже в этом году заметим) пользователь может перестать пользоваться вашим приложением, но продолжить пользоваться вашим сервисом.

Еще недавно цифровой продукт был устроен предельно понятно. Компания делала приложение, проводила продуктовые исследования, проектировала пользовательские сценарии, раскладывала кнопки, экраны, роли и ограничения. А пользователь либо принимал эту логику, либо уходил.

То есть сама модель была такой:
«Вот наш интерфейс. Вот наш сценарий. Пользуйтесь так, как мы задумали».

Эта модель не исчезнет завтра. Да и на текущий момент она устраивает болшинство пользователей, благодаря сформировавшейся десятилетиями потребительской привычке «используй что дают». Но именно сейчас она начинает терять монополию, потому что между пользователем и сервисом появился новый слой – агенты. Не просто чат-боты, которые подсказывают, а инструменты, которые уже умеют искать данные, ходить по сайтам, нажимать кнопки, связывать сервисы между собой и выполнять цепочки действий. OpenAI вывела Operator как браузерного агента, Anthropic продвигает Computer use и MCP, Microsoft на Build 2025 прямо говорит об open agentic web, а OpenAI отдельно документирует работу с remote MCP servers и коннекторами для доступа к внешним сервисам. 

И вот здесь начинается главное изменение – раньше продуктом был интерфейс, теперь продукт всё чаще смещается в три других слоя:

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

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

Flutter предоставляет для этого мощные инструменты, но истинное мастерство в создании тем оформления выходит далеко за рамки изменения нескольких цветов или шрифтов. Оно включает в себя создание единого языка дизайна, его предсказуемое применение ко всем компонентам, управление масштабируемостью и обеспечение доступности, производительности и удобства сопровождения пользовательского интерфейса по мере развития продукта на мобильных устройствах, в веб-среде и на настольных компьютерах.

Я не разработчик, но теперь у меня есть своё приложение в App Store, которое помогло мне больше ходить и в прошлом месяце я прошёл 500 000 шагов. В этой статье рассказываю как я к этому пришёл и какие инструменты помогли ускорить путь.

В 2013 году на Randomwire была опубликована интересная статья. В ней автор указал на интересные особенности японского дизайна. Японцы известны своим минимализмом, но в случае сайтов у них, почему-то, всё наоборот. Страницы пестрят всевозможными цветами, что уже нарушает 3 принципа дизайна, плюс на них используются мелкие иконки и мно-о-о-о-го текста.  Да вы и сами видите пример этого буйства фантазии на скриншоте выше, сделанном в ноябре 2022 года.

В упомянутой статье приводилось несколько возможных объяснений, которые позднее были подкреплены исследователями культуры, другими дизайнерами и недовольными гражданами.

И вот мне стало интересно, как обстоят дела сейчас, и можно ли как-то количественно оценить дизайн японских сайтов? Собственно, этим я и занялся.

Всем привет! Меня зовут Саша, и последние 12 лет моя жизнь — это дизайн. Сегодня я руковожу дизайн-командой в KISLOROD, а в прошлом — помогал крупным брендам и миллионным сервисам обрести их уникальный голос и форму.

Сегодня расскажу о реализации удобного функционала фильтрации и сортировки товаров.

Выбирая и сравнивая товары, пользователь чаще всего опирается на информацию в категориях со списком товаров — листингах. Функционал фильтрации на страницах листинга призван упрощать выбор, но содержание и логика работы фильтров не всегда отвечают ожиданиям пользователей, что может негативно сказаться на конверсии.

Привет, Habr!

Я — Оля, продуктовый дизайнер в Lenta tech («Группа Лента»). В команде Growth отвечаю за привлечение новых пользователей и развитие омниканальных сценариев в «Онлайне». Вместе с командой нашей задачей было превратить приложение из сервиса для заказа продуктов на неделю в единое омни-приложение, которое закрывает другие покупательские сценарии: повседневные покупки с быстрой доставкой, эконом-формат, товары для животных и алкоголь (в самовывозе). В статье расскажу, что мы сделали в этом направлении, с какими сложностями столкнулись и какие результаты получили.

Это не очередной TODO-лист и не очередной трекер расходов. Это комбайн, в котором живут задачи, заметки, бюджет, аналитика, помодоро-таймер и цели накоплений

Февраль — месяц UX-тематики в нашем блоге. Сегодня рассмотрим рецензию на книгу  про презентацию UX-решения, и это будет вторая книга по UX вслед за рецензией на книгу «UX для бизнеса: как создавать цифровые решения, ценные для бизнеса и пользователей». В UX есть один неудобный факт, который редко признают вслух: качество дизайна почти не коррелирует с тем, попадет ли он в продукт. Можно сделать логичное, интуитивно-понятное и аккуратное решение — и увидеть, как продукт-оунер или другие боссы его упрощают, откладывают или выбрасывают из спринта на ближайшем совещании. И наоборот: слабые решения нередко проходят без сопротивления, если они правильно «проданы». Вот про продажу UX-решения внутри команды сегодня и поговорим.

Есть набор рабочих инструментов для работы с колористикой: часть из них — достаточно простые, часть — могут показаться на первый взгляд сложными. Я постараюсь в этой статье сделать начало работы с инстументами чуть проще, чтобы ты смог быстрее разобраться и главное — постарался применить их в своей работе, чтобы работать с цветом стало проще, быстрее и качественнее. 

Этот набор инструментов будет полезен дизайнерам, потому что превращает работу с цветом из «на глаз» в системный процесс. Также часть из этих инструментов могут работать с OKLCH и помогать в сборке палитры, пока Фигма нам даёт только расширенный гамут в виде переключателя на P-3, но не обзавелась переключателем на OKLCH внутри окна цветовой палитры.

Как превратить ваше приложение в инклюзивный продукт, который используют ВСЕ - от слабовидящих до людей с когнитивными нарушениями. Плюс секретные фишки, о которых молчит документация Apple.

Это руководство создано не для того, чтобы вы просто поставили галочку в Jira. Мы поговорим о том, как код может стать мостом или стеной для миллионов людей.

У меня в ленте бесконечно мелькают размышления о том что все профессии больше не нужны, и только продакты/маркетологи/дизайнеры…etc останутся на коне благодаря вайбкодингу. Так вот, не останутся. Но кони у многих загнутся (Фотографы и копирайтеры, привет!).

По моей версии единственными конкурентными останутся T-shaped специалисты, так называемые принципалы. У которых есть хорошая база академического образования в визуальном дизайне, чтобы делать сочную картинку, есть понимание психологии пользователя, запросов рынка и методологий исследований. Которые знают как собрать минимально необходимую дизайн-систему с нуля под каждый определенный продукт, знают как собрать это всё в каком-нибудь Flutter/FlutterFlow, правильно заанимировать, как проработать воркфлоу и все корнер-кейсы, могут упаковать продукт в эффектную айдентику, создав бренд с нуля. При этом ещё и знают где и как продвигать продукт, ну а архитектуру и базы данных со всеми подключенными ручками уже могут делегировать нейросетям. 

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

Почему мобильное приложение — это база

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

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

Как мы работали раньше и почему ушли от готовых решений

Раньше мы работали с личным кабинетом на SharePoint и нативным мобильным приложением. Оно выполняло базовые задачи, но со временем стало очевидно: архитектура достигла предела масштабируемости, производительность просела, а развивать функционал стало сложно. Требуемую доступность 24/7 оно не обеспечивало.

Жалко, что современные творцы сервисов, которыми мы пользуемся каждый день, страдают от отсутствия хорошего образования и как следствия фантазии. Копипастить и перекрашивать интерфейс в ожидании изменения пользовательского опыта - ну, так себе идея. Стоит иметь минимальное представление о развитии цифровых интерфейсов, чтобы понимать, почему то, что все копирую у друг друга, выглядит именно так и как это можно улучшить минимальными вложениями.

Снова, снова и снова, речь пойдет о утерянной технологии древних Pan-N-Scan. 

Оставлю прелюдии на потом. Чё делать то? 

Добавляем всего одну иконку. Ставим ей два статуса вкл/выкл. Растягиваем контейнер с видео. И вуаля — наслаждаемся по настоящему Полноэкранным режимом, занимающим всю полезную площадь матрицы приобретенного устройства.

Привет, Хабр! На связи Дима Мандельштам, мобильный разработчик в core‑команде Яндекс 360, и Лёша Карпенко, руководитель команды дизайн‑системы. Дизайн — часть повседневной работы наших команд, и он не живёт отдельно. Поэтому сегодня в статье мы вместе поговорим о том, как мы собирали компонент List‑item.

Мобильные разработчики в этой статье найдут метод, с которым можно достичь баланса между гибкостью кода и простотой поддержки. Мы расскажем, как применили data‑driven‑подход к рефакторингу UI: написали анализатор AST для поиска реальных паттернов использования и вывели математическую метрику сложности API. А ещё расскажем о том, как аргументировать и провести масштабную переработку legacy‑кода, не останавливая продуктовую разработку.

Продуктовым дизайнерам будет интересен альтернативный взгляд на проектирование List‑item в дизайн‑системе. Мы разберём, как собирать List‑item — как универсальный компонент с максимальной гибкостью или как набор семантических шаблонов под конкретные сценарии.

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

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

Всем привет, меня зовут Двенадцатова Таня. Я руководитель команды исследователей в «БКС Мир инвестиций». Почти 2 года назад у нас в БКС появились Прожарки. Это мероприятие придумала не я. Более того, его концепция и идея мне изначально не нравились и не были на 100% понятны. Встреча называлась дерзко «Поясни за UX», и явка для всей команды исследователей на нее была строго обязательной.

Как «Поясни за UX» превратилось в Прожарку, зачем мы стали собираться и что обсуждать, а также как Прожарка стала регулярным и востребованным ритуалом, я и поделюсь в этой статье. Возможно, такую практику задумаетесь внедрить и вы, а возможно она у вас и так есть (просто называется иначе), но вы сможете подсмотреть что-то из моих лайфхаков.

Вы когда-нибудь открывали приложение, где переход между экранами выглядит так, будто интерфейс собрали на коленке за час до дедлайна? Экран мигает, элементы прыгают, анимация тормозит и вы инстинктивно хотите закрыть это безобразие. Проблема не в том, что разработчик не умеет делать анимации. Проблема в том, что он не понимает, как работает восприятие пользователя.

Давайте же разберем как делать переходы в iOS-приложениях так, чтобы они не раздражали, не ломали флоу и не заставляли пользователя думать "что-то пошло не так". Выясним почему 60 FPS - это не всегда гладко, как избежать типичных багов вроде джанка и мигания, правильно использовать matchedGeometryEffect, писать кастомные переходы без костылей и отлаживать всё это дело до идеального состояния. В конце разберём реальный кейс - переход от списка к детальной странице без единого моргания экрана.

Интерфейс можно сделать «современнее» по-разному: поменять визуал, добавить анимацию, пересобрать навигацию. Но в процессе можно увлечься и забыть, что пользователю нужнее результат, а не обновление дизайна. Давайте поговорим о ситуациях, когда лучше ничего не менять.

Фразу «давайте сделаем современнее» можно услышать и от бизнеса, и внутри продуктовой команды. Обычно за ней стоит не конкретная задача, а ощущение, что интерфейс устарел и требует изменений.

Пользователь при этом не думает категориями «современно» или «устарело». Он открывает продукт с вполне прикладным ожиданием: выполнить действие и не задумываться о том, как именно устроен пользовательский интерфейс.

Интерфейсы, конечно, меняются, но пользовательские привычки и ожидания формируются годами и обновляются гораздо медленнее. Это хорошо подтверждается практикой UX-паттернов: устойчивые решения сохраняются именно потому, что снижают когнитивную нагрузку и помогают пользователю действовать на автомате. Эту же мысль хорошо раскрывает разбор Якоба Нильсена про AI-агентов и пользовательские ожидания.

Когда их ломают без необходимости, это почти всегда отражается на скорости работы, количестве ошибок и общем отношении к продукту.

Контекст здесь тоже играет решающую роль:

Привет! Меня зовут Евгений Шаламов, я продакт-менеджер в Битрикс24 и отвечаю за мобильное направление. В нашем основном продукте, в веб и десктопной версиях, реализованы десятки инструментов и сценариев, но весь этот масштаб сложно уместить в мобильный интерфейс. Да и сценарии работы в веб и на мобильном устройстве сильно отличаются. Поэтому мы актуализировали мобильное приложение и сделали из него рабочий инструмент, удобный для многих пользователей.

В последнем релизе мы представили обновленный интерфейс мобильного Битрикс24. Нам нужно было решить, как реализовать некий «обязательный минимум» для различных групп пользователей, ведь приложением пользуются сотрудники с совершенно разными ролями.