UX долг a.k.a. Papercuts

· 2 мин

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

Я использую эту же концепцию для описания “UX debt” - дизайнерского или продуктового долга. Это те места в пользовательском интерфейсе, где мы срезали углы. Здесь пользователю нужно сделать один лишний шаг, тут немного кривая валидация формы, там кнопка чуть-чуть не вписывается по ширине. И т.п.

Все эти проблемы по отдельности - не такие существенные, но кумулятивно они - как порезы от бумаги. Резаться бумагой хоть и неприятно, но не смертельно. Однако, если на тело нанести тысячу порезов бумажками, то наступит то, что называется “death by a thousand papercuts”. Поэтому такие мелкие проблемы получили название “papercuts” и смерть от них вполне реальна.

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

Но как приоритизировать все эти мелкие порезы, если у тебя амбициозный roadmap, ограниченные ресурсы и эта мелочь не вписывается в большие цели?

  • Можно делать то же, что разработка делает с техническим долгом. В каждом цикле планирования (квартал/месяц/спринт) выделять определённый процент ресурсов (=времени разработчиков) на то, чтобы брать из бэклога papercuts и фиксить их. Один за другим, постепенно избавляясь от мелких недочётов.
  • Можно накидывать их в планы как задачи с низким приоритетом. Мы это называем “бонусными задачами”. Сделал большое дело - смело пофикси какое-нибудь маленькое, раз свободен.
  • В команде с полноценными онколл ротациями у разработчиков может быть свободное время во время онколла, когда они не занимаются разруливанием упавших систем и пострадавших пользователей. Это свободное время они могут исползовать на то, чтобы фиксить технический долг и papercuts.
  • Хакатон-фиксатон. Можно на неделю остановить работу над фичами и бросить все усилия на то, чтобы пофиксить долг.

Всё, что я перечислил - достаточно распространённые подходы к техническому долгу, которые можно распространить и на другие области продукта, куда обычно не доходят руки. Те, что растут из того же места, что и ноги, как у осьминога 🐙