×

Поговорим?

Звоните: +7 (812) 640-49-21

Croice и Dokity

Что делать с интерфейсами стартапа

Менеджер

Заур Гиясов


Команда

двое проекти-
ровщиков

Начало

июнь 2013


Срок

2 месяца


Объём

13 эскизов


Темп

4 итерации


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

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

Летом 2013 года к нам пришли ребята из двух стартапов бизнес-инкубатора «Ингрия».

  • Croice — платформа для создания, трансляции и прослушивания интерактивных радиошоу и подкастов.
  • Dokity— облачный сервис для обмена информацией из баз данных.

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

Croice и Dokity пришли к «Собаке» с громким Help! С интерфейсами надо было что-то делать. Для начала — оценить плюсы и минусы ситуации.

Плюсы

Гибкость команды

Это свойство стартапа, да. Но ведь не каждая команда способна подстраиваться под реальность и менять свое представление о прекрасном.

Скорость реализации

Обе команды готовы работать в темпе. Не отвлекаясь на фейсбучек и не перекладывая друг на друга задачи. Взяли и сделали. И пошли дальше.

Минусы

Слабые команды

Ну а чего мы ждали? Значит, придется подтягивать хоть до какого-то уровня.

Неопределенность с бизнес-целями

Есть какая-то идея, есть какое-то видение, но бизнес-польза (это еще речь не пошла про монетизацию) пока очень расплывчата.

Наше дело — не бизнесу учить, а помогать налаживать взаимодействие с пользователями. Учитывая ограничения, мы предложили UX-сопровождение.

Для каждого проекта получилась такая вот разбивка.

01

Постановка задачи

Встречаемся и обсуждаем, что болит, как болит, что можем сделать. 1 час
02

Проектирование

Самый ответственный этап. Объём работ ограничен — времени хватает только на эскизы без детализации. 5 часов
03

Обсуждение

Это тоже работа, да ещё какая! 1 час
04

Правки

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

Итого: восемь часов на одну итерацию.

Процесс

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

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

Надо отдать должное ребятам из обоих стартапов. Они уверенно придерживались плана и соблюдали сроки. Работа шла ритмично и продуктивно.

Теперь чуть более подробно о задачах для каждого проекта.

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

Если первый проект носил скорее развлекательно-познавательный характер, то Dokity (напомним, что это сервис для обмена информацией из разных баз данных) был серьезен как никогда.

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

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

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

Результат

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

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

Смысл

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

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

У вас похожая задача? Пишите нам:

+7 (812) 640-49-21

 

sobaka@pavlova.cc

 

Fb.com/PavlovaPage

 

Skype: pavlova.cc

ВВЕРХ