Как "подружить" дизайнера и инженера? Как дать им работать с одними и теме же данным, без ущерба продуктивности? Как хранить дизайн в системе контроля версий. Если вас интересуют эти вопросы, в такой же степени как и меня, то добро пожаловать под кат!

Данная статья это прямое продолжение "Хватит это верстать, ударим автоматизацией по макетам" и является результатом моих исследований интересующей меня проблемы.

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

В данной статья я раскрою более подробно это понятие и поделюсь результатами своих исследований.
Хочеться с чем-то поиграться? Вот проверка концепции.

Контролируемость

А о какой контролируемости вообще идёт речь?
Я выделил два основных положения:

1. Возможность влиять на процесс генерации HTML кода.
2. Прямое редактированию результата, которое будет учтено при последующей генерации.

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

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

Проблематика

Многие графические дизайн решения предлагают экспорт HTML кода, но на этом и останавливаются. HTML код является производным продуктом и любые его изменения будут утеряны при новой версии генерации.

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

Решение

Главная идея если макеты делаются для создания HTML документа, то весь макет можно описать в HTML и CSS.

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

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

Возможно, кто-то скажет, что это звучит как утопия, Unity 3D, скажу я в ответ.

Unity, как и любой другой игровой движок уже давно реализовали подобную концепцию в своих инструментах.

Моё мнение, единственное препятствие внедрения подобного подхода в веб индустрии и производных высокие требования к HTML разметке, этот вопрос я более подробно рассмотрел в предыдущей статье.

Единственное, что дополню, продолжая сравнение с игровыми движками, что помимо дерева иерархии объектов, с которыми работает специалист, сам движёк строит множество других деревьев, о которых никому знать не интересно. В отличии от веба.

Хорошо, я хочу иметь что-то типо Unreal Engine, но для WEB. С чего вообще начать?
У меня есть на руках:

1. Простой Drag&Drop визуальный редактор;
2. Концепт модуля генерации разметки;
3. Какой-то HTML код, что я хочу редактировать.

Первым вопросом стало, как это всё объединить вместе.

Движёк

Любой движёк состоит из модулей, значит с этого и стоит начать.

Ух, тут прям в голову начинают лезть мысли о модуле мокирования api, тестирования, управлением хранилищем, создания анимации, оптимизации, работы с зависимостями, документирования

Но стоит поумерить пыл и вернуться к текущей проблематике.

Модуль отображения

Возможно вопрос и очевидный, но вообще, что мы и где рисуем?

У нас есть HTML код, который мы должны чем-то прочитать и отобразить. Логичным выбором тут будет самый популярный рендер WebKit Blink, его мы используем как модуль отображения(рендеринга).

Модуль чтения-записи

А вот с модулем чтения всё не так очевидно. Пока речь идёт о единой точки входа (весь код лежит в index.html), никаких проблем нет. Но реальное приложение может иметь сколь угодно сложную архитектуру и храниться в любом формате.
Пока видится 3 варианта как с этим справиться:

1. Работа с финальным кодом, с промежуточным рендерингом;
2. Максимальное покрытие всех стеков популярных технологий;
3. Строгое стандартизирование.

Чистого варианта тут нет, каждый имеет свои минусы.

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

Первый же вариант кажется очень перспективным, но с рядом сложных моментов, решение которых может оказаться дольше, чем 2.

Из очевидных проблем:

1. Сопоставлени промежуточного с оригинальным;
2. Приведение промежуточного кода, к формату оригинального.

Проблемы интересные и требуют исследований.

Модуль создания разметки

По всей видимости, самая простая часть.

Модуль визуального взаимодействия

А с чем мы вообще можем взаимодействовать?

Вот так выглядит дерево на одном из лендингов, описывающее 2 блока, лежащие рядом.

Глядя на него, вспоминается Adobe Illustrator в котором, чтобы добраться до нужного элемента, нужно кликнуть на одно и то же место 2 * N раз. Если там это оправдано, то в редакторе интерфейса это совсем неуместно.

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

Этот факт хорошо иллюстрирует следующую концепцию не весь HTML код значим одинаково.

Из этого сформулируем правило. HTML код делится на:

1. Значимый и;
2. Незначимый.

Пользователь взаимодействует со значимыми элементами.

Причём значимым может быть как код, описывающий внешний вид, так и структуру дерева группировки, позиционирование и тп.

Сам же редактор должен соответствовать всем ожиданиям дизайнера.

Связь

А что мы вообще имеем и что с чем связываем?
У нас есть:

1. Код, как источник правды;
2. DOM дерево;
3. Визуальное отображение.

При изменении кода, меняется DOM, что приводит к перерисовки отображения.

При изменении визуального отображения мы можем:

1. Изменить DOM, сохранить производный результат в код.
2. Изменить код, что приведёт к изменению DOM.

Каждый из вариантов приведет к перерисовки отображения.

Состояние

Но каков жизненный цикл DOM? Помимо редактора, его может менять и логика.

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

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

Всё вышеописанное звучит так, что в пору дождаться сильного ИИ, а пока оставить данное занятие Или вводить ограничения.
Снова обратимся к сравнению с игровыми движками. Там всегда есть как минимум 2 режима:

1. Редактор;
2. Предпросмотр.

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

Что же касается остальных, то я бы разделил их на 2 типа состояний:

1. Ручные, те что может понять редактор и дать над ними контроль;
2. Автоматические, непонятные редакторому, управляемые программно.

Отличным примером ручных будет Pagedraw с его редактором состояний и переходом между ними.

Но всё таки данная темя является одной из самых сложных, и требует гораздо более глубокие и тщательные исследования.

Резюме

Из вышеописанного складывается следующий концеп:

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

Редактирование же состояний является отдельной задачей и может быть осуществлено как визуально, так и через код. Компоненты же формирую библиотеку. Это всё будет накладывать определенные правила и ограничения.

Проверка концепции

Для проверки концепции необходимо реализовать режим редактирования, в котором изменения в визуальном редакторе сразу влияют на код, а изменения в коде также сразу видны и в визуальном редакторе.

Код же выступает источником правды и хранит данные репрезентации, мета информацию, и структуру (контейнер-потомок).

Последующие же открытие кода восстанавливает состояние визуального редактора.

Вооружившись данным знанием, реализуем это в коде.

Ограничения

1. Значимыми элементами считаются те, у кого есть класс или идентификатор;
2. К элементам не применяются сторонние эффекты;
3. Идентификатор является уникальным, повторное использование приведёт к неожиданным последствиям;
4. Большинство крайних случаем не рассмотрены;
5. Ошибки ожидаемы;
6. Компоненты и состояни не реализованы;
7. Код в HTML формате.
8. Передвижение контейнера с потомками возможно при "захвате" пустого места

Вывод

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

Для каждого из стеков понадобится свой собственный интерпретатор, что невозможно без заинтересованности комьюнити данного стека.

Что дальше?

У меня есть ещё месяц свободного времени, так что достаточно игры в "кубики", пришло время реализовать чистовую модель редактора. Для начала, в качестве целевого стека, буду использовать React, а точнее JSX + styled-components, как наиболее используемый и изученный.

Данный процесс может занять довольно длительное время, понимая это, я смахнул пыль со своего twitter аккаунта и приглашаю всех заинтересованных следить за процессом, там я буде постить свои мысли о проблеме и текущее состояние работы, а если сойдутся звёзды, то и на результат свободный редактор для всех, чтобы "сдвинуть это веб".

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

Разумеется, буду очень рад видеть конструктивную критику и дискуссию.

Всем мир!

The Host (Stephenie Meyer)

На этот пост меня вдохновила недавняя заметка Александра Pogman25 про боль фронтендеров и непростую историю любви и ненависти между фронтами и дизайнерами интерфейсов. История стара как мир, и основная причина боли действительно в отсутствии диалога и нежелании или неумении оказаться по другую сторону макета. Нежелание может быть следствием профэгоизма, неумение недостаточным скиллом. И с тем и с другим можно работать.

Думаю, в недалеком будущем No-Code/Low-Code продукты сделают свое дело, и UI/UX и фронтендеры уже не будут знать, что это такое, когда глаз дергается синхронно с кнопкой в веб-версии макета. А что сейчас? Чтобы дизайнеру и фронту было проще ужиться друг с другом, а их совместная работа упростилась, мы придумали Quarkly.

Сооснователи проекта Саша и Артем не понаслышке знакомы со всеми болячками, которые возникают во время коммуникации дизайнера и фронта. Александр фулстек-разработчик, Артем UI/UX. В данном случае, что называется, карты сошлись.

В Quarkly мы стремимся к пресловутому Low-Code и даже No-Code при сборке сайтов и веб-приложений, и когда мы запустим в релиз каталог-маркетплейс готовых компонентов, это станет в целом очень даже возможным.

По состоянию на февраль 2021 года маркетплейса у нас пока нет, но есть весь базовый набор инструментов как для дизайнера, привыкшего делать макеты/прототипы в популярных дизайн-инструментах (Figma, Framer), так и для разработчика.

Уже сейчас готовый макет из Figma не без труда, но довольно быстро можно перетащить в Quarkly, ниже оставляю туториал с русскими и английскими субтитрами:

За счет чего Quarkly поможет снять боль

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

Чтобы не считать длину рабочего цикла в слонах, мартышках и попугаях, давайте наглядно сравним две ситуации:

1. Дизайнер и фронт работают, как они привыкли каждый это делать дизайнер создает макет в Figma, далее фронт переносит всё в код;
2. Дизайнер и фронт совместно создают проект в Quarkly.

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

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

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

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

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

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

Наш канал на YouTube, где можно найти полезные мануалы: смотреть

Наш чат в телеграме: https://t.me/quarklyapp

Продолжаем экспериментировать с парадигмой no code (и отчасти low code).
Собрали чатбота, помогающего дочитывать большие архивы статей.
В статье расскажем, какие инструменты взяли и на какие их ограничения наткнулись.



Материал для статьи и проект собраны вместе с roman_nebel.

Disclaimer. Да, нам тоже проще написать чистым кодом. Но суть nocode-упражнения именно в том, чтобы собирать полезные сервисы из готовых инструментов. Начали давно, продолжаем, нравится. Постепенно обо всём расскажем.

Аудитории Хабра, видимо, интересны технические, а не продуктовые подробности. Если о продуктовом слое работы в no code проектах без погружения в детали реализации тоже есть смысл рассказывать дайте знать в комментариях.

Что хотели сделать

Хотели помочь людям (и себе):

• приучить читать на английском;
• уходить на обед: Вот статья, почитаешь за столом.

Делать такой микропродукт решили через Telegram-бота:

1. Раз в день присылает ссылку на статью из архива. Для пробы раздербанили архив статей про дизайн ReadingDesign. Будет ещё.
2. Спрашивает читателя, понравилась статья или нет. Результаты складываем, копим данные, потом сможем найти самые интересные статьи и оценить активность пользователей.

Бота можно щупать: @bracho_read_bot
Баги есть. Идеи по фичам тоже есть. И план нового релиза есть.
Короче, всё есть, но много не мало, так что кидайте и свои мысли.

Что использовали

Chatforma. Один из многих (выбирали) конструкторов для чатов. Не идеальный, но хоть как-то делает что нужно. О выборе ниже.

Integromat. Передаёт данные туда-сюда по правилам и с условиями. Выбор по умолчанию для no code проектов.

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

Детали по инструментам

Bot Father

Для начала нам нужен сам бот, точнее аккаунт для него в Telegram. Самый простой способ найти Отца Ботов (@BotFather) в Телеграм и в нем зарегистировать нового бота. Пошаговое описание гуглится на любой вкус, если в двух словах: придумываем имя бота, его логин и все. После успеха вам придет токен (ключ для идентификации и связи бота с внешним миром), который и был нам нужен на этом этапе.

Chatforma

В сети есть куча сервисов для создания простеньких ботов для социальных сетей. Но у них у всех есть родовая травма: они созданы для воронок продаж. А потому простые и тупые.

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

Конечно, есть и решения вроде DialogFlow на Google Cloud, но чем в них разобраться, проще написать все ручками. Поэтому берем вариант попроще.

Взяли Chatforma. Из всего не такого уж многообразия у него у одного есть хоть какое-то API и поддержка Webhook. А раз так, то мы сможем доверить чатбот-платформе функцию непосредственно отправки, а логику настроить где-то в другом месте.

Да, предыдущий no code проект мы делали на AIMyLogic. К сожалению, интеграция с внешними сервисами у него устроена на ноль с плюсом. Так что увы, не в этот раз.

Airtable

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

Да, можно было и в Google Таблицах (на них мы уже сделали и эксплуатируем коммерческий no code проект, внезапно это дизайн-задачник). И в SQL можно было. И много где еще.

Причин выбора Airtable две: он приятный на мордочку и замечательно интегрируется со всем и вся. Получаешь токен API прямо в приложении и гоняешь данные в обе стороны как хочешь и где хочешь. Легко и приятно. А мы хотели, чтобы легко и приятно хоть где-нибудь и в чём-нибудь.

Integromat

И, наконец, мозги. Сложно назвать преимущества перед тем же Zapier, тут чистая вкусовщина. Мы уже использовали Integromat в предыдущих проектах, он как-то привычнее. Кстати, собирали список статей из архива мы тоже с помощью него.

Немного суровой коммерции

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

Как мы это сделали

Базовые настройки

Задача 0 в Chatforma завести нового бота, чтобы он просто был. Регистрируемся на платформе, радуемся, что у нас всего 14 бесплатных дней. Заходим во вкладку боты и находим заветную кнопку Добавить бота. Называем его (имя только для Chatforma, сам бот уже назван) и выбираем соцсеть (Telegram).

После этого сразу идем в нового бота и в разделе настройки прописываем тот самый токен, который дал нам Отец Ботов, без этого ничего работать не будет.

Настройка для токена спрятана хорошо, надо еще поискать

Первое, что должен сделать уважающий себя ботостроитель научить бота здороваться. Все просто: идем в Конструктор и видим два заготовленных сообщения: стартовое и по умолчанию. В чем разница: первое это сообщение придет, если вы только запустили бота (нажали Старт). Второе это универсальная заглушка на любое сообщение, которое бот не понимает.
А еще там можно добавлять инлайн-клавиатуру, но это уже совсем баловство

Собираем пользователей

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

По шапке таблицы можете легко определить ее полезность

Нам пригодится Integromat, Airtable и API запрос. В Integromat этим запросом вытаскиваем список пользователей и записываем в нужную таблицу в Airtable. Чтобы не плодить дубли, перед записью проверяем на наличие пользователя в таблице по ID. Если такой уже есть отсеиваем, остальных записываем.

Отдельный фетиш в Integromat пытаться там все выровнять

Настраиваем рассылку

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

Сейчас объясним, почему

Дело вот в чём. Chatforma умеет создавать два вида рассылок: обычные и авторассылки. Первые подойдут, если нужно единоразово отправить всем (или некоторым) участникам определенный текст, картинку, опрос и так далее. Второй позволяет настроить рассылку по расписанию и дням недели, но функционал отправки ограничен только текстом и медиа, опросы так отправлять нельзя.

Просто рассылка


Авторассылка

Вернемся к рассылке. То, что предлагает платформа, нам не подходит. Мы не можем сделать персонализированную рассылку и динамически вставлять туда любую информацию. Только заранее заготовленную. А ручками это делать не хочется. Когда у бота два пользователя, это еще ничего, но если их уже три Поэтому решаем проблему с помощью Integromat.

Создаем сценарий со следующей логикой: Получаем список статей из Airtable Оттуда же берем список пользователей, который мы занесли туда ранее Каждый пользователь проходит итерацию, где генерируется рандомное число и статья под таким номером строки отправляется через POST-запрос в Chatforma. Для этого пришлось залезть в документацию к API и найти там нужный метод.

Чтобы пользователю дважды не приходила та же ссылка, подгружаем базу с уже отправленными ссылками, сортируем ее по пользователю и проверяем ссылки на соответствие. Если такая ссылка была возвращаем на предыдущий этап и повторяем заново, если такой ссылки не было отправляем пользователю и заносим в таблицу с отправленными.

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

Вариация на тему бизнес-логики

Вот что после этого происходит на стороне Chatforma. Когда Integromat отправил сообщение, Chatforma его получает и формирует единичную рассылку для конкретного пользователя. В тексте все тоже, что сформировал Integromat. Вроде работает.

Тут же обнаружилась проблема: мало того, что есть задержка при получении данных извне, так еще и Chatforma долго (до 15 минут) проводит уже сформированные рассылки. Получается, что десятичасовая рассылка может прийти и в 10:01 и в 10:16, Техподдержка этот феномен изучала 4 дня и без особых успехов.

Но поддержка отзывчивая, и это приятно

Голосовалка

Ссылку все получили, кто-то даже прочитал содержимое. Теперь нужно эту статью оценить. У API Chatforma есть два ограничения, которые не дают нам простора для творчества: мы можем в сторонние сервисы отправлять только ответы, полученные из такой сущности, как Опрос. По API мы можем возвращать только текст, нужный нам опрос мы можем создать только внутри Chatforma, а значит можем пользоваться только теми видами рассылки, который описали ранее.

В итоге сделали следующее: расплодили опросы о качестве статьи на каждый день для всех подписчиков, поставили его на 11:00. После того, как пользователь проголосует, результат через webhook уходит в Integromat, и на основании ответа последней присланной статье для нужного пользователя проставляются баллы. Подсчет такой: за Огонь +1 балл проголосовавшему и +1 балл статье, за Не очень -1 балл статье и +1 пользователю. За Не читал ничего. Еще планировали отправлять пользователю сообщение-отбивку после голосования, но от этой идеи отказались. Потому что скорость доставки в духе Почты России в её лучшие годы.

В это голосование ЕР не вмешается

Итого по инструментам

Airtable

Никаких проблем при интеграции, записи и получении данных.

Integromat

Сервис хорошо справляется с линейными операциями. Если появляется логика if/else и сравнение данных, схема получается достаточно запутанной. Но работает.
Приходится много оптимизировать процессы, так как все тарифы ограничены по количеству выполненных элементов.

Chatforma

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

Найденные недостатки.

1. Ограничение видов контента в зависимости от вида рассылки.
2. Содержание рассылки, направленной через API, ограничено только текстом.
3. Webhook умеет отправлять только результаты опроса, а не любые действия пользователя.
4. Большая задержка при отправке рассылок.
5. Баги с задержкой внесения изменений после сохранения.
6. Лог не хранит присланные пользователем сообщения, только ответы на опросы.
7. Заплатить за сервис целый квест, и нужно очень хотеть, чтобы его пройти.

Вопросы к вам

1. Бота можно щупать: @bracho_read_bot и конечно, просим репортить о багах и предлагать фичи.
2. Какие ещё архивы англоязычных статей зашить в бота? Кое-что уже отобрали, хотим ещё.
3. Продуктоведы, вы тут есть? Вам о продуктовой части no code рассказывать или ну его и сами с усами?
4. Набор no code инструментов. Есть ли что получше для этой задачи? Конечно, в кандидатах на вылет в основном Chatforma.

Итак, MVP. Достаточно заезженная тема, на мой взгляд. Каждый, кто хоть как-то связывал себя с разработкой программного обеспечения за последние 5 лет, с 99% вероятностью слышал эти 3 буквы. Но даже несмотря на обилие информации, народ все равно наступает на грабли идеального продукта при создании проектов.

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

Начну с вирусной зарисовки пути развития стартапа по принципу MVP, которая гуляет по интернету и которую вы наверняка встречали.

90% авторов используют иллюстрацию в своих публикациях в буквальном смысле, что вводит в заблуждение читателей.

Разберем?

Верхняя строка ничего общего с MVP не имеет. Это понятно. На ней изображен классический цикл разработки. Автор использовал его как преувеличение ради контекста в примере ниже. Разумеется, ни о каком минимально жизнеспособном продукте на первом этапе с колесом речи и быть не может. Продукт прошел 3 стадии разработки (колеса, кузов, двигатель), прежде чем смог выполнить свое предназначение ехать.

Но и вторая строка, на мой взгляд, также не совсем корректно отображает принцип MVP.

Почему мое внутреннее понимание минимально жизнеспособного продукта не сходится с такой концепцией? Если предположить, что она отражает путь разработки какого-то продукта, становится очевидно, что он претерпел 4 коренных перестройки. В итоге его создатели получили три группы товарно-родовых конкурентов: 1 скейт-самокат-велосипед; 2 мотоцикл; 3 автомобиль.

Да, покупатель, как мы знаем, покупает не продукт, а решение своей проблемы. И скейт вроде бы решает базовую потребность (передвигаться быстрее, чем пешком). Но ведь скейт и автомобиль это абсолютно разные средства передвижения, нацеленные на разную аудиторию и цель езды для каждого из них имеет совершенно разную специфику. Продукты по-разному удовлетворяют запросы к комфорту, цене, сложности техобслуживания, скорости и т.д. В результате, у каждого своя целевая аудитория.

У автомобиля более широкий охват: пожилые и молодые люди, те, кто путешествует в одиночку или в компании, кто ездит на работу или мотается в другой город им нужна скорость, комфортное размещение и езда при любых погодных условиях. Скейт предназначен исключительно для одного человека, чаще ребенка или подростка, да и цель езды носит больше развлекательный характер. Аудитория скейта воспримет в штыки перспективу трансформации продукта в машину, которой нужно топливо, дорогостоящее ТО и возраст 17+, не говоря уже о цене самого автомобиля. А те, кому нужна машина, изначально не обратят на ваш самокат никакого внимания. Да, каждый из этих продуктов может иметь MVP, но они не являются MVP друг для друга.

Хенрик Книберг, автор этой картинки, не раз писал о том, что его изображение не всегда интерпретируется в правильном контексте. Дело в том, что он вкладывал в нее метафорический смысл, при котором цель разработки не построить автомобиль, а решить задачу добраться из пункта А в пункт Б. И самым простым жизнеспособным вариантом решения этой задачи является скейт. То есть на ней абстрактно и очень упрощенно передан некий концепт поиска продукта. Скейт или самокат не являются MVP для машины. Это факт. На картинке лишь изображена идея того, что в рамках создания продукта можно сделать несколько пивотов и в итоге найти MVP.

А эта переосмысленная версия MVP мне больше пришлась по душе:

В продуктовом бизнесе MVP продукта это сам продукт, только выполненный с какими-то упрощениями, сокращениями, удешевлениями. MVP высотного здания это та же высотка, но не на 24 этажа, а на 5, без лифта, мусоропровода и прочих благ. MVP автомобиля это автомобиль. Только попроще. Сначала из досок и сваренной на скорую руку рамой, с двигателем послабее (или вообще без него), сидениями от мебельного гарнитура. Но три ключевые функции, отстраивающие его от скейта или самоката, скорость, вместительность и дальние поездки уже будут при нем.

Что завернуть в MVP, чтобы его захотели попробовать?

С концепцией MVP разобрались. Теперь поговорим о том, как определить начинку пилотного продукта, приоритезировать функционал и сделать первую версию продукта востребованной.

Первое, что необходимо сделать, это выяснить, какие инструменты, фичи и возможности станут для вашего продукта must have.

Принцип Парето

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

MVP = обязательно + просто

Слышали про матрицу приоритетов? Популярная техника приоритезации задач, которая распределяет фичи по шкалам обязательно и просто. Изобразите две оси, где горизонтальная будет отображать увеличение сложности реализации конкретной функции, а вертикальная путь от желательного к обязательному. Раскидайте весь запланированный функционал на этой схеме, отвечая на 2 вопроса:

1. Сложно это или легко для реализации?
2. Желательно это или обязательно для пользователя?

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

Формула Rice Score

Еще один эффективный метод приоритезации идей и фич для MVP. Вам нужно оценить каждую функцию по четырем факторам и подставить значения в простую формулу.

• Охват скольким пользователям вы улучшите жизнь?
  (Оцените в течение определенного периода времени и берите цифры из метрик, а не с потолка)
• Влияние насколько вы улучшите жизнь пользователям?
  (Очень сильно = 3х, сильно = 2х, хорошо = 1х, слабо = 0,5х, совсем немного = 0,25х)
• Уверенность насколько вы уверены, что гипотеза окажется верна и продукт выстрелит?
  (100% = высокая уверенность, подтвержденная опросами или исследованиями, 80% = средняя уверенность, 50% = слабая уверенность, 50% и ниже = много сомнений)
• Усилия сколько человеко-часов, человеко-дней или просто дней уйдет на реализацию?
  (1 человеко-день = это день работы одного разработчика)

Рассчитайте оценку для каждой фичи, согласно формуле:

Вместо итога

MVP подход играет роль подушки безопасности и позволяет адекватно прогнозировать коммерческий и технический потенциал продукта. Поэтому, когда мы брифуем заказчиков, то настаиваем на том, что стартовать разработку лучше с него. И, разумеется, помогаем определиться с ключевым функционалом. Если вы планируете создание минимально жизнеспособного продукта, то лучший вариант построить его на NoCode технологии. Сегодня платформы для разработки приложений без кода пользуются бешеным спросом. Они позволяют быстрее и дешевле создавать web-приложения любой сложности, а существующие биржы NoCode фриланса помогают подобрать подходящую под запросы бизнеса технологию и проверенного специалиста. Осмелюсь предположить, что тенденция к упрощению и удешевлению разработки будет только усиливаться. И сейчас самое время задействовать ее потенциал.

Всем привет! На самом деле я сторонюсь сравнений с конструкторами сайтов и ниже расскажу, почему это так. Наш проект это скорее редактор, позволяющий динамически верстать макеты без кода и генерирующий на выходе оптимизированный продакшн-реди код. В остальном мы ближе к графическим редакторам. Этакий No-Code Pixel Perfect инструмент, где всё нужное под рукой, и где реализовано всё то, чего не хватало в Фигме.

За всё, что мы делаем, отвечаем тоже вместе (с)

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

Самое время представиться. Меня зовут Витя, занимаюсь дизайном около 12 лет. За это время поработал в разных компаниях. В самом начале пути это был аутсорс. Затем пришел в uKit.Group, а на тот момент uCoz (честно напиши в комментариях, сколько сайтов кланов по контре собрал на юкозе, пока был юн и горяч). Можно сказать, что uKit это мой первый серьезный продуктовый опыт.

Последние 4 года работаю на позиции арт-директора.

В команде проекта, о котором я сейчас буду говорить, помимо меня всего три человека: два программиста Рома и Слава, и тестировщик Егор.

Для кого наш проект

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

У нас несколько аудиторных фокусов, один из их это небольшие дизайн-студии. Также можно выделить дизайнеров-фрилансеров. Мы многое ещё не успели реализовать на текущий момент, но вот именно фрилансерам, создающим сайты-визитки и небольшие сайты до 10-20 страниц, Графит подходит уже сейчас. Он способен удовлетворить многие их потребности в области Pixel Perfect, необычных дизайнов и нетривиальной верстки. Многие макеты из Фигмы можно сверстать почти один в один внутри Графита.

Хорошо там, где нас нет

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

Наши конкуренты: Фигма, Скетч, Editor X от Wix, Studio.design, Webflow, Readymag, SquareSpace. Аудитория каждого сервиса может найти для себя мотивацию юзать Графит. Наша задача донести, почему стоит это сделать.

Допустим, человек использует Фигму и Скетч, но не пользуется сайтбилдерами. Такая аудитория для нас привлекательна. Многие дизайнеры не побоюсь этого слова страдают от необходимости работать с верстальщиками. На Хабре про боль дизайнеров было немало статей, и сколько их ещё будет!

Tell me Why

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

I. Сетка

Прежде всего, Графит это инструмент сетки. Звучит не ново, согласен. Однако в нашем случае сетка представляет собой визуальный инструмент автоматической верстки, который ломает для дизайнера барьер между кодом и графикой. Сетка внутри Графита объединяет два способа расположения элементов: непосредственно по сетке и свободное позиционирование. Поэтому мы называем её гибридной.

Любая конструкция, собранная в Графите, по умолчанию адаптивна: добавляйте в контейнеры элементы по координатам, не думая о том, что случится при входе с мобильного устройства.

Дополнительную гибкость при сборке макетов дает стек. Конструкции любой вложенности создаются прямо с холста, при этом можно реализовать любые возможности современного CSS и Flexbox.

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

II. Панель слоев

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

Что мы привнесли от себя:

• в списке слоев отображается структура сетки
• элементы со свободной позицией помечаются специальной иконкой
• элементы сетки сортируются по правилам, позволяя сохранить правильную структуру сайта

III. Дизайн-система

В Графите она рождается, живет и развивается вместе с сайтом. Это позволяет поддерживать и развивать дизайн-систему с минимальными затратами.

Что это дает:

• можно перекрасить сайт целиком в один клик, либо изменить цвет отдельных элементов или контейнеров
• управление всей типографикой происходит в режиме одного окна
• есть возможность настроить собственные переменные и наследовать их в любой момент в любом проекте
• каждую часть дизайн-системы можно заменить, используя механизм пресетов

IV. Визуальные компоненты

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

С помощью компонентов можно будет, например, создать шаблон шапки или карточки и редактировать их в одном месте.

Что ещё?

Я бы особенно выделил нашу концепцию работы с марджинами. Если ты кликнешь в элемент и наведешь на его край, там появится маленькая палочка. Потянув за неё, ты увеличишь или сократишь внешний отступ. Опция простая и далеко не новая, но в сеточной инфраструктуре она имеет важное значение. Это позволяет работать с пустым пространством. Для дизайнеров это важно. Именно контраст между пустым пространством и контентом формирует ощущение от макета.

Подкапотное пространство

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

Фронт: Lerna, React, Redux, Emotion (SPA), Flow, Prettier, Unit testing, Gitlab CI, Babel, Webpack, Sentry.

Бэк: Node.JS, Nest.JS, MongoDB, Firestore, Nginx + LUA, PM2, RabbitMQ, Docker, Dockerswarm, Grafana, Fluentd, Kibana.

О том, как мы всё это готовим и с какими трудностями сталкиваемся уже в следующем посте. Буду рад вашим вопросам!

Всем привет. В OTUS открыт набор на новый поток курса Product Manager IT-проектов. В связи с этим Сергей Колосков продакт-менеджер в Ozon, преподаватель в OTUS и автор телеграм-канала t.me/FreshProductGo поделился своей заметкой про No-code.

---

В процессе преподавания продакт-менеджмента в модуле Исследование продукта я заметил, что самое вкусное и вызывающее интерес у студентов место в нем это результаты проблемных и решенческих интервью (на работающем прототипе). И это разумно: именно тут острие работы продакт-менеджера, получение обратной связи с минимальными усилиями.

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

Ещё раз самое важное при проверке гипотезы: ценность, минимальные ресурсы и обратная связь.

Для таких проверок есть огромное количество инструментов, начиная от столба с плакатом для классифайда и видео-роликом для облачного хранилища (ранее тут некоторые описывал t.me/FreshProductGo/33). А именно:

1. Google-таблицы / Формы / Excel: создаете любой опрос или ведете клиентскую базу в таблице. Кстати, могу поделиться своей Nocode-проверкой гипотезы, что книги могут выбрать и купить по фрагменту: я запускал такой опрос с фрагментами книг без названий и вариантами ответов Купить/Узнать книгу/Следующий фрагмент. Выяснил, что покупка редка, а любопытства много.
2. Сюда же добавлю специализированный и более разнообразный инструмент форм: www.typeform.com.
3. Tilda, Ecwid и co. Реально можно подвигать блоки и запустить простейшие лендинги. Этот я сделал, потратив 4 часа (разбираясь с тильдой).
   
   И тут
4. Notion и ее лендинги постепенно перевожу свою работу в этот прекрасный инструмент. А недавно узнал про то, что там можно сделать лендинги.
5. Чат-боты в мессенджерах: очень хороший обзор есть тут. От себя добавлю, что также пробовал для выбора книги по фрагменту сделать бот на BotMother.
   
   Еще хорошие инструменты:
6. Webflow поможет наверстать простенький фронт.
7. AirTable может помочь собрать интерфейс CRM-ки.
8. Stacker app без кода и программирования.
9. Integromat поможет собрать простенький бекенд без кода и с интеграциями.
10. Bubble технология drag & drop позволяет легко добавлять и перемещать элементы страницы: текст, видео, карты, иконки, изображения, кнопки и пр. Все поддается настройке вплоть до цвета фона, иконок, прозрачности элементов.

Исчерпывающая подборка есть тут.

Что уже создали на No-code

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

• Ezume saas сервис по созданию резюме, который позволяет как конструктор сгенерить симпатичное резюме. SaaS сервис сделан на Bubble.io
• ImmuneCorps волонтерский сервис. Помогает людям с высоким риском заражения COVID-19 получить помощь в виде похода в магазин, выгула собаки, работы по дому и др. Сервис сделан на Bubble.io
• Peer to Peer для детей, где дети могут обмениваться своими знаниями и опытом с другими детьми и зарабатывать). Стек Tlida.
• TopShare сервис подбора индивидуального плана тренировок. Стек чистый Bubble.
• eTutorium LMS площадка для дистанционного обучения, которая позволяет делать конструктор тестов, проводить вебинары, геймифицировать мотивацию, получать аналитику по прохождению. Сервис сделан на Bubble.io
• Look App приложение, где можно делиться своими образами, брендами одежды, стоимостью и лайкать. Стек Glide.
• Reachr сервис, который соединяет бренды с блогерами для сотрудничества в рекламных кампаниях. Платформа забирает 10% со стоимости заказа. Стек Webflow (сайт с формой заказа), Airtable (база данных), Zapier.
• Сервис для проверки знаний по охране труда в органах исполнительной власти. Стек: Wordpress, WP-Pro-Quiz, Ultimate Membership Pro, WooCommerce.
• Comet сервис поиска подходящего фрилансера-профессионала под любой запрос. Транзакции на платформе уже превышают $1 млн в месяц. Стек Webflow (сайт с формой заказа), Airtable (база данных), Zapier.
• Tavalo мобильное приложение по предзаказу еды в ресторане, оплате чека и шерингу оплаты с друзьями. Также ребята сделали на No-code приложения для приема заказов для ресторанов. Стек Adalo
• Memolly-subscription сервис управления подписками на разные сервисы на Adalo
• Bookcelerator витрина смартридов книг с подпиской, сделана на Notion
• Book nerds приложение для ведения списков книг, которые хотите прочитать. Можно трекать что читаете сейчас, ставить оценку и писать отзывы, устанавливать челленж и отслеживать ваш прогресс, делиться книгами с друзьями и др. Стек Glide.

С какими минусами сталкиваются все

1. Не всегда nocode/lowcode это дешево. Например, у Mendix Стоимость лицензии на одно приложение начинается от $1875 в месяц при условии подписки на три года, лицензия ограничена 50 внутренними пользователями. Цена корпоративной лицензии с возможностью локального развертывания начинается от $7825, а это почти $100 000 в год. А можно сделать собственный продукт, и никому ничего не оплачивать. Выйдет дешевле.
2. Промах с технологией: взять то, что не позволит вам полноценно реализовать нужный продукт. Но технологии развиваются, тот же Bubble уже очень мощный, для разработки веб-приложений здесь есть почти всё, есть более тысячи плагинов, позволяющих расширить функционал, и постоянно добавляются новые.
3. No-code на сегодняшний день не подходит для больших проектов. По мере увеличения количества пользователей приходится оплачивать всё более высокие тарифы. При этом полностью собственной платформой владеть вы не будете, и если захотите отсоединиться от no-code-сервиса, всё придется разрабатывать с нуля.
4. Если что-то случится с Tilda или Bubble, или они решат, что вы нарушили их правила, и решат вас забанить, это может полностью убить ваш бизнес. Зависеть от сторонних площадок не очень комфортно. С другой стороны, это мало чем отличается от того же хостинга.
5. Если нужны нешаблонные решения, вы хотите создать то, чего еще не было на рынке вариант не подходит. Здесь нужен кодинг. No-code-решения хороши для расширения ниши, но не имеют полного пространства возможностей, этого в них просто не записано.
6. Часто не хватает буквально одной функции. К счастью, почти во всех конструкторах всё-таки есть возможность вставить собственный код, чтобы дополнить продукт. Но для этого, если вы не умеете кодить, приходится нанимать фрилансера или полноценного разработчика, который завершит проект. А совсем без кода, как мечталось, не получается.
7. Ограниченная кастомизация. Вариантов дизайна конструкторы no-code предлагают многие тысячи. Но, учитывая количество сайтов в интернете, этого не хватает. Если не нанимать дизайнеров, некоторые сайты в Сети неизбежно будут очень похожи на ваш. Что-то совсем уникальное создать не получится. Можно разве что добавить это с помощью сторонних плагинов и собственного кода. Но тогда опять же, многим будет проще изначально всё накодить, а не учиться работать с новым конструктором. Смысл no-code теряется.

На этом всё. А мы приглашаем всех желающих на бесплатный вебинар, в рамках которого подробно расскажем о курсе, процессе преподавания и ответим на интересующие вас вопросы.

Читать ещё:

• Метрики, которые отслеживают великие Product-менеджеры