Представьте, что дизайнера в команде нет, а экран надо выпускать. Саппорт пишет, что люди не находят нужную кнопку, тимлид просит переделать форму по-человечески, а в тикетах раз за разом возникает: «Не понимаю, что здесь нажать».
Представьте, что дизайнера в команде нет, а экран надо выпускать. Саппорт пишет, что люди не находят нужную кнопку, тимлид просит переделать форму по-человечески, а в тикетах раз за разом возникает: «Не понимаю, что здесь нажать».
В статье есть ссылки партнеров. Это значит, что если вы что-то покупаете с нашей помощью — вы также поддерживаете dev.by. (Вот другой способ).
При этом редакция и авторы независимы в выборе темы, концепции материала, фокуса описания, подхода к услугам или товарам. Прежде чем что-то советовать, мы много читаем и смотрим по теме, говорим с экспертами.
Редакция может выражать свое мнение и пробовать всё на себе.
Если рекомендательный материал обновляется, мы указываем, что и когда поменялось, в самом начале
Первая мысль: надо срочно стать дизайнером — освоить Figma, теорию цвета, композицию, типографику и пройти UX-курс. Но экран-то должен быть уже на этой неделе.
Инженеру без дизайнера не нужно на время проекта осваивать чужую профессию. Сначала достаточно собрать понятный типовой интерфейс, выбрать привычные решения и показать результат людям, которые не знают продукт изнутри.
Автор интерфейса почти всегда знает о нём слишком много. Вы помните, что кнопка запускает импорт, почему действие спрятано в этом меню и что означает аббревиатура рядом с полем. Пользователь этого не знает.
Так на экран попадают все поля из базы, настройки из API и действия, которые когда-нибудь могут пригодиться. Формально система работает. Но человеку приходится сначала разбираться в её устройстве и только потом делать свою работу.
Это и есть лишняя когнитивная нагрузка: силы уходят на расшифровку интерфейса, а не на работу. Nielsen Norman Group объясняет: чем больше усилий требует управление системой, тем труднее найти нужное и завершить задачу. Лишнее оформление, непривычные подписи и необходимость помнить данные только мешают.
Плохой UI редко падает. Люди выбирают первую похожую кнопку, возвращаются назад, пишут в саппорт или годами пользуются обходным путём. Команда видит работающую функцию, а пользователь каждый день теряет на ней время.
Вы тоже можете сделать понятный экран, даже если не планируете становиться продуктовым дизайнером.
Дизайнер работает не только с видом кнопки. Он разбирается, какую проблему решает продукт, как выглядит сценарий целиком, что нужно пользователю и как элементы будут работать вместе. Если дизайнера нет, ваша задача скромнее: собрать экран с понятной структурой и не добавить новых препятствий.
Не обязательно изобретать новый способ взаимодействия. Часто лучше взять знакомый паттерн и проверить, что он работает в вашем сценарии.
Пройдитесь по этому списку, когда экран уже собран и хочется поскорее закрыть задачу.
Теперь покажите экран людям, которые не участвовали в разработке и хотя бы примерно похожи на его будущих пользователей. Это не полноценное исследование и не статистика. Но три разговора часто быстро показывают, где человек застревает в типовом сценарии.
Дайте каждому одну конкретную задачу. Не «протестируй форму», а, например: «Добавь нового сотрудника и дай ему доступ к отчётам». Затем молчите: не объясняйте, где кнопка, и не защищайте решение.
Можно спросить: «Что ты сейчас видишь?», «Что, по-твоему, произойдёт дальше?» и «Что ты хочешь сделать?». Если несколько человек спотыкаются в одном месте, меняйте экран, а не ищите виноватого пользователя.
Такая проверка — не голосование. Пользователь показывает, где ему трудно. Как исправить проблему, решает команда.
Если продукту нужен date picker, select, модальное окно или таблица, сначала спросите не «можем ли мы написать это сами?», а «зачем нам это писать?»
Хорошая компонентная библиотека берёт на себя типовые состояния и поведение. Но она не сделает интерфейс понятным автоматически: всё равно нужно продумать сценарий, выбрать подписи, расставить приоритеты и проверить результат. Библиотека поможет реализовать ваше решение, но не примет его за вас.
Термины UI kit, component library и design system разные команды используют по-разному. Небольшой команде важнее другое: поддерживаются ли компоненты и понятно ли, как их применять. Тогда не придётся собирать каждый select с нуля.
Если вы не разово чините форму, а регулярно разбираете пользовательские сценарии и проводите проверки, знания стоит упорядочить. Но не учитесь на всякий случай: выбирайте курс под ближайшую задачу.
Foundations of User Experience (UX) Design на Coursera подойдёт, если нужен общий каркас. Это вводный курс Google для новичков: в программе заявлены основы UX, user-centered design, доступность и методы исследования. Он входит в профессиональный сертификат Google UX Design, но его можно проходить отдельно.
Usability Testing Boot Camp на Udemy — если нужно научиться проводить проверки. В программе — планирование теста, подбор участников, формулировка заданий, модерация и разбор наблюдений. Среди аудитории на странице курса отдельно указаны product development engineers.
Practical UI UX Design: End-to-end from research to testing на Udemy — когда нужен маршрут шире: исследование, информационная архитектура, основы визуального дизайна и usability testing. Это не быстрый способ исправить один экран, а вариант для тех, у кого UX становится постоянной частью работы.
Цена, язык и содержание программ могут меняться, поэтому перед покупкой проверьте актуальную страницу курса.
Принцип «не навреди» не должен становиться оправданием вечного отсутствия дизайнера. Для внутренней админки, MVP или узкой утилиты базовых правил, готовых компонентов и проверки сценария может быть достаточно. Но если продукт выходит на внешний рынок и конкурирует с другими, дизайн становится частью самого продукта. Важны onboarding, информационная архитектура, сценарии и то, насколько согласованно всё это работает.
Если команда спорит уже не о реализации, а о том, какой сценарий нужен пользователю; саппорт получает однотипные вопросы «где это найти» или проверки снова и снова находят проблемы в одной части продукта — пора искать дизайнера. Здесь работа уже вышла за пределы отдельного экрана. Но это не значит, что инженер плохо справился.
Не пытайтесь за вечер стать дизайнером. Сначала сформулируйте, какую задачу человек должен выполнить, соберите для неё знакомый интерфейс, выделите основное действие и не прячьте важное за инструкцией.
Потом покажите экран трём людям, которые не участвовали в разработке. Если они без подсказок понимают, что происходит и куда идти дальше, у вас уже есть хорошая основа. Если нет — вы узнаете это до релиза, а не из тикетов саппорта.
А если проверки постоянно приводят к вопросам о сценариях, структуре и поведении продукта, зовите дизайнера. Задача инженера — сделать так, чтобы отсутствие дизайнера не мешало пользователю работать.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.