Издание The Next Web приводит несколько советов, которые помогут дизайнерам понять разработчиков и создать для них более качественный продукт.
Психологи делят людей на две группы: тех, у кого доминирует левое полушарие мозга, отвечающее за логику и аналитические навыки, или правое полушарие, которое ответственно за чувства, интуицию и творческое мышление. Сегодня в ИТ-сообществе с этими двумя группами соотносятся разработчики и дизайнеры.
Это деление достаточно условно. Дизайнеры нередко подкрепляют свои графические решения фактическими данными и статистикой, анализируют сложные сценарии пользовательского поведения и иногда даже код. Разработчикам тоже приходится проявлять креативность, экспериментировать с различными решениями и искать наиболее удобные для пользователя. Обычно они также неплохо разбираются в инструментах дизайна.
Сотрудничество между дизайнерами и разработчиками иногда складывается непросто, но и те, и другие работают на одну и ту же цель: создать продукт, который наилучшим образом удовлетворяет потребности пользователя, привлекателен и функционирует без сбоев. Но вдвойне сложно им становится взаимодействовать, если этот продукт предназначен для разработчиков. Вот пять советов, которые в этом случае следует учесть.
1. Действительно знать своего пользователя
Очень быстро и удобно получать ответы, когда конечный пользователь сидит за столом рядом с создателем инструмента и может непосредственно с ним делиться постоянными тяготами и лишениями процесса разработки на ежедневных митингах.
Но полагаться только на мнение своих коллег при определении целевого потребителя ошибочно. Разработчики, как и дизайнеры, уникальны, и их взгляды могут не совпадать. Фронтенд- и бэкенд-разработчики выбирают различные инструменты, аналитики данных ставят перед собой абсолютно иные цели, чем DevOps-инженеры. Помимо предпочтений пользователя, необходимо также понимать их образ мышления именно в тот момент, когда они будут решать свою проблему с помощью создаваемого инструмента.
Например, средство отладки программ призвано помогать разработчикам в тот ответственный момент, когда обнаружился баг или ошибка, нужно быстро разобраться, что произошло, и исправить неполадки. С учётом удалённости и ограниченной возможности сбора оперативных данных, процесс отладки превращается в поиск иголки в стоге сена в темноте.
Пользователь расстроен, он нервничает, ему жизненно необходимы содержательные ответы и поддержка. Ему необходимо, чтобы кто-то подсказал, в правильном ли направлении он движется, и помог выправить ситуацию до того, как от ошибки пострадают уже его пользователи. Поэтому создаваемый инструмент должен придать пользователю уверенность и в то же время помочь ему быстро и просто найти ответы.
2. Разработка ПО как религия
В одной из серий «Кремниевой долины» упоминалась небольшая проблема Ричарда с табами и пробелами. К сожалению, это не было преувеличением: между двумя лагерями разработчиков действительно идёт безостановочная кровавая война.
Вот как один из толковых словарей английского языка определяет понятие «культ»:
- небольшая религиозная группа, отделившаяся от более крупной общепринятой религии, и верования которой многими признаются экстремистскими и опасными;
- ситуация, когда люди доводят обожествление или важность кого или чего-либо до крайней степени;
- небольшая группа ярых сторонников или фанатов чего или кого-либо.
Для разработчиков это должно звучать знакомо. Они всецело преданны своим фреймворкам, привычным инструментам, и непоколебимо убеждены в никчёмности всего прочего. Разработчики будут упорно сопротивляться, если потребуется изменить сформированные однажды, привычные им правила, будь то шрифты, цвета или иерархия. Поэтому, чтобы склонить их на сторону изменений в дизайне, потребуются очень веские аргументы.
Но держаться в рамках этих условных правил также значит ограничивать собственный творческий порыв. Важно найти правильный баланс между проверенными проектными решениями и свежими элементами UI — для этого необязательно переворачивать с ног на голову мир пользователя.
3. Разработчики тоже люди
Вопреки распространённому мнению и заслуженной репутации разработчиков как капризных, но технически подкованных пользователей, они в первую очередь люди. И как большинство людей, они ожидают от продукта максимальной эффективности и простоты в использовании. Разработчики не любят слишком сложные инструменты, с которыми придётся часами разбираться.
Важно: пользовательский интерфейс должен быть как можно более удобным и интуитивным. Не стоит думать, что так как разработчики — умные люди, то сами во всём разберутся. Если им что-то непонятно, они, скорее всего, не будут утруждаться.
4. Чем меньше, тем лучше
На Dribbble и Behance полно великолепных дизайн-проектов, безупречных таблиц и градиентных панелей, которые отлично выглядят на скриншотах, но на деле не работают. Пользователю не будет никакой пользы от неработающего, хоть и симпатичного приложения. Также пользователь склонен лучше запоминать плохое, чем хорошее, и вряд ли скажет: «Это приложение грузится целую вечность, и я не уверен, для чего здесь все эти кнопки, но заставка — просто божественна!». По достоинству оценить все прелести интерфейса можно только в том случае, если продукт надёжен, удобен и стабильно функционирует.
Сооснователь и главный дизайнер компании Sentry Крис Дженнингс сначала был продуктовым дизайнером GitHub, и уже потом создал инструмент отладки кода для разработчиков. По его мнению, в отношении разработчиков действует именно правило «чем меньше, тем лучше»:
«Есть только одно отличие разработчиков от среднестатистического потребителя: они не будут тратить время на бесполезные или неисправные вещи. Наши клиенты используют Sentry, чтобы решать довольно замысловатые задачи, и наша работа — гарантировать, что наш продукт не заставит их отвлекаться на несущественное, если этого можно избежать.
5. Не нужно бояться просить помощи
Некоторые продуктовые дизайнеры постоянно ищут инсайты о практичности и дизайне продуктов у друзей, которые готовы открыто объяснить технические вопросы и поделиться своими соображениями.
Дизайнеру не всегда просто понять мир разработчика. И хотя дизайнеры близко знакомы с технологией создания продукта, им редко известны технические моменты и терминология настолько хорошо, как разработчикам. В стартапах же у них есть возможность сотрудничать более тесно.
Чтобы оценить юзабельность продукта, дизайнеры могут найти подходящего человека из целевой аудитории, среди коллег или друзей-разработчиков в других стартапах. Скорее всего, им будет лестно и любопытно протестировать новинку, а дизайнер получит полезные отзывы и комментарии. Главное, не забывать, что любой продукт создаётся для людей.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.