Frontier who watches the watchmen?

Вы уже неплохой дизайнер

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

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

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

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

Закончив, он отойдёт на несколько шагов и, восхищаясь красотой, осознает: «Эй, да я же построил весь собор сам, может если бы я попробовал спроектировать свой собор, я бы получил все почести, а не этот ленивый чувак, который просто помог с планом и ждал, пока всё построят!»

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

1. Знакомство со сложностью реализации способствует компромиссам

Я дизайнер по профессии, у меня степень по информационному дизайну. Но, как это часто случается, незнание порождает уверенность, и я нырнул в программирование, думая, что это будет интересным хобби, но на самом деле оно засасывает вас с головой; вы становитесь другим человеком. Я не компетентный программист, с какой стороны ни посмотреть, но мне нравится программировать. Я создал memela.com полностью самостоятельно, можете глянуть моё портфолио и профиль на stackoverflow. Парадокс изучения в том, что область настолько велика, что стоит признать: вам не удастся познать всё за всю свою жизнь.

Когда я только начинал программировать, я начинал со скетчей общей идеи на бумаге, а когда мне наскучивало, я открывал Textmate и фигачил код. Иногда я сталкивался с тем, что какую-то фичу сложно реализовать, тогда я возвращался к бумаге и перерабатывал её так, чтобы было проще реализовать, даже если jn ‘ntuj страдал UX.

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

Сегодня я разделяю дизайн и программирование полностью. Я начинаю со скетчей на бумаге, потом создаю pixel perfect мок-ап, и только потом начинаю программировать. Если что-то сложно реализовать, я прошу помощи, и таким образом становлюсь более сильным программистом.

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

2. Моделирование данных затуманивает понимание сценариев использования и задач

Чёткое понимание моделей данных — знак отличия профессионального архитектора ПО. Оно создаёт фундамент для ясного и понятного кода. К сожалению, оно также заставляет смотреть на весь проект исключительно с позиций данных; и когда архитектор ПО дизайнит графический интерфейс, тот до чёрта похож на модели с прикрученным интерфейсом CRUD.

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

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

3. Во многом, дизайн описывают и преподают с точки зрения искусства

Когда я был помоложе и спрашивал людей, как танцевать, они зачастую отвечали «почувствуй музыку». Когда ты почувствуешь музыку, ты сможешь двигать телом в ритм, ну или что-то вроде того. «Просто скажите мне как двигать ноги и руки», но это всегда выходило плохо, потому что я просто махал руками в своём темпе. Грустное представление, которое я предпочёл бы забыть.

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

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

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

Ладно, теперь к хорошему:

Вы уже неплохой дизайнер

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

Имз: Дизайн сильно зависит от ограничений.

Дейкстра: Способность суждения высокого качества обязательно подразумевает способность нахождения возможных проблем.

Имз: Вводи новшества только в крайнем случае.

Дейкстра: Опытный программист <…> бежит от умных трюков как от чумы.

Имз: Кто вообще сказал, что удовольствие не функционально?

Дейкстра: Не должно быть такой вещи, как скучная математика.

Всё что вы знаете о проектировании и архитектуре в программировании можно уже применять к визуальному дизайну, за несколькими исключениями. Проблема в том, что ваш набор навыков ограничен определённой областью. У вас нет моста, чтобы применить всё то, что вы знаете о проектировании ПО к дизайну.

Вы уже креативны

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

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

Креативность означает способность создавать вещи. Объекты, которые могут быть показаны, обсуждены и использованы дальше. В этом смысле программисты куда более креативны, нежели многие так называемые креативные профессионалы вокруг.

Ваш систематизированный ум — ваше преимущество

Один из самых сложных концептов для обучения молодых и подающих надежды дизайнеров — это способность мыслить в рамках системы. Если я требую кнопку на 99design (без объяснения контекста), люди радостно начнут создавать блестящие реалистичные кнопки. Вы, наверняка, знаете, что неправильно в этом подходе: нельзя дизайнить кнопку без знания того, как выглядит остальной дизайн.

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

У вас уже есть внимание к мелочам

По шкале от одного до десяти, насколько грешно выбрать плохое имя для переменной?

Теперь, по той же шкале, сколько вы выберете для кода, в котором у каждой переменной странное имя?

Это внимание к деталям. Понимание того, что детали создают продукт. Я постоянно удивляюсь дисциплинированности некоторых программистов, чей код внимательно отформатирован, комментарии по делу, а структура очевидна, стоит только взглянуть.

Таким образом, как начать изучать дизайн?

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

Настоящая структура дизайнерского образования вертится вокруг критики дизайна: преподаватель объясняет некие концепты, затем просит студентов связать что-либо визуальное с этими концептами, добавив ограничений, после чего работа обсуждается всей группой.

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

Я думал долго и упорно, как воспроизвести этот формат в онлайне так, чтобы он масштабировался. Я расширю его до других дисциплин, но первоначальный курс будет про дизайн для программистов. Если вы заинтересованы, зарегистрируйтесь, чтобы мы известили вас, когда запустимся, или просто зафолловьте нас на Твиттере. Мы напишем ещё больше в этом блоге про взаимоотношения между дизайном и программированием. Keep tuned.

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