На пути к простоте: как сложно она дается разработчикам
Удивительно, но сделать продукт простым для пользователя очень сложно. Мы поняли это на собственном опыте, когда столкнулись с вопросами, на которые не нашли однозначного ответа:
• что важнее, простота или функциональность?
• до какой степени нужно и можно упрощать продукт?
• и на кого ориентироваться в конечном счете при внесении изменений?
Простота — это сложно
Конечно, нам всегда было ясно, что продукт надо делать простым для пользователя. Это подтверждается и здравым смыслом, и опытом успешных компаний из самых разных областей.
Посмотрите, например, на Dropbox. Однажды гендиректор Macroscop Артем Разумков пообщался с одним из создателей этого сервиса. Тот рассказал, что идея хранения файлов в облаке была известна давно, и для этого надо было нажать на кнопку только 1 раз — загрузить файл. То, что придумали они — это просто переход от одного нажатию к нулю нажатий: человек просто помещает файл в обычную папку, и он загружается в облако автоматически. Кнопку «загрузить» вообще не надо нажимать! Эта простая идея перехода от 1 нажатия к 0 нажатий позволила им взлететь до невероятных высот. Вот она сила простоты!
Или Uber. Почему он стал так популярен? Потому что он предельно прост для пользователя: не надо звонить и сообщать оператору, где ты и куда поедешь, отсчитывать наличные для таксиста и мучиться с разменом. Ты нажимаешь ровно на одну кнопку, и к тебе приезжает машина. Что может быть проще и удобнее?!
Но почему тогда не все продукты подобны Uber? Дело в том, что сделать просто очень сложно. Некоторые думают, что простота — это просто для всех, но на самом деле простота — это просто для пользователей, но она очень тяжело дается разработчикам.
Например, Google. Google для пользователя — это одна поисковая строка, это очень просто. Но над тем, чтобы, введя в этой строке поисковой запрос, пользователь получил то, что нужно, работают тысячи инженеров, разработчиков, исследователей. Можно было бы вставить много разных настроек и фильтров, которые пользователь должен был бы покрутить, чтобы поиск выдал ему то, что нужно, но инженеры Google взяли это на себя. И для того, чтобы у пользователя было все так просто, они реализовали чрезвычайно сложные технологии, которые понимают и догадываются, какие настройки поиска подразумеваются.
Как мы упрощаем продукт
Сделать просто — сложно. Разработать просто сразу — практически невозможно. Поэтому путь к простому для пользователя продукту чаще всего идет через упрощение чего-то сложного, а не создание с нуля чего-то сразу простого и удобного.
И для создания нового, и для упрощения существующего у нас один рецепт — делать все исключительно в связке с пользовательским опытом!
В одном из предыдущих постов мы рассказывали о том, как создали новый модуль видеоаналитики — функцию межкамерного трекинга. Она позволяет отслеживать траекторию перемещения человека по нескольким камерам видеосистемы. Изначально, когда появилась идея создать межкамерный трекинг, мы не думали о его удобстве для пользователей. Мы хотели ВЫПУСТИТЬ ФУНКЦИЮ, как хотят многие разработчики. И на начальном этапе межкамерный трекинг был одним из фильтров поиска.
Изначально межкамерный трекинг был одним из фильтров поиска Macroscop
В Macroscop был поиск по размеру, поиск по приметам, поиск по месту в кадре и… межкамерный трекинг. Конечно, это было нелогично и неудобно для пользователя. Чтобы активировать межкамерный трекинг, необходимо было проделать какие-то невероятные манипуляции: сначала найти человека, траекторию которого будешь строить — для этого задать приметы, раскрасить образец, найти его в архиве; потом на одном из результатов активировать режим межкамерного трекинга; потом добавлять туда образцы по одному вручную. Это было долго, сложно и абсолютно не так, как надо было пользователю. А ему надо было «трекать»: увидеть объект на экране и построить траекторию тут же, прямо сейчас, а не рисовать приметы и раскрашивать человечков.
Когда мы поняли это и решили работать над удобством и простотой, мы сформулировали цель: 7 из 10 людей, которые ранее не пользовались функцией межкамерного трекинга и более того не являются профессиональными пользователями систем видеонаблюдения, а просто умеют работать на компьютере, должны без устных подсказок с нашей стороны решить задачу построения траектории. Мы прошли несколько итераций улучшения, после каждой из которых приглашали 10 разных пользователей, садили их за компьютер и просили решить эту задачу. И когда 7 из 10 «подопытных» самостоятельно построили траекторию, мы решили, что сделали межкамерный трекинг действительно удобным для пользователя.
В обновленном межкамерном трекинге можно начать «трекать», как только нужный человек появился в кадре
Сегодня общение с пользователями непосредственно внедрено в процесс разработки. Разработчики созваниваются и встречаются с теми, кто использует видеосистемы, и непосредственно проверяют на них то, что разработали. А прежде чем начать разрабатывать что-то новое, они должны пообщаться как минимум с 5-ю пользователями и понять детально, что именно и в каком виде им надо.
Такая разная простота
Как соблюсти баланс простоты и функциональности? Как не уйти в отрыв и не удалить что-то реально полезное и незаменимое? До какой степени можно упрощать? Для продуктов широкого потребления этой грани нет. Но надо понимать, что консьюмерские и профессиональные продукты — это разные вещи, и надо по-разному рассматривать подход к их разработке. Да, человеку, который хочет уехать на такси, здорово для этого просто нажать одну кнопку. Но человеку, который работает с профессиональной системой безопасности, нажимать одну кнопку как-то несерьезно.
Для бизнес-продуктов, таких как ПО для видеонаблюдения, вопрос упрощения диалектичен. Надо искать баланс простоты и функциональности. Эта диалектичность возникла и с нашим упрощенным межкамерным трекингом. Мы сделали простой интерфейс, который позволяет неподготовленным людям построить траекторию, и для этого включили в функцию специальные подсказки. А когда обновленный межкамерный трекинг попал в руки профессиональных пользователей систем безопасности, они сказали, что эти подсказки им совсем не нужны и даже мешают.
Возможно, мы совершили ошибку, приглашая для тестирования не профессионалов, а людей с улицы, ведь это узкоспециализированная функция видеоаналитики, которой будут пользоваться эксперты. С другой стороны, мы считаем, что межкамерный трекинг — это решение, которое принципиально сможет изменить работу с архивом для всех, а не только для профессионалов. Вот вам и противоречие: с одной стороны, сейчас мы четко понимаем, что межкамерным трекингом пользуются только профессионалы и делать надо для них, с другой стороны, мы верим, что эта функция сможет изменить подход к работе с архивом в целом для ВСЕХ ПОЛЬЗОВАТЕЛЕЙ.
Нет однозначного ответа на вопрос предела простоты, и нет единственно правильного рецепта, иначе все бы его применяли.
Как совместить несовместимое? Разделить!
Если упрощать надо, а отказываться от функциональности не хочется, можно разделить продукты.
Однажды наш ключевой партнер обратился с запросом на доработку ПО Macroscop для очень крупного, серьезного проекта. Нужно было реализовать чат для общения операторов видеосистемы. Когда мы стали делать эту функцию, поняли, что она очень специфична, и 99% пользователей не понадобится. Тогда мы в первый раз задумались о разделении программного обеспечения на два разных продукта, один из которых будет сконцентрирован на простоте и им будет пользоваться большинство наших пользователей, другой, специфический продукт, будет фокусироваться на функциональности и использоваться в сложных крупных видеосистемах.
Мы решили, что такое разделение может стать хорошим вариантом соблюдения баланса простоты и функциональности. Несколько месяцев назад мы выпустили продукт для масштабных видеосистем Macroscop Ultra и приняли решение удалить часть существующего функционала из «обычного» Macroscop.
Единственно верного решения нет
Вопрос простоты при разработке продукта остается для нас открытым. Единственно верного решения и однозначного ответа на противоречивые диалектичные вопросы «до какой степени упрощать?», «как при этом оставаться функциональным и полезным продуктом?», «на какую аудиторию ориентироваться при упрощении?» мы не нашли. Возможно, потому что их нет, и каждый разработчик принимает свое решение. Тем не менее сегодня мы видим несколько путей прихода к простоте:
1. Исключить все маловостребованные возможности продукта. При этом решение об удалении каждой функции надо принимать, основываясь на обратной связи от непосредственных пользователей.
2. Оставить весь функционал и при этом глобально поработать над интерфейсом, стремясь свести получение нужного пользователю результата к «нажатию одной кнопки». При этом надо понимать всю степень утопичности этой цели :)
3. Разделить продукт на несколько версий, ориентированных на решение разных задач и использование разными пользователями.
