4 правила хороших видео

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

Когда хочется продемонстрировать баг, нужно показать результат работы по задаче, показать как работает интерфейс — лучше говорить, чем писать. Чтобы передать мысль быстро, а не ждать назначенной встречи, мы прибегаем к «лумам» — коротким видео, записанным при помощи https://useloom.com.

Чтобы лум сэкономил время тебе и коллегам — соблюдай простые правила:

— Не молчи. Хороший лум — это не урок из скучного курса, а живой рассказ живого человека. Когда ты молча возишь мышкой по экрану — это понятно только тебе.
— Включи камеру. С живым человеком гораздо приятнее общаться, чем с его экраном. И пофиг, что на фоне любимая рюмочная — живое общение всё компенсирует.
— Не тяни время. Если твое видео можно уместить в минуту — не записывай пятиминутный сериал. Цени время коллег.
— У готового видео обязательно укажи заголовок. Когда твоя проблема называется «HTTP://LOCALHOST:3000», её не очень хочется решать. Клёво — когда тема понятна сразу: «Не отправляется заказ с дробной ценой», «тормозит загрузка картинок» и т.д.

Часть вторая. Розыгрыш брифов!

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

В этот раз брифы были зашифрованы текстами песен. То есть по 1-2 строчки ты должен был догадаться о чем идет речь.

Итак, начинаем. Я хаотично пытаюсь прикинуть, какие темы могут быть и какая область для меня была бы наиболее интересна, но не успеваю закончить мысль как появляется первый слайд..

Первый слайд — «Все на свете из пластмассы и вокруг пластмассовая жизнь…»
В голове быстро проносится анализ: так, это либо экология, либо производство чего нибудь. Быстро решаю, что это не интересно, тем временем нужное количество человек уже подняли руки, идем дальше.

Второй слайд — «I really need you really love you, И как бы далеко бы я ни был от тебя…»
Что то про близкие отношения, думаю я, либо сервис знакомств, либо поиск кого то. Точно нет. В аудитории тоже происходит заминка. Серей Гальцев решает дать подсказку сомневающимся и говорит, что тема очень душевная. В итоге появляется нужное количество рук.

Третий слайд — «Перемен, требуют наши сердца! перемен, требуют наши глаза».
Опа, звучит круто, решаю поднять руку, но так же решает добрая половина аудитории, в итоге я был даже не четвертым, строчки явно пришлись многим по душе, так что я в пролете. Идем дальше.

Четвертый слайд — «Я раньше и не думал, что у нас на двоих с тобой одно лишь дыхание…».
Так, звучит подозрительно, дыхание, опять близость? нет не буду рисковать. В итоге команда формируется без меня.

Пятый слайд — «А у нас алкоголь дешевле, чем учебник — Так что, если ты ноешь, ты обсос, как Чендлер.»
Так, тут явно замешано образование, образовательными проектами я в той или иной мере занимался в университете, так что тоже пропускаю.

Шестой слайд — «Город-сказка, город-мечта».
Я смело поднимаю руку. Не особо следил за порядком, поэтому даже не заметил, что это последний слайд, просто понял, что мне это интересно. Урбанистика, город, в этом направление сейчас много чего происходит, должно интересно. Таким образом моя и ещё 3 руки сформировали последнюю команду.
Далее, нам показали те же самые слайды, но с брифом от заказчиков. Это было небольшое видеообращение с описанием проблемы.

1. «Все на свете из пластмассы и вокруг пластмассовая жизнь»
Фонд WWF заказал сервис, который поможет людям более осознанно подойти к проблеме загрязнения пластиком.

2. «I really need you really love you, И как бы далеко бы я ни был от тебя»
Фонд Добрая планета, попросил помочь им с организацией помощи волонтерам по работе с детьми-сиротами.

3. «Перемен, требуют наши сердца»
Фонд Борьбы с Коррупцией — это было довольно неожиданно, бриф читал начальник штаба — Леонид Волков. Он рассуждал о предстоящих выборах и о сложности наблюдений за их честностью. Его просьба была в том, чтобы придумать сервис, который облегчил бы жизнь наблюдателей. Все были немного в шоке, и я в том числе.

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

5. «А у нас алкоголь дешевле, чем учебник», Фонд поддержки образования и науки «Рекурсия» попросил помочь в проекте по менторству студентов.

6. И, наконец, «Город-сказка, город-мечта», где заказчик, в виде Студии транспортного проектирования, просил помочь в организации сбора данных на местности. И так как это моя тема, я остановлюсь на ней чуть подробнее.

Михаил Греков написал, как сделать удобнее таблицы, с помощью которых пользователи управляют данными (CRM, ERP и прочие системы).

Михаил Греков написал, как сделать удобнее таблицы, с помощью которых пользователи управляют данными (CRM, ERP и прочие системы).

Михаил Греков написал, как сделать удобнее таблицы, с помощью которых пользователи управляют данными (CRM, ERP и прочие системы).

В первой статье разбирается просмотр данных.

1. Рабочая таблица должна занимать максимум места на экране. Как вариант — опция «на весь экран».
2. Объединяйте данные. Если есть данные о фамилии, имени и отчестве, их целесообразно вывести в один столбец ФИО. Должность или роль в системе тоже можно присоединить к ФИО.
3. Бесконечная прокрутка и кнопка «Показать ещё» не подходят для отображения строк таблицы. Делайте постраничную навигацию. Это удобно и для коллективной работы с таблицей.
4. Показывайте по умолчанию больше строк на одной странице: 50, 100, 500.
5. Используйте цветовые индикаторы. Красить строку целиком стоит только при отклонении от нормы.
6. При наличии цветовых индикаторов полезно отображать легенду цветов.
7. Храните пользовательские настройки вида, не сбрасывайте их после окончания сеанса.
8. Связанные сущности (название организации может быть связано с карточкой организации) полезно делать ссылками на соответствующие карточки. Но если таких сущностей в строке много, выделите только полезные в работе.
9. Строка должна подсвечиваться при наведении курсора. Должна быть возможность выделить строку кликом на неё.
10. Нет ничего страшного при появлении горизонтальной прокрутки.
11. В некоторых случаях полезно маркировать просмотренные записи.
12. Должна быть настройка отображения столбцов с системными свойствами (ID, дата создания, автор, дата изменения).
13. Переход к просмотру записи удобно сделать по двойному клику.
14. Иногда удобен режим предпросмотра, когда по клику открывается не вся запись, а сводка по ней, как в Google Drive.

«Строка в таблице часто является прелюдией к просмотру полной информации по записи. На моей практике в 99% рабочих таблиц модальный режим просмотра уступал просмотру записи на отдельной странице».

Как генерировать идеи для продукта

Внешние источники:

1. Тренды в вашей индустрии: что происходит на рынке
2. Что делают конкуренты
3. Какие фичи просят пользователи конкурентов
4. Что делают похожие бизнесы на других рынках (например, Amazon vs InstaMart in India)
5. Что обсуждают на конференциях/форумах/спец ресурсах в вашей индустрии
6. Какие фичи просят ваши пользователи

Внутренние источники

7. Что пользователи делают в продукте (или не могут сделать); как выглядит user journey
8. Что говорят пользователи, которые перестали пользоваться продуктом
9. Что говорят другие отделы, которые общаются с пользователями (саппорт, сейлзы, маркетинг)
10. Что говорит руководство компании/топ менеджеры/лидеры
11. Что делают другие команды в вашей компании, есть ли возможность для коллаборации или заимствования
12. Догфудинг (интенсивное использование продукта самой командой)
13. Небольшие сфокусированные дискуссии с командой
14. Работа в "обратную сторону" от видения: если вы хотите достичь X, какие проблемы должны быть решены

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

Идеальный процесс

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

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

Женя Бондарев рассказал нам о типичной структуре разработки цифрового продукта:

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

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

Usability test
Тестирование всего продукта и финальные изменения — Женя советует писать гипотезы в гугл-доке на протяжении всего исследования, чтобы во время тестирования не упустить что-то важное.
По итогу тестирования выявляются критичные и не очень ошибки, после чего нужно решить, с чем можно выходить на рынок, а что требует обязательной доработки. На этом шаге может всплыть много неожиданностей, на эту тему как-то писал Костя Горский — t.me/desprod/239

Финализация
Финальное утверждение, подготовка к разработке, подготовка к публикации (кейс в медиа, либо конкурс и т.д.), авторский надзор.
Круто выпускать MVP как можно раньше, чтобы начать получать реальный фидбэк.

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

1. Погружение

1. Связаться с заказчиком
Сделать:
- интервью с заказчиком
- запросить метрики
Итог:
- утвержденное направление работу
- утвержденные с заказчиком сроки
Срок: 4.03

2. Поиск референсов/конкурентов
Срок: 04.03

3. Интервью с пользователями
Сделать:
-подготовить вопросы
-найти респондентов
На выходе:
- уточненный портрет
- проблемы пользователей
Срок: 13.03

4. Попробовать
Сделать:
- Сделать заказ (понять процесс, опросить мастера)
- Зарегаться как мастер (понят, процесс, взять заказ)
На выходе:
- проблемы
- полное понимание бизнес-процесса
Срок: 11.03

Анализ полученных инсайтов
Артефакты: понять на каких проблемах фокусируемся, список инсайтов, фичерлист
Показываем заказчику — 12.03
— Ретро —


2. UX — проектирование

1. Информационная архитектура — 20.03
2. Структура — 20.03
3. Карта экранов — 31.03
4. Сценарии
5. Прототип
6. Тестирование прототипа (проверка гипотез) - 7.04

Анализ полученных решений
Артефакты: протестированный прототип, карта экранов, структура, информационная архитектура
Показываем заказчику — 9.04

— Ретро —


3. UI — визуальный язык

1. Существующие гайды продукта
2. Мудборд
3. Дизайн концепт 3-5 экранов — 14.04
4. Масштабирование
5. Анимация

Анализ полученных решений
Артефакты: финальный дизайн продукта, анимация
Показываем заказчику — 30.04

— Ретро —


4. Передача в разработку
5 занятий 10.05-19.05

5. Подготовка портфолио
9 занятий 22.05-09.06

6. Презентация
3 занятия

7. Защита
23 июня


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

Как дизайнеры рэп читали

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

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

После Мемус-батла Саша посвятил всех в таинство ретроспективы, объяснив суть и важность этого мероприятия.

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

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

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

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

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