[Перевод] UX-команда MailChimp: Креативность и дорожные карты [7-я часть книги]
[ 1-я часть книги ][ 2-я часть книги ][ 3-я часть книги ][ 4-я часть книги ][ 5-я часть книги ][ 6-я часть книги ]
Креативность и фронт-эндДжейсон БиэрдВ UX Newsletter мы часто писали о нашей библиотеке шаблонов и о том, как она помогает нам проводить быстрые итерации и обеспечивать согласованность работы MailChimp. Разработка на основе существующих паттернов немного похожа на игру с Lego: когда вы начинаете работу, вы точно знаете, как те или иные элементы должны связываться между собой –, но иногда оказывается полезным нарушить паттерн и создать необычное решение. Я бы хотел поделиться несколькими примерами того, как такой подход был реализован в MailChimp.
Иконки выравнивания текста
Нам надо было добавить иконки для выравнивания по левому, правому краю, по центру и по ширине. Я мог просто добавить 4 новые иконки к нашему набору, но это было бы слишком просто. Я решил подойти к вопросу креативно и создал их в CSS. Использование расширения CSS Shapes — распространенная практика, но такие формы обычно создаются путем добавления цветов фона к модифицированным элементам. Вместо этого я использовал выровненные тире (длинные и средние) как псевдоэлементы, чтобы дать им возможность наследовать размер и цвет текста так же, как это можно было бы сделать и с другими иконками из нашего набора. Это было забавно и заняло всего несколько строк в CSS (демо-вариант иконок в Codepen).
Анимированные иконки часов
Более сложный пример фронт-энд-креатива стал результатом одного-единственного твита. Мардав решил, что для него личным вызовом будет предложение Терри Бланкпейна (Thierry Blancpain): «Учитывая их потрясающий копирайтинг, я немного разочарован тем, что иконки для «отложенных» кампаний в MailChimp не отражают реального времени отправки писем».
Мардав какое-то время ковырялся в библиотеке JavaScript под названием D3.js, которая обычно используется для сложных графиков и визуализации данных. Мы уже запланировали начать использование D3 для создания графиков, поэтому упражнение с иконкой часов стало отличной разминкой. Мардав сделал прототип, и при помощи нашей потрясающей команды разработчиков он был превращен в кастомный Dojo-виджет, который мы используем во многих элементах нашего приложения.
Если вы теперь зададите время рассылки на 13:45 или на 7:30, иконка часов будет отражать это время.
Мы не думали, что пользователи заметят эту забавную деталь, и были очень приятно удивлены, когда о ней рассказали в Little Big Details. Спасибо за идею, Терри (демо-вариант часов в Codepen).
Анимированные GIF для новых пользователей
Мы всегда использовали видео-туториалы для того, чтобы обучить новых пользователей тому, как работает MailChimp. Большая часть этих видео длится не более 2 минут, но мы обнаружили, что в некоторых случаях для наших целей нужно еще меньше времени — всего несколько секунд. Для этого отлично подходят анимированные GIF, поэтому с момента нашего редизайна в 2013 мы используем их по необходимости, чтобы показать, как работают новые элементы интерфейса.
К несчастью, если видео экрана сохранять в формате GIF в Photoshop, размер полученного файла может оказаться достаточно большим. Когда Федерико создал серию коротких роликов в рамках процесса «организационной социализации» нашего нового редактора, оказалось, что даже при использовании достаточно агрессивных настроек сжатия файлы занимали больше 1MB. Это совсем немного для видео, но многовато для быстрого анимированного туториала. Поэтому он начал искать другие примеры скринкастинга в формате GIF и случайно наткнулся на письмо от платформы по работе с фото Exposure.
2 GIF-файла из письма Exposure, содержащие фотоконтент, были созданы под дисплей retina и весили всего 171KB и 401KB. Федерико спросил у Люка Берда (Luke Beard) из Exposure, что они использовали, чтобы достичь этого, и тот ответил: «Только лучшее — cockos.com/licecap/».
Сначала мы решили, что это прикол: сайт выглядел так, как будто его создали в 90-е, и с тех пор там ничего не менялось, а компания, сделавшая его, выбрала себе название «Cockos Inc.», не говоря уже о продукте под именем «Licecap» (фу!) — все это не внушало нам никакой уверенности в том, что это будет работать. Но под непривлекательным названием скрывалось свободное ПО, поэтому Федерико решил попробовать и перезаписал GIF-файл — и вместо 1MB он стал занимать всего 182KB. Проблема была решена (Спасибо, Люк, и прости, что усомнились в тебе).
Не бойтесь потратить чуть больше времени на обдумывание возможных решений
Бюджеты и дедлайны иногда заставляют нас склоняться к наиболее очевидному варианту решения проблемы, но так не должно быть всегда. В следующий раз когда будете работать над фронт-энд-задачей, попробуйте рассмотреть и другие варианты решения. Сделайте что-то необычное. Используйте любую возможность применить новые техники и технологии, особенно если это может порадовать ваших пользователей. И не бойтесь узнавать, как кто-то другой решил ту же проблему — никогда не знаешь, каким новым навыкам можно таким образом научиться.
Циклы выпуска релизов и дорожные карты Федерико ХолгадоНам в MailChimp приходится двигаться вперед быстро — это относится и к тому, над чем мы работаем, и к тому, как ведется работа. Нам нужно вносить в план проекты, которые мы можем выполнить эффективно, и в каждый момент времени заниматься правильными вещами. Если вы объедините правильные идеи с надежным и в то же время гибким процессом разработки ПО, вы сможете достичь действительно высокой скорости работы.
Наш цикл выпуска релизов постоянно развивается, но прямо сейчас он занимает 5 недель: 4 недели на разработку новых функций и 1 неделя «замораживания» и оценки качества. Мы ограничиваем время разработчиков, чтобы избежать соблазна создания монолитных решений, которые могут привести к серьезным проблемам в работе MailChimp. В сравнении с решениями, которые разрабатываются по полгода-год, наши 4-хнедельные проекты гораздо меньше по объему, и тестировать их намного легче. Кроме того, из-за ограничения по времени мы предпочитаем работать с более управляемыми и менее «визионерскими» задачами. Но так было не всегда.
Старый подход: планирование «по случаю»
Когда я только начал руководить релизами в отделе разработки MailChimp, обновления обычно проектировались и разрабатывались в рамках одного цикла выпуска релиза. В то время один цикл занимал 4 недели вместо 5 — это значило, что у нас была всего неделя на создание дизайна, который мы могли бы отправить UX-проектировщикам и разработчикам. Когда дизайн и разработка ведутся в рамках одного цикла, становится сложно подготовиться к этому морально: детали оказываются упущены, объем и сроки возрастают по неизвестным причинам, все это делает работу более нервной. Кроме того, было довольно сложно отказаться от мысли сделать промежуточные релизы, поскольку нам приходилось возвращаться к проектированию снова и снова.
Новый способ: мы знаем, что будет дальше
Вещи несколько изменились с тех ранних дней планирования релизов. Одной из наших последних целей стало улучшение понимания наших последующих шагов. Теперь мы стремимся «развести» процессы разработки и проектирования. Программисты и CEO чувствуют себя гораздо комфортнее, зная, что берутся за разработку важной функции только после того, как ее тщательно изучили UX-проектировщики, дизайнеры и разработчики — такой подход позволяет нам найти как можно больше недостатков в первоначальной задумке и исправить их.
Крупные задачи теперь проектируются с привлечением разработчиков, с самого старта цикла предоставляющих дизайнерам ценные инсайты. Вовлечение их в процесс проектирования на самых ранних этапах означает, что мы с меньшей вероятностью потратим впустую энергию на обдумывание идей, которые просто не удастся реализовать. Выяснилось, что у нас есть несколько потрясающих программистов, которые оказываются не менее полезными, чем UX-проектировщики, когда речь заходит о генерации идей, обсуждении хода работы и функций продукта (я сам не сразу это понял!).
Правильная постановка целей
Быстрое движение вперед означает, что каждое ваше усилие по реализации той или иной задачи должно вносить вклад в работу. Нам приходится тщательно оценивать то, за что мы беремся, поскольку отказ от идеи стоит нам много времени. Единственный способ быстро прийти к соглашению относительно того, что разрабатывать — поговорить с теми, кто лучше всех может помочь нам ответить на этот вопрос. Обычно нас волнуют следующие вещи: «Возможно ли реализовать эту идею?», «Правильно ли заниматься этим именно сейчас?», и самый главный вопрос: «Стоит ли вообще этим заниматься?»
Чтобы выпустить релиз, я собираю главного инженера MailChimp Эрика Мюнца (Erick Muntz) и нашего CEO, Бена Честната (Ben Chestnut), чтобы обсудить возможные функции и улучшения, за которые мы сможем взяться. Иногда идеи приходят из исследований и проектов UX-команды, иногда в их основе лежат находки программистов, иногда новые идеи подкидывает сам Бен, который часто общается с клиентами. Мы втроем продумываем высокоуровневый функционал и пытаемся оценить объем работ относительно выбранного направления. Мы пытаемся ответить на одни и те же вопросы, обсуждая каждую новую большую идею.
Ключ в том, что пускай это и высокоуровневые идеи, но они основаны на тех вещах, которые мы уже обдумывали какое-то время. Например, мы решили добавить возможность комментирования и совместной работы в MailChimp через много месяцев после запуска приложения, которое мы называли OnStage, и которое дублировало часть интересующего нас функционала. Мы разобрались в том, что в OnStage работало хорошо, а что — не очень, использовали эти идеи и включили их в план по улучшению MailChimp. Как только мы решили воплотить его в жизнь, мы сразу смогли сформулировать, что мы хотим сделать — это позволило нам сфокусировать усилия и быстро выпустить важное обновление, которое, как мы знали, точно будет работать.
Если мы повернули не туда
Иногда, конечно, то, что мы разрабатываем, не доходит до финального релиза. Если мы понимаем, что «повернули не туда», мы принимаем решение прекратить работу как можно раньше, так, чтобы иметь возможность быстро перебросить ресурсы на решение других задач. Обычно, если мы прекращаем заниматься задачей, над которой уже начали работу, причиной происходящего является нехватка времени, а не неверный выбор направления. Когда бы мы ни решили прекратить разработку, мы добавляем то, что сделали, в «корзину запчастей», к другим проектам, которые мы в любой момент можем возродить к жизни.
Итак, давайте что-нибудь сделаем
Ниже представлен более детальный обзор того, что значит работать в рамках пятинедельного цикла разработки. Для меня этот процесс сродни написанию курсовых в университете: в начале мне кажется, что у меня куча времени; потом я начинаю осознавать, сколько же мне придется сделать и в последнюю ночь перед дедлайном изо всех сил пытаюсь написать хорошую работу.
1 неделя: выпуск и планирование
Мы провели последние пару дней за развертыванием кода с последнего релиза. Мы постоянно общаемся с командой поддержки, проверяем Twitter и почту, чтобы как можно скорее узнать фидбек и быстро среагировать в ответ. Мы наверняка упустили пару багов, которые надо исправить в первые пару дней после релиза. Мы общаемся и пытаемся определить, что делать в ходе следующего цикла и проводим на этой неделе наше собрание, посвященное последнему релизу.
2 неделя: больше планирования и немного разработки
У нас, как правило, есть пара задач с предыдущего цикла, которыми можно сразу же заняться пока мы решаем вопросы, связанные с деталями дизайна крупных проектов, над которыми мы будем работать в последующих циклах релизов. Иногда, если мы заканчиваем работать над дизайном, мы принимаемся за новые задачи.
3 неделя: делаем вид, что что-то разрабатываем
Вот тут вещи начинают обретать форму. В этот период мы много общаемся и пытаемся очертить детали внедрения нового функционала.
4 неделя: действительно разрабатываем
Мы приближаемся к дедлайну. Самое время начать разработку.
5 неделя: заморозка! И снова планирование
Мы каждый раз хотим полностью «заморозить» разработку в последнюю неделю до релиза, но наша команда по оценке качества работает настолько здорово и находит так много багов и ошибок, что только на этой неделе наша работа наконец-то приобретает законченный вид.
Я слышал истории о компаниях, которые заставляют целые команды заниматься разработкой только затем, чтобы свернуть проект в последнюю минуту. Прекратить работу целой команды — пожалуй, самая деморализующая вещь, которую можно сделать с людьми, занимающимися программированием, не говоря уже о том, что это совершенно непродуктивно. Мы делаем все возможное, чтобы тщательно выполнять то, на что мы подписываемся. Мы уважаем время и энергию, которую наши команды вкладывают в то, что делают — но, кроме того, нам нравится это волнующее чувство скорости.
