Max Ischenko

Здається немає більш невдячної і одночасно привабливої роботи ніж редизайн.

Trello (Atlassian) викатив новий дизайн, на який плюється вся команда і я перший.

Мені як продакту завжди цікаво зрозуміти як приймаються подібні рішення і які висновки можна з цього зробити. “вчиться на чужих помилках”.

1/ efforts != results

Редизайн часто перетворюється на sink cost fallacy: його релізять не тому, що він покращує метрики або вирішує бізнес задачу, а тому що дуже довго команда над ним працювала, витратила багато часу й зусиль.

Те, що ви довго працювали над фічою або проєктом не означає, що його треба релізити.

Те, що ви довго працювали над фічою або проєктом не означає, що його треба релізити.

Те, що ви довго працювали над фічою або проєктом не означає, що його треба релізити.

2/ shipped != done

Те, що ви “релізнули” фічу, не означає що вона “готова”. Часто це означає, що справжня робота тільки починається бо у вас зʼявляється реальний фідбек.

Інше питання чому цього фідбеку не було раніше–feature previews, limited rollouts, etc.

Скоріш за все цей фідбек був, але
“це наш інноваційний дизайн”
“юзери не експерти, вони не розуміють”
“вони звикнуть”

Компанії рідко мають сміливість “вбити” реліз, бо це політично дорого–на тебе образяться всі, хто над цим проєктом працював.

Замість висновку

Перш ніж починати редизайн чи будь який новий проєкт треба знайти відповіді на три простих питання: яку проблему ми вирішуємо? Звідки ми знаємо що це дійсно проблема? Як ми дізнаємось, що наше рішення дійсно її вирішує?

Якщо на ці питання немає зрозумілих відповідей то можливо не варто це проєкт починати. Або принаймні релізити на всю свою 50М аудиторію.