Эта статья вышла из моего пути “проб и ошибок”, и почти каждый тезис так или иначе связан с неудачей или успехом на этапе проектирования и дизайна для какого-либо стартапа.
Надеюсь, что она поможет дизайнерам избежать тех же ошибок, на которые натолкнулась в свое время я. Людям, которые решили сделать свой стартап, эта статья поможет учесть тонкости, связанные с процессом разработки и сделать более качественный продукт.
Я буду говорить исключительно про процесс проектирования, дизайна и верстки. Но не стоит воспринимать эти этапы как последовательные действия: мы не на фабрике. Идеально всё бывает только в книжках, поэтому надо привыкнуть к тому, что если что-то не идет так, как вы себе представляли, не надо отчаиваться и паниковать.
Поэтапность не значит отсутствия коммуникации
Самое важное, что можно только вообразить, при этом учитывается далеко не всегда.
Ситуация
К дизайнеру приходит клиент с прототипами, разработанными каким-то проектировщиком, имя которого не называется. Контактов с проектировщиком нет, так как свою часть работы он “закрыл” и уехал в отпуск/перешел к следующему заказу. Дизайн принимается, отдается на верстку. Общение закончено. С верстальщиком, имя которого не называется, контактов также нет, так как дизайнер свою часть работы формально “закрыл”.
Дело даже не в том, что очень часто не соблюдается очередность этапов “Plan-Do-Check-Act”, читай “Дизайн (в общем смысле, вместе с проектированием) — Верстка — Дизайн-контроль — Полировка и запуск”, а в том, что структуры, входящие в эти этапы, даже не общаются.
Мы не роботы, и одной передачей информации через менеджера или клиента, если он выступает в таком качестве, не обойдешься. Обязательно нужно общение с самого начала проекта между всеми его структурами (по крайней мере в нашем “общем деле” фронт-энда). Прямое общение ускоряет коммуникацию и решение задач проекта, да и качество проекта выше, так как все его участники могут вложить свой профессиональный опыт на других этапах. Главное, не переусердствовать.
Бывает, что на этапе дизайна верстальщик придумывает анимацию для того, что нарисовано, которая дает +100 к вау-эффекту у пользователей и +200 к ощущению удобства пользования.
При этом общении необходимо помнить, какой сейчас этап и что, например, не надо начинать верстать на этапе бумажных прототипов.
Приготовьтесь к вечной разработке
Разработка не кончается никогда, а первый дедлайн — это всего лишь начало пути.
Ситуация
Дизайнер завершил свою работу, проверил верстку и сайт запустили. Все, казалось бы, прекрасно. Через два дня нужно нарисовать иконку. Через неделю работы сайта становится понятно, что нужно перерисовать один из блоков. Через две недели нужно спроектировать новый раздел. Через месяц нужен лэндинг. Дизайнер, который изначально занимался сайтом, резко становится занят. Что делать и куда бежать?
Надо смириться с тем, что разработка — понятие практически вечное. Можно называть это “поддержкой” — да и как угодно, — но в случае сервисов это скорее полноценное развитие. Хотя я придерживаюсь точки зрения, что обычных сайтов не бывает. Возможно, меня укусили стартаперы, и поэтому я так думаю.
Дизайнеров можно разделить на два типа: краткосрочные и долгосрочные. И здесь не стоит вопрос о том, кто лучше: у них просто совершенно разные функции. Один занимается созданием и делает это лучше всех, а другой развитием, и опять же, делает это лучше всех. Если предложить краткосрочному дизайнеру долгосрочные отношения, он быстро “завянет”. Но если дать ему “чистый лист”, то вы увидите магию. Так же и с “долгосрочниками”. Если вы работаете с командой или фирмой, которые занимаются разработкой стартапов, они могут взять на себя функцию и создания, и развития.
Если вы дизайнер и не готовы влиться в команду навсегда, предусмотрите варианты отступления от проекта и сразу оговорите это с клиентом. Если вы не предоставляете услуги развития, еще в начале проекта начинайте готовить себе очень хорошую замену. Иначе потом начнутся большие проблемы. Бездействие может очень сильно испортить отношения с клиентом даже при отличном результате.
Несколько вариантов будущего
Практически у любого стартапа есть несколько ключевых вех развития. Не забывают об этом в бизнес-планах, на брэйнштормах и встречах с потенциальными инвесторами, а когда доходит до дизайна, все начинает идти наперекосяк.
Ситуация
На этапе программирования оказывается вдруг, что четырех из шести разделов не будет, профили пользователей тоже подождут, и вообще механика взаимодействия “немножко” меняется, потому что сейчас еще не готовы дать столько контента или еще не договорились с партнерами. И еще недоступно несколько функций, которые красной линией идут по всем страницам.
В итоге, как вы понимаете, это отражается абсолютно на всем, а в первую очередь, на качестве. Всё начинает перекраиваться, где-то что-то “едет” и получается плохо. А чтобы получилось хорошо, нужно, по сути, сделать все почти заново. Либо запуститься с полным функционалом через какое-то время.
Если клиент или проектировщик присылает вам прототипы только одной вехи проекта с задачей реализовать только ее, должен возникнуть резонный пакет вопросов о развитии проекта. Либо у стартапа одна веха развития (такое вообще бывает?), либо вам предложено реализовать только самую минимальную версию, либо у клиентов неправильное представление о разработке. Кстати говоря, клиенты совершенно не обязаны разбираться в этапах разработки сервиса и знать, что для разных вех развития нужны совершенно другие проектирование и дизайн. Надо устранять недопонимание в самом начале проекта. Может быть такое, что на этапе проектирования, где дизайнер не присутствовал (см. пункт про поэтапную разработку), произошла катастрофа. Эта катастрофа заключается в том, что было изначальное непонимание вех проекта и в том, что нужно было задавать правильные вопросы. Если катастрофа все-таки произошла, независимо от этапа разработки, задайте эти правильные вопросы пока не поздно. Возможно, еще можно доделать или переделать.
В случае со стартапами нужно понимать, что вы реализуете несколько продуктов одновременно, и при этом один и тот же. И в самом начале это, чаще всего, проект с урезанным функционалом. При этом о следующих “дополненных и расширенных” версиях очень нужно знать и понимать, куда расти.
Лучше плохой прототип, чем никакой
Ситуация
Клиент на словах рассказывает о проекте и говорит, что это срочно. Вдохновленный дизайнер надевает костюм супергероя, выкладывается по полной, высылает макет. Клиент разочарован, потому что это совершенно не то, что он себе представлял. Дизайнер расстроен, потому что он выложился, а ему сказали, что не так, как надо. Мотивации работать вместе все меньше и меньше.
Во-первых, если затрагивать тему постановки задачи дизайнеру, то так или иначе придется столкнуться с биологическими и психологическими вещами: левша/правша/амбидекстр и аудиал/визуал/кинестетик. Для каждого человека все индивидуально. Что касается меня, я совершенно не выношу телефонные переговоры, так как у меня выработана стойкая привычка “в одно ухо влетело, в другое вылетело”. Приходится спрашивать разрешение на запись голоса в скайпе, а позже переслушивать и расшифровывать. Либо тут же зарисовывать и записывать. Думать, потом говорить и делать. Самая идеальная постановка задачи в срочной ситуации при отсутствии прототипов: хотя бы накаляканное от руки представление того, что будет (дизайнером или менеджером) с выставленным дедлайном. Либо текст. Либо текст и картинка (хотя бы скан).
Во-вторых, очень здорово, что сами стартаперы могут научиться делать прототипы. Очень классно, что можно донести идею “в массы” (и разработчикам в том числе) на словах. Но лучшее, что можно сделать для проекта — нанять хорошего проектировщика отдельно под эту задачу. Он поможет взглянуть на проект по-новому, а работа дизайнера в связке с этим проектировщиком даст лучший результат.
Если у дизайнера нет прототипов, он будет делать их сам, и ничто не сможет этому помешать. Как вы понимаете, это займет намного больше времени, нежели работа с готовыми прототипами.
Как правило, клиентские прототипы, которые предназначены, чтобы рассказать о его представлении, переделываются совместно с проектировщиком и/или дизайнером (если он что-то понимает в проектировании).
Дизайн+верстка=?
Между верстальщиком и дизайнером должно быть больше, чем постоянная коммуникация. Между ними должно быть огромное доверие, потому что в результате получается максимально красиво и удобно.
Две ситуации
1. Принимается очень красивая графика, а на выходе получается полное несоответствие тому, что было в макете дизайнера. Вроде бы и сверстано по макету, а получилось ужасно. И, увы, знакомо каждому дизайнеру.
2. Довольно скучноватая графика. Верстальщик делает из нее самый лучший проект в мире. И анимации в тему, и сверстано всё просто прекрасно. Знакомо? Lucky you!
Верстальщики не очень любят, когда дизайнеры начинают лезть в верстку так же, как и дизайнеры недовольны, когда их макеты очень вольно интерпретируют в финале. И, все же, вопрос: кто должен придумывать и продумывать такие детали, как анимация?
У Артема Поликарпова был отличный доклад про то, что верстальщики — тоже дизайнеры.
Формально от верстальщиков никто не будет требовать того, чтобы они придумали какое-то интересное визуальное решение, но хороший верстальщик способен очень сильно улучшить дизайн. Настолько сильно, что даже сложно предположить.
Дизайнер, как минимум, должен понимать, что можно сделать, а чего сделать нельзя. Если дизайнер понимает, как сделать, к примеру, анимацию, какие существуют ограничения и области применения, сложно реализовать или просто — это замечательно. Еще лучше, если он может нарисовать и объяснить, какую анимацию сделать и удостовериться, что на выходе она соответствует задумке. Просто здорово, если он сможет помочь реализовать эту анимацию на этапе верстки.
В случае тесной связки дизайнера и верстальщика, помощи друг другу и хороших отношений, проект получится очень красивым и можно ожидать вау-эффекта в итоге.
Выводы
1. Не бойтесь участвовать на любом из этапов разработки идеями, силами и вопросами.
2. Помните, что запуск проекта — это только начало пути. За ним следует доработка, переработка и развитие: всегда что-то нужно. Поговорите об этом с клиентом и решите вопрос о том, кто будет развивать проект.
3. Задавайте правильные вопросы, предусматривайте реализацию разных вех развития проекта, даже если этого не предусмотрели до вас.
4. Знайте, что одинаковое понимание проекта и движение всей команды в одном направлении — залог успеха. Прототипируйте.
5. Дружите с командой и будьте в постоянном контакте со специалистами, от которых зависит качество реализации вашего этапа работы.
Автор: mewz
