Antoine Valot, эксперт по user experience из Щвейцарии, в своем блоге на Medium, опубликовал очень хорошую статью, максимально созвучную с моим практическим опытом. Решившись на адаптацию данного текста, я специально снабдил его собственными мыслями и поправками на российские реалии, так, чтобы статья не являлась бы дословным переводом, а скорее новым совместным произведением, раскрывающим некоторые секреты профессии UX.
![image](https://habrastorage.org/r/w780q1/getpro/habr/post_images/2c4/5cc/555/2c45cc555f0f4160f1b3ea02e07f41d5.jpg)
Да, сегодня уже трудно удивить кого бы то ни было новой «очередной статьей про юзабилити», в которой в сотый раз будут сделаны все те же очевидные выводы: возлюби пользователя своего, да не будет у тебя аргументов иных кроме результатов тестирования, сотвори себе кумира из Джобса…
А вот откровений от настоящего практикующего специалиста, которые годами исследуют и анализируют, и не стесняются признавать собственные ошибки — пока еще не так много. Antoine Valot не стесняется признаваться, что кучу раз за время своей профессиональной карьеры откровенно лажал, но именно совершенные ошибки, их принятие и глубокий последующий анализ и позволяли ему расти и развиваться как эксперту, чего не случилось бы при замалчивании или сокрытии проблем. И вот сейчас у нас есть уникальная возможность совершенно бесплатно научиться на чужих ошибках.
1. Цвет не имеет значения. Никакой
Пользователи не понимают вашего цветового кодирования. Зеленый может означать «позитив» у вас, но кому-то еще, на другой стороне экрана, это может означать «нечитаемый текст» или «гусиный помет» или «Давайте же все спасем планету от нефтяных олигархов».
Каждый человек видит каждый цвет абсолютно по-своему, и несколько лет в самом начале жизни учится точно навешивать нужный словесный ярлык «зеленый» — на все те вещи с определенным свойством, которое его научили опознавать родители.
Люди любят некоторые цвета, и ненавидят другие, и это совершенно непредсказуемо. Играя в цвета — вы никогда не сможете выиграть.
Цвет — не математический термин, не четкая формулировка, а всего лишь иррациональное восприятие. Без контекста и эмоций все цветовое кодирование само по себе не имеет ни малейшего смысла.
Вот реальные примеры того, как люди оценивают все ваши цветовые решения:
2. Расположение — важнее всего
Издревле именно удачное расположение отдельных городов или государств на пересечении мировых торговых путей — становилось для них путевкой в счастливую безбедную жизнь. И сейчас именно расположение элементов в интерфейсе и определяет его качество. Пользователям наплевать на ваши иконки, метки и цвета кнопок — вы можете менять их внешний вид и качество скругления хоть каждый день совершенно безболезненно (и без особого положительного эффекта).
Но изменение местоположения, передвигание важнейших блоков, исчезновение (сокрытие) каких-либо элементов — станет самой непростительной ошибкой. Люди используют их естественную позиционную память, чтобы помнить, как использовать сайт или приложение. Перемещение ключевых элементов интерфейса, смена привычных позиций воспринимается всеми, как наиболее изощренная форма пыток человеческой так называемой «мышечной памяти».
Если вы хотите знать, что такое чистая нефильтрованная сжигающая ненависть — начинайте двигать элементы в уже работающем интерфейсе.
3. Никто не читает
Скорее всего, вы даже не станете дальше читать этот абзац, ведь все же так понятно и очевидно. Да, вы слышали этот тезис тысячу раз, видели слайды, слышали вебинары и не хотите терять бесценные секунды своей единственной жизни на очередное прожевывание этой банальщины.
«Чертов Капитан очевидность, тоже мне — гуру, пойду лучше кофе себе налью» — не так ли?
![image](https://habrastorage.org/r/w780q1/getpro/habr/post_images/e1d/fd5/dc4/e1dfd5dc46d15fe815542aa121999d8c.jpg)
Так если это правда, почему мы постоянно пишем пояснительный текст? Почему мы позволяем выписывать длинные параграфы в наших интерфейсах? Почему мы делаем вид, что подсказки, руководства пользователя, и часто задаваемые вопросы, являются правильным решением для проблем с юзабилити?
4. Навигация подразумевает плохой интерфейс
Давным-давно мной лично уже была написана на Хабре подобная статья, и крайне приятно видеть созвучное подтверждение моих мыслей в блогах у западных коллег.
Итак, никогда не гордитесь вашей навигацией, или красивой менюшкой. Если ваше приложение имеет критичную потребность вообще создавать навигацию — вы уже на пути к неудаче. Путеводитель дают только в лабиринтах.
Ваша изначальная задача состоит в том, чтобы помочь пользователю достичь своей цели. Самым естественным образом — не сверяясь с картой, не определяя свое местоположение по солнцу и компасу, не спрашивая дорогу у прохожих, не пережидая метель под открытым небом — просто сразу вложите ему в руку все то, что причиталось бы ему на финише сложного и опасного путешествия по всем вашим экранам и всплывающим окнам.
Если вы сделали свою работу правильно, то любой интерфейс будет выполнять все необходимые операции последовательно и цельно, в соответствии с четким и продуманным алгоритмом, автоматически переключая экраны. А лучше всего, когда достичь своей цели человек сможет сразу на первом же экране (в идеале — вообще без экранов).
Но, завидев очередное меню, я отчетливо понимаю, что вы были не в состоянии создать единый неразрывный пользовательский сценарий и предпочли регулярно выдергивать его из «потока» только ради того, чтобы он сделал всю работу за вас.
![image](https://habrastorage.org/r/w780q1/getpro/habr/post_images/be0/7b6/b85/be07b6b8526ec0d4c635104ee0c30c60.jpg)
В идеале, дизайн должен сделать все выборы за пользователя. Именно это и определяет его качество.
Не все вещи на свете одинаково важны. Есть некоторые вещи, которые вы должны сделать в первую очередь, некоторые вещи, которые вы должны делать по мере сил, и некоторые вещи, которые вы можете полностью игнорировать.
Вот как стоит выстоить иерахию действий по важности:
5. Контент — хорошо, интерфейс — плохо
Само содержание интерфейса и является решением. Если вы не проектируете сам контент, предварительно определяя его размерность, эмоциональный накал, ритм повествования, то вы просто разрабатываете ерунду.
Каждый раз, когда вы создаете каркасы с Lorem Ipsum, вы оскорбляете своих будущих пользователей, и злоупотребляете доверием вашего клиента. Вы создаете деревянные рамки без картин внутри и надеетесь, что кто-то придет похвалить вас за старания? Их выкинут на растопку — и правильно сделают.
6. Прокрастинация избавляет вас от сложностей
Что бы вы сейчас ни проектировали — делайте карту сайта и навигацию в последнюю очередь. Лучше всего — не делайте их совсем. Это не шутка.
Возьмитесь сразу за центральный экран, тот — который будет цельно и неразрывно решать главную потребность пользователя. Лучше потратить все время, все силы и весь бюджет проекта на этот раздел\страницу, но удостовериться на 200%, что он идеально отвечает ожиданиям и устремлениям людей. Зациклитесь там на каждой детали, дайте причину существования и смысл для каждого пикселя на этой ключевой странице.
Уже потом, когда сроки почти закончатся, и ваш шеф начнет требовать с вас все оставшиеся 250 второстепенных страниц и экранов (ака Новости, О компании, Контакты, Регистрация…), которыми они собирались выносить пользователю мозг — просто прикиньтесь глухонемым идиотом. Объяснять, что вы не сделали весь этот мусор только потому, что он вообще не нужен, приводить цитаты: «Лучший интерфейс это полное отсутствие интерфейса» — бесполезно.
Просто гордитесь, вы решили основную проблему пользователя и сберегли его от лицезрения тонн виртуального мусора. Монах Уильям Оккам на небесах помолится за всех нас за то, что мы не наплодили армию лишних и бесполезных сущностей.
7. Тестирование на пользователях убивает младенцев
Нет, постойте, разумеется тестирование интерфейса на обычных людях — это хорошо, и это неоспоримый и всем известный факт. Независимо от того, как удивительно умны вы сами, и как гениален ваш пользовательский интерфейс, но десять минут пользовательского тестирования на ранних стадиях процесса гарантированно избавит вас от дальнейших унизительных неудач.
Однако, подобные тестирования вовсе не освобождают вас от ответственности и лишних усилий. Все еще, нужно быть мудрым и тонко чувствующим, прорабатывать все детали, и самостоятельно пройти через сумасшедший, извилистый, путь процесса проектирования. Вы по-прежнему должны быть гением, особенно, когда речь идет о революционных проектах, не знакомых ранее пользователям. Также необходимо постоянно иметь в виду, что среди людей регулярно встречаются недалекие, близорукие, тщеславные, ленивые и просто глупые. И осознавая это, вы будете по-прежнему посвящать всю свою жизнь для помощи и оптимизации жизни всех остальных.
Когда у вас есть прекрасная новая идея, она начнет свою жизнь в виде едва жизнеспособного и хрупкого зародыша. Она нуждается в воспитании и нежной заботе, чтобы превратиться в полностью сформированное решение, которое сможет стоять на своих собственных ногах, и выдерживать неосторожное обращение с обычными пользователями.
И здесь раннее опробование новой идеи на ничего не подозревающих пользователях, будет выглядеть, как проба хищным волком свежего ягненка. С немного предсказуемым результатом.
Так что не позволяйте вашему интерфейсу выходить в рабочую эксплуатацию без проверок, но проверяйте только тогда — когда ваша идея полностью сформирована и готова.
Логично будет сейчас спросить: "- Ну и как же узнать, когда интерфейс будет готов?"
Antoine Valot считает, что только тогда, когда вы поработали над ним достаточно долго, чтобы самим увидеть свои первые существенные недостатки, как то внутренние проблемы соответствия первоначальных целей и задач — с предложенным вами решением.
Пока не так важно, как это будет визуально смотреться вместе, но вы должны быть уверены в том, что ваше решение действительно может достигать нужных целей даже с самым некомпетентным пользователем. Только после этого устойчивого ощущения и стоит отправлять решение на пользовательское тестирование — только для того, чтобы укрепить вашу уверенность (или разрушить ее в пух и прах в 95% реальных случаев).
Иногда вы можете думать, что то, как кодеры уродуют ваш интерфейс — уже находится вне вашей компетенции. Может и так, но вы все еще можете управлять этим процессом. Если ваше интерфейсное решение оказалось непонятным или слишком сложным для вашей же команды разработки — что же будет с конечным пользователем?
Разработчики — по сути ваши первые аудиторы. Разумеется, кодеры — не совсем обычные люди, как, впрочем, и вы сами. Обычные простые люди не пьют смузи и не считают игру в приставку — за серьезную и сложную работу. Но заботиться вы должны обо всех без исключения. И вот несколько практических секретов о том, как можно помочь вашим коллегам:
8. Кодеры учатся на самых страшных примерах
Разработчики средней руки редко исследуют хорошо разработанные приложения и сайты, чтобы узнать о лучших возможностях и решениях. Нет, они начинают свое обучение на демонстрациях и руководствах, которые пытаются объяснить сложные понятия программирования, используя надуманные, а зачастую и просто смешные примеры. Впрочем, эту же абсолютную оторванность от мира можно найти в любом тестовом задании на вакансию дизайнера.
![image](https://habrastorage.org/r/w780q1/getpro/habr/post_images/17e/99a/40e/17e99a40edf352d424034027bdc1117d.jpg)
Сначала проектировщики создают выдуманных, никогда не живших на земле людей в виде Персонажей и сочиняют им нелепейшие проблемы и потребности, потом разработчики (познавшие азы своей профессии через чрезмерно простые, плохо разработанные, глупые сценарии), строят свое приложение на основе нескольких неубедительных каркасов. А затем все это расшибается в лепешку об реальный мир.
Никто никогда не думает о реальной экономической выгоде данных учебных примеров, никто не проводит тестирования при оценке «правильности» очередного тестового дизайнерского решения. Вымышленный мир, вымышленные люди, несуществующие проблемы. Вот почему все так плохо.
Так что, возможно, вы должны быть немного более конкретными с вашими спецификациями?
9. Программисты любят абсурд и автоматизацию
Программистам по ходу работы придется побеспокоиться о таких вещах, о которых ни один нормальный человек никогда не задумается. Вы просто перетаскиваете поле «Фамилия» из панели в Axure в центр будущей страницы, не думая они о чем. Но у вашего кодера уже есть сто тревог, связанных с этим:
Для любого обычного человека все эти вопросы являются абсурдными. Но у кодеров они имеют смысл. И вот, чтобы научиться мыслить как простой пользователь — научитесь сначала рассуждать хотя бы как сидящий с вами в одной комнате программист, и научитесь предвидеть его опасения.
А лучше всего — понравьтесь ему своей тягой к автоматизации всего и вся. Заставьте грядку пропалывать себя саму — и это даст вам кучу респектов и социальных бонусов от всей команды разработки.
![image](https://habrastorage.org/r/w780q1/getpro/habr/post_images/429/4a0/677/4294a06771ec638f809e8aa9fd88d1bb.jpg)
Например, вместо идиотского поля select с выбором года рождения с бесконечной прокруткой — задайте пользователю простые вопросы на знание эпохи. Например, «кто такой Константин Устинович Черненко».
Ну а если малец настолько крут, что в свои 15 реально знает, кто это — черт с ним, от вида сисек на вашем сайте ему точно не станет хуже.
![image](https://habrastorage.org/r/w780q1/getpro/habr/post_images/df0/272/3af/df02723af77ea43b80e477505090e137.jpg)
Вот такие незамысловатые советы, на понимание которых ушли годы и годы тяжелого труда.
Всем большой рахмет и наслаждайтесь поездкой.
![image](https://habrastorage.org/getpro/habr/post_images/2c4/5cc/555/2c45cc555f0f4160f1b3ea02e07f41d5.jpg)
Да, сегодня уже трудно удивить кого бы то ни было новой «очередной статьей про юзабилити», в которой в сотый раз будут сделаны все те же очевидные выводы: возлюби пользователя своего, да не будет у тебя аргументов иных кроме результатов тестирования, сотвори себе кумира из Джобса…
А вот откровений от настоящего практикующего специалиста, которые годами исследуют и анализируют, и не стесняются признавать собственные ошибки — пока еще не так много. Antoine Valot не стесняется признаваться, что кучу раз за время своей профессиональной карьеры откровенно лажал, но именно совершенные ошибки, их принятие и глубокий последующий анализ и позволяли ему расти и развиваться как эксперту, чего не случилось бы при замалчивании или сокрытии проблем. И вот сейчас у нас есть уникальная возможность совершенно бесплатно научиться на чужих ошибках.
И для начала «Четыре прописных истины о дизайне»:
1. Цвет не имеет значения. Никакой
Пользователи не понимают вашего цветового кодирования. Зеленый может означать «позитив» у вас, но кому-то еще, на другой стороне экрана, это может означать «нечитаемый текст» или «гусиный помет» или «Давайте же все спасем планету от нефтяных олигархов».
Каждый человек видит каждый цвет абсолютно по-своему, и несколько лет в самом начале жизни учится точно навешивать нужный словесный ярлык «зеленый» — на все те вещи с определенным свойством, которое его научили опознавать родители.
Люди любят некоторые цвета, и ненавидят другие, и это совершенно непредсказуемо. Играя в цвета — вы никогда не сможете выиграть.
Цвет — не математический термин, не четкая формулировка, а всего лишь иррациональное восприятие. Без контекста и эмоций все цветовое кодирование само по себе не имеет ни малейшего смысла.
Вот реальные примеры того, как люди оценивают все ваши цветовые решения:
Любой цвет: — О, эта вещь имеет цвет.
Другой цвет: — Ничоси, эта вещь — не похожа на другие вещи.
Серый: — Видимо, эта вещь сломана.
Красный: — Дизайнер ненавидит всех нас и хочет выбесить.
2. Расположение — важнее всего
Издревле именно удачное расположение отдельных городов или государств на пересечении мировых торговых путей — становилось для них путевкой в счастливую безбедную жизнь. И сейчас именно расположение элементов в интерфейсе и определяет его качество. Пользователям наплевать на ваши иконки, метки и цвета кнопок — вы можете менять их внешний вид и качество скругления хоть каждый день совершенно безболезненно (и без особого положительного эффекта).
Но изменение местоположения, передвигание важнейших блоков, исчезновение (сокрытие) каких-либо элементов — станет самой непростительной ошибкой. Люди используют их естественную позиционную память, чтобы помнить, как использовать сайт или приложение. Перемещение ключевых элементов интерфейса, смена привычных позиций воспринимается всеми, как наиболее изощренная форма пыток человеческой так называемой «мышечной памяти».
Если вы хотите знать, что такое чистая нефильтрованная сжигающая ненависть — начинайте двигать элементы в уже работающем интерфейсе.
3. Никто не читает
Скорее всего, вы даже не станете дальше читать этот абзац, ведь все же так понятно и очевидно. Да, вы слышали этот тезис тысячу раз, видели слайды, слышали вебинары и не хотите терять бесценные секунды своей единственной жизни на очередное прожевывание этой банальщины.
«Чертов Капитан очевидность, тоже мне — гуру, пойду лучше кофе себе налью» — не так ли?
![image](https://habrastorage.org/getpro/habr/post_images/e1d/fd5/dc4/e1dfd5dc46d15fe815542aa121999d8c.jpg)
Так если это правда, почему мы постоянно пишем пояснительный текст? Почему мы позволяем выписывать длинные параграфы в наших интерфейсах? Почему мы делаем вид, что подсказки, руководства пользователя, и часто задаваемые вопросы, являются правильным решением для проблем с юзабилити?
4. Навигация подразумевает плохой интерфейс
Давным-давно мной лично уже была написана на Хабре подобная статья, и крайне приятно видеть созвучное подтверждение моих мыслей в блогах у западных коллег.
Итак, никогда не гордитесь вашей навигацией, или красивой менюшкой. Если ваше приложение имеет критичную потребность вообще создавать навигацию — вы уже на пути к неудаче. Путеводитель дают только в лабиринтах.
Ваша изначальная задача состоит в том, чтобы помочь пользователю достичь своей цели. Самым естественным образом — не сверяясь с картой, не определяя свое местоположение по солнцу и компасу, не спрашивая дорогу у прохожих, не пережидая метель под открытым небом — просто сразу вложите ему в руку все то, что причиталось бы ему на финише сложного и опасного путешествия по всем вашим экранам и всплывающим окнам.
Перемещение по интерфейсу, загрузка приложений, заполнение форм, поиск в выдаче — никогда не будут реальными целями живого пользователя.
Если вы сделали свою работу правильно, то любой интерфейс будет выполнять все необходимые операции последовательно и цельно, в соответствии с четким и продуманным алгоритмом, автоматически переключая экраны. А лучше всего, когда достичь своей цели человек сможет сразу на первом же экране (в идеале — вообще без экранов).
Но, завидев очередное меню, я отчетливо понимаю, что вы были не в состоянии создать единый неразрывный пользовательский сценарий и предпочли регулярно выдергивать его из «потока» только ради того, чтобы он сделал всю работу за вас.
![image](https://habrastorage.org/getpro/habr/post_images/be0/7b6/b85/be07b6b8526ec0d4c635104ee0c30c60.jpg)
В идеале, дизайн должен сделать все выборы за пользователя. Именно это и определяет его качество.
Теперь перечислим три практических откровения о самом процессе проектирования:
Не все вещи на свете одинаково важны. Есть некоторые вещи, которые вы должны сделать в первую очередь, некоторые вещи, которые вы должны делать по мере сил, и некоторые вещи, которые вы можете полностью игнорировать.
Вот как стоит выстоить иерахию действий по важности:
5. Контент — хорошо, интерфейс — плохо
Само содержание интерфейса и является решением. Если вы не проектируете сам контент, предварительно определяя его размерность, эмоциональный накал, ритм повествования, то вы просто разрабатываете ерунду.
Каждый раз, когда вы создаете каркасы с Lorem Ipsum, вы оскорбляете своих будущих пользователей, и злоупотребляете доверием вашего клиента. Вы создаете деревянные рамки без картин внутри и надеетесь, что кто-то придет похвалить вас за старания? Их выкинут на растопку — и правильно сделают.
Без готового на 100% контента — любой прототип не готов и на 1%. Кстати, первом российском «Учебнике по UX» этому же вопросу была посвящена целая глава.
6. Прокрастинация избавляет вас от сложностей
Что бы вы сейчас ни проектировали — делайте карту сайта и навигацию в последнюю очередь. Лучше всего — не делайте их совсем. Это не шутка.
Возьмитесь сразу за центральный экран, тот — который будет цельно и неразрывно решать главную потребность пользователя. Лучше потратить все время, все силы и весь бюджет проекта на этот раздел\страницу, но удостовериться на 200%, что он идеально отвечает ожиданиям и устремлениям людей. Зациклитесь там на каждой детали, дайте причину существования и смысл для каждого пикселя на этой ключевой странице.
Уже потом, когда сроки почти закончатся, и ваш шеф начнет требовать с вас все оставшиеся 250 второстепенных страниц и экранов (ака Новости, О компании, Контакты, Регистрация…), которыми они собирались выносить пользователю мозг — просто прикиньтесь глухонемым идиотом. Объяснять, что вы не сделали весь этот мусор только потому, что он вообще не нужен, приводить цитаты: «Лучший интерфейс это полное отсутствие интерфейса» — бесполезно.
Просто гордитесь, вы решили основную проблему пользователя и сберегли его от лицезрения тонн виртуального мусора. Монах Уильям Оккам на небесах помолится за всех нас за то, что мы не наплодили армию лишних и бесполезных сущностей.
7. Тестирование на пользователях убивает младенцев
Нет, постойте, разумеется тестирование интерфейса на обычных людях — это хорошо, и это неоспоримый и всем известный факт. Независимо от того, как удивительно умны вы сами, и как гениален ваш пользовательский интерфейс, но десять минут пользовательского тестирования на ранних стадиях процесса гарантированно избавит вас от дальнейших унизительных неудач.
Правила тестирования интерфейсов состоят из 1 параграфа: Если вы не сделаете это, вы идиот.
Однако, подобные тестирования вовсе не освобождают вас от ответственности и лишних усилий. Все еще, нужно быть мудрым и тонко чувствующим, прорабатывать все детали, и самостоятельно пройти через сумасшедший, извилистый, путь процесса проектирования. Вы по-прежнему должны быть гением, особенно, когда речь идет о революционных проектах, не знакомых ранее пользователям. Также необходимо постоянно иметь в виду, что среди людей регулярно встречаются недалекие, близорукие, тщеславные, ленивые и просто глупые. И осознавая это, вы будете по-прежнему посвящать всю свою жизнь для помощи и оптимизации жизни всех остальных.
Короче, тестирования абсолютно новых идей — полный отстой. Если вы сделаете это, вы идиот.
Когда у вас есть прекрасная новая идея, она начнет свою жизнь в виде едва жизнеспособного и хрупкого зародыша. Она нуждается в воспитании и нежной заботе, чтобы превратиться в полностью сформированное решение, которое сможет стоять на своих собственных ногах, и выдерживать неосторожное обращение с обычными пользователями.
И здесь раннее опробование новой идеи на ничего не подозревающих пользователях, будет выглядеть, как проба хищным волком свежего ягненка. С немного предсказуемым результатом.
Так что не позволяйте вашему интерфейсу выходить в рабочую эксплуатацию без проверок, но проверяйте только тогда — когда ваша идея полностью сформирована и готова.
Логично будет сейчас спросить: "- Ну и как же узнать, когда интерфейс будет готов?"
Antoine Valot считает, что только тогда, когда вы поработали над ним достаточно долго, чтобы самим увидеть свои первые существенные недостатки, как то внутренние проблемы соответствия первоначальных целей и задач — с предложенным вами решением.
Пока не так важно, как это будет визуально смотреться вместе, но вы должны быть уверены в том, что ваше решение действительно может достигать нужных целей даже с самым некомпетентным пользователем. Только после этого устойчивого ощущения и стоит отправлять решение на пользовательское тестирование — только для того, чтобы укрепить вашу уверенность (или разрушить ее в пух и прах в 95% реальных случаев).
И напоследок, две истины о кодерах
Иногда вы можете думать, что то, как кодеры уродуют ваш интерфейс — уже находится вне вашей компетенции. Может и так, но вы все еще можете управлять этим процессом. Если ваше интерфейсное решение оказалось непонятным или слишком сложным для вашей же команды разработки — что же будет с конечным пользователем?
Разработчики — по сути ваши первые аудиторы. Разумеется, кодеры — не совсем обычные люди, как, впрочем, и вы сами. Обычные простые люди не пьют смузи и не считают игру в приставку — за серьезную и сложную работу. Но заботиться вы должны обо всех без исключения. И вот несколько практических секретов о том, как можно помочь вашим коллегам:
8. Кодеры учатся на самых страшных примерах
Разработчики средней руки редко исследуют хорошо разработанные приложения и сайты, чтобы узнать о лучших возможностях и решениях. Нет, они начинают свое обучение на демонстрациях и руководствах, которые пытаются объяснить сложные понятия программирования, используя надуманные, а зачастую и просто смешные примеры. Впрочем, эту же абсолютную оторванность от мира можно найти в любом тестовом задании на вакансию дизайнера.
Люди всегда учатся на худших и самых абстрактных примерах
![image](https://habrastorage.org/getpro/habr/post_images/17e/99a/40e/17e99a40edf352d424034027bdc1117d.jpg)
Сначала проектировщики создают выдуманных, никогда не живших на земле людей в виде Персонажей и сочиняют им нелепейшие проблемы и потребности, потом разработчики (познавшие азы своей профессии через чрезмерно простые, плохо разработанные, глупые сценарии), строят свое приложение на основе нескольких неубедительных каркасов. А затем все это расшибается в лепешку об реальный мир.
Никто никогда не думает о реальной экономической выгоде данных учебных примеров, никто не проводит тестирования при оценке «правильности» очередного тестового дизайнерского решения. Вымышленный мир, вымышленные люди, несуществующие проблемы. Вот почему все так плохо.
Так что, возможно, вы должны быть немного более конкретными с вашими спецификациями?
9. Программисты любят абсурд и автоматизацию
Программистам по ходу работы придется побеспокоиться о таких вещах, о которых ни один нормальный человек никогда не задумается. Вы просто перетаскиваете поле «Фамилия» из панели в Axure в центр будущей страницы, не думая они о чем. Но у вашего кодера уже есть сто тревог, связанных с этим:
Что делать, если человек не имеет фамилии?
Что делать, если их фамилия выражается в виде математического уравнения?
Что делать, если их фамилия длиннее 255 символов?
Что делать, если их фамилия содержит символы табуляции, несколько абзацев, неразрывные пробелы, смайлики, круглые скобки, запятые, одинарные и двойные кавычки?
Что делать, если их фамилия — величина непостоянная и изменяется в течении времени, даже в тот период, пока вводится в данное поле?
Для любого обычного человека все эти вопросы являются абсурдными. Но у кодеров они имеют смысл. И вот, чтобы научиться мыслить как простой пользователь — научитесь сначала рассуждать хотя бы как сидящий с вами в одной комнате программист, и научитесь предвидеть его опасения.
А лучше всего — понравьтесь ему своей тягой к автоматизации всего и вся. Заставьте грядку пропалывать себя саму — и это даст вам кучу респектов и социальных бонусов от всей команды разработки.
![image](https://habrastorage.org/getpro/habr/post_images/429/4a0/677/4294a06771ec638f809e8aa9fd88d1bb.jpg)
Например, вместо идиотского поля select с выбором года рождения с бесконечной прокруткой — задайте пользователю простые вопросы на знание эпохи. Например, «кто такой Константин Устинович Черненко».
Ну а если малец настолько крут, что в свои 15 реально знает, кто это — черт с ним, от вида сисек на вашем сайте ему точно не станет хуже.
![image](https://habrastorage.org/getpro/habr/post_images/df0/272/3af/df02723af77ea43b80e477505090e137.jpg)
Вот такие незамысловатые советы, на понимание которых ушли годы и годы тяжелого труда.
Всем большой рахмет и наслаждайтесь поездкой.