Экспертиза в домене
До сих пор встречаю дизайнеров, которые искренне стараются делать полезный продукт, но при этом полностью фокусируются на точечном пользовательском опыте, забывая о внутренней механике продукта: на чём зарабатывает компания, какие у неё цели, как выглядит рабочий процесс у клиента в реальной жизни. Всё это влияет на то, что и как мы проектируем. Особенно когда это касается профессиональных систем, где интерфейс – это средство ускорить и обезопасить процессы.
Когда ты не вникаешь в предметную область, когда ты не понимаешь, где теряются деньги и время, где часто факапят, где принятие решения идёт дольше, чем хотелось бы, ты не cможешь спроектировать эффективный инструмент. Получится поверхностный продукт, в который мы вложили силы на ненужные улучшения и сделали его сложнее, не заметив реальные проблемы. Каждое твоё решение должно рождаться из задач бизнеса и пользователей.
Ведь когда ты получаешь эти знания, ты начинаешь видеть логику за действиями, ты понимаешь, где нужно автоматизировать, где добавить предупреждение, а где просто не мешать человеку работать и не влезать с улучшениями.
В нашем продукте это проявилось на примере работы с заказами. Когда я только начал знакомиться с продуктом, меня смутила жесткая последовательность из вложенных сущностей «заказы → заказ → заявка → рейс», но что сами пользователи, что команда на тот момент не осознавали потерю контекста и замедление работы, потому что первые привыкли так работать и не жаловались (почти всё смежное ПО с аналогичной структурой), а вторые – не видели полной логики действий пользователей внутри бизнес-процессов.
И лишь когда мы глубже освоили доменную область и погрузились в реальный рабочий сценарий логиста, собрали набор его основных и частых действий, стали очевидны точки, где процесс можно упростить.
Эти знания привели к решению сделать навигацию сквозной: со страницы таблицы заказов можно сразу попасть в нужный заказ, а оттуда – к конкретной заявке или рейсу, обходя промежуточные шаги. Опыт логиста поменялся кардинально в лучшую сторону.
Само собой, это сказалось и на самой компании-клиенте: выросла пропускная способность логиста, снизились операционные затраты, а более быстрые реакции на ход торгов или инциденты во время перевозки снизили риск нарушения SLA.
Когда ты не вникаешь в предметную область, когда ты не понимаешь, где теряются деньги и время, где часто факапят, где принятие решения идёт дольше, чем хотелось бы, ты не cможешь спроектировать эффективный инструмент. Получится поверхностный продукт, в который мы вложили силы на ненужные улучшения и сделали его сложнее, не заметив реальные проблемы. Каждое твоё решение должно рождаться из задач бизнеса и пользователей.
Ведь когда ты получаешь эти знания, ты начинаешь видеть логику за действиями, ты понимаешь, где нужно автоматизировать, где добавить предупреждение, а где просто не мешать человеку работать и не влезать с улучшениями.
В нашем продукте это проявилось на примере работы с заказами. Когда я только начал знакомиться с продуктом, меня смутила жесткая последовательность из вложенных сущностей «заказы → заказ → заявка → рейс», но что сами пользователи, что команда на тот момент не осознавали потерю контекста и замедление работы, потому что первые привыкли так работать и не жаловались (почти всё смежное ПО с аналогичной структурой), а вторые – не видели полной логики действий пользователей внутри бизнес-процессов.
- Логист не сидит на одном заказе, а работает одновременно с несколькими: группой отправить в торги, отфильтровать по необработанным заявкам (обязательство на перевозку) и быстро посмотреть каждый на содержание документов в каждой.
- Инцидент по рейсу или заказу часто требует одновременного доступа к логам рейса, контактам исполнителя и условиям заказа, а такая вложенность заставляла открывать всё это в отдельных вкладках.
- Логисты часто отвлекаются на телефонные звонки или сообщения от водителей, а последовательная навигация требовала «воскрешения» предыдущего контекста работы.
- Каждый дополнительный шаг – шанс допустить ошибку и выбрать неправильный объект.
И лишь когда мы глубже освоили доменную область и погрузились в реальный рабочий сценарий логиста, собрали набор его основных и частых действий, стали очевидны точки, где процесс можно упростить.
Эти знания привели к решению сделать навигацию сквозной: со страницы таблицы заказов можно сразу попасть в нужный заказ, а оттуда – к конкретной заявке или рейсу, обходя промежуточные шаги. Опыт логиста поменялся кардинально в лучшую сторону.
Само собой, это сказалось и на самой компании-клиенте: выросла пропускная способность логиста, снизились операционные затраты, а более быстрые реакции на ход торгов или инциденты во время перевозки снизили риск нарушения SLA.
Обновлённая навигация заказов
Всё это и есть стык бизнеса и пользователя – конкретные процессы конкретных людей, где деньги, время и человеческий труд пересекаются.
Понятное дело, что у компании-клиента и её сотрудника разные цели. Продукту важно расти: увеличивать выручку, проводить больше заказов через наш продукт, снижать издержки и экономить. Пользователю же важно не ошибаться, не тратить время впустую и чувствовать уверенность. Иногда эти цели совпадают, а иногда – нет. И ты должен это видеть. Понимать, где интерфейс работает на бизнес, но вредит опыту (вспомни отмену подписки Плюса у Яндекса), и наоборот – где забота о пользователе тормозит рост.
Баланс между этими точками и есть наша работа – видеть обе стороны, учитывать интересы двух сторон и находить решение, которое работает в контексте продукта.стали очевидны точки, где процесс можно упростить.
Например, в Тракере мы не оставляем знание о логистике на совести каждого. У нас есть конкретные инструменты, которые помогают команде понимать, как устроены ключевые процессы, учитывать важные нюансы при выполнении перевозки, следить за изменениями в законодательстве и правилах рынка. Эти практики не просто для галочки, а необходимая база, чтобы делать качественный продукт.
Понятное дело, что у компании-клиента и её сотрудника разные цели. Продукту важно расти: увеличивать выручку, проводить больше заказов через наш продукт, снижать издержки и экономить. Пользователю же важно не ошибаться, не тратить время впустую и чувствовать уверенность. Иногда эти цели совпадают, а иногда – нет. И ты должен это видеть. Понимать, где интерфейс работает на бизнес, но вредит опыту (вспомни отмену подписки Плюса у Яндекса), и наоборот – где забота о пользователе тормозит рост.
Баланс между этими точками и есть наша работа – видеть обе стороны, учитывать интересы двух сторон и находить решение, которое работает в контексте продукта.стали очевидны точки, где процесс можно упростить.
Например, в Тракере мы не оставляем знание о логистике на совести каждого. У нас есть конкретные инструменты, которые помогают команде понимать, как устроены ключевые процессы, учитывать важные нюансы при выполнении перевозки, следить за изменениями в законодательстве и правилах рынка. Эти практики не просто для галочки, а необходимая база, чтобы делать качественный продукт.
Источник и формат на любой вкус
Компания максимально заинтересована в том, чтобы вся(!) продуктовая команда одинаково хорошо понимали, как работает бизнес, какие задачи стоят перед пользователями, что меняется в законах и внутренних правилах. Потому что чем глубже ты в контексте, тем точнее решения, быстрее диалог и выше ценность твоей работы.
Пришёл к нам и ничего не знаешь о логистике? Проведём несколько продуктовых онбордингов, более опытные сотрудники подскажут на ревью тонкие моменты, а кто-то поделится интересным сценарием с производства клиента во время сбора в зуме. Хочешь углубиться в нюансы? У нас есть Reading Club, записанные демо и внутренние воркшопы. Мы даже несколько раз выезжали прямо на производство к компании-клиенту, чтобы посмотреть на то, как с нашим продуктом работают пользователи в реальных условиях.
Пришёл к нам и ничего не знаешь о логистике? Проведём несколько продуктовых онбордингов, более опытные сотрудники подскажут на ревью тонкие моменты, а кто-то поделится интересным сценарием с производства клиента во время сбора в зуме. Хочешь углубиться в нюансы? У нас есть Reading Club, записанные демо и внутренние воркшопы. Мы даже несколько раз выезжали прямо на производство к компании-клиенту, чтобы посмотреть на то, как с нашим продуктом работают пользователи в реальных условиях.
Трансфер знаний в Trucker TMS
А зачем так глубоко погружаться? Всё равно ведь потом поменяешь компанию и эти знания для меня теперь с нулевой ценностью. Ну, отчасти это так. Знания из каких-то узких областей действительно могут не пригодиться на новом месте, но то, что точно останется с тобой – это навык разбираться в устройстве компании и её продукта, не бояться влезать в отчёты, процессы, задавать вопросы на любом этапе любому участнику и просить то, что тебе необходимо, чтобы сделать свою работу хорошо. Даже если кажется, что эти знания не универсальны, они всё равно становятся частью твоей насмотренности. Только не визуальной, а смысловой.
Поверь, если ты захочешь понять как принимаются решения, где у компании риски, как работает экономика продукта, эта насмотренность станет твоим инструментом в налаживании контакта со стейкхолдерами, в грамотном формулировании гипотез, а главное – давать рекомендации, которые работают здесь и сейчас, даже если завтра ты окажешься в другой компании с продуктом из другой области.
И это не делает тебя продуктовым менеджером. Это делает тебя дизайнером, который работает в системе продукта. Ты не просто передаёшь очередной артефакт по задаче, а понимаешь, откуда и почему она вообще появилась и можешь предложить лучшее решение, от которого выиграют все.
Поверь, если ты захочешь понять как принимаются решения, где у компании риски, как работает экономика продукта, эта насмотренность станет твоим инструментом в налаживании контакта со стейкхолдерами, в грамотном формулировании гипотез, а главное – давать рекомендации, которые работают здесь и сейчас, даже если завтра ты окажешься в другой компании с продуктом из другой области.
И это не делает тебя продуктовым менеджером. Это делает тебя дизайнером, который работает в системе продукта. Ты не просто передаёшь очередной артефакт по задаче, а понимаешь, откуда и почему она вообще появилась и можешь предложить лучшее решение, от которого выиграют все.
