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

Задаем больше вопросов

Вопрос «зачем?» — это то, с чего дизайнер должен начинать любую задачу. Вы должны понимать пользовательскую или бизнесовую проблему, которую вы решаете с помощью дизайна. Вопрос «зачем» — это мастхэв в вашей коммуникации с продактом или бизнес-заказчиком. Не бойтесь показаться глупым, желание докопаться до сути демонстрирует вашу профессиональную осознанность. Если вам требуется больше информации по задаче, например, вы проектируете навигатор для автомобилистов, но никогда не водили машину — не беда, опросите хотя бы 5 своих знакомых и узнайте, как они сейчас пользуются навигаторами. Вы удивитесь количеству инсайтов, которые соберете в результате небольшого исследования. В начале работы над задачей важно получить максимум вводных данных до которых вы можете дотянуться и приучить себя к осознанному проектированию — дизайнер не должен быть просто руками. Проявляйте инициативу.

Дизайнер + программист = крепкая дружба

Крайне важно построить коммуникацию с командой разработки. Без любимых программистов наш с вами дизайн пылился бы сейчас в рамочке на прикроватной тумбе. Я успел поработать в крупных IT-компаниях на разных продуктах и могу сказать, что чаще всего дизайнеры ведут себя обособленно и общаются по рабочим вопросам только с продакт менеджерами и другими дизайнерами. Фатальная ошибка. Отсутствие связки «дизайнер+программист» приводит к тому, что дизайнер приносит на обсуждение дорогое в реализации решение, получает долю критики и воспринимает это как что-то личное на свой счет. После нескольких таких встреч обиженный и демотивированный дизайнер еще больше отдаляется от программистов, что влияет на скорость и качество реализованных в дальнейшем фич. Каждый раз, когда я прихожу в новую команду, я прошу отсадить меня от дизайнеров поближе к разработке — это дает возможность еще на этапе проектирования оперативно обсуждать все технические нюансы и вовлекать программистов в создание общего дизайн-решения.

Тестируем дизайн-решения

Старайтесь проверять ваши решения на UX-тестах. Увы, но культура исследований не всегда встречается даже в крупных IT-компаниях. Если в вашей команде нет UX-исследователя, возьмите все в свои руки — используйте старые добрые коридорники или тестируйте прототипы на ваших друзьях и знакомых. Благодаря обратной связи вы улучшите продукт, получите доказательную базу для своих решений и прокачаете хард-скиллы.

Фидбек дизайнера дизайнеру

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

Не забываем про аксессибилити

Проверяйте элементы вашего интерфейса на доступность — размеры шрифтов, контрастность элементов в дизайне. Практика показывает, что дизайнеры пренебрегают этим и подбирают цвета элементов и размеры шрифтов на глаз. Если говорить про контрастность, то я использую контраст-чекер от Coolors — советую добавить этот инструмент во вкладки браузера, чтобы всегда был под рукой. Рекомендации по шрифтам смело можно брать из гайдлайнов Apple. А еще есть простое правило: чем больше шрифт, тем легче прочесть текст, так что не мельчите и забудьте про стиль Light у шрифтов — этот стиль придумали Apple для промирования новых Retina-экранов, а не для массового использования.

Job Stories — это полезно

В интернете полно материалов и статей о фреймворке JTBD, поэтому я попытаюсь затронуть только ключевые моменты и покажу примеры.

Jobs to be Done (работа, которая должна быть выполнена) - это методология, которая помогает дизайнеру понять, какие потребности и проблемы пользователи пытаются решить с помощью конкретного продукта.

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

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

Структура джобов состоит из трех значений:

• Ситуация (Situation)

• Мотивация (Motivation)

• Ожидаемый результат (Expected outcome)

Примеры джобов для онлайн-магазина одежды:

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

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

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

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

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

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

Сначала UX, а потом UI

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

Принцип 3 этапов в проектировании

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

• Концепция — на этом этапе, собрав все вводный данные, вы набрасываете UX и UI своего сценария. Закладываете логику и функциональность, работаете с композицией и акцентами вашего интерфейса. На этом этапе происходит согласование вашего дизайна с заказчиком.

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

• Упаковка — подготовка макетов для передачи в разработку. Используйте стрелки, чтобы собрать Screen Flow для вашего сценария и пропишите пояснения для экранов, чтобы помочь разработке лучше понять ваш замысел. Еще лучше, если вы поинтересуетесь у разработчиков в каком виде они хотят получать от вас дизайн — это не займет у вас много времени, а программист с комфортом выполнит свою работу.

Итоги

Здесь я привел основные принципы, которые советую использовать в повседневной работе UX/UI дизайнера. Если у вас есть какие-то дополнения или наблюдения, то буду рад увидеть их в комментариях.