Марио Трендафилов„Искам нов сайт.“
Това е напълно нормален начин един собственик или мениджър да започне разговор за проект.
Той вижда нещо, което не работи достатъчно добре, има идея какво трябва да се промени и търси човек, който да го реализира.
Проблемът е, че изречението вече съдържа решение.
А ние все още не знаем достатъчно за проблема.
Същото важи за:
„Трябва ни SEO.“
„Трябва да увеличим рекламата.“
„Трябва да направим редизайн.“
„Трябва да разработим нова функционалност.“
Всички те могат да се окажат правилни решения.
Но могат и да не бъдат.
Затова преди да обсъждаме дизайн, технология, бюджет или срокове, има един по-важен въпрос:
Какво трябва реално да бъде различно след този проект?
Често започваме една стъпка твърде късно
Когато даден проблем е видим достатъчно дълго, естествено започваме да търсим решение.
Сайтът изглежда остарял и стигаме до идеята за редизайн.
Органичният трафик е слаб и решаваме, че трябва SEO.
Продажбите не растат и увеличаваме рекламния бюджет.
Екипът върши много работа на ръка и решаваме, че трябва нов софтуер.
Това е разбираемо. Някаква част от системата очевидно не работи така, както очакваме.
Но видимото състояние рядко ни казва автоматично каква е причината.
Затова използвам една по-дълга диагностична верига:
заявено решение → симптом → желана промяна → възможни причини → проверка → решение
Първото „решение“ е това, с което започваме разговора.
Последното е това, до което стигаме, след като вече разбираме достатъчно добре проблема.
Понякога двете ще съвпаднат.
Понякога няма.
И точно това трябва да установи анализът.
Първо отделете решението от симптома
Да приемем, че първоначалната заявка е:
„Искаме нов сайт.“
Следващият въпрос не е какъв трябва да бъде дизайнът.
Трябва първо да разберем защо сегашният сайт се възприема като проблем.
Отговорът може да бъде:
„Хората трудно намират продуктите.“
Това вече е по-полезна информация, но все още не е диагноза.
Това е симптом.
Оттам трябва да стигнем до желаната промяна.
Например:
„Искаме човек, който вече знае от какъв тип продукт има нужда, да може по-лесно да намери подходящите варианти и да разбере разликите между тях.“
Това вече описва какво трябва да стане различно.
Но дори тогава не сме готови да избираме решение.
Защото още не знаем защо потребителят изпитва затруднение.
Причината може да бъде навигацията.
Но може да бъде и продуктовата структура.
Може да са недостатъчни характеристики.
Може различни продукти да са описани по несъпоставим начин.
Може категориите да следват вътрешната логика на компанията вместо начина, по който клиентите търсят.
Може информацията в самата база да не позволява изграждането на добри филтри.
Това са различни причини.
И изискват различни решения.
Три еднакви заявки могат да означават три различни проекта
Най-лесно тази разлика се вижда, ако поставим една до друга три компании.
И трите започват разговора с едно и също изречение:
„Искаме нов онлайн магазин.“
На пръв поглед проектът изглежда почти еднакъв.
Нов дизайн, нов storefront, миграция, категории, продуктови страници, checkout.
Но нека не приемаме заявеното решение за диагноза.
Компания А: клиентите трудно намират подходящия продукт
Собственикът вижда, че хората влизат в магазина, разглеждат и често не стигат до покупка.
Изводът е:
„Сайтът е стар. Трябва нов.“
При анализа обаче се оказва, че основният проблем не започва от дизайна.
Продуктите са организирани по начин, който е удобен за вътрешното управление на каталога, но не и за избора на клиента.
Част от характеристиките липсват.
Други са записани по различен начин при сходни продукти.
Филтрите не могат да помогнат достатъчно, защото самите продуктови данни не позволяват добро сравнение.
В този случай можем да направим прекрасен нов интерфейс и да пренесем същия проблем в него.
Заявеното решение е нов онлайн магазин.
Симптомът е трудният избор.
Желаната промяна е клиентът да може да открива и сравнява подходящите продукти по-лесно.
Възможната причина е структурата и качеството на продуктовите данни.
След проверка може да се окаже, че първата работа изобщо не е редизайн.
Тя е преструктуриране на каталога и данните.
Компания Б: сайтът създава твърде много работа на екипа
И тук заявката е:
„Искаме нов онлайн магазин.“
Причината, която собственикът дава, е, че настоящата система „вече не става“.
При разговорите с хората, които реално работят с нея, проблемът започва да изглежда различно.
Цените се обновяват ръчно.
Една и съща продуктова информация се въвежда на няколко места.
Промяна в една система трябва да бъде повторена в друга.
При грешка никой не е напълно сигурен коя система съдържа правилната информация.
Екипът губи време не толкова заради това, което клиентът вижда, а заради начина, по който бизнесът работи зад сайта.
Желаната промяна вече не е:
„Искаме по-модерен магазин.“
Тя е:
„Искаме продуктовата и ценовата информация да се управлява надеждно, без едни и същи операции да се повтарят ръчно.“
Това е съвсем различна цел.
Възможното решение може да включва нова платформа.
Но може първо да изисква промяна на процес, интеграция между съществуващи системи или автоматизация.
Ако не разберем това предварително, можем да сменим технологията и след няколко месеца да открием, че екипът продължава да върши почти същата ненужна работа.
Компания В: хората намират продуктите, но не вземат решение
Третата компания също казва:
„Искаме нов онлайн магазин.“
Тук продуктовата структура е сравнително ясна.
Технически сайтът работи.
Хората достигат до подходящите продуктови страници.
Проблемът се появява по-късно.
Потребителят вижда няколко сходни продукта, но трудно разбира кой от тях е правилният за неговата ситуация.
Ключови разлики са скрити в описанията.
Характеристиките са технически точни, но не помагат достатъчно при избора.
Няма ясна причина един вариант да бъде предпочетен пред друг.
Тук проблемът може да бъде в UX, съдържанието и продуктовото представяне.
Това вече е ситуация, в която редизайнът на определени части от магазина може действително да бъде част от правилното решение.
Но стигаме до него по съвсем различен път.
Имаме три компании.
И трите поискаха едно и също нещо.
Нов онлайн магазин.
Но при едната основният проблем е в продуктовите данни.
При втората — във вътрешния процес и връзките между системите.
При третата — в начина, по който информацията подпомага избора на потребителя.
Ако започнем директно от заявеното решение, и трите проекта лесно могат да изглеждат еднакви.
Ако започнем от реалната цел, те стават три различни проекта.
Бизнес целта трябва да описва промяната, а не инструмента
Полезната цел не казва непременно какво ще разработим.
Тя казва какво трябва да стане различно.
Има голяма разлика между:
„Искаме редизайн.“
и:
„Искаме посетителят да разбира по-лесно кой от няколко сходни продукта е подходящ за него.“
Между:
„Искаме SEO.“
и:
„Искаме хора, които търсят конкретните проблеми, които решаваме, да достигат до страници, които действително им помагат.“
Между:
„Искаме автоматизация.“
и:
„Искаме да премахнем повторното ръчно въвеждане на една и съща продуктова информация в няколко системи.“
Първото изречение във всяка двойка предлага средство.
Второто описва промяна.
А когато промяната е ясна, можем много по-смислено да проверим кое средство е подходящо.
Пет въпроса са по-полезни от ранното техническо задание
Преди да превърна заявката в конкретен проект, бих искал да имам добър отговор поне на следните въпроси.
Какво не се случва днес, а трябва да се случва?
Това ни помага да отделим реалния проблем от общото недоволство.
За кого трябва да се промени?
За клиента? За търговския екип? За хората, които управляват продуктите? За маркетинга? За всички тях?
Една промяна може да бъде удобна за един участник и да създаде проблем за друг.
Къде виждаме симптома?
В трафика? В избора на продукт? В checkout-а? В запитванията? В работата на екипа? В качеството на данните?
Какви са възможните причини?
Тук няма нужда веднага да избираме една.
Целта е да не заключим анализа около първата правдоподобна хипотеза.
Как можем да проверим кое обяснение е вярно?
Едва тук започва истинската диагностика.
Тя може да изисква данни, наблюдение на поведението, преглед на продуктовата структура, технически анализ или разговор с хората, които ежедневно работят с процеса.
Конкретният метод зависи от проблема.
Добре формулираната цел премахва ненужни решения
Една от най-полезните функции на добрата цел е, че ограничава проекта.
Когато не знаем какво точно искаме да променим, почти всяка идея може да изглежда полезна.
Нов дизайн.
Нова платформа.
Нови филтри.
Нова интеграция.
Ново съдържание.
Нова реклама.
Още една функционалност.
Всичко може да бъде защитено с някакъв аргумент.
Но когато имаме ясна цел, можем да зададем много по-неудобен въпрос:
Как точно тази задача ще помогне за промяната, която търсим?
Ако няма добър отговор, задачата вероятно не трябва да бъде приоритет.
Понякога това означава и да не бъде разработено нещо, което първоначално е изглеждало необходимо.
Това не е загуба на проект.
Това е избегнат разход за решение, което не адресира причината.
Целта не е диагноза
И тук има още една важна граница.
Дори правилно формулираната бизнес цел не ни казва автоматично какъв е проблемът.
Ако кажем:
„Искаме повече хора, които намират подходящ продукт, да завършват поръчката си.“
вече имаме много по-добра цел от:
„Искаме нов сайт.“
Но все още не знаем защо хората не завършват поръчката.
Може да се съмняват в избора.
Може доставката да ги спира.
Може да липсва удобен метод за плащане.
Може техническа грешка да прекъсва процеса.
Може да достигаме до неподходяща аудитория.
Може самото предложение да не е достатъчно конкурентно.
Затова целта е началната точка на анализа, не неговият край.
Тя ни казва каква промяна търсим.
След това трябва да открием какво пречи тази промяна да се случи.
Проектът започва преди първия дизайн, keyword или ред код
За мен един проект не започва в момента, в който отворим Figma, направим keyword research или създадем нов repository.
Започва по-рано.
В момента, в който отделим това, което бизнесът първоначално е поискал, от това, което действително се опитва да постигне.
Понякога анализът ще потвърди първоначалната идея.
Ще се окаже, че наистина е нужен нов сайт.
Или SEO.
Или нова функционалност.
Тогава можем да пристъпим към тях с много по-ясна причина.
Но понякога ще открием, че проблемът е на друго място.
Точно затова не приемам заявеното решение за диагноза.
Първо трябва да разберем:
Какво трябва реално да промени проектът?
След това можем да търсим причината.
И едва когато имаме достатъчно основания за нея, има смисъл да избираме решението.