Не убить дизайнера
— Кнопки недостаточно круглые, картинки недостаточно яркие, тексты слабые, и вообще все не так и не то.
— А что «то»?
Гуру веб-разработки могут проходить мимо - статья для чайников от бизнеса, которым рано или поздно приходится делать ЭТО.
Я смотрела, как мучается наш маркетолог и заодно мучает не нашего дизайнера, который волею рока подписался отрисовать лучший в мире макет нам на лендинг. При этом, лендинг уже работает, и уже есть постоянная аудитория.
Вывод: утонули в деталях и понятия не имеем, как должно выглядеть целое. В принципе, самое страшное, что может сделать менеджер проекта — это зациклиться на элементах и не видеть всей системы, которой управляет.
Родилась простая идея — подойти к сайту, как к процессу. Рисуем схемы и помним, что они — идеальные, т.е. описывают только часть реальности. Это важно. Итак.
1. Кто?
Любой сайт, продающий или информационный — неважно, обслуживает аудиторию с определенными целями. Необходимый минимум информации о ней легко собрать через входящие/исходящие контакты. Так были выделены 4 основные категории клиентов:
- фанаты
- быстрые
- сомневающиеся
- бизнес
И еще 3 неосновные, функционал для которых можно реализовать во второй очереди.
Под каждую категорию прописали цели:
- найти конкретную марку товара и надежный сервис
- сделать заказ быстро и особенно не думать
- найти информацию для принятия решения о товаре/ надежности сервиса
- все перечисленное + оформить документы
2. Пользовательские сценарии.
Под каждую категорию прописываем свой сценарий поведения на сайте. Отличная игра — вжиться в шкуру вашего клиента, понять о чем и как он думает, и что в результате будет делать: звонить, писать, изучать цены, болтать в чате или что-то еще? Осторожно — потребуется эмпатия, много.
3. Как?
Продумываем, какой функционал поможет человеку достичь своих целей в первые 5 секунд посещения сайта и без скролла — хотим уменьшить отскок и подтолкнуть посетителя к дальнейшим действиям. Кнопки, фильтры, заголовки, картинки, тексты — в каждом сценарии свое. Чем больше придуманного вами функционала кочует из сценария в сценарий, тем лучше. Выписываем все, что получилось, безотносительно категорий пользователей, в отдельную таблицу и не забываем указать, на каком по счету экране/ в каком блоке это должно быть опубликовано.
4. Проектируем интерфейс.
Можно быстро на бумаге, лучше, но дольше, — в программной среде. Ничего удобнее, чем интерактивная Axure 7, мы не нашли. Рисуем весь функционал, что пришел в голову, не стесняемся. Не забываем смотреть исследования, о том, как пользователь воспринимает информацию — F/Z паттерны и диаграмма Гутенберга вам в помощь.
Нарисовали вашего сферического коня в вакууме? Расслабляться и радостно бежать к дизайнеру рано. Пора свериться с суровой пользовательской реальностью — смотрим вебвизор, метрики и аналитики. Составляем 2-4 реальных пользовательских сценария, смотрим в каких точках они совпадают/не совпадают с нашими идеальными выкладками, и что, в конечном итоге, мешает сделать заказ. Думаем, какой функционал и/или информация помогут привести реальные сценарии к желаемому.
А теперь критикуем проект интерфейса на предмет простоты и удобства восприятия. Несколько правил:
- Никакого функционала «на всякий случай». Если без него можно обойтись — не публикуем
- Если для достижения цели нужно больше трех кликов, ваш сайт/приложение не работает
- Кнопка/анимация, которую не хочется потрогать, не работает.
- Первой проектируем мобильную версию. Справились с ювелирной работой — десктопную версию нарисуете в два щелчка.
Сделали? Вот теперь у вас есть цельное видение сайта — можно идти к дизайнеру.
Описанный выше подход системный и может использоваться для управления практически любыми проектами. Золотое правило:
В системном подходе формулируется такой принцип, обеспечивающий соорганизацию деятельности: начинать надо с целого, более точно — с процесса, который мы организуем, и, определив его в целом, затем решать вопросы о морфологии, обеспечивающей части. А при несистемном подходе мы идем от частей, оптимизируем каждую из этих частей и таким образом выходим на агрегат, потому что при таком подходе даже целого фактически не будет, оно будет агрегированным.