Процессы проектирования состоят из значительного количества движущихся частей. Будь то общение с клиентами, проблемы с бюджетом, несовпадение интересов заинтересованных сторон или соблюдение сроков - их практически невозможно усовершенствовать.
Из-за сложности веб-проектов поразительно, что «25% из них терпят неудачу» (Ruby Development).
При разных типах дизайнерских проектов и клиентов невероятно сложно придерживаться только одного процесса. Я часто корректирую свой процесс в зависимости от целей проекта, сроков, бюджетных ограничений и т. д.
Но даже в этом случае всегда возникают проблемы, шаги, которые пропускаются, и в результате выпускаются некачественные продукты.
Чаще всего я обнаруживаю, что есть несколько аспектов дизайн-проекта, которым необходимо следовать, чтобы он не резко ухудшился, и я хочу поделиться этим опытом с вами.
В этой статье я рассматриваю 5 компонентов, которые, по моему мнению, являются наиболее важными, которым следует следовать в процессе проектирования, и то, как вы можете предотвратить срыв вашего следующего проекта.
1) Совместная подотчетность
На этапе открытия дизайн-проекта вы обычно находите время, чтобы поговорить со своим клиентом и понять, что должно произойти, чтобы проект стал полным успехом. Проведен значительный объем анализа, чтобы вы могли собрать воедино цель проекта, насколько он действительно необходим, долгосрочные и краткосрочные ожидания и т. д.
Но прежде чем вы даже пойдете на ознакомительную встречу и начнете выяснять, что вам или вашей команде предстоит сделать, вам нужно подготовиться к обсуждению того, что вашему клиенту нужно сделать, чтобы успеть выполнить проект и помочь вам добиться успеха. тоже.
Это может быть сообщение им о важности обратной связи по дизайну, согласованности действий команды, позволяющей сторонам согласовывать результаты, обеспечение использования соответствующих каналов, необходимых для завершения проекта, и т. д.
Например, вы и другой член команды разрабатываете несколько веб-страниц, но одним из важнейших этапов работы является получение контента, за доставку которого отвечает клиент.
Если клиент обнаруживает, что не может доставить контент вовремя из-за того, что забыл или был слишком занят, это в конечном итоге сокращает время, необходимое для выполнения своих задач. В большинстве подобных сценариев очень сложно перенести сроки.
Если вы позволите этому случиться и продолжите сообщать, что у вас все еще есть возможность уложиться в срок, но неизбежно поймете, что не можете, теперь вам некого винить, кроме себя.
Когда начинают проявляться подобные проблемы, обратите на них внимание и подчеркните последствия невыполнения X. Но будьте осторожны, чтобы не представлять эти проблемы с позиции гнева или разочарования. Убедитесь, что ваш клиент знает, что вы требуете от него ответственности, потому что хотите, чтобы он добился успеха, соблюдал график и в конечном итоге получил лучшую версию конечного продукта, какую только возможно.
Если вы сможете успешно поддерживать это на протяжении всего проекта, ваши клиенты в конечном итоге будут доверять вам гораздо больше, потому что они поймут, что вы заботитесь об их интересах.
2) Ограниченные версии
Получение одобрения каркаса - одно из первых препятствий при проектировании, которые вам действительно нужно преодолеть. Но есть следующее серьезное препятствие: утверждение фактического макета.
В идеальном мире каждый дизайн, который мы показываем клиенту, будет одобрен мгновенно, без вопросов, потому что вы только что хорошо выполнили свою работу.
Но человек так далек от того, что происходит.
Чаще всего нам приходится вносить изменения, с некоторыми из которых мы не всегда согласны лично, но понимаем, что визуально это может лучше отражать то, чего хочет клиент.
К сожалению, мы часто позволяем клиенту постоянно запрашивать исправления. Иногда раздел хорош в первую неделю, но не в следующую. Затем вы меняете дизайн этого раздела и обнаруживаете, что другой раздел теперь не соответствует действительности. Вскоре вы окажетесь в состоянии постоянного изменения дизайна разделов.
Как только вы приступите к третьему раунду доработок и обнаружите, что клиент все еще хочет настаивать на большем, вам нужно остановиться и действительно начать критически спрашивать клиента, почему. Это потому, что они продолжают вдохновляться разными макетами, которые видят в Интернете, хотя ваш по-прежнему достигает той же цели? Пытаются ли они стремиться к совершенству? Вам нужно провести с ними эти трудные разговоры и обязательно сообщить, что это неизбежно приведет к тому, что вам придется сдвинуть сроки.
Одна из тактик, которую мне также нравится использовать, - это демонстрировать важность реализации того, что у нас есть, с намерением доработать и улучшить дизайн позже. Или, что еще лучше, протестируйте, чтобы увидеть производительность этой конструкции по сравнению с другой, которую вы можете попробовать через месяц или два. Это дает клиенту время вернуться к дизайну и посмотреть, является ли одна из идей доработки тем, что он все еще хочет попробовать, или то, что у вас есть, действительно является лучшим вариантом, которого стоит придерживаться.
3) Честность
Если вы чего-то не знаете, узнайте или спросите того, кто знает. Страшно сообщить кому-то, что мы не знаем ответа на что-то. Поэтому, когда мы оказываемся в ситуациях, когда нам задают вопрос, и мы не уверены в правильности ответа, мы стараемся ответить на него максимально позитивно, чтобы клиент был доволен.
Например, клиент спрашивает, возможны ли какие-либо функции для проекта веб-разработки с помощью только что представленного вами дизайна. Если вы ответите «да», не зная истинного ответа, вы рискуете вернуться к клиенту и сказать ему, что вы были неправы.
Вы никогда не должны чувствовать, что вам нужно отвечать на каждый вопрос, который задает клиент, особенно если вы рискуете, что он окажется неправильным и повлияет на что-то в долгосрочной перспективе. Клиент предпочел бы, чтобы вы сказали ему: «Я не уверен, что у меня есть все знания, чтобы ответить на этот вопрос сейчас. Позвольте мне провести небольшое исследование/спросить кого-нибудь, кого я знаю, и свяжусь с вами в ближайшие пару дней.”
Я обещаю, что они скорее предпочтут, чтобы вы вернулись с более сформулированным ответом позже, чем обнаружили, что вы ввели их в заблуждение. Просто убедитесь, что вы вернетесь к ним через соответствующее время и получите альтернативную рекомендацию, если что-то не совсем возможно.
4) Функциональность
Одна из характеристик, о которой, как я заметил, некоторые дизайнеры не задумываются, - это то, как их дизайн превратится в функционирующий прототип.
Я говорю не о том, что вам нужно понимать код, который используется при разработке вашего проекта (вы можете оставить это разработчикам), а скорее о том, как вы представляете движущиеся и ведут себя объекты.
Это приводит не только к отсутствию понимания того, как дизайн должен функционировать при воплощении в разработку, но и к тому, как клиенты вообще могут ожидать от него поведения.
Если вас это не совсем устраивает, я рекомендую дизайнерам сделать пару вещей.
Во-первых, нужно потратить некоторое время на то, чтобы по-настоящему понаблюдать за средой, для которой вы проектируете. Например, как веб-разработчик, я одержим просто просмотром веб-сайтов, изменением размера моего браузера и наблюдением за тем, как веб-сайт трансформируется с больших экранов на меньшие. Я также потрачу время на то, чтобы открыть их на разных устройствах и взаимодействовать с ними, делая заметки и записывая, какие функции могут быть полезны для использования в моих собственных проектах.
Но одна возможность обучения, которую нельзя упускать из виду, - это просто просматривать и читать блоги UX, такие как Nielsen Norman Group, Smashing Magazine или UX Collective, чтобы научиться мыслить таким образом.
5) Обзор финальной сборки
После того, как вы передадите свой проект команде для его создания (если применимо), вы можете подумать, что ваша часть проекта на этом заканчивается, хотя на самом деле у вас остался еще один важный шаг. Обзор финальной сборки.
Прежде чем клиенту будет отправлен работающий прототип дизайна, вам необходимо убедиться, что ваш дизайнер просматривает его в последний раз, чтобы учесть все, что может быть не совсем точным.
Это быстрое действие, которое может избавить вас от потенциальной головной боли в будущем, если клиент заметит что-то или два, которые не были сделаны при сборке и которые в противном случае могли бы быть обнаружены при проверке.
Выделите немного дополнительного времени ближе к концу графика проекта, чтобы вы могли провести эти проверки и попросить своего разработчика или инженера устранить возникающие проблемы. Хотя нам всем хотелось бы думать, что таких ошибок не произойдет, вы должны предполагать, что они произойдут, и планировать время, чтобы оставаться в безопасности.
Ключевые выводы
Дизайн-проекты могут принимать самые разные формы и размеры, поэтому, скорее всего, не все эти важные шаги применимы к вашему проекту или команде, с которой вы работаете.
Я всегда говорю, что хороший образ мышления - это никогда не оставлять камня на камне. Если вы когда-нибудь задаетесь вопросом или думаете, что чего-то не хватает, скажите что-нибудь кому-нибудь или обратитесь к своему клиенту за подтверждением. Нет ничего хуже, чем предполагать или игнорировать информацию, которую вам потенциально может понадобиться знать.
Руководствуйтесь таким образом, чтобы у вас была вся информация, необходимая для действительного достижения цели клиента, к которой вы стремитесь. Это поможет вам в первую очередь подумать об их интересах на протяжении всего проекта и обеспечить лучший конечный продукт.