Приемы проектирования сервисов (часть 4)

Мы продолжаем цикл статей о приемах проектирования интернет сервисов.

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

17329099

В первой части были освещены вопросы о том, что такое проектирование и зачем оно нужно.

Во второй части мы поговорили о целях проектирования и ролях участников команды в этом процессе.

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

 

Гипотеза о проблеме

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

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

Сервис НАЗВАНИЕ предоставляет ЦЕННОСТЬ ВАШЕГО ПРОДУКТА, чтобы помочь КОМУ КОНКРЕТНО решить КАКУЮ КОНКРЕТНО ПРОБЛЕМУ.

 

Пример

Предлагаю в качестве примера рассмотреть гипотезу о проблеме для приложения Яндекс Навигатор.

Сервис Яндекс Навигатор предлагает БЕСПЛАТНЫЙ НАВИГАТОР, КОТОРЫЙ СТРОИТ МАРШРУТЫ С УЧЕТОМ ПРОБОК, чтобы помочь ВОДИТЕЛЯМ ПОЛЬЗОВАТЕЛЯМ СМАРТФОНОВ @@ ДОБИРАТЬСЯ ДО НУЖНОЙ ТОЧКИ МАКСИМАЛЬНО БЫСТРО.

Фокус на том, для кого и зачем вы делаете ваш сервис, поможет вам не делать социальную сеть для владельцев животных 🙂

 

Сценарии использования

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

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

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

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

 

Схема сервиса

Гипотеза о проблеме совместно со сценариями использования (гипотезой о решении проблемы) даст вам схему вашего сервиса.

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

схема_использования

 

Работа со схемой сервиса далее должна вестись по следующему алгоритму:

  1. убрать все лишнее (или определить «ядро» вашего сервиса )
  2. хватит обманывать себя, см. пункт 1

 

Основной сценарий использования вашего сервиса

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

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

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

Это не означает, что дополнительные функции не имеют смысла. Имеют. Но они вторичны по отношению к ключевому сценарию использования.

Постоянно задавайте себе вопрос о том, что является основным в моем продукте? Не делаю ли я автомобиль без руля, но с навороченной аудио системой?  Если вдруг так, то тогда лучше займитесь разработкой аудио системы, а не автомобиля 🙂

 

Важное

В тексте статьи употреблялось слово «гипотеза». Это важное слово и еще важнее понимать, почему оно важное.

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

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

 

Запись опубликована в рубрике Аналитика, Дизайн / Проектирование интерфейсов, Менеджмент с метками , , , , , . Добавьте в закладки постоянную ссылку.