.png)
Основная сложность в работе со стартапами в том, что стартап обычно рождается на основании одной идеи, которую в начале понимает только основатель. И даже если он сам хорошо понимает свою идею, не факт, что он может правильно передать и объяснить её остальным участникам разработки продукта.
Поэтому Garry Tan, соучредитель Posterous и Posthaven и бывший партнер Y Combinator, в лекции по дизайну для стартапов советует до инвестиций Series-A делать дизайн руками одного из сооснователей (посмотрите лекцию тут, если не смотрели). Даже если вы уже сейчас готовы возразить и сделать иначе, или у вас в команде нет сооснователя-дизайнера, или продукт просто невозможно сдизайнить усилиями одного человека, прочтите абзац ниже, чтобы понять насколько важен этот этап.
Смысл здесь вот в чем: когда вы только начинаете готовить к запуску свой стартап, вы концентрируетесь на чем-то одном, очень важном для вас. Вы делаете первую версию того как это видите вы, показываете продукт своим друзьям и потенциальным клиентам и получаете целый ворох замечаний, как это хотели бы видеть они на месте пользователей.
Большинство этих замечаний будут не о форме продукта, а о сути. Они не скажут вам “это плохой продукт, потому что синий цвет недостаточно синий, а логотип проекта недостаточно современный” (привет и прощай, корпоративный мир). Они скажут: “Ты знаешь, это не удобно” или “Я посмотрел, интересненько, молодец”, и вы будете понимать: их просто не зацепило.
Таким образом, как только вы сделали первую версию продукта, вы начинаете процесс поиска Product-Market Fit – соответствия продукта рыночной потребности. В это время вы будете много раз менять функциональность, позиционирование, и у вас должна быть возможность делать это просто, дешево и быстро. Именно поэтому лучше делать первый UX дизайн стартапа руками сооснователя проекта или того, кто вовлечен в проект так же сильно как и вы.
Поэтому UX-прототипирование стартапа обладает несколькими важными особенностями, которые отличают его от корпоративных проектов:
В корпоративных продуктах всё это тоже важно, но когда у вас уже есть запущенный бизнес, у вас больше права на ошибку, чем когда вы начинаете с нуля. Ведь у готового и работающего бизнеса уже есть поддержка лояльных пользователей и финансовые резервы, а у стартапа их пока нет.
В любом случае, вы должны двигаться по классическому UX-процессу, потому что этот процесс будет защищать вас от очевидных ошибок. Что же такое UX прототип и как происходит сам процес?
Базово процесс состоит из таких шагов:
Пройдя все эти шаги, вы получите описанные и зафиксированные цели, задачи, персоны, ценности, use cases проекта, которые пригодятся вам и для получения инвестиций и при запуске продукта в мир.
Визуальный прототип такого продукта можно делать средней детализации (подробнее об уровне детализации прототипов читайте тут). Это нужно ещё и для того, чтобы как можно раньше показать его потенциальным клиентам и пользователям продукта, не тратя время на бесконечные доработки. Подробнее о том, как сделать UX тестирования читайте тут.
А что, если вы всё спроектировали, нарисовали, а вам говорят “это неинтересно” или “это неудобно”? Важно понять, что это нормальный процесс. Если вы придумываете что-то новое для рынка, и у вас нет прямого аналога, с которого можно скопировать ценность и функционал, вы будете ошибаться. Вы должны быть готовы тестировать и рисовать снова и снова, пока не добьетесь реакции: “Всё понятно, выглядит удобно, хотел бы попробовать это в деле!”.
Хорошей практикой для стартапа, целью которого не является визуальная новизна, будет взять UI-kit под ваш любимый frontend-фреймворк (например такой, как Vuetify) и дальше делать всё на нём.
В любом случае делать мокапы быстрее, чем писать код, поэтому для прототипирования мы всё же используем и рекомендуем вам использовать инструменты прототипирования. А уже потом, по готовым и утвержденным mockups можно собрать прототип в коде. Здесь можно вывести следующее правило: “Если совсем непонятно, то лучше сделать прототип. Если похоже на то, что сделали раньше и уже есть рабочий код, проще поменять код”.
Если у вас достаточно опыта в UX, чтобы сразу сделать удобный фронтенд, вы вполне можете делать прототип сразу в коде, на основании мокапов. Многие вещи так получится сделать быстрее и проще, чем разрабатывать сначала высокодетализированный прототип, потом дизайн, а затем ещё и верстать.
Однако делайте это только в случае, если ваш уровень в разработке UX высокий. Иначе UI Kit развалится, а вы получите неудобный и сложный интерфейс, который потребует редизайна еще до запуска проекта. 
Частой проблемой в проектировании стартапов является то, что буквально каждый следующий клиент вносит новое понимание в то, что же вы делаете и как оно должно работать.
И вам крайне важно как можно раньше узнать, если клиенту что-то не понравилось, где-то возникло неудобство или проблемы. Для этого можно использовать инструменты аналитики для приложений (как Mixpanel), а также триггеры для отслеживания поведения (как Hotjar).
Данные должны быть просто интерпретируемые. На основании аналитики вы можете строить гипотезы, которые потом будете реализовывать сначала в прототипах, потом в интерфейсе. Результат которого вы должны добиться – улучшение показателей в цифрах. Старайтесь максимально деперсонализировать аналитику и её интерпретацию. Если с помощью интерфейса А заказать такси занимает 3 минуты и 16 кликов, а с помощью интерфейса Б – 30 секунд и 3 клика, интерфейс Б лучше. Независимо от того, что нравится лично вам.
Тогда лучше воспользоваться услугами профессионалов. Мы не знаем, что скажут вам в других компаниях, но мы придерживаемся мнения, которое выразили здесь. И точно будем привлекать вас к созданию прототипа на самых ранних этапах. Для нас крайне важно, чтобы конечный продукт отображал заложенную вами в него идею.
Если ваше мнение совпадает с нашим, обращайтесь к нам через любой удобный канал связи. С удовольствием поработаем над вашим проектом.
