Мне не близка манера Антона Назарова. Я не подписана на его канал и не покупаю доступ к сообществу. Это важно понимать сразу, чтобы вы не искали тут фан-клуб. В своей прошлой статье я поделилась подходом к созданию личного бренда, а в этой решила разобрать его на примере кейса, который работает, даже если вызывает раздражение.
Антон Назаров - бывший инженер-разработчик с карьерой в EPAM, Electrolux, Grid Dynamics, Autodesk, Everli. Сейчас у него:
Опыт пользователя — понятие составное. В случае с ИТ-продуктами это и про логику интерфейсов, и про типографику, и про специфику дизайн-системы; наконец, в целом про то, как клиент воспринимает продукт, начиная с этапа его поиска/приобретения.
На уровне отдельных аспектов оценивать UX, UI и CX нам помогают те или иные виды исследований. Но когда речь идёт о разноплановых продуктах с различными пользовательскими сценариями, задумываешься об унификации. Возникает вопрос: можем ли мы оценивать опыт пользователя комплексно — по единым критериям и в рамках одной методологии?
В Сравни для решения этой задачи мы разработали и внедрили Product Score — скоринговую модель оценки UX, UI и CX. С её помощью получаем независимую оценку продуктов, формируем конкретные гипотезы по развитию пользовательского опыта и пополняем бэклог улучшений.
Под катом рассказываем, как устроен наш Product Score. И подробно раскрываем методологию оценки на практических примерах.
Моделирование поведения системы — это процесс создания упрощённого, формального или визуального представления динамики системы во времени, ее реакций на события и взаимодействий между компонентами.
Основные виды моделирования поведения:
1) Диаграммы поведения в UML
Продолжаю изучать различные UI/UX/CX кейсы в мобильных приложениях, веб-сайтах и в реальном мире. Дизайнерам и менеджерам по продукту, чтобы вдохновиться и добавить в заметки.
Под катом: Intsagram и его рекомендательные алгоритмы, Tinder и его парадокс.
Что такое JTBD
Jobs To Be Done, «Работы‑Которые‑Надо‑Сделать» — это маркетинговая теория о том, почему люди принимают те или иные решения о покупке. Эта теория помогает предпринимателям, компаниям, менеджерам и теоретикам лучше понимать потребности людей и создавать действительно нужные этим самым людям продукты...
Привет! Меня зовут Елена Тупикова, я академический руководитель программы онлайн-магистратуры от Яндекса и МФТИ «Управление IT-продуктами». В этой статье я расскажу о сфере управления IT-продуктами: о трендах, актуальных профессиях и навыках.
В прошлой своей статье “Сказ о том, как три разработчика сделали работу за шестерых и в два раза быстрее” я упомянул о положительных результатах, достигнутых с помощью системы приоритезации. Здесь же разберу подробнее этот вопрос.
FFF — методология, которая держит сроки и бюджет, даже когда всё идёт не по плану. Гибкий подход без сказок о всегда стабильной разработке. В статье – о том, почему, как и когда этот подход может сработать.
Срочно нужен человек — HR присылает резюме — быстренько интервью — берём. Через три месяца выясняется, что кандидат не подходит. Ещё месяц уходит на увольнение, потом снова поиск. В итоге полгода потеряно.
Эффективное управление ИТ-командой на примере взаимодействия популярных дирижеров и их оркестров. От Герберта фон Караяна до Леонарда Бернстайна: как принципы дирижирования помогут вам руководить ИТ-командой.
После того как мы определились с перечнем основных сценариев, выявили сущности предметной области и спроектировали для них хранилище, необходимо соотнести все эти артефакты друг с другом, распределив поведение системы по ее классам.
Как обычно зададим цели на следующий этап работ: На основании выявленных сущностей и процессов, разрабатываемого целевого продукта спроектировать поведение системы, распределив ее по классам.
Добавим на диаграмме, иллюстрирующей наш процесс, новый элемент – Модель поведения, связанный, как упоминалось выше, со Сценариями и Моделью данных.
Как упаковать веб-приложение в нативную обёртку, пройти модерацию и снова стать доступным в App Store и Google Play — без дублирования разработки.
За последние годы машинный перевод сделал серьёзный шаг вперёд. Если раньше он использовался в основном туристами, пытающимися объясниться с местными за границей, то сегодня его активно применяют в бизнесе. Особенно востребован он при переводе технической документации: благодаря объемам, прямому стилю и предсказуемой структуре, машинный перевод обеспечивает хорошее качество и позволяет существенно экономить ресурсы и поддерживать стабильное качество.
Но можно ли использовать машинный перевод в интерфейсе — самой чувствительной части продукта для пользователя?
Я управляю локализацией цифровых продуктов с акцентом на масштабирование процессов, их интеграцию в продуктовые циклы и соответствие бизнес-целям. Один из ключевых векторов моей работы — внедрение решений, ускоряющих выход продукта на международные рынки, включая стратегическое использование машинного перевода. В этой статье, опираясь на реальный кейс из своей практики, я расскажу, как выявить типичные ошибки нейронного машинного перевода в интерфейсах и понять, насколько такой подход подходит для вашего продукта. Это поможет принять взвешенное решение: можно ли использовать машинный перевод интерфейса вашего продукта без ущерба для качества локализации и пользовательского опыта.
В прошлой части мы разобрали:
1. Что техническая реализация заметно влияет на успехи бизнеса, хоть и не очень критично;
2. Что из всех аспектов технической реализации наибольший вклад в успех вносит именно архитектура;
3. Что самое важное свойство архитектуры — максимальная независимость команд друг от друга;
4. Что это свойство вытекает напрямую из двух фундаментальных характеристик программного обеспечения: coupling и cohesion, где coupling — характеристика связи двух точек системы/кодовой базы; а cohesion — характеристика того, насколько плотно упакованы такие связи в компоненты.
С этим багажом заканчиваем с теорией и переходим к практике. Теперь, когда мы знаем, что хорошо, а что плохо, необходимо понять, как этого добиться. Тут надо задать два вопроса с совершенно разными ответами:
1. Как не допустить появления связанной архитектуры и сразу сделать хорошо?
2. Как исправить уже связанную архитектуру?
В этой части постараюсь развернуто ответить именно на первый, оставив второй на десерт.
Привет, Хабр!
Если вы не разработчик и не понимаете, каким способом разработка определяет приоритет вашей задачи (спойлер: лунный календарь или ретроградный Меркурий к этому не имеют отношения), то эта статья будет вам полезна.
Если вы продакт-менеджер, который видел все в этой жизни, и отчаялся настолько, что уже готов приоритизировать бэклог по картам таро, то эта статья будет вам полезна.
Если вы разработчик и устали гореть от того, что задачи в бэклоге выстраиваются по пирамиде Маслоу или рандомайзеру, то эта статья будет вам полезна (как минимум, разбавите рутину на следующем стендапе).
В общем, в новом посте рассказываем про популярные способы для приоритизации бэклога команды разработки и почему мы запилили свой.
Привет! Меня зовут Катя Матвеева, я стажер ux-исследователь (исследователь цифровых интерфейсов) в дирекции digital мобильного оператора t2. В этом посте расскажу, как мы в дирекции смотрим на веб и мобильное приложение.
Спойлер: для нас это не конкуренты, а части единой стратегии.
Всем привет! Меня зовут Александр Бондаренко, работаю CPO в Garage Eight. Это следующая статья из цикла про то, как строить продукт. Как и другие современные компании, мы постоянно ищем способы улучшить свои продукты. Но бесконечные улучшения могут навредить. Почему? И где та точка, в которой нужно остановиться? Разбираю в статье.
— Победа любит подготовку, так говорят.
Одна компания решила пренебречь этим золотым стандартом. Внедрила в свою программу лояльности кэш-бэк. Люди покупают – копят баллы. Их можно будет потратить при следующей покупке.
Пару лет все шло неплохо. Пока аналитики не начали замечать – покупки с бонусными баллами натурально сжирают пол маржи. В реальных деньгах – 15-20 млн каждый месяц.
Из этих же баллов на заднем дворе “склада аналитики и данных” началась вырисовываться натурально горы “токсичных отходов”. Кэш-бэка у пользователей за пару лет накопилось примерно на 500 млн. рублей.
— Это что, все отдать надо? — Возник в головах молчаливый вопрос. А за ним последовали мысли о скорейшем увольнении. Слинять, пока никто ничего не заметил…
Начали чесать затылок. Цугцванг никак не решался:
Цель этой статьи — показать, в каких случаях Agile не принесет ожидаемого эффекта, рассмотреть наиболее распространенные случаи его некорректного применения и обозначить ключевые моменты, на которые важно обратить внимание перед началом Agile-трансформации.
В какой-то момент всё становится серьёзным — даже в приложениях про любовь. Команда Redspell, создатели игры Senses (интерактивные романтические истории), решили стать одними из первых, кто интегрировал новую платёжку от RuStore — Pay SDK. И встроили — с нуля, но в итоге с ростом метрик.
Вот честный рассказ о том, как ребята внедряли RuStore Pay SDK, что пошло не так, как с этим справились и какие результаты в итоге получили. Если вы тоже раздумываете, стоит ли связываться — читайте до конца. Там есть приятные цифры.
