На мой взгляд, команды как раз чаще склонны упрощать идеи. Не хотят рисковать и не хотят усложнять себе жизнь. Но, в конечном счете, и смелые идеи не должны становиться самоцелью.
У фреймворка нет цели фокусировать вас на сложных и рискованных задачах. Он только помогает понять, где идея находится на шкале SAFE-BOLD. А дальше уже ваш стратегический выбор: попробовать найти более инновационное решение, или наоборот поискать более очевидное.
А как делить ресурсы между простыми задачами и инновационными – это уже вопрос управленческой работы.
Хороший вопрос! BOLD-идеи — это смелые, амбициозные шаги, которые могут радикально изменить игру: открыть новые возможности, выделить вас среди конкурентов и принести долгосрочный рост. Они заметны, вдохновляют и дают конкурентное преимущество в среде, где сотни голодных игроков борются за внимание. SAFE-идеи — это безопасные, постепенные улучшения, которые хороши, если ресурсы ограничены, риски недопустимы или отрасль консервативна (например, естественные монополии или госкомпании). Но часто SAFE выбирают просто из страха "как бы чего не вышло" (у Даниэля Канемана в Теории перспектив это описано, как склонность к избеганию потерь), что в долгосрочной перспективе может стать проигрышной стратегией для коммерческой компании. BOLD требует смелости и расчета, но именно такие идеи двигают прогресс и выделяют лидеров.
У вас интересный подход, но мне кажется, что его применимость в реальных условиях ограничена. Вы используете синтетические данные, предполагая отсутствие внешних искажений. Например, вы делаете предпосылку, что «увеличение комплектности сопровождалось снижением списаний», что может быть далеко от реальности.Возможно, стоит проверить гипотезу на реальных данных, даже если они будут «шумными». Также было бы интересно узнать, как вы предлагаете учитывать в модели такие факторы, как сезонность или изменения в поведении клиентов.
А/Б тесты внешне просты, но это не означает, что результата легко добиться. Меньше 15% тестов в зрелых командах приводят к значительным результатам. Искажение распределения трафика по вариантам на 0,2% уже искажает результат тестирования. Даже при наличии выигрышного результата у вас есть почти 26% вероятности, что результат неверен. И как говорил генеральный директор Airbnb Брайан Чески: «А/Б-тестирование — это отказ от ответственности перед пользователями.» Полная его цитата звучит так: «А/Б-тестирование — это отказ от ответственности перед пользователями. Если вы собираетесь проводить A/B-тестирование, оно должно быть основано на гипотезах. Если это сработает, вы должны быть в состоянии сказать, почему, а не только что».
Ваше заключение: "...мы правильно сформулировали гипотезу, выбрали оптимальное соотношение процента прироста и длительности эксперимента, а также определили наиболее подходящее распределение аудитории " — кажется мне скорее попыткой выдать желаемое за действительное, нежели выводом основанным на реальных фактах. Вся статья больше похожа на попытку разобраться в самом подходе к проведению эксперимента. А содержание проводимого эксперимента, вообще, очень сомнительным. Возможно, руководство недостаточно критично отнеслось к вашей работе и этому материалу, только этим я могу себе объяснить появление и первого и второго.
Спасибо за статью. У меня есть несколько замечаний, может вы их сможете прокомментировать. Непонятно всё-таки, почему была выбрана визуализация данных на карте, а не на дашбордах. Ведь для управленческих решений структурированные дашборды удобнее: на них можно показать динамику во времени, вывести прогнозные значения из аналитических моделей, да и просто места больше. И даже если выбрали карту, кажется, что профессиональнее было бы использовать не карту общего назначения, а схему железнодорожной сети. Так было бы меньше визуального шума, и можно было бы обеспечить большую плотность элементов.
А что чаще сейчас используете для требовательных случаев ProtoPie, Axure или что-то другое? Я просто в обоих работаю и, на мой взгляд, они очень разные по ресурсоемкости и то, что в одном сделать легко, то во втором будет слелать можно, но сложно.
Мне казалось, что в продукте с миллионами клиентов мелких задач не бывает, а черти как раз в деталях и прячутся. Тем более, если посмотреть на сценарии с точки зрения времени прохождения флоу, то на клавиатурный ввод уходит огромная его часть, и во время ввода возникает разное количество дополнительных сценариев (валидация, фокус ввода, видимая область, быстрые результаты, подсказки и т.д.).
Из вашего ответа я понял, что вы для требовательных прототипов просто берете другой инструмент и как я понял бизнес-заказчику надо вас аргументировано убедить, что простого прототипа в Figma будет недостаточно и нужно капнуть глубже. Или Figma всегда хватает?
Спасибо за пример. Меня смущает, что из-за ограничений Figma, невозможно сделать в прототипе ввод данных с клавиатуры (у вас это ситуация при поиске банка или вводе суммы), и это ограничивает функциональность (нет реального поведения элементов, трудно реализовать проверку ошибок в условиях естественного поведения). Как вы объясняете бизнес-заказчику, что в прототипе такой функционал не нужен? Ведь можно было бы взять другой инструмент и все это реализовать.
Реализация важна. Информационная архитектура не снимает вопросы реализации. Да и в рамках проработки IA вы не сможете описать и зафиксировать цели и задачи для сотен блоков, из которых состоит обычный сайт. Там хотя бы со структурой разобраться, вложенностью и иерархией. Бизнес неохотно обсуждает такие вещи. А если вы становитесь человеком, который без фиксации IA не делает следующий шаг, то ваше место занимает более сговорчивый дизайнер. Для меня уточнее требований на основе прототипов - это здоровой компромисс, когда и далеко от смысла не уходим и при этом уже видно, что получится.
Иногда очень непросто отказываться от привычного интерфейса, а еще SEO противодействует опасаясь любых изменений. Но для сайтов, где нет глубокой вложенности, можно полностью отказываться от хлебных крошек. Очень во многих случаях можно обойтись одной стрелочкой "Назад".
Все-таки нельзя подменять параметры, кроме случаев, когда хочется что-то подделать. Я про время чтения спросил исходя из того, что оно может коррелировать (а может и нет) с результатами теста на понятность, накину гипотезу, что те, кто читает медленнее (вдумчивее), отвечают на итоговые вопросы лучше не зависимо от того, какое форматирование страницы.
Иллюстрации хорошие, но вместе с их заменой из приложения выкидываются не менее хорошие вещи.
Вот о ценностях: в старом варианте, когда «ничего не нашлось» пользователю предлагали помощь, а в новом просто разводят красиво руками и все действия оставляют на откуп самого пользователя. Так сказать, оптимизировали нагрузку на службу поддержки и стали немного безразличнее. История с экраном про любимые товары тоже немного похожа: в старой версии он учил пользователя, в новой он в меньше на этом акцентируется и ушел в иллюстративность.
Кажется, что учитывая ожиданиия от стажеров, можно было бы обойтись запросом портфолио и одним разговором с теми, у кого есть, что вменяемое показать. А не создавать для себя объемную задачу по просмотру 130 работ, чтению тысячи страниц текста (как Войну и мир прочитать) и формальному ранжированию результатов.
Лично для меня всегда была важна мотивировка кандидата. Мне кажется, что человек, который хочет с тобой работать в тысячу раз полезнее того, кто что-то знает. Знания легко набрать, а вот горящие глаза - они или есть или их нет. И только на личной встрече можно это понять.
Основная идея в том, что перед тем, как спроектировать интерфейс нужно пройти еще каки-то шаги. И когда хочется включить в работу команду, чтобы получить синергию участников, то нужны промежуточные артефакты, которые можно обсуждать и которые обеспечивают разную степень детализации проекта. И все вместе обеспечивает надежный результат.
Ожидание понятно, но боюсь, что просто примеров будет недостаточно. Это надо писать с детальными объясненинями, а это уже может превратиться в учебное пособие. А до такого я еще не созрел.
На мой взгляд, команды как раз чаще склонны упрощать идеи. Не хотят рисковать и не хотят усложнять себе жизнь. Но, в конечном счете, и смелые идеи не должны становиться самоцелью.
У фреймворка нет цели фокусировать вас на сложных и рискованных задачах. Он только помогает понять, где идея находится на шкале SAFE-BOLD. А дальше уже ваш стратегический выбор: попробовать найти более инновационное решение, или наоборот поискать более очевидное.
А как делить ресурсы между простыми задачами и инновационными – это уже вопрос управленческой работы.
Хороший вопрос! BOLD-идеи — это смелые, амбициозные шаги, которые могут радикально изменить игру: открыть новые возможности, выделить вас среди конкурентов и принести долгосрочный рост. Они заметны, вдохновляют и дают конкурентное преимущество в среде, где сотни голодных игроков борются за внимание. SAFE-идеи — это безопасные, постепенные улучшения, которые хороши, если ресурсы ограничены, риски недопустимы или отрасль консервативна (например, естественные монополии или госкомпании). Но часто SAFE выбирают просто из страха "как бы чего не вышло" (у Даниэля Канемана в Теории перспектив это описано, как склонность к избеганию потерь), что в долгосрочной перспективе может стать проигрышной стратегией для коммерческой компании. BOLD требует смелости и расчета, но именно такие идеи двигают прогресс и выделяют лидеров.
Попытка навешивать ярлыки на всех подряд - это очень манипулятивная техника. Вы сейчас весь корпус авторов Researchgate назвали шарлатанами.
У вас интересный подход, но мне кажется, что его применимость в реальных условиях ограничена. Вы используете синтетические данные, предполагая отсутствие внешних искажений. Например, вы делаете предпосылку, что «увеличение комплектности сопровождалось снижением списаний», что может быть далеко от реальности.Возможно, стоит проверить гипотезу на реальных данных, даже если они будут «шумными». Также было бы интересно узнать, как вы предлагаете учитывать в модели такие факторы, как сезонность или изменения в поведении клиентов.
А/Б тесты внешне просты, но это не означает, что результата легко добиться. Меньше 15% тестов в зрелых командах приводят к значительным результатам. Искажение распределения трафика по вариантам на 0,2% уже искажает результат тестирования. Даже при наличии выигрышного результата у вас есть почти 26% вероятности, что результат неверен. И как говорил генеральный директор Airbnb Брайан Чески: «А/Б-тестирование — это отказ от ответственности перед пользователями.»
Полная его цитата звучит так: «А/Б-тестирование — это отказ от ответственности перед пользователями. Если вы собираетесь проводить A/B-тестирование, оно должно быть основано на гипотезах. Если это сработает, вы должны быть в состоянии сказать, почему, а не только что».
Ваше заключение: "...мы правильно сформулировали гипотезу, выбрали оптимальное соотношение процента прироста и длительности эксперимента, а также определили наиболее подходящее распределение аудитории " — кажется мне скорее попыткой выдать желаемое за действительное, нежели выводом основанным на реальных фактах. Вся статья больше похожа на попытку разобраться в самом подходе к проведению эксперимента. А содержание проводимого эксперимента, вообще, очень сомнительным. Возможно, руководство недостаточно критично отнеслось к вашей работе и этому материалу, только этим я могу себе объяснить появление и первого и второго.
Спасибо за статью. У меня есть несколько замечаний, может вы их сможете прокомментировать.
Непонятно всё-таки, почему была выбрана визуализация данных на карте, а не на дашбордах. Ведь для управленческих решений структурированные дашборды удобнее: на них можно показать динамику во времени, вывести прогнозные значения из аналитических моделей, да и просто места больше.
И даже если выбрали карту, кажется, что профессиональнее было бы использовать не карту общего назначения, а схему железнодорожной сети. Так было бы меньше визуального шума, и можно было бы обеспечить большую плотность элементов.
Сделайт тогда статью и с ProtoPie, чтобы было понятнее, как вы используете его для прототипов и в каких случаях.
А что чаще сейчас используете для требовательных случаев ProtoPie, Axure или что-то другое? Я просто в обоих работаю и, на мой взгляд, они очень разные по ресурсоемкости и то, что в одном сделать легко, то во втором будет слелать можно, но сложно.
Мне казалось, что в продукте с миллионами клиентов мелких задач не бывает, а черти как раз в деталях и прячутся. Тем более, если посмотреть на сценарии с точки зрения времени прохождения флоу, то на клавиатурный ввод уходит огромная его часть, и во время ввода возникает разное количество дополнительных сценариев (валидация, фокус ввода, видимая область, быстрые результаты, подсказки и т.д.).
Из вашего ответа я понял, что вы для требовательных прототипов просто берете другой инструмент и как я понял бизнес-заказчику надо вас аргументировано убедить, что простого прототипа в Figma будет недостаточно и нужно капнуть глубже. Или Figma всегда хватает?
Спасибо за пример. Меня смущает, что из-за ограничений Figma, невозможно сделать в прототипе ввод данных с клавиатуры (у вас это ситуация при поиске банка или вводе суммы), и это ограничивает функциональность (нет реального поведения элементов, трудно реализовать проверку ошибок в условиях естественного поведения). Как вы объясняете бизнес-заказчику, что в прототипе такой функционал не нужен? Ведь можно было бы взять другой инструмент и все это реализовать.
Реализация важна. Информационная архитектура не снимает вопросы реализации. Да и в рамках проработки IA вы не сможете описать и зафиксировать цели и задачи для сотен блоков, из которых состоит обычный сайт. Там хотя бы со структурой разобраться, вложенностью и иерархией. Бизнес неохотно обсуждает такие вещи. А если вы становитесь человеком, который без фиксации IA не делает следующий шаг, то ваше место занимает более сговорчивый дизайнер. Для меня уточнее требований на основе прототипов - это здоровой компромисс, когда и далеко от смысла не уходим и при этом уже видно, что получится.
Иногда очень непросто отказываться от привычного интерфейса, а еще SEO противодействует опасаясь любых изменений. Но для сайтов, где нет глубокой вложенности, можно полностью отказываться от хлебных крошек. Очень во многих случаях можно обойтись одной стрелочкой "Назад".
Ну в вашем примере, это было бы, как если бы добавить к pdf вариант pdf high-res. Но сработало бы это только в ситуации, когда на это есть спрос.
Все-таки нельзя подменять параметры, кроме случаев, когда хочется что-то подделать. Я про время чтения спросил исходя из того, что оно может коррелировать (а может и нет) с результатами теста на понятность, накину гипотезу, что те, кто читает медленнее (вдумчивее), отвечают на итоговые вопросы лучше не зависимо от того, какое форматирование страницы.
Спасибо за статью. У меня есть небольшой вопрос: Почему среднее время чтения не учитывалось, как параметр?
Иллюстрации хорошие, но вместе с их заменой из приложения выкидываются не менее хорошие вещи.
Вот о ценностях: в старом варианте, когда «ничего не нашлось» пользователю предлагали помощь, а в новом просто разводят красиво руками и все действия оставляют на откуп самого пользователя. Так сказать, оптимизировали нагрузку на службу поддержки и стали немного безразличнее. История с экраном про любимые товары тоже немного похожа: в старой версии он учил пользователя, в новой он в меньше на этом акцентируется и ушел в иллюстративность.
Кажется, что учитывая ожиданиия от стажеров, можно было бы обойтись запросом портфолио и одним разговором с теми, у кого есть, что вменяемое показать. А не создавать для себя объемную задачу по просмотру 130 работ, чтению тысячи страниц текста (как Войну и мир прочитать) и формальному ранжированию результатов.
Лично для меня всегда была важна мотивировка кандидата. Мне кажется, что человек, который хочет с тобой работать в тысячу раз полезнее того, кто что-то знает. Знания легко набрать, а вот горящие глаза - они или есть или их нет. И только на личной встрече можно это понять.
Основная идея в том, что перед тем, как спроектировать интерфейс нужно пройти еще каки-то шаги. И когда хочется включить в работу команду, чтобы получить синергию участников, то нужны промежуточные артефакты, которые можно обсуждать и которые обеспечивают разную степень детализации проекта. И все вместе обеспечивает надежный результат.
Ожидание понятно, но боюсь, что просто примеров будет недостаточно. Это надо писать с детальными объясненинями, а это уже может превратиться в учебное пособие. А до такого я еще не созрел.