1. Пропускать этап концепции
Этап согласования концепции может сэкономить много вашего времени. Понимание расположения элементов, композиция, в которую они складываются, – для этого достаточно нарисовать главную страницу в нескольких вариантах. Иначе, когда вы уже нарисовали 40 страниц сложнейшего личного кабинета, выставили по сетке и скомпоновали в формах все поля от «ФИО» до «День рождения вашего попугайчика», с небес от клиента может прозвучать страшное: «Коллеги, мы показали это руководству, они хотят навигационный блок сделать не шапкой, а боковой колонкой…».
Впрочем, от работы с заказчиком здесь тоже зависит многое, но об этом – в другой раз.
2. Не использовать чек-листы
Посвящается всем коллегам, кто сталкивался с таким явлением, как ядерная зима правки. То есть всем коллегам.
Мы не роботы. Мы ошибаемся и забываем. Работая не над одним проектом, а, к примеру, над пятью или десятью параллельно, ошибаемся и забываем мы, увы, гораздо чаще. На самом деле речь не только о правках: проектирование сложного набора функций тоже подразумевает список требований, которые нужно учесть.
Даже если какие-то требования и корректировки поступают к вам в сумбурном виде, прочитайте, разбейте на пункты и вычеркивайте все, что сделали. Используйте любые удобные способы: CRM, заметки в телефоне, лист бумаги с карандашом – все, что поможет вам, убедившись в добросовестно сделанной работе, со спокойной душой переходить к следующим задачам или заканчивать рабочий день. Есть хорошая пословица: «Совесть – лучший контролер». Помогите совести с контролем – используйте чек-листы.
3. Принижать значение референсов
И вот настало время собирать камни референсы. Вы посмотрели работы на Behance и Dribbble, нашли около полумиллиарда макетов для маленькой уютной кофейни, очередного клона Spotify и непонятных страничек на экологическую тематику, призывающих спасать тюленей от лесных пожаров. Вам это безумно интересно, вот только ваш проект – сайт юридической фирмы. И референсов по теме вы нашли аж целых пять, из которых четыре практически одинаковые.
Кроме того, вы не забыли познакомиться с сайтами схожей тематики, существенная часть которых выполнена в дизайне тех времен, когда юридические споры закрывались умело подброшенной в чей-то «Мерин» гранатой.
Тем не менее, эти сайты работают, висят на каких-то совсем не последних позициях в поисковой выдаче, а значит, что-то владельцы этих ресурсов делают правильно. Поэтому абстрагируйтесь от оформления, которое вам так не нравится, и обратите внимание на структуру, на приоритет информации, которая подается на этих ресурсах, подчеркните для себя основные моменты.
Более того, описанная выше ситуация – это самый негативный сценарий, потому что на практике в большинстве случаев клиент предоставляет эти референсы сам.
По итогу обсудите референсы с клиентом и разберите, какие моменты ему нравятся, а какие – нет. Помните, что эти ребята находятся внутри своего бизнеса и хорошо понимают, что им действительно важно. Ну а дальше уже смело можно делать «так же, только лучше».
4. Всё для удобства пользователя!
Не всё. Пользователю нужно предоставлять удобство взаимодействия ровно в той степени, в которой это интересно целям и задачам проекта.
Если вы слышали термин «когнитивное сопротивление» – речь как раз о нем. Если кратко – это то, насколько далеко человек готов зайти, чтобы получить желаемое. Нет, речь не о рецидивистах, которые идут по головам, чтобы сорвать хороший куш, мы говорим о пользователях, которые кликают на разные кнопочки и ссылочки в нашем интерфейсе и обращают внимание на то, что им так заботливо предоставлено.
Простой пример: если на странице карточки товара мы расположим качественные, заманчивые ссылки на статьи об этом товаре выше, чем кнопку «купить», человек, конечно же, пойдет читать статьи, потому что мы расположили все понятно, удобно и сфокусировали его интерес. Правда, он покинет карточку товара, и вероятность возвращения на нее и покупки товара уже ниже, чем во время нахождения на самой странице товара. Ну а его лайк под нашей шикарно написанной статьей мы на хлеб не намажем.
Расставляйте приоритеты действий, которые вы ожидаете от пользователей, делая это с помощью расположения (от начала к концу страницы), размеров объектов, цветов и анимации. Определите ключевую пользу, которую должна приносить страница или экран мобильного приложения в том или ином состояния, и фокусируйте внимание на соответствующих элементах интерфейса. Не забывайте о том, что для принятия решения информация может быть востребована по ходу ознакомления и подаваться мелкими порциями – для этого отлично подойдут всплывающие подсказки и окна, не уводящие человека с целевого экрана.
И уж если наш пользователь в процессе навигации по интерфейсу так ничем и не заинтересуется и дойдет до конца страницы – так и быть, отправьте его почитать статью. Пусть хотя бы лайкнет.
5. Сразу проектировать сложный набор функций с большим количеством фич
Есть мнение (вполне справедливое) что одним из признаков хорошего дизайнера является желание улучшить продукт, над которым он работает. Но нужно иметь хладнокровие и сфокусироваться на основной задаче, которую этот самый продукт решит. Пользователю будет проще сориентироваться в вашем продукте, если в нем не будет ничего лишнего.
Также не забывайте, что у проекта есть определенный ресурс на разработку и сроки реализации. Поэтому, получив от вас макет, на котором через весь экран летает радужный кот и трансформируется в логотип компании, ваш frontend-разработчик возьмет в руку что-нибудь потяжелее и придет задавать неудобные вопросы. Словом, не забывайте про MVP.
6. Начинать рисовать с больших разрешений
Этот пункт о том, что важно быть в курсе статистики и данных о целевой аудитории, а если статистики нет – исходить из самого проблемного сценария. Разумеется, с точки зрения презентации клиенту макет в fullHD смотрится круто. Но здесь снова нельзя забывать про вопрос «Как это будет работать?», который надо задавать себе до потери пульса как можно чаще.
Мы можем иметь дело с ситуацией, когда создаем сервис для отслеживания логистики, с кучей полей и статусов в интерфейсе. Им, разумеется, будут пользоваться операторы, сидя в офисе со стационарных компьютеров, а мобильная версия может быть вообще не предусмотрена. Но вот перед нами встает задача спроектировать интернет-магазин с цифровой и электронной мелочью, куда люди будут заходить с телефона и, не сильно задумываясь, покупать USB‑кабели, карты памяти, отпугиватели ворон на Android с Wi-Fi и прочие необходимые для жизни вещи. И тут наступит момент, когда надо будет вспомнить про mobile first, потому что ваш шотландский замок, над башнями которого гордо реет заголовок h1, написанный 150-м кеглем, увы, не влезает даже в экран ноутбука.
Ничего плохого в шотландских замках нет, но всегда держите в голове важный момент:
если имеете дело со сложной композицией, продумайте и (очень желательно) отрисуйте, как она будет выглядеть на всех распространенных экранах, и какими элементами допустимо пожертвовать, если экран небольшой.
7. Соблюдать единообразие и стандарты... и слишком увлечься этим
Единообразие и стандарты – один из принципов юзабилити NNG. Грамотно построить интерфейс сайта или мобильного приложения можно только при сформированной системе модулей и правил, по которым она должна работать (со стороны дизайнера это отражается в таком документе, как UI-Kit).
Все можно стандартизировать до такой степени, что результат вашей работы не сильно будет отличаться от содержимого командной строки. Разумеется, чем выше степень стандартизации, тем проще разработка и поддержка. Но не забывайте, что ваша задача как UX/UI-дизайнера – не свести весь набор модулей к одной кнопке, одному начертанию шрифта и одной лампочке Ильича одному полю ввода, а понимать и уметь объяснить, когда, для чего и почему тот или иной элемент используется, даже если этих элементов достаточно много.
8. Не задумываться о типах данных
Если вы дочитали до этого места, посмотрите на мрачного мужика за огромным столом, который смотрит на всех коршуном. Это ваш backend-разработчик – настало время подойти и познакомиться, если вы почему-то этого еще не сделали. Особенно это важно, когда речь идет о большом и/или сложном проекте. Это человек, с которым вам предстоит согласовать, какая информация и в каком формате будет выводиться в итоге на работающем сайте или приложении, и, соответственно, как вам ее нужно отрисовать.
Вообще понимание о типах данных и булевой алгебре желательно иметь самому, благо это входило в школьный курс информатики, но, если вы вдруг не слушали учителя, а рубились в Quake подзабыли – ничего страшного, просто загуглите, что это такое: информация не особо объемная, и в будущем она поможет вам работать продуктивнее. Если кратко – backend выводит в ваш макет данные из базы, а в базе информация хранится в определенном виде, например, в числовом или в текстовом. Поэтому, если в одной карточке товара у вас рядом с подписью «Количество товара в наличии» стоит значение «1000», а в другой – «много», то эта ситуация вашему backend-специалисту не понравится. А уж если так действительно должно быть, то будьте готовы объяснить логику этого решения.
Для вас же как для дизайнера понимание типов данных и логики их вывода тоже будет крайне полезно, поскольку у вас откроется больше возможностей структурирования контента, а грамотно структурированный контент положительно сказывается на пользовательском опыте.
Эта ошибка проистекает из другой – более очевидной, но более масштабной...
9. … Не согласовывать макеты с другими специалистами до согласования с клиентом
Итак, вы уже познакомились с вашими разработчиками из backend и frontend. А еще есть ребята, которые пишут контент, с ними тоже рекомендуется перекидываться парой слов. А еще есть руководитель проекта, который формирует для вас и других специалистов требования, выясняя всю необходимую информацию у клиента. Со всеми этими прекрасными людьми вам следует побольше общаться, потому что провалы в коммуникациях создают множество дополнительной и неприятной работы для всех.
Если вы с руководителем проекта втихаря покажете клиенту ваш дизайн, клиент воскликнет «Как здорово! Давайте приступать к разработке» и проект перейдет на следующий этап. И на этом самом этапе выяснится, что…
-
…такую анимацию мы реализовать не сможем, а если и сможем, то сорвем все сроки;
-
…отзывы в формате видео мы выводить не сможем, клиент их вообще собирает только в виде сканов;
-
…данные без личного кабинета хранить не получится, а личный кабинет мы вообще не рисовали;
-
…трехмерная модель, которую вы хотите повесить на главную, весит 200 мб, у нас всех браузер вылетает;
-
…в блоке «О компании» нужно только 3 абзаца текста, а не 20 000 символов, которые вам уже, конечно же, написали;
-
…цемент так и не завезли, а без него – как строить?
Клиент далеко не всегда вникает и далеко не всегда понимает, как система будет работать. За вникание и понимание, он, собственно, и платит вашей команде.
10. Делать строго так, как сказал клиент
Клиент не всегда прав. Но не потому, что вы лучше разбираетесь в его проекте, а потому, что он просто может не знать всех вариантов реализации. Например, заказчик хочет давать пользователю возможность отправлять данные через поля ввода или файле по выбору. Он говорит вам сделать для этого две формы и еще карту созвездий северного полушария? ОК. Но вы же знаете, что это будет выглядеть ужасно? А еще вы знаете, что можно просто добавить шаг выбора, после которого будет появляться нужная форма? Просто скажите об этом заказчику. Он не враг своему бизнесу и сам все прекрасно поймет.
Помните: вы создаете не просто картинки по заказу. Вы решаете задачи и помогаете людям.
Читайте также:
Финтифлюшки в картинках – это такой прошлый век… Кейс Berry Bouquet
Когда дизайн не «попал» в бизнес: 5 плохих логотипов
ТОП-10 стилей графического дизайна прямо сейчас – они влияют на продажи