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


Предисловие: Дизайн-навыки — концепция взмаха кисти

Было бы безответственно объединять дизайнеров в какие-то группы, толком не уточнив, кто на что способен. Вместо того, чтобы думать, будто навыки любого человека являются только Т-образными (это когда человек имеет широкое представление о многих вещах и глубокое понимание только одной вещи), лучше представлять их как растекающиеся мазки краски на мокром холсте.

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

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

«Окей, — скажете вы, — но как тогда узнать, кто именно мне нужен для проекта?!»


1. Узкие специалисты

Верхняя строка — ширина охвата специальности, оттенок под линией показывает глубину способностей в спектре всех навыков

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

А причем тут фронтенд-разработчики, спросите вы? В наши дни граница между фронтендом и дизайнером настолько размыта, что им обоим важно иметь базовые знания из сфер разработки и дизайна.


2. Кросс-функциональные навыки

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


3. Дизайнеры широкого спектра

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

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


Если мы совместим эти три группы в одной картинке, получится вот что:

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

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

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


1. Ссылка на авторитета

Обращение к какому-либо авторитету означает, что ложное утверждение хотят сделать правдивым только потому, что некий авторитет считает, что это правда. Возможно, "эксперт" ошибается — сначала лучше изучить его исследования или послушать его рассуждения, прежде чем принимать его выводы на веру. На встрече по проекту часто можно услышать нечто вроде:

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

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


2. "Специально для кого-то"

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

Тут, конечно, есть лазейка — глава Амазона ведь вправе принимать дизайнерские решения, а значит, он в курсе цвета кнопок. Тем не менее, обвинять его в игнорировании исследований — глупо и крайне похоже на обобщение. Если уж цвет кнопок так важен, лучше устроить исследование пользователей на этот счёт. Это было бы куда полезнее для критики дизайна, чем беспочвенные обвинения.

Этой ловушке легко противостоять, но трудно привлечь другого человека на свою сторону. Если вы обсуждаете дизайн с кем-то, кому страшно хочется сослаться на другую персону в духе "А вот в компании Мистера Х так-то!", будьте готовы к тому, что диалога, подчиненного логике, не получится. «Даже остановившиеся часы дважды в день правильно показывают время» — такой аргумент может сработать в краткосрочной перспективе, чтобы намекнуть собеседнику, что тот, на кого он ссылается, оказался прав по счастливой случайности.


3. Соломенные мозги (подмена тезиса)

Ошибка тут в том, что мы сначала упрощаем аргумент собеседника, а потом ему же подсовываем эту упрощенную версию в качестве контраргумента. Перевернуть с ног на голову, чтобы вам было проще защищаться — замечательно!

В этом примере второй собеседник перевернул аргумент первого, добавив "вам нравятся", хотя тот ничего такого и не говорил. Фактический аргумент, сделанный первым человеком, является существенным и не может быть опровергнут контраргументом.

Мы часто видим, как человек с техникой "соломенные мозги" использует перевёрнутые аргументы собеседника, чтобы защитить свою позицию. Часто случается, что такие странные аргументы всплывают при критике дизайна, и оказывается, что у них и автора-то нет. Если такую атаку удалось отразить, не теряйте бдительности — следите и дальше за тем, чтобы ваши аргументы не переиначивали и не использовали против вас.

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

Это и обо мне — я посредственный разработчик. Статья поможет вам выжить в отрасли, если вы не гений.


Я постоянно гуглю самые простые вещи

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

Несколько недостатков такого метода:

1. Ты копируешь так-себе-дизайнерские решения или уязвимый код от других создателей.
   
2. Это формирует конкретное мышление: если ты не можешь что-то сделать, то сразу — «Хьюстон, у нас проблемы».
   
3. Если интернет отвалится, ты не сможешь работать.

Но я не думаю, что это так уже серьезно. Вы можете сделать этот приём своим секретным оружием. Вот несколько советов, чтобы уменьшить негативные последствия от "загугливания":

1. Используйте, IDE (интегрированную среду разработки) для автозаполнения и подсказок, чтобы не гуглить по сто раз базовые основы.
   
2. Помните, где (а не как) вы уже решили эту проблему — всегда можно подсмотреть там решение.
   
3. Весь код, который вы вставляете в проект, должен быть проанализирован, реорганизован и рассмотрен позже. Так мы не навредим проекту плохим кодом, но поможем ему быстрым решением.

Я всё делаю максимально просто

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

Но как понять, простой это код или сложный? Используйте метод измерения "Какого чёрта/в минуту" для измерения его качества:

Принцип прост и понятен. Всякий раз, когда вы находите в коде нечто, что вам непонятно — он слишком сложный.

Что можно сделать?

1. Перепишите, чтобы сделать дизайн чище.
   
2. Запаситесь документацией.
   
3. Добавьте комментарии к самым сложным частям. Но помните, что комментарии уже сами по себе выглядят подозрительно сложно.

Как сделать код простым с самого начала:

1. Используйте правильные имена для переменных, функций и классов.
   
2. Убедитесь, что каждая часть вашей программы выполняет только одну функцию.
   
3. Предпочитайте чистые функции регулярным.
   
4. Предпочитайте регулярные функции классам.
   
5. Прибегайте к классам только в случае острой необходимости.
   
   

Я себе не доверяю

Некоторые разработчики демонстрируют высококачественный код. Как Маргарет Гамильтон, ведущий инженер-программист проекта Apollo. На этом фото она стоит рядом со стопкой кода бортового программного обеспечения, который она написала для космической программы «Аполлон»:

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

• Ошибки языка.
  
• Логические ошибки.
  
• Ошибки проектирования.
  
• Ошибки стиля.
  
• Ошибки безопасности.
  
• Ошибки "Какого чёрта!?" (мои любимые!)

И нет волшебной книги о том, как «научиться писать код без ошибок». И это совершенно нормально. У всего программного обеспечения есть ошибки. Просто смиритесь с этим.

Как я могу защитить проект от этого?

1. Напишите тесты. Напишите много тестов. Начиная с тестов по интеграции до модульных тестов. Это защитит вас от некоторых логических ошибок.
   
2. Используйте статический ввод текста — это экономит время и улучшает дизайн.
   
3. Используйте автоматические проверки стиля. Их тонны для каждого языка.
   
4. Используйте инструменты проверки качества, которые анализируют код на предмет различных проблем и сложностей.
   
5. Просмотрите свой код. Просмотрите его ещё раз перед слиянием с чем-либо. И ещё раз после этого.
   
6. Заплатите другим людям, чтобы те проверили ваш код — когда разработчики просматривают код впервые, им легче обнаружить несоответствия и плохие дизайнерские решения.
   
   

Это должно работать не только на моём компьютере

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

И вроде бы в последние годы появились докеры (и контейнеры в целом), с которыми легко работать в одной изолированной среде и не упустить что-то важное, я всегда забываю что-то при создании серверов, изначально настраивая или связывая их вместе. О стольком нужно помнить! Присмотритесь к автоматизированным системам для деплоя: terraform, ansible и упаковщикам. Найдите свою.

Как быть:

1. Автоматизировать все, что вы используете для деплоя.
2. Используйте докер для разработки приложений, тестирования и деплоя.
3. Используйте инструменты деплоя.

После деплоя я всё ещё не доверяю себе

О, наконец-то приложение работает! Я могу немного поспать, ничто не сломается. Подождите, нет! Всё сломается. ВСЁ.

Инструменты, которые облегчают поиск и устранение проблем:

1. Sentry. При возникновении ошибки для любого из ваших пользователей — вы получите уведомление. Имеет привязки практически к любому языку программирования.
2. Различные службы и инструменты для сбора журналов регистраций из нескольких процессов и серверов в одно место.
3. Мониторинг серверов. Настройте мониторинг для процессоров, дисков, сетей и памяти и даже время масштабирования системы, когда пользователи попробуют уронить сервер.
   

Постоянное обучение

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

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

Рекомендуем после приёма столь питательного ланча часок прогуляться для его усвоения — весна ж за окном!