Как сделать дизайн сайта через призму UX? Без танцев с бубном, SMS и регистрации
С чего начинается работа по дизайну сайта? Почему Вася делает дизайн за 30 тысяч, Лена — за 150 тысяч, а известная студия — за 1 миллион? Почему конкурент сделал сайт за 200 тысяч, а мой будет стоить 500? И можно ли вообще сделать сайт раз и навсегда, без всяких этих этапов согласования и правок?
Я — Лена, дизайнер, и сегодня поговорим о том, как по уму (моему, конечно) стоит делать проекты по веб-дизайну. Конечно, не всегда есть возможность и время сделать четко по этой инструкции. Но именно так вы достигнете максимальной эффективности при адекватном бюджете.
Зачем я написала сие?
“А как ты делаешь дизайн?” — самый популярный вопрос у моих заказчиков. Да и коллеги тоже часто его задают. Причем, только половина заказчиков действительно включается в процесс, следит за всеми этапами, запрашивает примеры. Остальные, чаще всего, делают вид, что понимают структуру работы, но по глазам читается желание найти мне подходящий костер. А ведьма не ругается, ведьма просто так работает.
А как же? Сейчас расскажу.
Вводные данные
Представим себе некоего заказчика в вакууме, который пришел со своей идеей. В лучшем случае, у него есть небольшое ТЗ и несколько зарисовок ручкой (влитых в Figma, Miro или GDocs).
Ему нужен дизайн стартапа: веб-версия, 2 приложения и немного макулатуры для инвесторов. С чего же начать? Нет, не с фейспалма. Уверяю — такое встречается сплошь и рядом. Нацепив дежурную улыбку, я отправляю в бой менеджера проектов (с навыками UX) и иду пить кофе в ближайший Старбакс, на время забывая о заказчике.
Шаг 1. Разбираем проект.
Итак, PM, одаренный широким кругозором, усиленно пытается понять, с чем едят полученный проект. Иногда в разговоре с заказчиком приходится скатываться до очевидностей: «Почему треугольничек не вставляется в круглое отверстие, нипанимаааааюююю…»
Итогом этапа, в идеале, должно стать:
- flow или короткое ТЗ на проект;
- базовый прототип с основным функционалом;
- краткое и емкое пояснение: для чего делается проект, какие есть конкуренты, как планируется монетизация, основные плюсы и минусы запуска проекта.
Что могу посоветовать:
- не пренебрегайте созвоном или личной встречей с клиентом. Даже если ваша интроверсия приобретает критические масштабы. За время карантина (ох, простите, самоизоляции) я встретилась как минимум с 3 ситуациями, когда часовые переписки составляли исключительно неверное представление о проекте. И да, не столкнувшись с этим, я бы сама себе не поверила.
не стесняйтесь задавать глупые вопросы. Порой самый глупый вопрос может открыть невиданные ранее грани проекта.
- составьте чеклист того, что вы хотите получить от клиента. И не продолжайте проект, пока не получите всё.
если на этом этапе даже вы понимаете что проект не взлетит, и промдизайн летающего ТС в виде топора очевиден только вам, попробуйте мягко убедиться в том что вы поняли все верно (селф-тест на дурака): наглядно представьте топор заказчику. Если ваш оппонент не видит ничего зазорного в происходящем — акститесь, лучше отказаться, чем получить минус в карму.
Шаг 2. Пилим сырые прототипы, изучаем конкурентов & составляем CJM
На этом этапе я обсуждаю с командой и заказчиком сырые прототипы. Все происходящее постепенно обрастает подробностями. И как раз тут нужен профессионализм всех участников. В этот момент понимаешь, почему менеджер проектов, которому ты платишь 1500 в час, отрабатывает их на 150% — и даже немножечко больше.
Затем сравниваем то, что получилось, с конкурентами. Иногда они есть — но чаще всего нет. И даже похожего ничего нет. Стартапы — штука веселая, да. В таком случае ищем аналогии, другие сервисы со схожей моделью работы (и из других тематик тоже). Сравниваем логику, упрощаем, составляем листы сравнений с конкурентами и псевдоконкурентами, дорабатываем прототип.
Наступает время создавать CJM. Приветствую UX инженера, аналитика... И хотела бы я сказать, что снова ухожу пить кофе — но нет. Втроем мы собираем группы клиентов, согласовываем с заказчиком, вживаемся в роли/приглашаем респондентов, раскладываем прототипы и начинаем штормить. В подробностях посмотреть, как создавать CJM, можно, например, тут https://vc.ru/marketing/96029-instrukciya-po-sostavleniyu-customer-journey-map-cjm. Созданию CJM я могу посвятить отдельный лонгрид и это обязательно когда-нибудь произойдет.
В итоге имеем:
- прототипы v2;
- обзор конкурентов;
- CJM.
Только после этого шага можно сказать, что мы подобрались напрямую к работе над дизайном сайта.
Шаг 3. Делаем прототип и UX копирайтинг
Все прототипы, которые мы делали до этого, можно назвать базовыми. Теперь мы создаем финальный прототип, на основании которого будем делать опрос ЦА и — после доработки — дизайн.
Тут все очевидно — если нужно нечто “вау”, берем Digital Producer и UX Copywriter. Если нет — можно обойтись своими силами. Превращаем литры кофе в кликабельный прототип, который закрывает максимум потребностей по CJM. Да, кажется Старбакс уже должен оформить мне программу лояльности.
Кстати — многие спрашивают, кто такой UX копирайтер, и почему он столько стоит. Этот персонаж, в первую очередь — психолог и UX аналитик, и лишь во вторую — человек пера. Он обладает знаниями о поведении пользователей и умеет работать с прототипами и CJM. Текст, написанный UX'ером, упрощает пользовательский путь и, в целом, быстрее ведет к понятной юзеру конверсии.
Получившийся детализированный прототип + тексты уже похожи на дизайн, и все созданное можно смело закидывать в ЦА, подкрепляя вопросами аналитика. По ответам — дорабатываем.
Итого, после этого этапа мы имеем:
- прототип в деталях;
- листы опросов;
- тексты — на прототипе и в отдельных файлах.
Шаг 4. Дизайн и иллюстрации
Ура! Наконец-то мы подобрались непосредственно к дизайну! На основании конкурентов, best practices, хотелок клиента, желаний левой пятки в полнолуние — рисуем дизайн и иллюстрации. Порой обсуждаем. Порой до 20+ раз одну страницу (реальная цифра: привет, Антон!). На серьезных проектах, которыми пользуются тысячи людей, количество обсуждений не имеет решающего значения — важен исключительно результат.
Обсуждаем итоговый дизайн с клиентом, тестируем на ЦА, дорабатываем.
Получается:
- кликабельный дизайн в Figma (320px+768px+1140px+big);
- иллюстрации в векторе;
- геморрой у арт-директора (ладно-ладно, не всегда)
Шаг 5. ТЗ для верстальщика и ревью
Уф, один из самых сложных этапов. Нужно собрать весь наш супердизайн и максимально толково объяснить верстальщику, чего мы от него хотим. Иногда такое ТЗ занимает больше страниц, чем вся собранная до этого информация по проекту.
Пишем, не забывая скриншоты:
- поведение каждого элемента при масштабировании;
- сценарии анимаций, ховеров и прочая-прочая;
- все возможные исключения;
- подробные техтребования: браузеры, стили, сборка, специфические пожелания.
После верстки проверяем с разных устройств и корректируем получившуюся работу. До 3 итераций — норма, 4я — повод сменить верстальщика. Кстати, многие думают, что работа front-end'а не так уж важна, рутинна — и делать ее сможет даже обезьяна. Я в корне не согласна с этим мнением. На мой взгляд, за хорошего верстальщика, который еще и развивается, стоит держаться, как за любимый айфон.
Результат этого этапа:
- тз для верстальщика;
- готовая верстка.
Шаг 6. Программинг
Как дизайнер я могу помочь Заказчику определить приоритетный фронт работ и дать свои рекомендации по итерациям.
В роли UX-специалиста я понимаю — что стоит сделать в первую очередь, чтобы выпустить не самый куцый MVP. Пользоваться этими рекомендациями или нет — уже выбор тимлида.
Также, иногда рекомендую стек — когда на моем пути встречаются оригиналы, которые в 2К20-м разрабатывают на плюсах то, что практически не касается железа. Разработка на том же Питоне, с учетом планируемых нагрузок, будет и в 10 раз дешевле, и в 10 раз быстрее. Я не претендую на экспертность в выборе стека и часто сама обращаюсь за советом. Но когда вижу, что клиент пытается прыгнуть на грабли с разбега — стараюсь убедить хотя бы выбрать лопату вместо грабель.
В конце этого этапа мы получаем:
- документ, расставляющий приоритеты разработки с точки зрения бизнеса;
- предложения по стеку (чаще всего — несколько).
Шаг 7. Тестирование на устройствах, нагрузочное тестирование
Вместе с помощниками тестирую конечный результат на небольшом зоопарке устройств. Да, на профессиональном уровне этим занимаются тестировщики — сторонние или на стороне клиента. Однако последние — как показала практика — часто не видят очевидных моментов по дизайну.
И это не камень в огород тестировщиков. Задача QA часто ставится заказчиком в контексте: “Проверить, что все работает и найти баги”. А улетевшая на 5px кнопка или несовпадение шрифта — не баги же.
А со мной такое не прокатит. Поэтому я еще раз делаю ревью полученного продукта с точки зрения дизайна и скорости работы.
Результат этого шага:
- документ с правками по дизайну;
- документы, отражающие скорость работы продукта и баги на конкретных (чаще всего — мобильных) устройствах.
Шаг 8. Запуск трафика, A/B тесты, выводы
После запуска продукта смотрю на происходящее. Вместе с UX инженером мы ищем проблемные моменты, на которых пользователь может выпадать из контекста или уходить по своим причинам.
Поднимаю составленные на Шаге 3 общие идеи для A/B тестирования, добавляю те, которые появились после запуска продукта, планирую их в итерации, обсуждаю с клиентом и рисую.
В таком состоянии проект переходит на постоянную поддержку, в которую входит:
- A/B тестирование;
- Отрисовка нового функционала, обновлений;
- Создание креативов, баннеров, графики для рекламы и т.д.
В конечном счете Заказчик получает команду, с которой удобно работать. Стоимость таких услуг в месяц редко превышает З/П одного-двух дизайнеров на постоянке. Однако компетенций у нас намного больше, а также мы предоставляем расширенные возможности по аналитике и тестированию и имеем большой пул подрядчиков по программированию и других digital-специалистов. Поэтому выгода тут очевидна.
По итогам этапа получаем:
- документ, содержащий план на A/B тесты, отрисованные блоки для тестирования, регламент тестирования;
- договор на поддержку клиента.
И главный вопрос всех клиентов: почему мы должны тебе верить? Почему мы должны платить такую сумму?
Да, я такой же дизайнер, как и тысячи других. Писать этот материал заставила меня та боль, которую я испытала, сделав за последние полгода несколько проектов из финтеха и схожих тематик ТЗ: “Хотел бы, чтобы вы сделали игру, 3Д-экшон, суть такова…” И что-то там про “корованы”, задачи застройщиков, стартапы и прочие радости жизни. И мне очень хотелось бы, чтобы вы этой боли избежали. А именно — правильно считали проекты и привлекали нужных специалистов, когда вашей квалификации не хватает.
Будем честны. В одиночку качественно пройти все эти этапы практически нереально. И вряд ли вы — тот Д’Артаньян, который пребывает исключительно в окружении лиц мононаправленной ориентации, и может всё. Всегда будет страдать что-то, что в конечном счете обернется для заказчика финансовыми и временными потерями. А зачем вам это надо?
И да, я понимаю, что в каких-то моментах — я не самый удобный подрядчик. Я откажу заказчику, если он будет предлагать срезать половину вышеперечисленных этапов; если увижу что человек не готов к партнерским отношениям; если пойму, что во мне видят многорукого многонога и не готовы работать с моей командой.
И всё-таки. Сколько в кассу?
- Себестоимость лендинга, проработанного по такой схеме — не менее 70.000 рублей. С учетом издержек, минимальной прибыли — получаем 100.000 рублей и выше.
- Стартапы, приложения в самой простой реализации обходятся в 150.000 — 600.000 рублей и более.
- Сложные решения по типу “а сделайте мне досье по всем клиентам финучреждения с модулями, блэкджеком и дамами” — от 1.000.000 рублей только за дизайн и это себестоимость (!).
Сколько берут при этом крупные студии, которые собрали у себя под крылом достойных профессионалов — мне и подумать страшно, с их-то издержками. Да и ДМС, как и корпоративный авто, сам себя не купит.
При работе с крупными проектами на взаимодействие с клиентом и его ЦА может уходить до ¼ рабочего времени. Это тоже нужно учитывать при планировании проекта.
В завершении
Я намеренно опустила некоторые этапы, ценность которых может быть высокой на проектах >1.000.000 рублей и старалась не ругаться, бросаясь в вас терминами типа RITE, ET, Desk Research и т.д.
Буду рада конструктивной критике, предложениям, вашим историям взаимодействия с клиентами. Всяко, наша общая цель — делать сайты лучше, удовлетворять заказчиков и их клиентов, попутно занимаясь тем, что нам нравится на профессиональном уровне.
OMG! Статья изобилует сарказмом. Пожалуйста, воздержитесь от прочтения, если это вам не близко. Говорят, люди, не понимающие сарказм — читают с конца.
За иллюстрации — спасибо Ирина Сальварт. За идею для статьи — всем клиентам, которых в "карантин" стало много больше.
Где я могу посмотреть Ваши работы? Ссылка на фейсбук у Вас не работает.
Комментарий недоступен
Я где-то писал, что хочу именно беханс увидеть? Какая часть фразы "Где я могу посмотреть Ваши работы" указывает на то, что мне нужен именно беханс?
Комментарий недоступен
Сайт портфолио, ссылки на проекты в соц. сетях и т.д. Буд-то кроме беханса мест больше нет)
Комментарий недоступен
Я вообще не понял Егора, зачем было рассказывать, что работы на бехайнс ничего не показывают, а потом дать ссылку на бехайнс.
Комментарий недоступен
Спасибо за ссылку! Кстати ожидал прям намного большего после прочтения статьи. Может просто проекты такие в открытом доступе, но выглядит портфолио так же, как у подавляющего большинства дизайнеров с фл.ру
Намного большее закрыто семью скрепами NDA :) Обычно, клиенты спокойно относятся к тому, что после подписания NDA с нами - мы можем показать много больше вкусных работ, чем на Бихансе.
Комментарий недоступен
Согласна на 50% :)
Почему так? Я делала множество проектов, направленных не на прямое получение прибыли, а на улучшение взаимодействия в крупных компаниях.
Когда ты делаешь CRM/ERP продукты - на первое место выходит простота использования, очевидность тех или иных манипуляций, общее время выполнения заявки, креатив различных фишек, используемых для упрощения навигации и так далее. В этом случае речь идет не о прибыли, а, скорее, о сокращении затрат на сотрудников и используемый софт.
По ходу разработки продукта внедряются десятки различных метрик, по которым оценивается интерфейс и, в дальнейшем, планируются доработки.
https://www.facebook.com/profile.php?id=100023675267412 пожалуйста.
Подскажите, а при клике из профиля по ссылке что происходит? Я сейчас попросила пару человек зайти на мой FB из профиля и у них получилось.
Вот эта ссылка открылась. А когда на ссылку в профиле нажимаю получаю: "К сожалению, этот контент сейчас недоступен" и дальше то что ссылка устарела.
Спасибо что подметили ;)
Пообщаюсь с поддержкой.
Господи, ну и чушь. Сайт то свой откройте чтоб посмотреть. Веб-дизайнеры епт.
Неконструктивный комментарий
Грамотно и толково написано! Елена, думаю, что вы так же тщательно и профессионально работаете над дизайнами, как над этим описанием! 🙏😎
Спасибо, стараюсь.
Часто рассказываю почему дизайн, готовый к продажам, невозможно сделать за 1-2 недели и забыть про него, поэтому и написала этот материал. Лучше буду тщательнее делать дизайн, чем каждый раз рассказывать почему :)
🥰
Да, кстати) Спасибо) Теперь на вопрос почему так долго и дорого буду показывать Вашу статью)
Всё это верно расписано, но без предварительного анализа, проработки структуры и разных других моментов по итогу будет не сильно лучше чем в среднем по рынку. И это самые важные вещи, о которых у вас ни слова нет.
Илья, спасибо за ценный комментарий.
Структура есть CJM в нашем понимании, анализ конкурентов и псевдоконкурентов проводится (в т.ч. зарубежных), что бы вы сделали еще?
При условии, что задача - стартап, который не имеет аналогов на рынке, однако потенциально может иметь нишу, закрывающую базовую потребность ускорения производства (переход от человекоресурсов к машинным).
Я скорее имел ввиду, что вашу работу должен предварять глубокий кусок маркетинга, но это задача другого специалиста. К дизайнеру тут претензий быть не может.
Самое важное - это наложение бизнес-процессов на структуру сайта. Просто без внимания к этому сайт не будет выполнять хорошо свою роль и работа дизайнера сведётся к айдентике. Но проблема ещё глубже, так как возможно потребуются какие-то изменения в работе клиента. А вы как дизайнер в любом случае не сможете сильно изменить то, что в теории может потребоваться.
Согласна.
Я вникаю в бизнес клиента как дизайнер, а весь маркетинг на блюдечке мне приносят коллеги, внешние подрядчики и так далее.
Я просто хорошо выполняю свою работу и всех призываю к тому же в статье http://prntscr.com/vxqsx0. Не стоит пытаться охватить всё силами 1-2 людей, а грамотно распределить ресурсы, убедиться в том, что каждый выполняет свою работу, и только тогда приступать. Иначе что-то всегда будет страдать.
Так что мы с вами на одной стороне :)
В регионах где таких клиентов то находить. Ха-ха. Только Москва.
У меня есть клиенты из региональных центров России, из других стран. Чаще всего заказчик не готов платить, условно, 1.000.000р за дизайн, так как не видит его ценности и, в целом, много людей демпингует.
Объяснив ценность на примере схожего проекта - даже средний региональный клиент (имеется ввиду средний бизнес), видя повышение продаж и конверсий, согласится попробовать поработать на сумму 200.000р и выше. После первого удачного проекта и повышения доверия к персоне дизайнера - следующий проект вполне может быть на 500.000р или больше. Также в регионах я часто не вижу культуры тестирования/улучшения сайта, на которой может зарабатывать и дизайнер, и заказчик, а значит эту культуру можно развивать самостоятельно.
Стоит помнить что Мерседесы ездят не только по Москве, а значит не только в Москве есть деньги. Тем более что "самоизоляция" стерла границы.
У вас своя студия или держите команду на контрактах? Интересен этот момент, так как открывать студию (как юр лицо/ ИП) совсем не рентабельно, а люди, которым нужно делегировать некоторые функции нужны. Как у вас обстоят с этим дела?
Со проектами и командой можно работать так:
- Собрать все IT льготы для ООО и тогда официально платим меньше налогов. Так может быть устроен "костяк" команды.
- Для проектов, где требуются редкие компетенции - приглашаем проверенных специалистов (в качестве ИП/самозанятых) с заключением NDA.
- Для проектов, где нужно только мое внимание - я работаю как ИП или самозанятая.
Если бы я сейчас открывала студию с нуля - я бы создала ИП и работала с ИП/самозанятыми, по мере повышения чеков - устроила бы их по трудовому контракту.
Большинство заказчиков устраивает работать с самозанятым/ИП, а для работы с крупным бизнесом, в некоторых случаях, требуется ООО.
Если еще могу чем-то помочь - дайте знать :)
Вообще хотелось бы спросить ещё ваше мнение по такому вопросу: как задокументировать именно дизайн-концепцию?
Очень часто заказчик пускаешься во все тяжкие «чего-то не хватает», «а давайте добавим красоты», «давайте картиночки на фон добавим» и тд.
Брифы и ТЗ как будто не работают, особенно с мелкими и средними заказчиками, которые вообще не смотрят и не понимаю ux,а только подбирают часами цвет кнопочки.
Визуальное оформление такая «творческая» штука, как ее согласовать? Причём проблема в том что согласовать концепцию (и посчитать) надо до начала работ, а сама крутая идея может придти уже в ходе процесса
Очень интересный вопрос!
1. Я стараюсь не работать с заказчиками, которые многократно используют выражения типа "а давайте покрутим", "а вот тут чего-то не хватает". Чаще всего, такой заказчик не умеет работать с подрядчиком по дизайну и не верит в его профессионализм, а значит я и моя команда потратим очень много времени на взаимодействие. Выбор тут из двух: или убедить в том, что обратившись к нам, он доверил нам задачу и ее выполнение; или прощаться. Если желания/возможности отказаться нет - переходим к п.2.
2. Регулируем в договоре все услуги в часах и итерациях. Указываем стоимость часа, максимальное время, которое Исполнитель может потратить на задачу (например, прототип) в приложении к договору, указываем максимальное количество итераций правок. Согласовываем каждую часть задания, получаем "ДА" по электронной почте или закрываем актом.
3. Про "крутые мысли в процессе" согласна, бывает и такое. Поэтому:
- Лучше всего сначала продать только аналитику, ТЗ и прототипы, а не весь дизайн или сайт. Так у вас будет больше пространства для маневра, а у заказчика - уверенность, что он получит более качественный продукт (в этом еще нужно убедить).
- Если требуют назвать всю цену сразу - называем условный фикс за начальные работы, вилку за остальные.
4. Не бойтесь отказывать. Если вы уже согласовали ТЗ, прототип, а на дизайне вам выставляют правки, которые идут ну совсем не туда - мягко предложите доплатить или вернуться к согласованным материалам.
Общее пожелание такое: не нужно работать со всеми заказчиками. Если у вас складывается сотрудничество - можно сделать больше, не повышая прайс; если не складывается - убедитесь что вы правы, а затем - апеллируйте к договору и защищайте свои ресурсы или отказывайте.
Спасибо за подробный ответ!😊
Спасибо!)
А ещё расскажите, в чем разница между функционалом и функциональностью?
Часто я использую эти слова как синонимы, однако с точки зрения морфологии русского языка это не совсем верно.
На примере. Когда телефон умел только звонить, у него был функционал (функция) звонка и всё. А вот Nokia 3310 был функциональной вещью, т.к. кроме стандартной функции "звонить" он мог отправлять смс, использоваться в качестве калькулятора или орудия самообороны в критической ситуации.
Однако, ввиду отсутствия у меня филологического образования, я могу ошибаться. Если интересно - могу спросить у коллеги-филолога, хотя она, скорее всего, скажет что слово "функционал" в IT сленге является жаргонизмом, а, по первоначальному применению, относится к разделу математики.
я думал, функционал - это в математике
спасибо за статью)
А разработчики (фронт с бэком) на каком этапе подключаются в процесс - почему только после составления всех прототипов и всех согласований с заказчиком? Как показывает опыт, в сложных продуктах (возьмем какую-нибудь cms-ку или crm-ку) дизайнеры не обладают знаниями в оценке времени реализации тех или иных фич. Местами можно кратно сократить стоимость/время разработки и поддержки, не повредив бизнесу и пользователям, если заранее проговорить острые моменты с разработчиками
Ильнар, в ваших словах много правды и жизненного опыта. Одновременно и согласна, и нет. Смотрите:
1) Как правило, с проектом в первую очередь работает PM и UX инженер/аналитик. Оба этих персонажа знают что возможно реализовать в рамках кода, а что нет, и понимают примерные сроки (+- несколько месяцев, если продукт сложный).
2) Когда уже есть MVP, или у заказчика есть команда разработки - создание CJM/прототипов/дизайна, конечно, идет гораздо проще.
3) Когда в проекте есть только UI дизайнер - конечно, на его знания в области разработки программных продуктов полагаться не стоит.
И вообще, скажу что для сложных проектов уровня CRM/CMS - индивидуальное планирование, индивидуальное согласование, и лучше, конечно, со старта иметь полную команду, которая представляет что делать.
🥰 отличная статья
Интересно ваше мнение и как ваша команда работает:
1) аналитик строит СJM ки? если да в каком виде он преподносит вам данные для дальнейшей визуализации структуры?
2) в метриках мониторить и выявлять слабые места это тоже вроде задача аналитика?
3) и вы как дизайнер в каком виде получаете общие данные от методологии DDD для построение дизайна?
Спасибо!
1. CJM и базовая иерархия в Miro
2. У меня это UX инженер, его квалификация шире. Однако, для решения данной задачи хватит и аналитика.
3. Про применение методологий в дизайне лучше написать отдельный пост. Скажу только одно, мне, как дизайнеру, ближе FDD.
Я как понял вы UX-UI дизайнер, вам как UX дизайнеру не перепадает радость составлять CJM- ки в миро? или этим занимается исключительно аналитик с UX инженером?
Всё что мы изобретаем - уже изобретено. Почему за прототип не взять пару сайтов: этот по функционалу, а этот по дизайну, этот UX - и упростить придумывания и согласования?
тогда не будут нужны подобные авторке
вот смотрю сейчас в беханце вашего отделкина — как сказал мой клиент на днях "что мы не делай - у нас всё равно получается трактор" — и у отделкина тоже: какой прототип ни рисуй — получаем всё тот же шаблон.
Расскажите, как проводите АБ тесты. Что чаще всего является метрикой для принятия решения?
Этому можно посвятить отдельную статью.
Я различаю метрики на бизнес, продуктовые и второстепенные.
В каждом случае устанавливается:
- Гипотеза на основе мнений продакта/UX-инженера/стейкхолдеров/запросов ЦА, подтвержденная аналитикой пользовательских данных или хотя бы им не противоречащая.
- Цель, срок и регламент индивидуального теста на базе набора тестов.
И так далее...
Например, сейчас мы занимаемся подготовкой к тестированию интернет-магазина, где одна из целей - повысить общую конверсию на 1% и более путем установления большего доверия к интернет-магазину за счет размещения дополнительных блоков на карточке товара.
Для меня, как для специалиста с опытом, очевидно что результат с вероятностью 90%+ будет достигнут, однако, в целях установления доверительных отношений с новым заказчиком - порой, по согласованию, мы проводим подобные простые тесты.
Думаю, до нового года успею написать статью по тестированию, где будет много интересного. Начиная с того, что кроме A/B существуют и другие подходы к тестированию, не менее интересные.
спасибо, пойду выпью смузи
Спасибо! Вы мне отрыли глаза на многие вещи и процессы.
Спасибо! Если будут нужны детали или остались вопросы - задавайте, с радостью подскажу :)