Смерть для обработки машин!

Найдите свой идеальный процесс проектирования, придерживаясь нескольких простых принципов вместо жесткого сценария.

Вы услышите массу разных советов о правильном и неправильном способе разработки приложения или веб-сайта.

«Вы должны использовать Sketch».
«Системы проектирования или GTFO».
«Настоящие дизайнеры проектируют на 100% код».
«Каркасы - пустая трата времени».
«Если вы не создаете прототипы, вы делаете это неправильно».
«Вы должны начать на бумаге».

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

Классический линейный подход выглядит примерно так:
исследование → эскиз → каркас → статические композиции → прототип → код

Это что-то вроде тех машин Rube Goldberg-esque, которые они используют для изготовления Doritos и Ding-Dongs. Бросьте идею в технологическую машину, и после того, как она будет растертой и отлитой в форму, когда она изгибается по ступеням, готовый продукт выскакивает на другую сторону! Предсказуемость! Эффективное!

Что-то вроде.

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

Хэнк, a.k.a. «Сабо»

В последнее время я смотрю «В поисках Дори» с моим ребенком, и часть съемок «делаю из» постоянно бросается на меня.

В фильме есть этот осьминог по имени Хэнк:

Disney / Pixar

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

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

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

Disney / Pixar

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

Лекарство от предписывающего процесса

Команда Finding Dory сделала лучший продукт быстрее, принимая решения, которые отдавали предпочтение скорости и качеству, а не придерживались заурядного процесса.

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

Определение принципов, управляющих вашим процессом, - это только начало. Вот как вы можете применить их на практике.

Начните с больших вопросов

Если вы цените скорость, начните проект, выяснив, какие самые большие, самые фундаментальные вопросы. В Getting Real это называется «дизайн эпицентра»:

Начните с ядра страницы и постройте наружу
Дизайн эпицентра фокусируется на истинной сущности страницы - эпицентре - и затем строится наружу. Это означает, что в начале вы игнорируете конечности: навигацию / вкладки, нижний колонтитул, цвета, боковую панель, логотип и т. Д. Вместо этого вы начинаете с эпицентра и сначала разрабатываете самый важный фрагмент контента.
То, без чего страница абсолютно не может жить, является эпицентром. Например, если вы разрабатываете страницу, на которой отображается сообщение в блоге, само сообщение является эпицентром. Не категории на боковой панели, не заголовок вверху, не форма комментария внизу, а фактическая единица блога. Без блока сообщений в блоге страница не является сообщением в блоге.
Только когда этот блок будет завершен, вы начнете думать о втором наиболее важном элементе на странице. Затем, после второго наиболее важного элемента, вы переходите к третьему и так далее. Это эпицентр дизайна.
Эпицентр дизайна отказывается от традиционной модели «давайте создадим фрейм, а затем бросим контент». В этом процессе строится форма страницы, затем включается навигация, затем маркетинговые «вещи»
 вставляется, и, наконец, основная функциональность, фактическое назначение страницы, добавляется в оставшееся пространство. Это обратный процесс, который принимает то, что должно быть главным приоритетом, и сохраняет его на конец.

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

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

Просто спросите, WMGMTCATMQITLAOT?

Как только вы знаете вопросы, на которые сначала нужно получить ответы, задайте себе вопрос:
«Какая среда дает мне наиболее четкий ответ на мои вопросы за наименьшее количество времени?»

В случае моего стороннего проекта ответом был код. Для страницы на Basecamp.com ответом часто является текст или эскиз. Для вас это может быть что-то совсем другое.

Зная, когда переключать передачи

Это дает вам место для начала, но как вы узнаете, когда пришло время переключиться на другую среду? Когда вы попали в сопротивление.

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

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

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

Второй случай - возврат к более низкой верности - более сложный. И потому, что люди менее практикуются в этом, а также потому, что это сложно. Продолжай работать в коде. Вы работаете с 100% точностью, поэтому у носителя нет возможности отвечать на вопросы. Но есть предел его способности быстро отвечать на вопросы.

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

Использование среды в ваших интересах

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

Чем больше вы понимаете, как средство влияет на вашу работу - какой инструмент он помечает, - тем больше вы можете использовать его в своих интересах. Хотите, чтобы ваш дизайн был выразительным? Вероятно, лучше работать с визуальными инструментами, такими как Sketch, Illustrator или даже * задыхаться * Photoshop. Хотите минимальный, легкий дизайн? Придерживайтесь проектирования в коде.

Практический пример

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

Мы запускаем новый способ работы с клиентами в Basecamp, и моя работа заключалась в создании новой страницы на Basecamp.com для ее продажи. Вот как это разыгрывается:

Определение больших вопросов, выбор среды

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

«Какая среда дает мне наиболее четкий ответ на мои вопросы за наименьшее количество времени?»

Компсы и зарисовки отсутствуют. Это врезка в существующий дизайн и существующий шаблон. Я мог бы перейти прямо к коду, но на этом этапе разметка - это шум. Текст в самый раз.

Куча недоделанной копии

Увеличение точности

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

Зачем?

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

Работа через редактирование копии в коде

Выборочно снижается верность

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

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

Куча полуиспеченных Sketch Comps

Заметьте, как ни один из них не испечен полностью? Это потому что они не имеют значения! Это не для презентации клиента или для передачи разработчикам. Они там, чтобы помочь мне что-то выяснить, тогда они мусор. Тратить время на их полировку было бы пустой тратой усилий.

Заканчивать

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

Это не то, как каждый проект заканчивается. Иногда я набрасываю что-то в Procreate, иногда я начинаю с быстрой и грязной визуальной компоновки, иногда я пишу копию в Sketch, иногда я работаю на 100% в коде. Все зависит от проекта под рукой.

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

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