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