Как провести критику дизайна пользовательского интерфейса
Опубликовано: 2022-03-10Критиковать легко. Кажется, что у каждого есть свое мнение, но, как отмечает писатель Харлан Эллисон: «Вы не имеете права на свое мнение. Вы имеете право на свое обоснованное мнение». Однако, чтобы стать информированным, требуется исследование. Критика дизайна — важная часть любого исследования продукта.
Критика дизайна — когда создатель обсуждает и объясняет создание с остальной частью команды и/или клиентом — не сводится к тому, чтобы приставать к дизайнеру или подталкивать его к оправданию каждого принятого решения. Это просто критика. Хорошая критика дизайна предназначена для изучения дизайна , определения того, где он работает и где его можно улучшить. Если все сделано правильно, критика дизайна позволяет всем в команде чувствовать, что они были услышаны, и позволяет клиентам давать ценные отзывы.
Дальнейшее чтение на SmashingMag:
- Критика веб-дизайна: практические советы
- Лицом к лицу со своими страхами: обращение к людям за исследованиями
- Как эффективно реагировать на критику дизайна
- The Rainbow Spreadsheet: инструмент для совместного исследования UX в области бережливого производства
Если вы являетесь лицом, проводящим критику, переход к конструктивной критике часто является проблемой, особенно с группами, у которых нет опыта работы с форматом критики дизайна. В agile-среде у вас часто будут кодеры, менеджеры проектов, менеджеры по продуктам и люди из других дисциплин, которые будут давать обратную связь, и вам нужно знать, как быстро привести их в соответствие с ожиданиями, если вы хотите быстро добиться чего-либо. .
Принципы проведения отличной критики пользовательского интерфейса
По своему собственному опыту я обнаружил, что критические анализы дизайна пользовательских интерфейсов (UI) необходимо проводить на протяжении всего процесса проектирования и разработки продукта, по крайней мере, еженедельно, а возможно, даже ежедневно в определенное время. Они следят за дизайном продукта и становятся еще более важными в интерактивной гибкой или экономичной среде продукта UX, где проекты проходят несколько итераций перед развертыванием. Критика дизайна пользовательского интерфейса — это сложная задача, требующая от вас не только объяснения решений, но и внимательного выслушивания других идей.
Установление четких принципов — а не «правил» — в начале каждой критики обязательно. В отличие от правил, которые являются догматическими и кажутся ограничительными, принципы помогают каждому понять ожидания, но при этом допускают свободное обсуждение, которое необходимо.
Главным среди этих ожиданий является согласие всех с тем, почему вы на самом деле критикуете то, на что смотрите. Джейсон Улашек рекомендует:
Начните с вопроса о цели или намерении дизайна, который вы критикуете. Почему мы запрашиваем эту информацию? Какие ожидания были установлены, что позволяет нам просить об этом? Что мы будем с этим делать? Если мы сможем ответить на эти вопросы, то мы перейдем к обсуждению различных вариантов интерпретации необходимости элемента и соответствующих преимуществ и недостатков каждого варианта.
Чтобы помочь вам придерживаться этого правила, я рекомендую следовать стандартным принципам, которые вы можете применить к любой критике дизайна, независимо от того, касается ли она дизайна пользовательского интерфейса или нет:
- Прояви уважение. . Это может звучать банально, но если каждый участник критики не уважает мнение и навыки других за столом, критика быстро перерастет во враждебность.
- Назначьте роли. . Прежде чем начать, уточните, кто какую роль (роли) возьмет на себя во время критики. Лучше всего чередовать их от критики к критике, чтобы никто не чувствовал себя обделенным, и оптимально, если три главные роли будут разными людьми (но это не всегда практично).
- Ведущий . Это человек, ответственный за представление дизайна и идеи, лежащие в его основе. Этот человек отвечает на все вопросы или направляет их другим участникам критики, которые могут на них ответить.
- Модератор . Если возможно, лучше всего, если эту роль будет выполнять кто-то, кто не несет прямой ответственности за дизайн, часто менеджер проекта или продукта. Модератор следит за тем, чтобы все оставались в теме и чтобы все были услышаны.
- Ведущий заметок . Этот человек сосредотачивается на том, чтобы записывать то, что обсуждается, и особенно важен для того, чтобы убедиться, что выводы (еще один принцип, перечисленный ниже) четко определены в конце критики. Ведущий не должен оставаться в стороне от обсуждения, хотя его роль может заключаться в том, чтобы заставить других членов команды разъяснить то, что они сказали.
- Сформулируйте цели проекта и критики заранее. . Быстро напомните всем о целях проекта и о том, что будет охватывать этот конкретный критический анализ. Держите критику сосредоточенной на поставленной задаче, а не позволяйте масштабу ползти к другим соображениям, которые могут подорвать основную цель обсуждения.
- Проанализируйте аудиторию (аудитории). . Чтобы подчеркнуть, что люди, участвующие в критике, не являются целевой аудиторией продукта, напомните всем о том, кто является целевой аудиторией.
- Избегайте придумывать «ответы». Участники почувствуют сильное желание решить проблемы и найти «ответ» в критическом анализе. Однако лучшие решения редко возникают на реальной встрече. Суть критики состоит в том, чтобы исследовать проблемы и обсудить несколько потенциальных решений, которые дизайнер может принять и рассмотреть.
- Согласен на вынос. . После того, как все было сказано в критическом анализе, ведущий заметок должен просмотреть задания на вынос для всех, кто участвовал, чтобы убедиться, что все находятся на той же странице для следующего критического анализа.
К сожалению, слишком часто критика дизайна пользовательского интерфейса в значительной степени фокусируется на визуальном аспекте и недостаточно на интерактивной, а тем более на временной природе дизайна. Для критики дизайна пользовательского интерфейса добавьте следующие элементы:
- Определить презентационный носитель. . Наряду с определением аудитории изучите платформу и технологии, используемые для создания продукта. Это приложение для айфона? Сайт? Вы используете AngularJS? С#? Убедитесь, что все это учтено, чтобы не предлагать решения, которые не сработают.
- Обрисуйте ход процесса. . Вы должны знать дорожную карту. Для дизайна пользовательского интерфейса это будет процесс взаимодействия с пользователем. Это может быть в виде раскадровки, карты пути или других способов описания процесса, но все должны быть знакомы с этим, прежде чем рассматривать пользовательский интерфейс.
- Продемонстрируйте продукт, но больше покажите, чем расскажите. . Я не могу не подчеркнуть это в достаточной степени: отличный пользовательский опыт может больше показать, чем рассказать. Конечный пользователь должен будет точно знать, как работает продукт, с минимальным объяснением. Ваша демонстрация также должна требовать как можно меньше объяснений. Как говорится, хороший пользовательский интерфейс похож на шутку: если вам приходится что-то объяснять, это не очень хорошо.
Задавайте правильные вопросы
Множество вопросов и утверждений работают против тесного сотрудничества в критике дизайна. Вот несколько вопросов, которые я нашел в открытом диалоге для изучения дизайна в сотрудничестве, а не в борьбе, которые вы можете предложить своей команде.
«Как вы пришли к такому решению?»
Отличный способ начать любую критику или разговор — спросить дизайнера, как — а не почему — они что-то сделали. Вопрос «почему» сразу заставляет их защищаться, а вопрос «как» побуждает исследовать происхождение концепции без необходимости обоснования.
Вопросы «почему» подталкивают нас к попыткам доказать что-то «истинно», а не объяснять это как одну из возможностей. По словам Аарона Мортона:
«Почему» вызывает историю, объяснения того, почему что-то является правдой. Если вы спросите, почему ничего не получается так, как вы хотите, вы, скорее всего, создадите историю, которая может быть правдой, а может и не быть. Это опасная территория, заставляющая вас чувствовать себя плохо.
Вместо того, чтобы спрашивать «почему», попробуйте задать вопросы «как», чтобы получить рассказ о процессе создания, а не защиту его существования. Оттуда вы можете затем спросить, какие возможности дизайнер рассматривал ранее, и только затем исследовать альтернативы, которые они, возможно, не рассматривали. Но внимательно выслушайте, что дизайнер уже пробовал , прежде чем предлагать варианты. Возможно, они что-то упустили из виду, но не вступайте в разговор, предполагая это.
«Откуда вы взяли идею сделать это таким образом?»
Знаменитое высказывание Томаса Эдисона: «Гений — это один процент вдохновения и девяносто девять процентов пота». Но в значительной степени он украл свой один процент у Николы Теслы. С другой стороны, Пикассо сказал: «Хорошие художники берут взаймы, великие художники крадут» (но он, вероятно, украл эту строчку).
Центральная идея книги президента Pixar Animation Эда Кэтмулла Creativity, Inc заключается в том, что иметь отличную команду важнее, чем иметь отличную идею:
Правильные люди и правильная химия важнее, чем правильная идея.
Мы редко придумываем идеи в вакууме, и размышления о том, откуда мы черпали вдохновение, могут подтолкнуть нас к инновациям. Более того, объединение нашего вдохновения в командной обстановке может породить новые идеи.
Предупреждение: будьте осторожны, чтобы не звучать обвинительно или снисходительно, т.е. не подразумевая, что они украли идею. Тем не менее, вы хотите, чтобы дизайнер продвигал свое собственное понимание мотивов своих идей и того, откуда они взялись, не подавляя инновации.
«Когда это должно произойти?»
Точно так же, как и в комедии, тайминг — это все во временном дизайне, и события должны происходить в нужное время и в правильном порядке. Однако когда мы проектируем, этот порядок не всегда очевиден, пока нам не придется сесть и объяснить его.
Отличный пользовательский интерфейс подобен отличной истории, а это значит, что вы должны тщательно следить за его темпом. Сколько информации достаточно, чтобы начать работу с формой? Отображаете ли вы данные в правильном контексте, чтобы пользователь мог их понять? Это подходящий момент, чтобы показать заключение?
Джейсон Кунеш, генеральный директор Public Good, стартапа, который помогает некоммерческим организациям общаться с людьми через новости, говорит мне:
Для наших клиентов отличное взаимодействие в нужный момент — это разница между счастливым поклонником продукта или услуги и упущенной возможностью связаться. Превращение случайного взаимодействия в прочные отношения зависит от серии крошечных, позитивных взаимодействий и сообщений, поступающих, когда люди готовы к ним.
Часть процесса критики должна состоять в том, чтобы сгладить недочеты во времени интерфейса, спрашивая при каждой возможности, является ли это подходящим моментом для выполнения действия, вопроса или предоставления данных.
«Можем ли мы использовать движение для добавления визуальных подсказок?»
Этот вопрос удивит многих дизайнеров, привыкших к статике, которая годами доминировала в дизайне пользовательского интерфейса. Однако движение, анимация и переходы становятся нормой в дизайне пользовательского опыта. Движение скоро будет так же важно учитывать в дизайне, как и цвет.
По словам эксперта по анимации пользовательского интерфейса Рэйчел Соседи:
С появлением плоского дизайна и связанных с ним проблем с UX мы увидели, насколько опасным может быть удаление визуальных подсказок из компонентов сайта. Анимацию можно использовать для противоположного эффекта.
Движение или изменение может быть таким же простым, как изменение непрозрачности или цвета, или рука обезьяны, протянувшаяся через страницу, или восход солнца, когда пользователь выполняет задачу. Спрос на добавление движения от момента к моменту в дизайн пользовательского интерфейса часто подталкивает дизайнера к изменению своей точки зрения в лучшую сторону. Заставьте дизайнера думать не только о дискретных моментах и обсуждать дизайн во времени, а не только в пространстве.
«Как мы можем сделать это проще?»
Простота — это тяжело. Кажется, что добавить всегда проще, чем убрать, и многие интерфейсы страдают от того, что я люблю называть синдромом «снежинки в метель»: конечно, каждая снежинка уникальна, но вы никогда не заметите этого в метель. В дизайне пользовательского интерфейса мы слишком часто видим интерфейсы, битком набитые ссылками, кнопками, элементами управления и изображениями. Клиенты часто думают, что им нужно включить все, что может когда-либо понадобиться аудитории, до такой степени, что вы не сможете найти ничего, что вам действительно нужно.
Я задал вопрос о простоте Стиву Кругу, автору книги « Не заставляйте меня думать» :
Я думаю, что это очень полезный вопрос. Я бы подумал, что это урок, который все уже усвоили, но я знаю, что это не так. Мне всегда нравится говорить, что все на странице или экране, что не является частью решения — для реальных целей пользователя — это шум и кандидат на выбрасывание за борт.
На каждом этапе проектирования мы должны спрашивать себя: как мы можем создать что-то, что требует меньше размышлений, но при этом сохраняет ту же мощность? В критике это лучше всего выражается вопросом, как сделать что-то проще. Важно сохранить ясность дизайна , но сделать это с меньшим количеством кликов, меньшим количеством текста и меньшим количеством полей формы. Сократите до минимума необходимое для выполнения работы, и ваши пользователи будут вам благодарны.
"Что будет дальше?"
Хорошая критика дизайна имеет много общего с хорошим интервью: они оба посвящены исследованиям. Один из лучших интервьюеров Стадс Теркель сказал:
[Допрос] — это не расследование; это исследование, обычно исследование прошлого. Поэтому я думаю, что самый деликатный вопрос — лучший, а самый деликатный — «И что потом произошло?»
Применяя это к дизайну пользовательского интерфейса, нам всегда нужно просить дизайнера подумать о том, что будет дальше. Этот вопрос побуждает их думать не только о том, что они считали концом. У пользователей всегда должно быть, куда идти дальше.
Одна из самых больших проблем при создании любого пользовательского интерфейса — рассмотреть все возможные пути, а не только «счастливый путь», который мы хотим, чтобы пользователь выбрал. Что происходит после того, как они нажимают кнопку? Что произойдет, если возникнет ошибка? Что происходит после отправки формы? Спрашивайте, что произойдет дальше, пока вы не рассмотрите все возможные сценарии, иначе вы рискуете оставить пользователя в зависании, что всегда плохо.
Не просто задавайте вопросы, чтобы на них ответить
Задавая эти вопросы — или любые другие, если уж на то пошло — не спрашивайте просто так, чтобы вы могли ответить сами себе. Раздражает, когда кто-то задает вам вопрос не для того, чтобы услышать ваш ответ или понять ваши мысли, а просто для того, чтобы услышать собственный голос.
Если вы один из таких людей, немедленно прекратите это. Задавайте все свои вопросы с широко открытым разумом для полученных ответов. Затем составьте свои ответы на основе этих ответов, а не ответов, которые вы хотели услышать.
Как выглядит хорошая критика пользовательского интерфейса
Критика будет сильно различаться в зависимости от навыков, целей и обязанностей участников. Однако хорошая критика всегда фокусируется на конкретных аспектах продукта и тщательно исследует представленное решение.
Критика пользовательского интерфейса фокусируется не только на том, как продукт выглядит в данный момент, но и на том, как он работает с течением времени и соответствует ли это потребностям пользователя. Вместо того, чтобы учитывать потребности пользователей, участники часто задаются вопросом, почему что-то не было сделано так, как они ожидали. Джейсон Улашек из UX for Good соглашается, рассказывая мне о своей критике:
Сохранение объективности в нашем обсуждении и учет ментальной модели человека, которому поручено использовать дизайн [т.е. пользователя], имеет решающее значение при обсуждении решения.
Всегда имейте в виду, что — как и в случае с клеточной анимацией, где на создание финального фильма, стоящего секунды, могут уйти недели или месяцы — хотя мы можем часами мучиться над мельчайшими деталями в интерфейсе, это, вероятно, будет просто вспышкой. радар пользователя.
Стив Круг сказал следующее, когда я спросил его об этом:
Мы думаем «отличная литература» (или, по крайней мере, «брошюра о продукте»), в то время как реальность пользователя гораздо ближе к «рекламному щиту, движущемуся со скоростью 60 миль в час». Дизайнерам пользовательского интерфейса невероятно сложно понять, как быстро люди просматривают — или прогоняют — интерфейс, над созданием которого они так усердно работали, и как мало они на самом деле воспринимают.
Хорошая критика пользовательского интерфейса замедляет рассмотрение каждого элемента, но признает, что пользователь увидит дизайн не так. Если участники вашей критики не имеют формального обучения, чтобы говорить непосредственно о цвете, типографике или дизайне опыта, они все равно могут учитывать следующие важные факторы во всех проектах пользовательского интерфейса:
- Консистенция . Согласованы ли дизайн и его реализация во всем продукте? Это включает в себя цвет, типографику, элементы управления, изображения и любой элемент дизайна (статический или интерактивный), который используется в интерфейсе более одного раза.
- Контекст . Всегда ли вы уважали контекст пользователя, когда он использует продукт? Постоянно задавать этот вопрос является ключевым, потому что вы, вероятно, не в этом контексте, а просто имитируете его при проектировании или тестировании.
- Голос . Имеют ли бренд и дизайн ясный, последовательный и узнаваемый голос?
- Переходы . Используете ли вы переходы из состояния в состояние для каких-либо значительных изменений пользовательского интерфейса? Современный дизайн — это гораздо больше, чем просто визуальное оформление. Рассмотрим, как перемещаются и изменяются все элементы интерфейса во время взаимодействия с пользователем.
- Простота . Является ли дизайн настолько простым, насколько это возможно для выполнения работы?
Избегайте враждебной критики
Критика может быть — и часто бывает — в драчливой манере, когда члены команды по какой-либо причине склонны критиковать работу, не прислушиваясь к мыслительному процессу, который сопровождал ее создание. Они привносят в дизайн свои собственные предубеждения, а не учитывают пользователя, и часто просто пытаются показать, насколько они умны.
Вы всегда можете сказать, когда критика становится чрезмерно агрессивной: дизайнер склонен становиться колючим в своих решениях, а не объяснять, как они пришли к ним, и обсуждать альтернативы. Ключ к тому, чтобы избежать агрессивной критики, — установить четкие принципы и задать открытые конструктивные вопросы. Помните, что идея состоит в том, чтобы совместно усилить дизайн , а не выиграть битву за дизайн.
Я считаю агрессивную критику бесполезной и обычно вредной. Антагонистическая критика вынуждает дизайнера занимать оборонительную позицию, укрепляя его в том, что он сделал, вместо того, чтобы дать ему возможность расширить его. Дизайн — в значительной степени — интуитивно понятен и не всегда легко поддается оценке, а тем более количественному определению.
Однако это не означает, что критика касается только мнения дизайнера; речь идет о хорошо информированном мнении дизайнера, полученном за годы обучения. Веб-продюсер Филип Джва из Agentic считает, что ключ в том, чтобы…
…говорю из своего опыта, а не пытаюсь обобщать. Например, я бы спросил: «Интересно, достаточно ли начальный баннер передает информацию о бренде?» вместо «Вау, люди никогда не поймут, какая у нас ценность бренда».
Заключительное слово: критика — это не юзабилити-тестирование
Легко обмануть себя, думая, что вы говорите от имени аудитории, используя образы или собственные предубеждения. Независимо от того, сколько персонажей вы создаете или сколько критических замечаний вы проводите, вы не являетесь своей аудиторией . Стив Круг говорит мне:
Это одна из причин, почему я считаю, что каждый дизайнер должен проводить время, наблюдая за тем, как люди пытаются использовать то, что они создали (т. н. тесты удобства использования).
Точно так же, как лазерный уровень по сравнению с пузырьковым уровнем, юзабилити-тестирование является более точным и точным, чем внутренняя критика, но, как правило, требует больше времени и средств. Регулярная критика дизайна имеет неоценимое значение для поддержания проекта на цели, но никогда не может заменить выход в поле и тестирование с реальными пользователями. В противном случае все, что вы делаете, это разговариваете сами с собой.