Интерфейсы *

Тест на собеседовании на должность проектировщика интерфейсов

Ставим перед соискателем большую коробку с конструктором типа Лего. Задача: собрать его за час. А дальше наблюдать.

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

2. Конструктор должно быть физически невозможно собрать за час. Первый пакет должен занимать в среднем пятнадцать минут, а остальные пакеты должны быть примерно такого же объёма и сложности и это должно быть заметно. Если соискатель, собрав первый пакет за пятнадцать минут, укажет на невыполнимость задачи — он молодец.

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

К сожалению, этот тест — плод моей фантазии развлекательного характера. Представляете, сколько это мороки — подготавливать и упаковывать в пакеты подобные наборы для каждого нового соискателя? Не, проще пообщаться. Но идея не даёт мне покоя :)

А вот ещё один теоретический способ, с помощью которого я бы проверял квалификацию соискателей. Там про цепляние к мелочам.

Несмотря на кадровый голод в IT занято огромное количество лишних людей деятельность которых в общем-то бесполезна. А все что бесполезно как известно приносит только вред. Возьмем к примеру новомодную отрасль UI/UX которая по задумке должна улучшать пользовательский опыт - так называемый "экспириенс". На планете существует целый зоопарк разных форматов дат: 1 ноября 2000, 01.11.2000 и т.д и т.п. Это мелочь, но и в мелочах можно тот самый "экспириенс" взять да и улучшить. И он был повсеместно "улучшен" до формата "3 года назад". Как правило без какой либо возможности вернуть нормальную дату.

Теперь просто хочется простереть руки к небу и крикнуть за что это мне?

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

Как получилось, что юристы используют среду для разработчиков?

e/acc часто пишет про изменение индустрий, вижн будущего, которые он берет из исследований либо из общения с фаундерами (со стороны инвестора). И я у него на канале не первый раз вижу упоминания одной странной штуки.

Мол, можно взять AI среду для разработчиков Cursor и настроить ее как рабочую программу для неразработческих задач. Звучит сомнительно. Но я попытался "покритиковать свою критику", вот что вышло:

Зачем вообще сложный Cursor вместо простого chatgpt?

1. Встроенная реализация агентов

   Система планирует новые действия на основе результатов предыдущих. Пример агента – openai deepresearch. Он понимает, на какие сайты еще сходить на основе того, что уже нагуглил.

   Агент выполняет сложную последовательность шагов (пройтись по гуглтабличке с ссылками на видосы, скачать их, вытащить из них аудиодорожку через ffmpeg, сделать транскрибацию, саммари и сохранить в файлики). Даже если она не известна заранее.

2. Рабочий контекст

   Часто у нас есть какой-то рабочий контекст. Файлики, таблички, инструкции. Программистам важно быстро добавлять нужный контекст к запросам, и Cursor поддерживает это by design. Можно сослаться на конкретный файл или папку. И результаты тоже сразу сохранятся в виде готовых файлов. Плюс есть .cursor/rules "настройками" поведения LLM под разные задачи.

3. Встроенная расширяемость

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

4. Очень удобная работа с текстом.

   Cursor – лучший инструмент для написания текстов. Он умеет завершать предложения за меня, на лету исправляет падежи, сам понимает, куда я хочу переместить курсор. Можно выделить часть текста и дать задачу чисто под нее. Можно сделать что-то со всем текстом и он подсветит изменения.

   По сути, если вы работали с Canvas режимом в ChatGPT, то на пальцах:

   ChatGPT < Canvas < Cursor

   А точнее

   ChatGPT < Canvas <<< Cursor

А что мешает сделать себе полноценный сервис под свою область (ко мне часто приходят с таким запросом)?

Реализовать нормальную агентскую систему – сложно. Бизнесу дешевле взять уже готовое и расширяемое. Но собственные системы можно и нужно делать, когда есть четкие повторяемые задачи, где есть потенциал свести участие человека к минимуму.

А вот если задач много, разных, они не разбиваются на заранее известную последовательность шагов + нужен человеческий контроль/планирование, то я пока не могу ничего лучше придумать, чем Cursor. Переобулся, короче.

P.s. у меня гораздо менее технооптимистичный взгляд, чем у e/acc, и вижу много сложностей во внедрении таких инструментов в реальном бизнесе, но где-то это может сэкономить десятки тысяч долларов.

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

Привет, развил тему пропихивания стручков (pod'ов) в кубернетис, добавил в меню выбора типа объектов команду apply. Теперь kui'ем можно приклеивать мYAMLики, создавая любые типы объектов. По умолчанию предлагает создать стручок:

Но с помощью кнопки edit можно изменить мямлик, изменения сохранятся в файл ~/.kyml.

С удивлением обнаружил что хаб Кодобред переименован в Говнокод О_о Чтож, так даже интереснее.

Творите, выдумывайте, пробуйте!)

Привет, приспичило создать тестовый стручек (pod), проверить кое-что. Создал и добавил это в kui, в секцию "быстрых" команд:

Тестовый стручек создается вот такой командой:

kube run $quick_pod_name $ns --image=$quick_pod_image --command -- $quick_pod_command 2>&1

Для изменения названия, образа или команды стручка подредактируйте вот эти переменные в начале скрипта:

quick_pod_name=busytest          # Pod name for simple test pod
quick_pod_image=busybox:1.32     # Pod image for simple test pod
quick_pod_command="sleep 3600"   # Pod command for simple test pod

Творите, выдумывайте, пробуйте!)

Что не так с кассами самообслуживания? Разбор ошибки в UX

Взяв продукты в Магните, я пошла на кассу самообслуживания. После сканирования товаров, нажала на кнопку «Карта лояльности". Появилась модалка с подсказкой: "Отсканируйте карту в нижнем углу". Я пробовала сканировать её разными способами, но сканер не распознавал телефон. Сотрудник подсказал: "Положите телефон вертикально». Оке, заветный писк машины - задача решена.

После этого на экране появилась вторая модалка с текстом: "Количество баллов — ХХХ, списание баллов невозможно по тех причинам". И две кнопки: «Начислить баллы» и «Вернуться назад». Я случайно нажимаю "Вернуться назад", и карта сбросилась. Снова сканирование, снова модалка — на этот раз всё прошло нормально, скидка применена, баллы начислены. Задача вроде бы простая: получить скидку и баллы за покупку, но процесс оказался не таким уж очевидным. Давайте разбираться. 

Что не так

— Неочевидный сценарий
Когда я сканирую карту лояльности, я ожидаю два простых результата:
• Применение скидки по карте
• Начисление баллов за покупку

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

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

Как можно улучшить

— Объединение шагов.
Зачем разделять информацию на две разные кнопки, если можно предоставить все нужные данные в одном окне? Вместо того, чтобы показывать «начисление баллов» и «сбросить», лучше использовать одну универсальную кнопку с кнопкой «Продолжить», которая будет обрабатывать все сразу.

— Упрощение текста.
Модалку можно отредактировать, чтобы она содержала только нужную информацию для пользователя в одном окне:

модалка
Количество баллов: 36,8
Будет начислено за покупку: 17
Списание баллов невозможно по техническим причинам.
[продолжить] 

Всё, процесс завершён! Всё становится понятно с первого взгляда, и пользователь не теряет время на лишние шаги.

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

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

Android-приложение «Контакты»: работает — не трогай

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

Чтобы заменить стандартные типы полей, нужно добавить новую базу данных с доступными типами полей, а также реализовать отображение и возможность выбора поля. Для этого пришлось во многом переписать код редактирования полей контакта, где и без этого логика была непростой. Теперь стало совсем сложно: при добавлении или обновлении поля в contentProvider нужно указывать тип поля, так что мы начали указывать «custom».

После добавления кастомных типов приложение потеряло стабильность, появились кейсы, в которых кастомные типы работали неправильно. Один из них приводил к крашу: база данных не успевала создаваться при открытии интента на редактирование контакта.

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

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

Пришлось опять добавлять костыль: в отдельной корутине ожидать инициализации БД и только потом начинать рисовать экран...

Дмитрий Бражник, старший инженер-программист в департаменте разработки мобильных приложений YADRO, рассказал в статье, как его команда пыталась допилить стандартное AOSP-приложение «Контакты» и к чему они в итоге пришли.

#статья Гайд: как сделать хороший текст для интерфейса, на примере сайта Самоката

Новая статья уже вышла на нашем Хабре. на этот раз своим опытом поделилась UX-редакция ecom.tech. На примере сайта Самоката рассказали, как писать просто о сложном и не раздражать пользователей.

Время прочтения: 4 минуты.

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

🙂 Читать статью

Что такое дизайн?

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

На текущей момент мне близки несколько вариантов определения в контексте профессии продуктового дизайнера или UX/UI-дизайнера, которые уже и не помню откуда помню:

Вариант №1: Дизайн — это художественное конструирование.

Для меня дизайн-отдел — это в какой-то степени конструкторское бюро, а дизайнеры — конструкторы или архитекторы.

Вариант №2: Дизайн — это рациональная и эстетическая организация пространства.

Где-то услышал и записал себе. Похоже на первое, но другими словами, с акцентом на преобразование свойств пространства.

Вариант №3: Дизайн — это наведение порядка.

Довольно специфическое понятие, но я заметил, что часто именно через него смотрю на дизайн. В хорошем дизайне всё на своих местах и этот порядок нужно понять или [пере]придумать.

БИП-FIN - двуязычная клавиатура для быстрого и точного ввода текста одним пальцем

• Никаких AI подсказок и глупой авто коррекции, после которой запаришься исправлять.

• Никаких микроскопических кнопок в которые фиг попадёшь.

• Все кнопки находятся рядом, а не разбросаны по экрану.

• Не занимает много места - можно отображать в углу, не отъедая пол экрана.

• На таче каждая буква вводится одним простым жестом: нажал-провёл-отпустил.

• На пульте каждая буква вводится двумя нажатиями: выбор клавиатуры -> выбор символа.

Ближайший аналог: MessageEase - всем хорош, но переключение языка очень не удобное.

Демка в вебе на попробовать тут. Кто готов реализовать её на Android/iOS - гоу сюда, обсудим детали.

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

Хотя, признание недуга - первый шаг к выздоровлению, обращайтесь коллеги, у меня еще будут рецепты, например от «свинства».

Такая вот непризнанная победа.

Задача казалось бы реализованная уже множество раз. Но я вдруг осознал, что не знаю на нее ответа.

Простейший календарик-напоминалка о наступающих днях рождений: в соцсети, в мессенджере, на сайте. Обычно формат "дата - имя". Просто, лаконично, единообразным списком. И вот приближается праздник у родившегося 29 февраля. А в этом году в феврале только 28 дней. Традиции празнования - понятно, лучше после, чем до. А технически, в списке напомнинания, как вывести несуществующую дату? Какие есть красивые решения, и чтобы не соврать, и человека не обидеть, и не занимать лишнее место в продуманном компактном интерфейсе.

Вышла седьмая версия UIKit — ключевой библиотеки дизайн‑системы Gravity UI

Добавили больше возможностей, которые упрощают создание доступных интерфейсов.

• Все всплывающие элементы реализованы на основе Floating UI вместо устаревшего popper.js. Эта библиотека позволяет делать такие элементы более доступными и предоставляет более богатый инструментарий для настройки их поведения.

• Компоненты Button и Link расширяют интерфейс базовой кнопки или ссылки. Теперь их легче использовать как нативные элементы.

• Обновили дизайн у компонента RadioButton, заодно сменили его имя. Новое название SegmentedRadioGroup точнее отражает суть.

• Переработали Popover, удалили из него всё лишнее, упростили API — теперь компонент стал проще, понятнее и ближе к лучшим практикам разработки. Старую версию отметили как устаревшую.

• Компонент NumberInput перенесли из тестирования в основные компоненты.

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

• Переработали Tabs, теперь это набор компонент TabList, Tab и TabPanel с улучшенной доступностью. Компонент Tabs отметили как устаревший.

• Добавили новые размеры в компоненты Avatar, User и UserLabel.

• Убрали стилизацию скроллбаров страницы по умолчанию.

Полный список изменений можно посмотреть здесь. Если вы уже используете Gravity UI, будем рады обратной связи: обязательно заглядывайте в наш комьюнити‑чат. А также ставьте звёздочки на GitHub и следите за обновлениями!

Привет, Хабр! 👋

Сегодня обсудим:

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

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

Почему правильные названия классов важны?

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

Правильное именование классов:

Быстро передаёт логику интерфейса от дизайна к коду.
Упрощает поиск и правки элементов.
Ускоряет работу всей команды.

Как закладывать названия классов в Figma?

1. Осмысленно именуйте слои

Избавьтесь от названий вроде Rectangle 57. Используйте понятные иерархические названия, отражающие суть элемента:

button/primary вместо Rectangle 3.

card/header вместо Frame 7.

Используйте иерархию через /:

form/input — поле формы.

menu/item, menu/icon — структура меню.

2. Смысл важнее внешнего вида

Названия должны описывать функциональность элемента, а не его внешний вид:

❌ red-button, big-header.

✅ button/primary, header/main.

3. Группируйте элементы в компоненты

Например, карточка:

card/container — внешний фрейм.
card/header — заголовок.
card/description — текст.

4. Добавляйте комментарии

Если элемент сложный, подпишите его в Figma:

У слоя button/primary напишите: «Класс button--primary».

Как формировать названия классов в HTML?

1. Используйте методологию BEM

Методология BEM (Block Element Modifier) позволяет структурировать классы:

Блок — независимый элемент (button, card).
Элемент — часть блока (card__title, button__icon).
Модификатор — состояние или вариация (button--primary, button--disabled).

Пример:

<div class="card">
  <h3 class="card__title">Заголовок</h3>
  <p class="card__description">Описание</p>
  <button class="button button--primary">Подробнее</button>
</div>

2. Не перегружайте классы визуальными характеристиками

❌ card-blue-border.

✅ card--highlighted (если это акцентная карточка).

3. Сократите вложенность

Чем проще структура, тем легче её поддерживать.
Плохой пример:

<div class="container">
  <div class="card">
    <div class="card__header">
      <h3 class="card__title">Заголовок</h3>
    </div>
  </div>
</div>

Лучше так:

<div class="card">
  <h3 class="card__title">Заголовок</h3>
</div>

Практический пример: кнопки

В макете есть три вида кнопок: основная, второстепенная и отключённая.

В Figma:

button/primary.

button/secondary.

button/disabled.

В HTML:

<button class="button button--primary">Купить</button>
<button class="button button--secondary">Подробнее</button>
<button class="button button--disabled" disabled>Недоступно</button>

Если названия в Figma понятные, разработчик легко перенесёт их в HTML.

Частые ошибки

1. Слои без имён
   Rectangle 47 или Frame 8 только замедляют работу.

2. Визуальные характеристики в названиях
   Названия вроде red-button или big-header усложняют масштабирование проекта.

3. Сложные иерархии
   Чрезмерная вложенность в макете или коде создаёт путаницу.

Мини-чеклист для дизайнера

1. Осмысленно и структурировано именуйте слои в Figma.

2. Избегайте визуальных характеристик в названиях.

3. Используйте иерархию через / для группировки элементов.

4. Добавляйте подсказки для разработчиков.

5. Согласуйте с командой принципы именования до старта.

Итоги

Грамотно продуманные названия классов и слоёв:

Упрощают связь между дизайном и кодом.
Экономят время команды.
Делают проект удобным для доработок и масштабирования.

Закладывайте структуру на этапе дизайна, и работа станет проще для всех. 🚀

Где почитать:
BEM для дизайнеров от DSGNERS
Подробно на Хабре про взаимодействие дизайнеров и разработчиков от PIXONIC
Про нейминг слоев от Павла Пономаренко

До связи 🤝

Привет, Хабр! 👋 Сегодня говорим про

Дизайн-токены: как настроить зависимости между базовыми и сложными токенами, и не потеряться

Что такое дизайн-токены?

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

Разделяются на:

Базовые — это минимальные элементы (цвета, отступы, шрифты). Например:

color-primary: #FF5722;   
spacing-base: 8px;   
font-size-base: 14px;  

Сложные — они зависят от базовых и описывают конкретные элементы интерфейса (кнопки, карточки, модальные окна). Например:

button-primary-bg: color-primary;
button-primary-padding: spacing-base * 2;  

Почему важно настраивать зависимости?

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

🚀 Ускоряет внесение правок.

⚖️ Гарантирует консистентность.

📈 Облегчает масштабирование.

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

Как настроить зависимости между токенами?

1. Начните с базы

Создайте чёткий набор базовых токенов, которые описывают вашу визуальную систему. Они должны быть универсальными и легко читаемыми.

Пример:

color-primary: #FF5722; 
color-secondary: #2196F3; 
spacing-base: 8px; 
font-size-base: 14px; 
radius-base: 4px;

2. Используйте базовые токены в сложных

При работе с компонентами используйте базовые токены как основу для сложных. Это создаёт гибкую систему, где каждый компонент "наследует" свойства от базовых переменных.

Пример:

button-primary-bg: color-primary;
button-primary-text-color: #FFFFFF;
button-primary-padding: spacing-base * 2;
card-border-radius: radius-base;

3. Структурируйте токены по уровням

Для больших проектов важно организовать токены в логичные группы:

Базовые токены: цвета, размеры, отступы.
Токены компонентов: кнопки, карточки, поля ввода.
Токены состояний: ховер, фокус, отключённые элементы.

Пример структуры:

// Базовые токены 
color-primary: #FF5722; 
color-primary-hover: darken(color-primary, 10%); 
spacing-base: 8px;
// Кнопки 
button-primary-bg: color-primary; 
button-primary-hover-bg: color-primary-hover; 
button-primary-padding: spacing-base * 2;

4. Автоматизируйте процесс

Для упрощения работы с токенами и синхронизации между дизайном и разработкой используйте инструменты:

Figma Tokens — плагин для создания токенов в Figma.
Style Dictionary — инструмент для генерации токенов в разных форматах (CSS, SCSS, JSON).

5. Тестируйте на реальных кейсах

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

Частые ошибки при работе с токенами

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

Отсутствие связи между токенами
Избегайте "хардкода". Например, вместо #000000 используйте базовый токен color-primary.

Игнорирование инструментов
Попытки вручную управлять токенами в большом проекте только усложняют процесс.

Что мы получим, если сделаем всё правильно?

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

Где почитать:
Простыми словами про токены на Хабре
Ультимативный гайд по дизайн-токенам на Хабре от Usetech
Про взаимодействие дизайнеров и инженеров при работе с токенами на DevMaster

До встречи, Хабр!

Собрала топ горячих клавиш в Figma для ускорения ежедневных задач, которыми пользуюсь постоянно и считаю must have для каждого.

Слэш (/) используется для разделения клавиш, которые выполняют одну и ту же функцию на разных платформах (Mac OS / Windows)

Навигация по слоям
Когда макет разрастается до десятков фреймов и сотен слоёв, ручное копание в слоях превращается в мучение, но процесс можно ускорить:

Cmd/Ctrl — Выделение конкретных объектов внутри группы

Enter — Провалиться на слой ниже

Shift + Enter — Подняться на слой выше

Cmd/Ctrl + Y — Переход в режим скелета (помогает найти потеряшек)

…

Перемещение объектов
Часто объект просто не хочет встать на место, потому что автолайаут тянет его туда, куда не надо. Добавьте гибкости в перенос с помощью клавиш:

Shift + Cmd/Ctrl + R — Вставка с заменой выбранного элемента

Перемещение с зажатым Space — Игнорирование структуры макета

Перемещение с зажатым Сontrol/Ctrl — Игнорирование автолайаута

…

Масштабирование
Хватить мучать колесико мыши и «зумить» вручную, просто зажимай:

Shift + 1 — Показ всех макетов

Shift + 2 — Фокусировка на выделенном объекте

Shift + 0 — Зум до 100%

Двойной клик по иконке слоя — Фокусировка рабоче области на объекте

…

Общее

/ — Включить курсорный чат

Shift + С — Скрыть комменты

Cmd/Ctrl+ L — Скопировать ссылку на конкретный фрейм/объект

Shift + Cmd/Ctrl + С— Скопировать выделенный объект в буфер обмена как PNG

…

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

Совет: Добавляйте горячие клавиши для плагинов и действий, если используете их хотя бы раз в неделю. Это заметно ускорит работу и избавит вас от лишних кликов.

Привет, Хабр! 👋 Сегодня говорим про

UX‑аудит, как найти и устранить проблемы интерфейса с помощью UX‑законов

Создание удобного интерфейса — сложная задача, где даже мелкие недочёты могут вызвать недовольство пользователей. Если метрики падают, а отзывы оставляют желать лучшего, вам нужен UX‑аудит. Сегодня расскажу как провести аудит, какие методы использовать и как помочь себе с помощью UX‑законов.

Что такое UX‑аудит и зачем он нужен?

UX‑аудит — это проверка интерфейса на удобство использования. Его цель — выявить проблемные точки, которые мешают пользователям выполнять задачи.

Когда проводить UX‑аудит?

📉 Низкая конверсия или высокий показатель отказов.

👿 Пользователи жалуются на сложности.

👨‍🎨 Вы готовитесь к редизайну.

Методы UX-аудита

1. Использование UX-законов

UX-законы — принципы, объясняющие поведение пользователей. Примеры:

Закон Миллера: Человек удерживает в памяти 5–9 элементов. Убедитесь, что ваш интерфейс не перегружен информацией.

Закон Фиттса: Чем дальше и меньше элемент, тем сложнее на него нажать. Проверьте размеры кнопок.

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

2. Анализ данных

Инструменты аналитики помогут найти проблемные места:

Карта кликов: показывает, какие элементы привлекают внимание, а какие игнорируются.

Сессии пользователей: дают понять, где пользователи застревают.

Конверсия и отказы: указывают на слабые места в пути пользователя.

3. Пользовательские исследования

Юзабилити‑тесты: наблюдайте, как пользователи выполняют ключевые задачи.

Опросы: выясните, что нравится или раздражает.

Интервью: погружайтесь в опыт реальных людей, чтобы понять их мотивацию.

4. Хейтерская сессия

Попробуйте сами быть самым критичным пользователем: что мешает вам дойти до цели? Этот метод помогает выявить очевидные проблемы. Не переусердствуйте!

Как провести UX‑аудит?

1. Сбор данных

Начните с анализа аналитики и обратной связи. Выявите точки, где пользователи испытывают трудности.

2. Проверка по UX‑законам

Проанализируйте интерфейс: Не перегружен ли он информацией? Удобно ли пользоваться навигацией? Интуитивно ли расположены кнопки?

3. Тестирование с пользователями

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

4. Составление рекомендаций

После сбора данных подготовьте список аргументированных доработок.

Например: Оптимизировать структуру страниц. Улучшить тексты, чтобы они стали понятнее. Изменить дизайн кнопок или форм.

Зачем учитывать UX‑законы?

Применение UX‑законов помогает избежать распространенных ошибок. Например:

Проблема: высокая отказоустойчивость в онлайн‑магазине.

Решение: сократили количество фильтров (закон Миллера), упростили поиск. Конверсия выросла на 20%.

Итоги UX‑аудита

После UX‑аудита ваш продукт станет:

Понятным: пользователи быстрее осваивают интерфейс.

Интуитивным: меньше ошибок и сложностей.

Эффективным: выше конверсии, меньше отказов.

Где почитать:
Подробно про аудит и как его делать от Fuse8
Руководство по улучшению интерфейса от Pixcap
Чек-лист по юзабилити в e-commerce от TexTerra

Помните: UX‑аудит — это не разовая акция, а постоянный процесс. Всегда найдётся, что улучшить! До связи 🤝

Привет, Хабр! 👋 Поговорим о том,

Как учесть особенности Android и iOS при проектировании интерфейсов

Делаете приложение для Android и iOS? Отлично! Но чтобы ваш продукт стал действительно удобным и естественным для пользователей обеих платформ, нужно учитывать их особенности. Сегодня расскажу, как платформа влияет на дизайн, в чем основные различия и как с этим работать.

Почему важно учитывать специфику платформ?

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

Пользователи почувствуют, что «что-то не так» — привычные жесты или расположение кнопок будут работать иначе, что вызовет раздражение.

Разработка станет сложнее — без учета гайдлайнов платформы команде придется тратить больше времени, сил и нервов.

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

Разберем ключевые различия между Android и iOS

Навигация

🤖 Android: используют нижнюю панель (Bottom Navigation) или бургер-меню.
🍏 iOS: предпочитают Tab Bar и размещают кнопку «Назад» в верхнем левом углу.
👉 Совет: следуйте нативным паттернам платформы. Например, Tab Bar на iOS работает лучше, чем бургер-меню.

Кнопки

🤖 Android: чёткие формы с тенями (Material Design).
🍏 iOS: минимализм с большим количеством свободного пространства.
👉 Совет: создайте универсальный UI-kit с вариантами для каждой платформы.

Шрифты

🤖 Android: шрифт Roboto.
🍏 iOS: шрифт San Francisco, оптимизированный для устройств Apple.
👉 Совет: используйте нативные шрифты, чтобы текст выглядел привычно.

Анимации

🤖 Android: акцент на плавных переходах и изменениях состояния.
🍏 iOS: сложные жесты и динамичные анимации для интерактивности.
👉 Совет: обсуждайте анимации с разработчиками, чтобы они соответствовали возможностям платформ.

Иконки

🤖 Android: детализированные, с акцентом на материалы.
🍏 iOS: минимализм, строгие пропорции.
👉 Совет: согласуйте с командой размеры и формат иконок заранее.

Как это влияет на продукт?

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

На чем фокусироваться?

Изучайте гайдлайны: перед проектированием прочитайте рекомендации для Android и iOS. В Figma Community можно найти актуальные гайдлайны для обеих систем и опираться на них.

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

Создавайте дизайн-систему: унифицируйте элементы, но учитывайте специфику каждой платформы. Разделяйте, стандартизируйте в меру и поддерживайте актуальность.

Тестируйте на устройствах: проверяйте макеты на реальных Android и iOS.

Итог

Проектирование интерфейсов для Android и iOS — это баланс между ожиданиями пользователей, стандартами платформ и возможностями разработки. Уважайте гайдлайны, работайте в команде и создавайте продукты, которые будут удобными и органичными для всех.

До связи 🤝

Привет, Хабр!

Сегодня хочу поговорить о том, как развить дизайн‑концепцию, создать UI‑kit, и шагнуть на новый уровень с помощью дизайн‑систем.

Готовы? Окей летс го!

Что такое дизайн‑концепция?

Это основа вашего визуального решения: стиль, настроение и принципы, которые делают продукт узнаваемым и целостным. Это как фундамент дома — без него всё развалится.

Зачем она нужна?

💡 Помогает визуально выделить продукт на рынке.

🎯 Упрощает коммуникацию с командой: все работают в одном направлении.

⏱️ Экономит время: больше не нужно гадать, как стилизовать новый экран.

Как развить свою дизайн‑концепцию?

Погрузитесь в проект
Исследуйте продукт, целевую аудиторию, конкурентов. Поймите, какие эмоции должен вызывать ваш дизайн: доверие, радость, уверенность?

Пример:
Для финтех‑приложения важно создать ощущение надёжности. Значит, дизайн должен быть строгим, минималистичным, с использованием сдержанных цветов.

Определите основные элементы стиля:
Шрифты / Цветовая палитра / Графика и иконки / Стиль фотографий или иллюстраций

Совет: Не пытайтесь придумать всё сразу. Начните с базовых вещей: 2–3 основных цвета и 1–2 акцента.

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

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

Создание UI‑kit: с чего начать?

UI‑kit — это набор компонентов, который помогает вам быстро собирать интерфейсы.

Определите основные компоненты
Кнопки, текстовые поля, переключатели, карточки — начните с самых базовых элементов.

Пропишите состояния
У каждой кнопки или поля ввода есть несколько состояний:
Нормальное / Наведение / Активное / Ошибка / Заблокированное

Пример: Кнопка «Купить» в обычном состоянии зелёная, а при наведении становится чуть темнее.

Унифицируйте стили
Используйте одни и те же отступы, закругления, шрифты.

Задокументируйте
Пропишите, где и как использовать каждый элемент. Это сэкономит время команде.

Что дальше? Дизайн‑система!

Когда ваш UI‑kit становится большим и вы начинаете работать с масштабными проектами, пора задуматься о дизайн‑системе. (тут можно упомянуть работу с токенами, но это тема для отдельного поста)

Дизайн‑система — это:

Чёткий свод правил и компонентов.

Инструмент для масштабирования дизайна.

Связующее звено между дизайнерами и разработчиками.

Пример структуры дизайн‑системы:

1. Гайдлайны: цвета, шрифты, стили.

2. Библиотека компонентов: кнопки, карточки, модальные окна.

3. Паттерны: как компоненты используются вместе.

4. Документация: примеры и объяснения.

Итог:

Развивать дизайн‑концепцию — это как сочинять музыку. Всё начинается с вдохновения, но только систематическая работа превращает идею в мощный инструмент.

Думайте стратегически: ваша концепция — это не просто про красоту, а про решение задач.

Делайте проще: UI‑kit и дизайн‑системы помогут вам ускорить работу.

Тестируйте: каждый элемент должен быть полезным и логичным.

Где почитать:
Что такое UI-kit от Bang Bang Education
Доходчиво про дизайн-системы от моих любимых Tilda Publishing
Еще про дизайн-системы на Практикуме

До встречи на Хабре! 👋

Хабр, привет!

Сегодня поговорим о UX-тестировании и глубинных интервью.

Как сделать так, чтобы тесты выявляли настоящие проблемы, а интервью давали ценную обратную связь? Разбираем степ бай степ!

Что такое UX-тестирование?

Это процесс, в котором вы наблюдаете за тем, как пользователь выполняет определённые задачи в вашем продукте. Цель - понять, что работает, а что вызывает сложности.

Как провести эффективное тестирование?

1. Сценарии вместо вопросов.
Давайте пользователям конкретные задачи, а не абстрактные вопросы. Вместо «Что вы думаете об этом экране?» скажите: «Попробуйте найти ближайший магазин на карте». Это помогает увидеть реальное взаимодействие.

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

3. Молчите и наблюдайте.
Когда пользователь запутался, не спешите подсказывать. Вместо этого спросите: «Что бы вы сделали дальше?» или «Почему вы решили нажать сюда?». Молчание помогает понять, где интерфейс недоработан.

4. Фиксируйте факты.
Записывайте то, что пользователь делает, а не то, что вам кажется важным. Например, вместо «он ошарашен и запутался» напишите: «трижды нажал на кнопку “Назад”, чтобы найти меню».

Что такое глубинные интервью?

Это формат, где вы задаёте пользователю вопросы, чтобы узнать его опыт, мотивацию и проблемы. Главное здесь - не задавать наводящих вопросов.

Как провести глубинное интервью?

1. Открытые вопросы — наше всё.
Спрашивайте так, чтобы человек мог подробно ответить. Например: «Как вы обычно ищете билеты на концерт?», а не «Вам нравится искать билеты в приложении?».

2. Спрашивайте о прошлом опыте.
Пользователи не всегда знают, чего они хотят, но помнят, что им не нравилось раньше. Вместо «Что вы хотите от новой функции?» лучше спросить: «С какими проблемами вы сталкивались, когда пользовались похожими продуктами?».

3. Уточняйте детали.
Если человек сказал что-то важное, не бойтесь уточнить: «Почему это для вас важно?», «Что именно было неудобным?». Это раскроет проблему глубже.

4. Не оценивайте ответы.
Сохраняйте нейтральность. Например, не говорите «Это интересное мнение». Пользователь может начать говорить только то, что, как ему кажется, вам нужно услышать.

5. Всегда спрашивайте: «Что я забыл спросить?»
Этот вопрос открывает новые инсайты. Пользователь может вспомнить то, о чём вы даже не подумали.

Зачем это всё?

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

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

Где почитать:
Про виды и методы UX-тестирования на Яндекс.Практикум
9 методов UX-тестирования на UX Journal от Рината Шайхутдинова
Про глубинные интервью от UPROCK