Редизайн сайта агентства
О проблемах внутренних проектов и заказной разработке
Я работаю в агентстве, которое занимается интерактивом для недвижимости. Как и любая студия с большой историей, мы много раз обновляли свой сайт, и каждый раз это была вакханалия для сильных духом.
В этой статье расскажу о том, с какими проблемами сталкиваются агентства, когда делают проект для себя. Местами статья самоочевидная: увы, есть много граблей, о которых все знают, но продолжают биться лбом, поэтому говорить об этом нужно, пусть даже истины и не новы.
Статья будет полезна ребятам, которые работают в заказной разработке, делают много хорошего для клиентов, но никак не могут найти время на собственные проекты.
Как не надо делать свой сайт
Полтора года назад мы решили сделать немецкую версию собственного сайта — «Кельник.de».
Пару слов о контексте. В последние пару лет мы активно развиваем представительство в Германии — делаем 3D-визуализацию, интерактивные планировки и небольшие сайты для немецкого рынка. Сначала мы продавали свои услуги с помощью презентаций и личных встреч, потом сделали на коленке простой лендинг с перечнем услуг, а через год дозрели до того, чтобы сделать большой полезный сайт.
Дело осложнялось спецификой рынка. Мы рассматривали вариант «просто взять и перевести российский сайт», но российский сайт не подходил под задачи и проблемы Германии, и немецкие клиенты его не понимали. Поэтому всё надо было делать с нуля.
Ну, надо — значит надо.
Собрались большим составом, обсудили всё, чего хотим от нового сайта. Был ноябрь 2017. Фронт работ не казался пугающим. Ну, что такое сайт агентства — 10 страниц с адаптивом? Для клиентов мы разрабатываем сайты с огромным количеством шаблонов, с разветвлённой админкой, с кучей сложных состояний у фильтров. Рядом с этим объём «Кельник.de» выглядел незначительным, и казалось, что мы управимся с ним очень быстро.
Наш тогдашний проектировщик, прекрасная Алсу Газиева, продумала информационную архитектуру и сделала понятный и логичный прототип, умудрившись не упустить ничего из бесконечного списка хотелок.
Мы долго обсуждали прототип, спорили о позиционировании компании, о функциях и структуре, о том, на каком языке всё это делать, как потом лучше переводить и как наш будущий сайт обязан всех сразить на немецком рынке.
Потом пришла очередь дизайна. Он тоже обсуждался часами. Светлый, тёмный, белый, синий, с паттернами и без паттернов, с анимацией, без анимации — короче, времени не пожалели.
Немецкое подразделение просило обойтись без фарша и придерживаться максимально нейтрального стиля. По российским меркам он скучноват, но немцам именно так и надо.
Тут начались сложности. Работать приходилось в промежутках между клиентскими задачами, поэтому дело затянулось. Когда проект дошёл до вёрстки, был уже конец марта. Фронты, как обычно, были загружены. Если чудом кто-нибудь из них оказывался свободен, ему давали поверстать «Кельник.de», а потом отбирали, перебрасывая с проекта на проект.
К лету в очередной раз вырос поток задач, мы расширили штат, клиентских проектов стало ещё больше, и до внутренних проектов руки уже не доходили. «Кельник.de» лежал в долгом ящике.
Пришла осень, а затем и зима. Однажды вынырнув из потока клиентских задач, мы посмотрели на статистику. Прошло больше года, потрачена уйма часов, над проектом работало семь человек, а конца и края не видно.
А ведь сайт-то небольшой. Несложный по дизайну и совсем простой в наполнении, без коммуникационных проблем с клиентом и командой. На нём даже нет фильтров и личных кабинетов, которые мы привыкли внедрять у клиентов. Нет ничего, что могло бы оправдать такие потери. Трудно сказать, запустим ли мы вообще когда-нибудь этот сайт, и, если запустим, то когда именно. И самое страшное: не получится ли так, что наш бедолажный проект устареет уже к моменту релиза?
Причины факапов
Сообразительный читатель уже понял, что пошло не так. Каскадная разработка, косяки в управлении проектом, неадекватные ожидания.
Увы, этим список проблем не исчерпывается.
- Низкий приоритет задачи. Внутренняя задача — вечно неприкаянная. «Кельник.de» — не то, на чём мы напрямую зарабатываем, и при появлении клиентского проекта мы вынуждены отфутболить его до лучших времён.
- Долгие обсуждения и согласования. Проект затрагивает интересы кучи людей в агентстве — менеджеров, продажников, директоров, руководителей направлений. Пока со всеми скооперируешься, проходят недели.
- Высокая степень неопределённости. В случае с клиентским проектом у нас давно всё отлажено — мы знаем, когда стартуют этапы работы, какой контент нам нужен, кто будет его подготавливать, в какие сроки. Но внутренний проект — не профильный, на нём всё неопределённо. Куча времени уходит на утрясание нюансов и определение, кто за что отвечает.
- Загруженные фронтендеры. Техническим специалистам трудно переходить с задачи на задачу по щёлчку. На трёх страницах сменилось три фронта. Каждый из них заново вникал в проект, тратил кучу времени на то, чтобы разобраться в задаче, но мало что успевал сделать.
- Адовый перфекционизм. Очень хочется, чтобы свой собственный сайт был идеальным. Фокус смещается с решения задачи на то, чтобы произвести впечатление — и на клиентов, и друг на друга. Ограничений нет, и ничто не дисциплинирует: ковыряйся с макетами хоть до второго пришествия, расставляй отступы пиксель в пиксель, отрисовывай по двадцать макетов для каждой страницы — кто остановит? Парадоксально, но возможность бесконечно оттачивать детали загоняет проект в тупик.
«Как так-то?»
Я пишу эту статью, потому что мы не одни такие. Я знаю множество прекрасных дизайнеров, у которых нет портфолио, и множество агентств, которые делают сильные проекты для клиентов, но годами не могут переделать свой сайт.
Нельзя сказать, что эти ребята не умеют управлять процессами. У них неплохо всё отлажено, есть огромный опыт работы, да ещё и в авральных условиях. В головах у них горят неоновые лампочки дедлайнов, они обвешаны регламентами и чеклистами. Ребята привыкли постоянно разгребать чужие проблемы, и у них неплохо получается.
Кажется, что мы можем многому научиться у этих улиточек. Но, когда дело касается чего-то, что сделано исключительно для себя, всё идёт наперекосяк.
Вся эта беда с внутряком возникает не потому, что ребята неорганизованные. Проблема внутренних проектов вытекает из фундаментального свойства заказной разработки — разрабатывать для других, а не для себя.
(Здесь попутно всплывает философский вопрос — как приучиться любить себя, беречь и заботиться о своих долгосрочных интересах, когда постоянно занят решением чужих проблем. Но об этом как-нибудь в другой раз. В этой статье и так слишком много боли.)
Как надо было сделать
Все вышесказанное, разумеется, не означает, что в наших проблемах виноват мир вокруг, а не мы сами. Однако случай с «Кельник.de» показал, что процесс работы над внутренними проектами нуждается в серьёзном пересмотре.
Агентство не может тратить год на то, чтобы сделать себе сайт. Это нормально для корпораций, но не для студии в 70 человек. К сожалению, ничего нельзя сделать с приоритетами — внешние задачи всегда победят внутренние, потому что внешние приносят деньги. И бесполезно даже пытаться вести внутренние задачи так же, как клиентские.
Во-первых, для внутренних задач нужен другой процесс — минимум обсуждений и согласований. Завязываем с многочасовыми совещаниями на 10 человек. Выделяем дизайнера, который отвечает за главные решения, и раз в неделю собираемся маленькими группами по 2–3 человека, чтобы быстро посмотреть результат и устранить противоречия.
Во-вторых, нужна другая технология — та, что позволит запустить продукт, не верстая его месяцами. То есть сайт нужно делать на каком-нибудь конструкторе вроде Тильды или Редимага, а уже потом в свободное время доводить до приемлемого состояния и довёрстывать модули, которых в конструкторе нет.
В-третьих, нужна другая задача. Отныне мы не допиливаем мелочи месяцами, стараясь удовлетворить всех без исключения. Не нужна куча концепций, не нужны долгие разговоры о позиционировании, и, откровенно говоря, не нужен сайт, который сразит всех наповал.
На самом деле нужен сайт, который:
а) будет отражать действительность: показывать не то, кем мы были несколько лет назад, а то, кто мы прямо сейчас;
б) поможет демонстрировать компетенции: чем мы полезны другим компаниям;
в) можно сделать быстро, пока поток клиентских задач в очередной раз не заставил сменить фокус.
«То есть всё сводится к MVP?»
Да, совершенно верно. На третий день индеец Зоркий Глаз заметил, что у сарая нет четвёртой стены, а я спустя год после старта «Кельник.de» обнаружила, что нам был нужен всего-навсего минимально жизнеспособный продукт (minimum viable product, MVP). А вся предыдущая работа пригодилась для того, чтобы избавиться от иллюзий и воздушных замков.
«Кельник.de» было не спасти, но принципы, появившиеся в ходе разбора ошибок, можно было применить к другому проекту. Через несколько месяцев, занимаясь редизайном «Кельник.ру», мы попробовали сменить подход, обратившись к концепции MVP вместо каскада.
Вот что из этого вышло.
Исправление ошибок
Итак, пора признать неизбежное: чтобы не делать проект год с лишним, мы вынуждены чем-то жертвовать. Но от чего именно надо избавиться, а что — сохранить?
Раньше мы отвечали на этот вопрос, собираясь на совещания. В новом подходе один раз провели опрос коллег в телеграме. Что бесит, что радует? Что вам важно на старом сайте? Чего критически не хватает ?
Помимо опроса, пригодилась статистика: мы поменяли порядок пунктов в меню в соответствии с их востребованностью и решились выкинуть разделы с низкой посещаемостью. На их создание и поддержку уходило лишнее время, а пользы не было.
Ещё мы убрали всё, что можно было разместить на сторонних сайтах: например, нет смысла делать свою страницу вакансии, если можно просто ставить ссылки на «Мой круг» и «Хэдхантер». То же самое — с кейсами и старыми проектами.
Поиски дизайна
В новом подходе мы не рисовали с нуля множество концепций, а взяли готовый старый сайт и по мелочам улучшали его.
Пара дней ушла на прикидки, как освежить дизайн, обходясь малыми силами и сохраняя структуру. После этого мы переместились в Редимаг, и дальше собирали сайт уже в нём, минуя стадию подготовки макетов для десктопа и адаптива.
Мы выбрали Редимаг, потому что прежде делали в нём кейсы и презентации и хорошо знали технические ограничения. С тем же успехом можно выбрать и Тильду — принципиальной разницы в подходе нет.
После просмотра черновиков раздался плач хора продажников.
— Даша, — кричали они, — почему все наши сайты белые? Где справедливость, где цветное?
Из препирательств с продажниками родилась серия странненьких плакатов для офиса.
А уже из них — новый дизайн «Кельник-ру».
Сложности
Новый подход сработал — в отличие от «Кельник.de», который так и остался в подвешенном состоянии, «Кельник.ру» мы запустили. От старта работ до релиза прошло всего 2 месяца.
За это время мы успели:
— сделать весь дизайн, включая мобильную версию,
— собрать его на Редимаге,
— написать контент для внутренних страниц,
— настроить простейшую анимацию,
— создать три новых кейса,
— сфотографировать офис,
— несколько раз обсудить все нюансы с командой и менеджерами,
— провести презентацию для своих,
— перевезти старый сайт на поддомен,
— отловить и исправить баги.
Первый раз на моей памяти редизайн агентского сайта (а я уже не в первый раз бьюсь об эти грабли) прошёл почти без геморроя. Мы обнаружили только три проблемы, и все три связаны с возможностями Редимага, а не с проблемами в процессах:
- Нет админки. На главной странице предусмотрена лента из проектов, а в портфолио — карточки кейсов и сайтов. Хочешь добавить новый проект — сдвигай вручную все карточки, меняй размеры, высоту, пропорции. Мобильную версию почти всегда приходится настраивать отдельно.
2. Нет сортировки. Мы не можем дать пользователю возможность выбирать кейсы по тегам или типам (сайты, 3D, VR), поскольку в Редимаге это пока что можно реализовать только с помощью костылей с дублированием страниц.
3. Нет прелоадера + чужой сервак. Сервера Редимага временами могут тупить и не всё загружать по-божески, а проконтролировать этот процесс, ускорить его или хотя бы повесить прелоадер на долгую загрузку нельзя. В качестве компромисса мы всё-таки повесили на главной свою имитацию прелоадера, но это снова костыли, и работает оно через раз.
Если через какое-то время у нас появится железная необходимость в расширении, мы всё-таки переверстаем сайт и переедем с Редимага на свою платформу. Но, пока этого не случилось, сайт уже работает, приносит пользу, новых клиентов и соискателей.
Резюме: как не облажаться с внутренними задачами, если работаешь в агентстве
- Не вести внутренние проекты так же, как клиентские. Не надо масштаба, не надо больших прототипов и исследований, не надо раздутой команды.
- Лучше MVP, чем каскад. Лучше мало, но сейчас, чем много и никогда.
- Выкинуть из проекта всё лишнее. Если можно вместо своей страницы поставить ссылку на сторонний сервис — ставить ссылку. В случае с клиентскими крупными проектами это бы ударило по конверсии, но если речь идёт о сайте агентства, это серьёзно сэкономит время и силы.
- Конкретизировать задачу. Задавать себе вопрос: чего конкретно мы хотим добиться, какой сайт нам нужен, действительно ли важно иметь кейсы для каждого проекта, действительно ли нужны огромные описания услуг прямо в первой итерации, или что-то можно перенести на потом.
- Если можно не верстать — не верстать. Конструктор в помощь.
- Чтобы не забыть ничего важного из фидбэка коллег, но в то же время не утонуть в обсуждениях, устроить один опрос, а не двадцать встреч со всеми подряд.
Это была очередная горемычная статья о дизайн-процессах, граблях, ошибках и извлечённом из них опыте. Если у вас есть свой полезный опыт об успехах и неудачах в заказной разработке, буду рада почитать об этом в комментариях.
Кроме этого блога, я также веду канал в телеграме о визуальных приёмах — https://t.me/mozhno
