Процесс создания Твиттер Видео

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

Я крайне горд тем качеством исполнения, которого нам удалось достичь. Это результат тесного сотрудничества отдела дизайна с менеджментом продукта и разработчиками, в особенности с коллегами из удаленных офисов (например, офиса в Сиэтле). Отдельная благодарность моим коллегами — продакт-менеджеру Джой Динг и программисту Джефу Куриэру.

И обязательно прочитите рецензию журанала WIRED.

«Живой прототип — отличное средство для коммуникации».

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

Вы, возможно, знакомы с моей статьей Provide Meaning With Motion о том, насколько важно дизайнеру интерфейсов понимать моушн-дизайн и интерактивное прототипирование. Тогда я только начинал использовать Framer.js и Framer Studio и не подозревал, насколько решающую роль это сыграет в будущем.

Однако JavaScript-прототипами дело не ограничилось. Ниже я расскажу, как сотрудничал с нашими iOS-прототайперами и проводил эксперименты в нативном коде под iOS.

Что такое Твиттер Видео

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

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

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

Впечатляет, что весь функционал поместился на одном экране. Еще больше впечатляет, что все действия выполняются только двумя кнопками: „Записать“ и „Отправить“

—WIRED

В самом начале пришлось переписать функционал видеокамер с нуля. Нативные камеры iOS и Android просто не позволили бы нам реализовать многие вещи. После этого оставалось еще два вызова: доработать текущий режим фотосъемки и добавить в него режим видеосъемки. Мой коллега Уэйн Фэн занялся фоторежимом, а я начал думать о видео.

За все время мы перебрали кучу набросков, внесли множество правок в макеты и прототипы — я покажу только основные направления. После того, как выяснилось, в чем суть проблемы и какими могут быть ее решения, я начал набрасывать самые разные варианты, какие только приходили мне в голову, и самые перспективные отбирал для проверки прототипом. Дизайн-команда Google Ventures называет этот подход «Вникнуть, нагенерировать, отсеять, запрототипировать и проверить» (Understand, Diverge, Decide, Prototype and Validate).

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

Все мои прототипы выглядели очень реалистично: они поддерживали жесты, скролинг, запоминали все состояния и т. д. Единственное, что я не стал делать — это подключать камеру (несмотря на то, что JavaScript это позволяет), я просто использовал заготовленные заранее фотки и видео.

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

Для кого мы прототипируем? В первую очередь для самих себя — чтобы пощупать вещь руками, проверить идею в действии. А также прототипы делаются для людей, принимающих решение. Самые первые варианты я чаще всего показывал моему руководителю Брендану Донохью, чтобы послушать его рассуждения; еще я носил их на дизайн-критику и, конечно же, отправлял в виде скринкаста самой команде Твиттер Видео.

Один прототип равноценен тысяче встреч в переговорках.

Почему я выбрал Framer в качестве инструмента: благодаря моему бэкграунду во фронтенде, я чувствую себя комфортно с JavaScript. А мне не хотелось столкнуться с ограничениями какого-нибудь инструмента в самый разгар работы над проектом — все-таки HTML/CSS/JS позволяют сделать практически все, что угодно.

Итерация #1

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

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

Мой самый ранний вариант дизайна получился двухстраничным: на одном экране я расположил запись видео, а на другом — предпросмотр и редактирование его фрагментов. При первом приблежении казалось логичным разбить все функции на две группы по типу задач. Для включения записи нужно было нажать и держать кнопку с камерой, во время съемки появлялся голубой прогресс-бар. Для фрагментов дольше 5  секунд я решил использовать мини-раскадровки. Благодаря им длинные видео легко распознавались при беглом взгляде, без вчитывания в пометки с длительностью фрагментов.

Замечания

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

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

С продактом (PM) и инжиниринг-менеджером (EM) мы пришли к единому мнению на счет бесполезности второго экрана. Он смахивает на функционал для продвинутых пользователей, ведь скорее всего самым частым кейсом будет «быстро записать однофрагментное видео и сразу же его запостить».

Правки

Свой следующий прототип я посвятил проблеме удаления видео-фрагментов: крестик я заменил на удаление перетаскиванием. Превью фрагментов я перенес со второго экрана на первый и добавил кнопку для перехода в режим редактирования. Таким образом фокус смещался с редактирования сложных видео на записывание коротких.

Замечания

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

Правки

Я сделал еще один вариант удаления, в котором корзина появлялась при наведении превью на большое видео. Чтобы проявить «зону удаления», фон становился красным. Кроме того, я начал вводить NUX-подсказки (New User Experience), рассказывающие о возможностях упорядочивать фрагменты и удалять их перетаскиванием. На этот раз у меня уже был iOS-прототип.

Итерация #2

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

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

Замечания

У нас появилось что-то осязаемое, и нужно хорошенько им попользоваться. Мы презентуем наш результат нашему гендиректору Дику Костоло.

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

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

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

Правки

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

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

В процессе дизайна и разработки этой фичи мы постоянно говорили о главной миссии — помочь людям запечатлеть момент. Например, был такой разговор: «А что если событие, которым ты хочешь поделиться, длится дольше 30 секунд?» Мы рассматривали идеи, позволяющие снять лимиты по времени. Например, снимать можно сколько угодно, но опубликовать из всех снятых видео можно только 30 секунд.

Ближе к финалу все усложнилось и обросло фичами. Если сравнивать с нашими аналогами, то 30 секунд — это приличный отрезок времени, мы просто слишком увлеклись. Упрощаем.

Замечания

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

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

Мы прокрутили эту идею в голове. Главное опасение тогда было связано с маленькими превью уже записанных видео, которые могли захламить экран с видоискателем и отвлечь человека от его главного намерения — записи нового видео. Если люди начнуть тратить время на ковыряние в контролах проигрывания и редактирования, позже это выльется в низкую конверсию дошедших до публикации видео-твитов.

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

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

Правки

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

Благодаря им любое сегодняшнее «а что если…» становилось на следующий день работающим iOS-прототипом. Я мог прийтий к ним с сырой идеей, и они сами доводили ее до ума и быстро создавали по несколько вариантов одного решения.

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

На следующий день я крутился возле стола Ави и заметил, что он продвинулся еще на шаг вперед: выбранному фрагменту он добавлял зацикленное проигрывание.

iOS-прототип

Этот слегка глючный прототип (голубые прогресс-бары поверх видео работают некорректно) — впечатляющее исполненние моей идеи.

От прототипов к нативным билдам

Я очень быстро заметил, что есть значительное несоответствие между прототипом во Framer и его реализацией в билде. Анимации и спринги Framer не совпадают с теми, что мы обычно используем в наших iOS и Android-приложениях. Поэтому, закончив калибровать упругости, скорости и ускорения анимаций во Framer, я не смог передать их сразу в разработку. Мне пришлось самостоятельно искать им эквиваленты в iOS и Android отдельно.

К счастью, Ави и Дэйв просвятили меня по параметрам анимации в iOS, и в частности по их собственному фреймворку. Подробнее об этом будет ниже.

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

Итерация #3

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

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

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

• Таймер следует разместить на экране с учетом маленьких устройств, вроде iPhone 4.
• Нужно продумать все детали интерфейса предпросмотра записанных видеофрагментов.
• Нужно визуализировать состояние, когда запись уже начата, но камера еще не включилась. Это особенно актуально для Android.

Framer Studio

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

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

Юзабилити-тестирование

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

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

Но есть загвоздка. У нас нету даже подобия видеозаписи на текущий момент. .

Подключаем снова команду iOS-прототипирования. Ави и Дэвид полностью сэмитировали приложение. Люди даже не заметили разницы. Я отправил им нарезку и текущие макеты, а затем мы объяснили Дэйву, как все работает.

Дэйв Дирман распросил каждого респондента о его увлечениях, о нем самом; какими сервисами он уже пользуется, чтобы делиться видео-контентом; в каких ситуациях у него возникает необходимость опубликовать что-либо через Твиттер. Он с легкостью мог разговорить человека, а чтобы получить откровенный фидбек, он часто говорил: «Не бойтесь меня обидитеть — это приложение делал не я».

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

Наблюдение за юзабилити-сессиями открыто для всех, и особенно для того, кто делал дизайн. В это время я находился в нашем офисе в Сиэтле и наблюдал тестирование в Сан-Франциско через трансляцию, делал пометки и записывал интересные цитаты.

• Когда было записано несколько фрагментов, Дэйв спросил, что произойдет, если нажать на одну из миниатюр. Несколько человек ответили, что так мы выбираем тот фрагмент, который в итоге попадет в твит. В дизайне же подразумевалось, что в твит попадут все записанные фрагменты в виде одной композиции.
• После записи длинного видео люди пытались его обрезать или укоротить. Когда выяснялось, что такой функции нету вообще, они расстраивались.
• Все разобрались с включением камеры и переходом в режим видеозаписи; поняли, как работает интерфейс с удержанием кнопки для записи (помогли подсказки, которые возникали только в том случае, когда человек вместо долгого нажатия просто кликал); и все поняли, что если таймер краснеет, то приближается лимит.
• На вопрос, какое ограничение видео по времени было бы комфортным, несколько человек ответили, что 30 секунд вполне достаточно.
• В прототипе не работало удаление фрагментов, но на вопрос, каким оно могло бы быть, многие ответили, что пробовали бы перетащить миниатюру за пределы панельки с фрагментами. Один человек провел параллель с интерфейсом переключения между приложениями в iOS, где можно закрывать приложения свайпом.

Правки

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

Я вынес прогресс в отдельную область, и решил показывать его в контексте всей композиции. Например, если у вас 4 фрагмента одинаковой длины и вы только что нажали на второй, то прогресс равен 25%. Ави и Дэйв также предложили сделать тонкие риски на голубой линии, чтобы разбить общий прогресс на соответствующие фрагментам части.

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

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

Мелочи совсем не мелочи. Из них строится дизайн

—Чарльз Имз

Я был доволен выбранным направлением, и следующие юзабилити-сессии не выявили особых проблем.

Мы с Джефом и Джой начали оценку реализации — прошлись по всем деталям дизайна и прикинули, сколько на что уйдет времени; затем ознакомили Дика и руководство с актуальным дизайном и графиком работ, выслушали их мысли. Их все устраивало, и мы дали ход этому направлению.

Благодаря процессу с итеративным циклом «дизайн—прототипирование—тестирование» и вовлеченности каждого члена команды, нам удалось выйти за рамки того, что мы могли бы выпускать в качестве первой версии — какой-нибудь MVP (минимальный реализуемый продукт). Конечно, если нам в Твиттере что-то нужно срочно, мы можем обрубить объем функционала, но никогда не жертвуем качеством в угоду дедлайнам.

Во время разработки последней версии с одностраничным интерфейсом мы стали регулярно тестировать ее на разных девайсах. Я сразу обратил внимание, что неправильно использовать один и тот же размер миниатюр для всех экранов. Приемлимый для iPhone 4 размер выглядел абсурдно на iPhone 6+. Я тут же решил ввести три градации размеров в зависимости от величины экрана (50 dp, 70 dp и 90 dp).

Тесное сотрудничество с разработкой

У меня уже давно не вызывают интереса дизайнерские споры о том, как правильно делать спецификации для разработчиков и передавать их. Наличие «спек» в вашем процессе свидетельствует о том, что настоящее общение с разработчиками отсутствует. Несмотря на технический бэкграунд, мои навыки даже рядом не стоят с навыками разработчиков из Твиттера, поэтому я не упускаю ни единой возможности поработать с ними бок-о-бок, чтобы побольше узнать о код-базе наших iOS- и Android-приложений; о том, какими средставами они обычно располагают и о том, что в принципе реализуемо, а что нет.

Мне достаточно спросить простую вещь, типа: «Как вы будете реализовывать ease-in или ease-out?» или «Можно ли задать изменение этого параметра в виде квадратичной функции?» Затем я ухожу и играюсь с этими параметрами сам, пока не добьюсь нужного результата. Это гораздо лучше, чем нагружать разработчика ненужной работой, заставляя присылать тебе на пробу билды со всеми возможными параметрами; особенно если вы работаете в разных офисах, как у нас.

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

Я стараюсь быть максимально конкретным, когда описываю анимации в JIRA. Например, когда мы делали Android, выяснилась что там у нас нету такого фреймворка с настраиваемыми анимациями, как для iOS. Но Гордон Люк показал мне стандартные андроидовские «интерполяторы», вроде OvershootInterpolator, и я сделал описание на его основе.

Фреймворк для iOS, который делают Ави и Дэйв, позволяет настраивать анимацию на лету без перекомпиляции. Я скопировал себе код, скомпилировал у себя на компе и игрался прямо внутри приложения с параметрами, которые назывались Magnification, NaturalFrequency и DampingRatio. Когда удалось добиться нужного баунс-эффекта, я закоммитил доработки в iOS-репозиторий.

В код-базе iOS и Android я нашел немало вещей, которые можно было поправить.. Начиная от доработки анимации прозрачности в блоке UIView animateWithDuration и заканчивая ночными посиделками бок-о-бок с Йоши, который отрефакторил для меня код, и я самостоятельно смог поправить размер красной точки для разных iOS-устройств (по тому же принципу, что и размеры миниатюр).

Reason 8384 I love having @Stammy as a designer: Cut his polish bugs in triage & he'll learn Android dev to fix them pic.twitter.com/acNJuup4Lv

— joy_ding.app (@joyding) January 16, 2015

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

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

Свежие билды приходили от разных разработчиков: Крис показывал финальную версию анимации увеличения объектов, Пабло только начал работать над временными метками поверх миниатюр.

Сырая версия

Один из важнейших в проекте этапов настал, когда мы открыли доступ к Твиттер Видео внутри компании. Когда ты просишь тысячу людей попробовать фичу, вылазят баги… в том числе и абсолютно неожиданные баги. Вроде таких: «Я переключился раз 20 между фото- и видеорежимом, и экран стал черным», либо таких: «Приложение вылетело, когда я одним пальцем нажал на запись, а другим — перетаскивал записанный до этого видеофрагмет».

Когда запуск был уже совсем близко, мы с Джой и Джефом ежедневно собирались, чтобы обсудить и приоритезировать новые баги.

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

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

Эпилог

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

Twitter video, huh? I like it! pic.twitter.com/k8kKoMeE8a

— Adam Shapiro (@adamshapiro) January 30, 2015