Исповедь дизайнера UX — Prototypr

Нарушение работы с дизайном UX

Я собираюсь совершить кардинальный грех против богов UX в написании этой статьи. Моя душевная душа, вероятно, страдает от вечного проклятия. И, как Иуда Искариот, меня навеки преследует звук тридцати кусков серебра, грохочущих в моем кармане. Прости меня, отец, потому что я собираюсь грешить … и я согрешил.

. После того, как более десяти лет проектов ушли в прошлое, проекты, которые никогда не доводили до развития, концепции, которые никогда не должны были быть концепция и скорость улитки многих проектов, над которыми я работал, эта статья давно назрела. Я бы хотел написать статью, где я виноват где-то, кроме команд UX, с которыми я работал. Но это было бы не честно или верно. Это было бы не признание . Часто, моя команда или я виноваты в неудачных проектах или проектах, которые могли бы принести лучшие результаты.

Прежде всего, я должен сказать, что мне нравится и нравится UX и дизайн в Генеральная. Но, есть также много, что попадает под мою кожу. UX может стать отличным решением проблем, с которыми сталкивается организация со своими продуктами на рынке. Но UX также может быть частью проблемы. Я часто стал частью проблемы.

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

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

Как ни парадоксально, это все преступления, которые я совершил в своем собственном прошлом. Мои грехи. Это признание дизайнера UX.

Правила, эвристика и догма

Я не знаю, как мои умные дисфункции. Но большую часть времени, когда кто-то дает мне правило, я автоматически спрашиваю об этом или пытаюсь его сломать. Это не всегда так. В начале моей карьеры я следовал правилам UX в тройник. Я не знал ничего лучшего и был слишком зеленым, чтобы иметь опыт, когда правила не работают, или знать, что они не применимы к ситуации.

Мы дизайнеры. Мы мыслители. Правила — это немного больше, чем когнитивная разгрузка. Теперь я не предлагаю, чтобы не было никаких хороших правил дизайна, или нет каких-либо правил, которые вы должны соблюдать в дизайне UX. Я просто предлагаю подумать, прежде чем мы бездумно следуем правилу дизайна.

Вот несколько правил UX, которые вы можете найти в быстром поиске:

• Будьте последовательны (см. Ниже)
• Дизайн вокруг реального контента (т. Е. Не используйте lorem ipsum)
• Вы не пользователь
• Исследование пользователей — наш Золотой теленок
• Люди могут помните только 5-7 единиц информации в определенный момент времени

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

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

Дизайнеры не всегда придерживаются правил. Фактически, они часто нарушают правила для создания гениальных проектов. Это, конечно, приходит с опытом. Дизайн — часть искусства и частичная наука. И, большое искусство часто нарушает правила.

UX Bandwagon

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

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

Тем не менее, хороший процент профессии прыгнул на подножку и укрепил значок гамбургера. Lean UX была еще одной тенденцией несколько лет назад, и, несмотря на то, что мы пытались перенести нашу профессию из «поставляемого бизнеса», краткий интернет-поиск быстро выявит, что мы все еще находимся в бизнесе с множеством публикаций о результатах UX.

Мобильный дизайн — это, наверное, мой любимый пример. Именно здесь команды преследуют этот блестящий объект и используют технологию просто потому, что она есть. Я был в многочисленных инициативах мобильного дизайна, которые были полными неудачами. Черт, даже я думал, что некоторые из них были хорошей идеей в какой-то момент. Но, я был сожжен столько раз, что теперь внимательно изучаю любое предложение для мобильного дизайна с дополнительной бдительностью. Просто потому, что вы можете поместить свой дизайн или продукт на мобильное устройство, это не значит, что он должен быть на одном. Это трендовые команды любят обниматься, потому что все остальные обезьяны тоже делают это. Monkey see, monkey do.

Если вы проводите много времени на серфинге в сети и изрыгаете последнюю статью, которую вы читаете по определенной теме (например, я так много лет занимаюсь), вы быстро найдете ее сильно отличается от нынешней моды, которую вы носите. Примерно через 5-10 лет вы оглянетесь на картину того, как вы занимаетесь этими новыми штанами, и рубашка, которую вы считали настолько здоровой, чтобы смеяться над тем, как вы выглядите. Победа UX ничем не отличается. Через пять лет вы больше не будете верить даже половине того, какова нынешняя ярость в нашей профессии.

Некоторые тенденции останутся в нашей профессии. Это, как правило, теории, основанные на прочных основополагающих принципах — принципах нашей профессии от многолетних исследований и приложений. Они похожи на 501 Levis и сплошную печатную футболку. Они никогда не выйдут из моды. Но большинство тенденций будет падать на обочине. Следующее за ними часто приведет вас и ваш проект в заблуждение.

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

The Little Things

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

Да, мелочи подсчитываются. Я соглашаюсь с этим. И когда у вас есть время и ресурсы для решения мелочей, вам нужно. Но то, что я вижу слишком часто, — это команды UX, пришедшие к мелочам, когда они игнорируют большие проблемы.

У меня были длительные дискуссии о переключателях переключателей по сравнению с флажками, переключателями переключателей и капельками, закругленными или квадратными углами, сохранять диалоги с несколькими опциями, цветами, размещением кнопок, сетками и т. д. Длительные дискуссии. Обсуждения длились недели или месяцы. Потоки электронной почты длиннее, чем руки и ноги NBA All-Star.

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

Но здесь я всегда приземляюсь: действительно ли это влияет на работу пользователя? Действительно ли пользователю очень важно, закруглены ли углы? Это повлияет на их опыт? Им все равно, все ли ваши компоненты привязаны к сетке? Я много времени проводил в разных проектах, и редко я нахожу пользователя, который комментирует какой-то аспект функции, которую я обсуждал с тобой, с моей командой. Обычно это то, о чем я даже не думал, что это оказалось проблематичным — нам нужно было больше времени обсуждать, но этого не делал.

Признаюсь, что я был втянут в это в прошлом и даже недавно. Я займусь этими обсуждениями (большинство из них окружают визуальные аспекты интерфейса), и они продолжатся вечно. Мы создадим небольшую команду для «расследования» этих проблем или тестирования группы пользователей. Но в какой-то момент я буду сидеть там, в то время как дискуссия дронит и думает о том, как это действительно влияет на общий дизайн. Обычно это не так и мало влияет на пользовательский опыт с целостной точки зрения.

Всегда задавайте себе этот вопрос: Является ли это проблемой, учитывая все другие проблемы, которые мне приходится решать, что повлияет на пользователя?

Согласованность в дизайне

Важное значение имеет согласованность. Но я твердо верю, что закон убывающей отдачи вступает в игру с последовательностью. Сколько времени вы готовы потратить на каждом экране, чтобы обеспечить абсолютную согласованность?

Очевидно, что если у вас есть полное отсутствие согласованности между экранами, и система даже не выглядит одинаково с одного экрана на другой, это означает, что это время и деньги. вызовет множество проблем. Но если вы на несколько пикселов выберете размер кнопки с одного экрана на другой, это действительно повлияет на работу пользователя? Это неряшливый дизайн, абсолютно. Но он не будет убивать продукт при выпуске.

Я не предлагаю, чтобы мы игнорировали согласованность или небольшие подробности, которые я отмечал выше. Я предлагаю справедливый баланс между энергией, которую мы тратим на эти вещи, и отдачей от наших инвестиций. Если вы работаете с Atomic Design в большой системе, насколько вы будете работать над проектом раньше того времени, когда будете экономить на проектировании и изменении дизайна? Если это будет сделано правильно, вы, вероятно, сможете получить большую отдачу от своих инвестиций. Но в какой-то момент закон убывающей отдачи вступит в силу.

Консистенция также должна быть контекстуально зависимой. Рассмотрим компонент поиска в системе. Предположим, вы определили, как должен работать поиск, а затем заявите, что он должен работать одинаково во всей вашей системе. Это кажется логичным? Мы хотели бы, чтобы поиск работал одинаково по всей системе, а не отключил пользователя, переключив функциональность. Единственная проблема с этим заключается в том, что у нас теперь есть приоритет согласованности (как первичной эвристики) над пользовательским интерфейсом.

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

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

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

Сроки и сроки выпуска

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

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

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

В моем случае, я должен постоянно напоминать себе, что я работаю над опытом пациента. Это моя «основная директива». Я не появляюсь каждое утро, чтобы сделать крайний срок для следующего спринта. Эта цель вторична. Моя самая высокая лояльность должна быть связана с опытом пациента.

Вот трюк: вы можете встретить крайний срок, сделать все счетчики бобов и менеджеров проектов счастливыми и все еще строить продукт дерьма. Я сделал это. Я провел всю гонку и несколько раз пересекал неправильную финишную черту в своей карьере. Это не победа. Это я сидел на финише, размышляя, как, черт возьми, я оказался здесь.

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

Инструмент Религиозность

Если мне нужно выслушать еще одну дискуссию по инструментам проектирования и как один инструмент лучше другого, Кажется, я могу повеситься на одном из моих невысоких галстуков. У меня было неудовольствие работать с консалтинговой командой не так давно, у кого хватило смелости предложить использовать один инструмент, чтобы дать нашей команде конкурентное преимущество в будущей рабочей силе. Такой мусор. Я не знаю, получали ли они откаты или если они просто выпили слишком много своего собственного «Kool-Aid».

Я вырос с механиком — моим отцом. (Он действительно больше инженер-механик, чем механик.) Но я всегда помню все инструменты, которые у него были — некоторые из которых я даже не знал, что они сделали. Для каждой работы был набор инструментов. Я узнал, наблюдая за ним и еду вместе с его поездками в магазин Sears Craftsman, когда ему понадобится специальный предмет. UX ничем не отличается.

Некоторые инструменты лучше подходят для прототипирования, а другие — для визуального дизайна. Вы не можете победить доску и маркер сухого стирания, чтобы быстро получить идеи. Многие наши выборы очень субъективны. И, если есть профессия, которая должна знать, насколько личным и субъективным этот выбор, это должен быть UX.

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

UX Snobbery

Никто на самом деле не говорит об этом. Но отношение часто проявляется даже в том случае, если оно невысказано. Это часто является территориальным. Мы не хотели бы, чтобы кто-то нарушал наше пространство или меня заменил, верно? Именно такое отношение может создать только тех, кто формально обучен (или тех, кто имеет титул на работу с UX в нем).

Мы все были там. Бизнес-аналитик или разработчик предстают перед вашим столом с грубым эскизом идеи, которую они имеют. И многие из нас превратили свой нос в этих людей — фактически остракизуя их из наших привилегированных рядов. Кто они могут предложить потенциальное решение? Я сделал это и когда-то был snob UX. Я не хотел, чтобы кто-то делал что-то очень похожее на мою работу.

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

Как это ни парадоксально (и это было похоже время), Джаред Шпаул заявил:

«Любой, кто влияет на то, что делает дизайн, является дизайнером. Сюда входят разработчики, PM, даже корпоративные юридические. Все дизайнеры.

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

Если у вас возникли проблемы с защитой UX в вашей организации и поиском акцепта, убедитесь, что вы не являетесь снобистом UX. Ваша карьера (и проекты) будет иметь большое значение, если вы сконцентрируетесь на построении отношений и привлечении различных точек зрения (через другие дисциплины) к таблице.