Дизайнер маркетплейса что это
Создание маркетплейса: от идеи до готового дизайна
Всем привет! Я хочу поделится своим опытом, как я проектировал маркетплейс с нуля, когда клиент принес только идею и набросок функционала. Рассказываю о своём опыте, надеюсь вам будет полезно.
Перед стартом я сразу хочу сказать что аналитика не моя основная область деятельности, я все-таки UX UI дизайнер, поэтому я провел ее на том уровне компетенций которые у меня есть.
Пришёл клиент с идеей
Он хотел чтобы я спроектировал MVP маркетплейс в сфере медицинского туризма. Клиент сразу сказал что он плохо разбирается в IT, и будет рад если я возьму инициативу в проекте и доведу его до готового дизайна, который можно передать в разработку. Разработчики благо у него есть. Из вводных данных от клиента было сумбурное ТЗ с неполным описанием ролей и функционала. «Ну что ж» — подумал я, — «Будем доводить до ума».
Коротко, в чем суть маркетплейса
Например у вас тяжелое заболевание, которое не лечат в России. Вы думаете как бы решить проблему, попадаете на нашу платформу, и вводите в поиске свое заболевание. Вам открывается каталог с докторами, клиниками, и агенствами по всему миру, все они специализируется на вашей проблеме. Вы можете выбрать как напрямую доктора, клинику, так и агенство (чтобы получить услугу под ключ). Вы связываетесь с теми кто как вам кажется лучше всего справиться с вашей проблемой, и обсуждаете. С другой стороны есть независимые клиники, доктора, и агенства которые размещаются на платформе.
Погружение в сферу медицинского туризма
Я был не знаком с медицинским туризмом. Я не знал что это, и для чего. Поэтому первое я решил разобраться что из себя представляет медицинский туризм, зачем люди им пользуются.
Я решил далеко не ходить, составил список вопрос, позвонил клиенту, и спросил все что меня интересует.
Тезисно, что самое главное я вынес:
Естественно, дополнительно я почитал разные статьи и находил ответы там на интересующие меня вопросы, я хотел пропитаться всем этим, чтобы лучше понять пользователя и его проблемы, что им движет и почему.
Что по конкурентам
https://ru.bookimed.com/ — крупный конкурент, и успешный, который хорошо ложился под наш проект. Отличие его от нас, что это одна большая платформа-агенство которое предоставляет множество клиник / врачей, но координирует все процессы самостоятельно. У нас же это платформа-посредник где отдельно клиники, врачи, и агенства, и вы связываетесь с ними напрямую.
Кроме изучения сайта как дизайнер, потыкать кнопки и посмотреть как все работает, важно было пройтись как пользователь по сайту. Чтобы быть как реальный пользователь, я решил найти у себя реальную проблему с которой я бы мог обратиться в клинику. У меня плохо растут волосы, поэтому моей задачей стало найти клинику или доктора по пересадке волос. Я пошёл изучать сайт, чтобы решить свою проблему. Это позволило мне понять на практике что мне нравится, что вызывает вопросы, и что я не понимаю.
Пришло время составлять список страниц. Важно было не только написать страницы на листе, но и проверить пользовательские сценарии. Есть ли где-то места где может застрять пользователь. Есть ли упущенные звенья цепочки или наоборот лишние. Я подготовил карту путей, чтобы самому разобраться что к чему. Подумал над разной вариативностью движения пользователя на сайте. Так же я принял решение отказаться от форума (что предлагал клиент), решил что он не нужен для MVP. Эта карта создана не для клиента, она больше для меня и моей головы. Хотя сейчас она выглядит красивой и понятной, но изначально все было не так, я ее «задизайнил» для презентации.
Когда все страницы были готовы, важно прописать функционал каждой из них. То есть какие элементы включает в себя главная, каталог, и другие страницы.
Можно было бы и не писать функционал письменно, а сразу делать набросок, но я этого не хотел. Мне важно было разграничить работу на две части:
Это разные задачи — смешивая их можно упустить детали, потому что одновременно думаешь что нужно добавить и куда это разместить.
Функционал страниц формировался из всего что я изучил до, по проекту плюс пожелания клиента. Погрузившись в эту тему, я уже лучше мог представлять что для пользователя важно и нужно. Конечно если бы была проведена профессиональная аналитика, и была бы объективная обратная связь от ЦА, может все было бы по другому, но надеюсь что я ушел в правильное русло.
Следующий этап прототипирование. Про этот этап написано много статей. От себя лишь хочу сказать, что я проектирую сразу в фигме (или sketch), и все элементы заворачиваю сразу же в компоненты (символы), выстраивая удобную для себя структуру. Больше всего я не люблю рутину, и на стадии дизайна мне уже хочется заниматься не перерисовкой элементов, а их непосредственно дизайном.
В прототипе важно проработать удобство. Что и где находится, почему именно там, а не в другом месте. Сделать ли этот блок больше, чтобы сфокусировать фокус пользователя на нем. Удобные ли переключатели, или лучше сделать их по другому. Сделать в ряд одну или две карточки в каталоге, и почему. Прототип формируется так же из того, что ты изучил ранее, ты понимаешь что для пользователя главное а что второстепенное, и из этого выстраиваешь структуру.
В дизайне важно как будет воспринят интерфейс. У нас тематика медицинский туризм. На первый план выходит «медицина», ведь по сути люди едут лечить заболевания в другую страну. Ассоциация с медициной это синие оттенки, и много белого.
Для интерфейса я взял необычный синий цвет, а немного приближённый к цвету моря, потому что хотел выделиться на фоне большого количества сайтов, с синими оттенками. Хотелось получить такую легкость, при этом чтобы интерфейс был глотком свежего воздуха. Надеюсь вы меня понимаете. Давайте дальше.
О это важная штука, без которой либо лучше сразу убегать от клиента и не отвечать ему, или же получать сотни писем с непониманием как и что работает, и как итог большой негатив от разработчиков и клиента.
Если кратко, то суть библиотеки показать все переменные всех элементов с которыми можно взаимодействовать, чтобы разработчик мог взять любой интерактивный элемент на сайте и посмотреть в библиотеке как он работает.
Отличие составление моей библиотеки в том, что я ее проектирую после готового дизайна. Я видел много статей где описывается что библиотеки сначала создаются, а потом используются. Мне так не удобно. Мне важно сфокусироваться на интерфейсе при работе, чтобы я мог спроектировать подходящие, уникальные решения. Если же делать сразу библиотеку, не видя и не понимая как это будет использоваться. В общем, я так не могу или не умею. Поэтому я после дизайна начинаю формировать библиотеку.
Чтобы время не терять после того как десктоп улетел на вёрстку, можно делать мобильную версию. Это последний этап, но не менее важный, нужно подойти к адаптации с полной ответственностью и вовлечённостью. Предполагаю что больше половины аудитории будут заходить на платформу с мобильного. О том как я адаптирую интерфейсы рассказывать в этой статье не буду, это уже совсем другая история.
Что получилось в итоге
Переходите по ссылке и смотрите полную презентацию. Проект пока в разработке, поэтому только презентация. Как запуститься проект, я возможно напишу вторую часть, и расскажу что из этого вышло.
Инфографика для Вайлдберриз: Как сделать крутую карточку товара, если вы не дизайнер
Разбираемся из чего состоит привлекательная карточка товаров и что лучше НЕ делать, если вы занимаетесь оформлением сами.
У селлеров на маркетплейсах есть вопрос: как продать свой товар среди бездны таких же предложений с одинаковыми ценами? Один из рабочих вариантов — сделать привлекательный дизайн карточки: яркий, сочный, с наглядным описанием преимуществ. Давайте посмотрим как делается классный дизайн и как не сотворить монстра убивающего продажи и отравляющего душу.
Будем отталкиваться от настоящих примеров. Мы делаем конструктор инфографики для маркетплейсов Wondercard и ориентируемся на тех пользователей, которые далеки от дизайна. Бывает, что итоговые результаты карточек на выходе получаются не очень, и мы ищем закономерности, которые к этому приводят. На основе этих закономерностей мы дорабатываем сервис, а идеями, как сделать хорошие дизайны, делимся с вами.
В качестве примеров я подобрал товары прямо с Wildberries. Здесь не важно в каком редакторе они были сделаны. Главное наглядно показать суть и принципы дизайна.
Эти советы актуальны для новичков, поэтому для тех, кто хорошо разбирается в оформлении карточек, некоторые из пунктов могут показаться наивными.
Для начала выделим самую простую идею — хороший дизайн в коммерции должен приносить деньги. Чтобы это работало в сфере маркетплейсов, я лично для себя определил три задачи дизайна карточек (свои варианты можно написать в комментариях):
В качестве примера приведу вот эти картинки:
Яркие и контрастные цвета привлекают внимание. В заголовках сразу обозначено, что это узнаваемый бренд и что корпус крепкий и сделан из металла. С точки зрения добавленной стоимости, тоже понятно. Эти машинки мало бы кого интересовали за эти деньги, если бы товар выглядел вот так:
С графической точки зрения — здесь тоже все круто: динамика, глубина, цвет и шрифты. Много сложных элементов, которые собираются в единую атмосферную конструкцию.
Мне очень нравится как сделана эта карточка, но!
Новичкам я предлагаю так НЕ делать!
Вот 3 причины, почему новичкам не стоит делать сложный дизайн:
Каждый раз продумывая структуру дизайна обложки хочется рассказать о товаре как можно больше: вес, габариты, цвет, отличительные особенности. Впихнуть по максимуму, чтобы покупатель узнал сразу все. Но акцентировать все — невозможно. Так можно потерять самое главное, а текст может превратиться в нечитаемый узор. Как например здесь:
Если информации много, разбейте ее на несколько разных изображений. Заинтересуйте привлекательной обложкой с основной характеристикой и добавьте информацию с помощью второстепенных картинок.
На заглавной фотографии оставляйте только самое важное:
В нашем конструкторе есть шаблоны, с помощью которых можно сделать яркую заглавную картинку, например:
Есть 3 популярных графических способа привлечения внимания к карточке:
Когда мы делали первую версию Wondercard, мы хотели создать миллиард тематических шаблонов с яркими подложками и элементами. Плюс прикрутить инструмент для простого стирания фона с фотографий. Так пользователи смогут делать классные дизайнерские карточки сами, а вопрос итогового изображения должен зависеть от качества и потенциала шаблона. Мы сделали несколько ярких шаблонов с цветным фоном:
Но на практике такие шаблоны подходят не для всех фотографий. Например, только для студийных фото с изначально нейтральным фоном. Если у вас такие, то этот вариант для вас. Но часто бывает, что в арсенале продавца не всегда есть подходящие фото, либо товаров много и вырезать фон будет очень долго, а выкладывать товар надо уже сегодня. Поэтому решение с заменой фона подходит не всегда и в этом нет ничего страшного, потому что есть и другие способы выделиться.
Если у фотографии сложный фон, например, съемка проходила в интерьере или после обтравки кадр выглядит хуже, то лучше его вообще не трогать, а оставить в первоначальном виде. Вместо этого для привлечения внимания можно обвести кадр в рамку. На примере вот этого товара видно, что нет смысла удалять фон, так как сама фотография и без этого хорошая, а чтобы привлечь внимание ей сделали обводку.
С заменой фона, фотография будет выглядет странно — девчонка на матрасе летит по космосу с одеялом вместо паруса. Или сидит на фоне взрыва, а одеяло спасает от осколков. Жесть, не надо так.
Рамка может выглядеть нескромно, но даже Вайлдберриз практикует этот эффект на своих товарах. Очевидно, что они шарят в том, как делать, чтобы продавать лучше.
Или вот как сделано, а фон остался белым и никаких взрывов.
В нашем конструкторе есть несколько вариантов рамок. Они накладываются отдельным слоем от фотографий, поэтому дополнительное редактирование фото не нужно:
Яркий фон или рамки могут не всегда работать. Посмотрите на карточку товара с гамаком:
Мы видим яркий акцент, но при скроле страницы покупатель может не успеть считать, что это за товар. Фотка гамака классная и судя по количеству продаж работает, но бежевый товар сливается с бежевым фоном и теряется акцент.
В то же время, рядом находятся капсулы для стирки, которые на мой субъективный взгляд сильнее бросаются в глаза. Почему так происходит? Здесь играет роль четкие очертания товара и контрастные элементы.
Другой пример, когда установлены неконтрастные значки. Они сливаются с фоном. Товар виден, а инфографику не разобрать:
Вот несколько минималистичных карточек на белом фоне со значками, которые хорошо привлекают внимание:
В Wondercard есть готовые наборы со значками, как для заглавных фотографий, так и для дополнительных. В них можно менять цвета, тексты и изображения:
Я заметил несколько закономерностей в работе со шрифтами, которые делают дизайн хуже или лучше. Вот несколько частых ошибок, которые встречаются.
Смотрите как по-разному может выглядеть текст в разном шрифте и с разными стилями:
Маркетплейсы: создаем идеальную карточку товара
И разбираемся, как она влияет на продажи.
К предыдущей статье про мой старт работы на маркетплейсах было несколько вопросов, которые тянут на полноценный пост. Первый из них – это создание карточки товара. Вероятно, гуру уже знают все нюансы, но для новичков данный материал будет полезен.
На маркетплейсах вы не контактируете с клиентом напрямую и не имеете данных для повторных продаж. Ваша главная точка опоры — это страница товара и отзывы клиентов на ней. К этой странице нужно отнестись серьезно.
Мы будем рассматривать создание собственной карточки товара для долгой и плодотворной работы. Вообще на Ozon есть два варианта: можно прикрепиться к чужой странице и торговать с нее (если у вас одинаковый товар), а можно создавать свою карточку товара. Первый вариант интересен, если вы продаете товары известных брендов или, например, трендовые товары и быстро меняете ассортимент. Второй – актуален для тех, кто создает или планирует создать собственный бренд.
Быстрее всего создавать страницы через загрузку. хls файла (на WB есть только такая возможность). Да, это не очень увлекательное действие, но не ленитесь! Нужно заполнять все возможные поля, потому что потом вас будут ранжировать. И чем больше релевантной информации — тем больше шансов, что именно ваш товар покажут покупателю.
У каждого маркетплейса есть подробный FAQ, и там есть требования ко многим параметрам для заполнения в зависимости от товара и категории. Осведомлен — значит вооружен!
Вроде бы технический момент, но сначала важно изучить, в какой категории находятся ваши конкуренты, у которых много продаж. Иногда товар может относиться к нескольким разделам, и вы можете попасть туда, где совсем мало сессий. Либо потратить время на модерацию карточки, указывая не подходящий раздел. Посмотрите на конкурентов, изучите их продажи и попадайте в свою категорию.
Аналитика развития дизайна маркетплейсов в России
Нашу команду DIGIMATIX посетила идея написать статью, в которой мы сравним визуальную составляющую крупных маркетплейсов, а повторный «замер» произведем через год.
Это поможет посмотреть и проанализировать, как крупные компании растут и развивают сервис для своих партнеров и покупателей: что прижилось, а что наоборот стало лишним и изжило себя, какие элементы улучшились и улучшились ли вообще.
Для сравнения страниц маркетплейсов мы выбрали книгу «Интерфейс. Основы проектирования взаимодействия» Алана Купера и Роберта М. Рейманна в качестве примера.
Мы обратили внимание и сделали скриншоты следующих элементов:
Один из самых старых интернет-магазинов России, который с недавнего времени стал еще и маркетплейсом. В категориях продаваемой продукции можно и потеряться, но основными являются: электроника, книги, одежда и обувь, детские товары, товары для дома и сада, ж/д и авиабилеты. Несомненно это хорошо для покупателей, ведь в одном месте можно приобрести практически всё.
Интерфейс маркетплейса OZON является одним из самых узнаваемых. Преобладающий фирменный «синий» с отлично подобранными комплементарными и акцентными цветами. При первом знакомстве кажется перегруженным, но элементы управления находятся на своих местах. Поиск нужного товара не вызывают затруднений.
Меню каталога не умещается в один экран прокрутки, что неудивительно при таком обилии товаров. Очень удачно реализован поиск с уточнением категории и предварительной выдачей.
Процесс поиска товара отлично спроектирован, с возможностью сразу уточнить категорию где он будет происходить. Наша книга моментально нашлась даже не переходя на страницу выдачи с максимальной возможной информацией.
В карточке товара доступна информация и характеристики товара, опции покупки (для конкретного товара), отзывы пользователей с фотографиями, возможность добавить в избранное, задать вопрос о товаре, поделиться и сравнить.
Первое о чем хочется упомянуть, это докучающий блок «открыть в приложении». На смартфонах с небольшой диагональю экрана вызывает «дискомфорт». На главной странице он закреплён, что вместе с тапбаром «отнимает» полезную область контента. В категориях, подкатегориях, карточке товара таким же свойством не обладает.
Поиск в мобильной версии, кажется немного урезанным. Нельзя заранее выбрать категорию товаров для поиска, но это не помешало найти то, что нам нужно не переходя на страницу выдачи.
В карточке товара царит порядок. За исключением некоторых нюансов реализация повторяет десктопную версию, а переход к блоку «Отзывы и вопросы о товаре» реализован по-другому. До него нужно проскролить, попутно просматривая информацию о других товарах. В целом сценарий ведущий к покупке отработан и не вызывает затруднений.
Явившийся нам как совместное творение «Сбербанка» и «Яндекса», базой для которого стал сервис «Яндекс.Маркет», в конечном итоге им и стал. Правда разделение на «народную базу» и «магазин» в данный момент не совсем очевидна и временами вызывает путаницу, так как интерфейсы очень схожи.
Интерфейс сохранил стиль и легкость своего предшественника. Узнаваемый стиль, но уже с атрибутами и блоками интернет-магазина. Паттерн меню схож с предыдущим маркетплейсом. А вот поиск товара не кажется настолько же удобным и простым. Возможно, сказывается «заточенность» сервиса под технику. Озадачивает выбор между «Везде» и «Покупки в Маркете» и вызывает чувство, что нас чего-то лишили. Также не сразу становится понятно, где конкретно найден товар: на Яндекс.Маркет или в другом магазине.
Напоминаем, что для сравнения страниц маркетплейсов мы выбрали книгу «Интерфейс. Основы проектирования взаимодействия». Нам удалось найти нужный товар, указав его полное название. Такого же мощного представления товара здесь, как на OZON нам встретить не удалось, но назвать страницу неполной мы всё же не можем. Страница товара выглядит лаконично, но не сразу ясно — книгу можно купить здесь же или нужно перейти в другой магазин?
Интерфейс мобильной версии страниц отличается от десктопной версии четкими разделениями блоков друг от друга, что в целом добавляет удобства в восприятии контента пользователем. Важным дополнением считаем появление в строке поиска функции поиска по изображению: по загруженному из памяти телефона или по фотографии, которую можно сделать тут же. Функция работает отлично, хотя некоторые варианты поисковой выдачи приводят в легкое недоумение.
Карточка товара в мобильной версии дает больше понимания, где конкретно товар можно приобрести, благодаря плавающему блоку с кнопкой «В корзину».
В обеих версиях сервиса нельзя не отметить отличный блок отслеживания изменения цены на товар. Правда в некоторых случаях ощущаешь себя трейдером, когда цена находится на пике и хочется немного «подождать» — вдруг товар в цене упадёт. Также есть возможность подписаться на уведомления.
Как создать маркетплейс: технический ликбез
Денис Гордиенко, руководитель Bright Mobile, — о том, что нужно знать основателям при создании маркетплейса.
Предприниматели сильны в своих идеях, но часто не имеют технических знаний в разработке сайтов и приложений. Из-за этого возникают трудности на всех этапах развития маркетплейса. В рамках обучающего курса m-p.academy провёл вебинар по базовым вопросам при создании маркетплейсов.
Первая версия приложения выполняет главную задачу процесса. В этой версии может не быть красивого дизайна или каких-то функций, удобных, но не принципиальных для основной идеи. Первая версия решает задачу, для которой пользователь скачивает приложение или заходит на сайт. Если говорить по-простому, то MVP — это тест, стоит ли дальше развивать тему или такая идея никому не интересна.
Если при проектировании в приложении получилось больше 20 экранов, то скорее всего, вы внесли в проект больше функций, чем это необходимо на первом этапе. Это не тотальное правило, но повод основательно задуматься.
Например, для доски объявлений нужны пять основных экранов:
И дополнительные экраны, такие как переписка пользователей или уведомления, — уже опциональная вещь. Лучше сделать пять экранов и услышать от пользователей требования расширить функциональность, чем сделать 50 и после запуска понять, что 30 из них никому не нужны. Детальнее о таком подходе можно почитать в Lean Startup.
Если уходит больше, это значит, что проект слишком большой (смотри первый пункт). Либо задержки идут со стороны автора проекта: одобрение технического задания, проверка приложения, принятие актов и тому подобное. Обычно это происходит, если есть основной бизнес и остаётся только пара часов на стартап.
Очень редко при таком подходе проект вырастает до крупных масштабов. В какой-то момент времени нужно будет ответить на вопрос — заниматься текущим и проверенным бизнесом или полностью погрузиться в стартап, где и риски больше, и потенциальные выгоды.
У стартапов перед лидерами рынка только одно преимущество — скорость. Стартап может быстро внедрять изменения. Если растягивать этап разработки, то можно лишиться единственного преимущества.
При запуске важно поставить гипотезы и средства измерения. Если за два месяца начнут использовать приложение 100 человек, то сколько средств это вам принесёт? Выгодно ли это и что сделать, если нет? Сколько нужно будет вкладывать средств, чтобы привлечь необходимое количество пользователей?
Важный момент, на который обращают внимание инвесторы, — сходимость юнит-экономики. Если объяснять дилетантски, то экономика сходится, если на каждый вложенный в маркетинг рубль сервис зарабатывает больше одного рубля. Более глубоко можно почитать здесь.
Если гипотеза реализуется, то благодаря чему? Часто бывает, что основатель думает, что пользователям нужна одна функциональность, а приложение выстреливает совсем по другой причине. Как пример — YouDo, который начинался как сервис шуточных заданий. Здесь нужно не навязывать то, что было задумано ранее, а подхватить волну спроса.
Понять, из скольки экранов будет состоять приложение, сколько времени уйдёт на его разработку, и проверить часть гипотез можно ещё до создания приложения или сайта.
Как ни странно, проверка гипотез напрямую относится к техническому ликбезу. Можно поверить, что единственная гипотеза — это выстрелит сервис или нет, и с упоением тратить миллионы на разработку. Гипотеза должна быть простой, понятной и точно проверяться в короткие сроки.
Маркетплейс — это стартап, который потребует много сил и (чаще всего) средств. И если бизнес-модель нерабочая, то чем раньше предприниматель это поймёт, тем лучше. Сначала делают MVP-версию: если «взлетит» — добавляют функции, которые необходимы пользователям, и развивают проект дальше.
Сама суть MVP в том, что если идея находит свой отклик, то вы попадаете в счастливое число 2% стартаперов, у которых получилось (речь не о «единорогах», а о выходе на стабильный бизнес). Если нет, то потратите меньше денег, чем могли бы.
В большинстве случаев на первые несколько лет используется стандартный для веба стек: PHP + mySQL на какой-нибудь популярной CMS.
Для маркетплейсов сейчас есть готовые решения от «1С-Битрикс» (доски объявлений), WordPress (доски и товарные маркетплейсы), CS-Cart (товарные маркетплейсы). Здесь важно оценить, во сколько вам обойдётся доработка под себя. Рекомендовал бы самостоятельно выбрать решение и уже на FL или в студиях оценить именно доработки под вашу идею. Это позволит существенно сократить бюджет на старте.
Если кажется, что ни одно готовое решение вам не подходит, нужно вернуться к первому пункту — можно ли упростить ваш проект? История о том, что ваша идея настолько уникальна, что нет даже примерных аналогов, вызывает больше вопросов, чем уверенности. Скорее всего, подобные проекты уже были, но что-то пошло не так. Вопрос в том, что именно и учли ли вы это у себя.
По приложениям на рынке сформировалось три принципиальных подхода:
Натив — это написание приложения с нуля, отдельно под iOS, отдельно под Android на родных Swift, Objective-C и Java. Чаще всего нативщики хвастаются скоростью работы и реализацией любой мыслимой функциональности, начиная от игры, заканчивая простеньким бизнес-приложением.
В целом они правы, но, само собой, 99% успеха в прямых руках программиста (помните, сколько грузилось приложение «Сбербанка» полгода назад?). Цена, соответствующая возможностям технологии.
PWA — мобильный сайт, на который можно перейти не из браузера, а при нажатии на иконку, как и в приложении. Webview — мобильный сайт, обёрнутый в приложение-контейнер. Стек самый дешёвый из всех трёх, так как вы покупаете веб-разработчика, которых на рынке очень много.
Ограничений в технологии достаточно много. Очень не многие могут грамотно работать с push (а в PWA — это не на всех устройствах возможно), GPS страдает, скорость загрузки зависит от соединения с сервером. Технология подойдёт для простеньких приложений, где нет большой нагрузки на сервер и само устройство.
Кроссплатформа — это когда приложение разрабатывается в одном стеке, а потом уже компилируется под iOS и под Android. Благодаря этому экономится время (работает один программист, а не два, как в нативе), что отражается на стоимости.
Из минусов я вижу ограничения по анимации и 3D-объектам. На мой взгляд, такое решение идеально подходит для бизнес-проектов, но не подойдёт для игр и подобных «тяжёлых» приложений с VR и AR.
Маркетплейс — сложный продукт. Не получится один раз написать техзадание, забыть про разработчика и получить в конце полностью готовое идеально работающее приложение или сайт, приносящие прибыль.
В процессе разработки могут появиться дополнения и уточнения, которые не учли в самом начале, к которым нужно быть морально и финансово готовым. Поэтому в ИТ используют гибкие методологии управления проектами.
Суть их сводится к тому, что команда имеет общее понимание, что она реализует, а в процессе реализации:
Это делается для того, чтобы работа программиста была максимально прозрачной. Чтобы было сразу видно, где возникают трудности, где возможны временные задержки.
На самом деле о самой разработке можно писать много, и всё кажется важным. Напишите в комментариях, какие принципиальные вопросы есть, — отвечу в следующих статьях.
Затраты на программиста — постоянные, как и на маркетинг. Рынок развивается постоянно, и вам придётся регулярно делать обновления, доработки.
Работу программиста оплачивают двумя способами:
Программист взял задание, сделал, сказал вам, сколько часов потратил, вы оплатили.
Программист говорит вам фиксированную стоимость, и неважно, сколько времени займёт по факту.
В итоге, всё сводится к управлению риском «что, если не уложился в оценку?». В первом случае — риск на вас, и вы оплачиваете фактическое время. Можно сэкономить, если программист сделал всё быстрее оценки, но и дополнительно оплатить, если не уложился.
Во втором — цена фиксированная, но, как правило, выше оценки по ТМ. Если программист реально оценивает задачу в десять часов, он назовёт тринадцать (на всякий случай). Это не хорошо и не плохо — он тоже управляет своими рисками. Важно ответить себе на вопрос, что для вас выгоднее — заплатить меньше или зафиксировать бюджет, который не изменится.
Есть три варианта, куда обратиться:
Лично я отношусь ко второй категории, но постараюсь быть максимально объективным в плюсах и минусах каждой из сторон.
Вам нужно будет уметь техническим языком объяснить, что делать. Программисты не вникают в бизнес, они хотят получить чёткую и однозначно понятную задачу.
Кроме того, нужно иметь ввиду важный нюанс. Человеку должно быть выгодно работать с вами. В ином случае — он найдёт себе другого заказчика, с которым будет комфортнее работать.
В начале пути легко простить человека и найти нового, но если вы ушли далеко вперёд, то нужно всегда знать, как вы будете расставаться, не переписывая всё с нуля. Обладание исходниками — не панацея. С сайтом ещё можно найти разработчика, готового ковырять чужой код, а вот с приложениями почти никто на это не соглашается.
Тем не менее нужно обязательно просить исходники. Чтобы в случае конфликтных ситуации можно было обратиться к другому программисту даже с условиями частичного рефакторинга. Но чаще всего выгоднее помириться с автором кода.
Кстати, вопрос авторских прав тоже актуален. Важно грамотно оформить передачу прав, иначе, если проект будет успешным, можно воспользоваться лазейкой в законодательстве и заявить авторские права на ваш проект как минимум в технической части.
ПМ — это человек, который курирует создание вашего приложения в студии. В его задачах — говорить вам о том, как идёт разработка, о возникших проблемах, предлагать решения. Бывают менеджеры, которые не хотят конфликтов с заказчиками и при проблемной ситуации до последнего умалчивают об этом.
Не предупреждают заказчиков о возможных сдвигах сроков, удорожании разработки и так далее. Всё это выливается в непрогнозируемые проблемы уже у вашего стартапа. На мой взгляд, честность и профпригодность ПМа в большинстве случаев даже более важна, чем квалификация программиста.
Нужно учитывать, что студия — это тоже бизнес. Поэтому студии будут защищаться от неоговоренных доработок сильнее фрилансера, который может вздохнуть и сделать, лишь бы не ругаться с клиентом.
В студии с большей долей вероятности вам выставят счёт. Кто-то из основателей это воспринимает как само собой разумеющееся, кто-то — нет. Нужно быть готовым к тому, что дополнительные траты могут появиться при уточнении каких-либо деталей. Само собой, затраты должны быть обоснованными.
У студии помимо вас есть ещё другие заказчики. И в приоритете будут те, кто быстро отвечает, вовремя производит оплату, вовлечён в процесс. Грубо говоря, когда административный ресурс студии задействован по-минимуму, а производственный — работает на полную.
Иногда у основателей появляется ложное ощущение, что собственный программист выйдет дешевле. Это основано на том, что нормального программиста можно купить на рынке за 80 тысяч рублей в мес (500 рублей в час), а студии за тот же час просят минимум 1200 рублей (оборзели?). Однако не учитывается ряд важных деталей, которые в эту стоимость заложены.
Вам необходимо будет придумывать, как грузить программистов, чтобы не было простоя. То есть если задач нет и программист простаивает, то зарплата всё равно капает. Это отражается и в мотивации. Налоговая нагрузка также на вас, если всё вбелую, то +33%.
На вас падает и ведение проекта. Вы можете нанять менеджера проекта для управления, но если вы сами не обладаете экспертизой в разработке приложений или сайтов, можно столкнуться с тем, что сотрудники будут надевать розовые очки, пока проблемы не станут очевидными, а потом просто уволятся.
Подбор новых, отпуска, как и риски за простой — тоже проблемы, появляющиеся из-за прямого найма.
Тем не менее в своей разработке есть и очевидный плюс. Если в студии нужно делать дополнительные соглашения, чтобы изменить задачу, то своей команде вы в любой момент можете изменить задачу.
Всегда сложно делать выводы из такого объёмного материала. В статье хочется охватить все нюансы и поделиться опытом, а на заключение остаётся некая банальность. Пожалуй, ограничусь основной рекомендацией, которую бы хотел донести до своих подписчиков основателей маркетплейсов. Она связана с подходом к запуску проекта:
Ребзя, пилите MVP на Тильде за 1 день, рекламу на второй, новый проект на 3-ий )
Хороший совет. Конкретно в статье не стал писать, т.к. речь о маркетплейсах. В тишьду вендоров не получится прикрепить. Если только ей общий спрос измерить
А что вы имеете ввиду под термином «маркетплейс»?
Имеет ввиду поиск новых клиентов на vc с помощью простыни текста.
Система, где сводятся две роли пользователей, со взаимными интересами. Чаще всего выделяют три типа:
Хорошо написано, без воды, спасибо.
Скажите, а вот решения от 1С-Битрикс, которые вы упомянули, это полноценные отдельные продукты, которые передаются в виде кода покупателям, или это нужно быть как-то связанным с битриксом и что-то куда-то интегрировать?
И, пользуясь случаем, еще один вопрос: на Ваш взгляд, каковы основные преимущества решений подобных битриксу, которые стоят десятки тысяч рублей, перед теми же решениями от wordpress, которые либо бесплатные либо значительно дешевле? Будет интересно узнать мнение эксперта.
P.S. Я намеренно не провожу аналогию с решениями вашей компании, потому что у вас все-таки мобильные приложения(если я правильно понял), а не сайты.
Спасибо за высокую оценку 🙂 По Вашим вопросам:
1. Это передаётся с открытым кодом. Т.е. на маркетплейсе битрикса покупается понравившийся шаблон с редакцией CMS и вы получаете исходники, которые ставите себе на хостинг и используете на своё усмотрение.
3. Да, мы занимаемся приложениями для маркетплейсов. Сайты тоже делаем, но только в качестве комплексного договора (вместе с приложением) и только при нестандартных требованиях к проекту, где обычный php+mySQL+CMS не удовлетворяют.