Дизайн от задачи против дизайна от системы

Различие сформулировал Ryo Lu (Head of Design в Cursor, ранее founding designer в Notion) в интервью для Dialectic и a16z. Тема всплыла в sail-muddy-lessons как одна из причин, почему Sail/Muddy столкнулся с трудностями.

Два режима

Дизайн от задачи (purpose-driven): отталкиваться от конкретной проблемы пользователя. Каждый экран выстроен под эту проблему. Продукт описывается пользователям через проблему, которую он решает.

Дизайн от системы (system-driven): проектировать гибкие, универсальные концепции, которые можно комбинировать. Продукт превращается в небольшой набор примитивов и правил их сочетания. Канонический пример - блоки, страницы и базы данных в Notion. Фраза, которую использует Ryo Lu: "Каким минимальным числом строительных блоков можно обойтись?"

Чем соблазнительны системы

В Sail проводили глубокую "платоническую декомпозицию" - искали минимальный набор концепций, из которых можно собрать всё остальное: веб-карточки, текстовые карточки, комментарии, сообщения, треды, уведомления. Группы и треды были одной и той же сущностью (группы на canvas, треды сообщений). Сообщения существовали одновременно в пространствах canvas и чата.

Для создателей продукта это ощущается как нахождение истины. Смена формы продукта (canvas -> board -> chat) становится тривиальной, потому что внутренняя механика одна и та же. Возможности, возникающие из комбинации примитивов, ощущаются как рычаг.

Почему системы обычно проигрывают

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

Notion - пример выжившего, но стоит присмотреться: в идеале это "tool for thought", но на практике пользователи описывают его как "wiki / документы / трекер задач". Система работает, потому что она чётко сопоставляется с тремя уже существующими задачами пользователей. Система - это реализация; задача - это маркетинг.

Когда не удаётся связать систему с понятной задачей, получается "собери свой собственный workspace" - и работа по поиску сценария использования перекладывается на пользователя. Большинство пользователей такую работу делать не готовы.

Работающий гибрид

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

Связанные страницы

• positioning-vs-vision-gap - систему всё равно в итоге сводят к сценарию использования в одну строчку
• dogfooding-trap - продуктам от системы особенно полезно внешнее тестирование, потому что авторам примитивы кажутся очевидными
• type-system-axes - другая область, где ортогональные концепции смешиваются воедино