Когато в един онлайн магазин липсва важна продуктова информация, проблемът изглежда като проблем на страницата.

Когато филтрите не помагат достатъчно, изглежда като UX проблем.

Когато цената е грешна, изглежда като проблем с данните.

Когато наличността не е актуална, изглежда като технически проблем.

И четирите могат да бъдат точно такива.

Но могат да бъдат и последният видим резултат от процес, който започва много преди информацията да стигне до сайта.

Това е причината при подобни проблеми да не започвам автоматично от интерфейса.

Първо искам да разбера:

Как тази информация изобщо е стигнала дотук?

Понякога сайтът не е мястото, където проблемът възниква.

Той просто е мястото, където проблемът става видим.

Това, което клиентът вижда, често е последицата

Да вземем прост пример.

В онлайн магазин има стотици продукти от няколко доставчици.

При част от тях размерът е записан като:

10 mm

при други:

10мм

при трети:

10

а при четвърти стойността изобщо липсва.

За клиента резултатът е неприятен.

Филтърът не показва всички подходящи продукти.

Сходни артикули не могат да бъдат сравнени лесно.

Категорията изглежда непоследователна.

Първата реакция може да бъде:

„Трябва да оправим филтрите.“

И това изглежда напълно логично.

Само че филтърът не може да създаде липсваща информация.

А без ясни правила и контекст не може надеждно да определи дали 10 mm, 10мм и 10 трябва да се третират като една и съща стойност.

Можем да разработим normalization логика, която да преобразува различни формати.

Но преди това някой трябва да е определил какво означават стойностите, кои формати са допустими и как трябва да се обработват изключенията.

Ако проблемът е в начина, по който данните постъпват и се поддържат, можем да направим много по-добър филтър и пак да оставим причината непокътната.

Тогава въпросът вече не е:

„Как да подобрим филтъра?“

А:

„Как продуктът стига от източника до клиента и къде по този път информацията губи структура?“

За да разберем проблема, трябва да проследим процеса назад

Представете си, че продуктовите данни идват от няколко места.

Един доставчик изпраща Excel файл.

Втори има собствен формат.

Част от информацията се копира от сайтове.

Някои характеристики се допълват ръчно.

Един човек създава продуктите.

Друг коригира цените.

Трети подготвя съдържанието.

Няма общо правило как се записват определени характеристики.

Няма ясно определение коя система е окончателният източник на дадена информация.

На сайта виждаме:

лош филтър.

Но зад него може да стои:

неясен процес за управление на продуктови данни.

Това са две различни неща.

И ако решим само видимото, има голяма вероятност проблемът да се появи отново.

Процесът е пътят, по който работата преминава през системата

Когато казвам „процес“, нямам предвид непременно сложна диаграма с десетки стрелки.

Понякога е достатъчно да можем да отговорим на няколко прости въпроса.

Откъде започва информацията?

Кой я получава?

Какво прави с нея?

Къде я записва?

Кой я променя след това?

Кой отговаря за правилността ѝ?

Какво се случва при грешка?

Къде приключва процесът?

Ако на тези въпроси няма ясен отговор, има основание да проверим процеса, а не само техническата реализация.

Системата може да започне да зависи от паметта на отделни хора.

От лични файлове.

От чатове.

От инструкции от типа „обикновено го правим така“.

Тогава загубата не е само във време.

Губи се яснота.

Загубата на време е само един от симптомите

Най-очевидният сигнал за лош процес е повторяемата ръчна работа.

Човек копира една информация от една система в друга.

След това я копира в трета.

При промяна операцията трябва да се повтори.

Това лесно се разпознава като неефективност.

Но има и по-малко видима загуба.

Някой трябва да провери дали колегата вече е направил промяната.

Друг трябва да пита коя цена е правилната.

Трети не знае дали може да редактира дадено поле.

Четвърти пази собствен файл, защото не вярва напълно на информацията в системата.

В този момент организацията не губи само минути.

Тя губи увереност в собствения си процес.

А когато хората не знаят коя информация е вярна, започват да създават паралелни начини за работа.

Така един недостатъчно ясен процес постепенно произвежда още процеси.

Клиентът може да вижда вътрешния хаос, без да знае това

Клиентът няма представа как работи администрацията.

Не го интересува кой импортира продуктите или колко системи има зад сайта.

Но вижда последствията.

Един продукт има подробни характеристики, друг почти няма.

На една страница пише едно условие за доставка, на друга — друго.

Категорията съдържа продукти, които не би трябвало да са там.

Филтърът пропуска очевидни варианти.

Продукт се показва като наличен, а след поръчката се оказва, че не е.

За клиента това е част от преживяването със сайта.

За SEO може да бъде проблем със съдържанието или структурата.

За разработчика може да изглежда като проблем с интеграцията.

За бизнеса обаче има смисъл да се зададе по-ранният въпрос:

Какъв процес произведе това състояние?

Автоматизацията не е първата стъпка

Когато видим много ръчна работа, изкушението е да кажем:

„Това трябва да се автоматизира.“

Понякога — да.

Но автоматизацията не поправя автоматично процеса.

Ако не сме определили:

коя информация е правилна;

кой е нейният източник;

кога трябва да се променя;

какво става при конфликт;

кой носи отговорност;

автоматизацията може просто да изпълнява неясния процес по-бързо.

А това не е непременно подобрение.

Ако човек веднъж дневно въвежда грешна стойност, имаме ограничен проблем.

Ако автоматизацията я разпространява към няколко системи на всеки пет минути, вече имаме много ефективен механизъм за разпространение на грешката.

Затова преди въпроса:

„Как да автоматизираме това?“

идва друг:

„Защо изобщо правим това по този начин?“

Не всяка ръчна стъпка е проблем

Ръчната работа не е автоматично лоша.

Има действия, при които човешката преценка е важна.

Има редки операции, за които разработването на автоматизация би струвало повече от спестеното време.

Има процеси, които още се променят и не са достатъчно стабилни, за да бъдат автоматизирани надеждно.

Следователно целта не е да премахнем човека от всяка система.

Целта е да открием къде човешката работа носи стойност и къде човекът просто компенсира липсата на добра система.

Това е съществена разлика.

Един проблем може да има няколко собственици — и точно там да няма собственик

Да се върнем към продуктовите данни.

Маркетингът иска по-добри описания.

SEO иска ясни категории и достатъчно информация.

Търговският екип се интересува от цени.

Складът — от наличности.

Разработката трябва да покаже всичко правилно.

В такава среда лесно възниква ситуация, в която много хора работят с дадена информация, но никой не отговаря за нея като система.

Тогава при проблем всеки коригира своята част.

Цената се оправя на едно място.

Описанието — на друго.

Категорията — на трето.

Но причината, която създава несъответствието, остава.

Това е моментът, в който локалните поправки започват да маскират системния проблем.

Как бих проследил подобен проблем

Вместо да започна от решението, бих тръгнал от видимия симптом.

Например:

„Филтрите в категорията не помагат достатъчно.“

След това бих проследил какво им е необходимо, за да работят.

Кои характеристики използват?

Имат ли стойности всички продукти?

Стойностите стандартизирани ли са?

Откъде идват?

Кой ги въвежда?

Кога се проверяват?

Какво се случва с нов продукт?

Какво става при промяна от доставчик?

Така постепенно се движим:

видим симптом → процес зад него → участници → предаване на информация → място на загуба → необходима промяна

Едва след това има смисъл да решаваме дали ни трябва:

нова административна функционалност;

промяна в начина на работа;

интеграция;

валидация;

автоматизация;

или действително нов интерфейс.

Понякога UX решението започва преди интерфейса

Ако човек трябва да избира между продукти, интерфейсът има нужда от качествена информация.

За да има качествена информация, някой процес трябва да я създаде и поддържа.

Ако процесът не може да го направи надеждно, интерфейсът има ограничени възможности.

Можем да подредим непоследователните данни по-добре.

Но това не ги прави последователни.

Същото важи за SEO.

Ако продуктовата структура постоянно създава дублиране, непълни категории или нестабилни страници, не всеки SEO проблем ще бъде решен с metadata.

Ако продуктовият feed съдържа грешна информация, проблемът в рекламната платформа може да е започнал много преди данните да стигнат до нея.

Различни канали могат да показват различни симптоми на един и същ процес.

Сайтът може да бъде диагностичен прозорец към бизнеса

Грешната цена не е само грешна цена.

Тя може да постави въпроса:

Как се управляват цените?

Липсващата характеристика:

Как се управляват продуктовите данни?

Разминаването в наличността:

Как системите обменят информация и коя от тях е източникът, на който трябва да вярваме?

Това не означава, че зад всеки малък проблем стои организационен дефект.

Понякога бъгът просто е бъг.

Но ако проблемът се повтаря, появява се на различни места или изисква постоянни ръчни корекции, има основание да проверим дали не лекуваме само резултата.

Не поправяй резултата, ако системата продължава да произвежда проблема

Едно добро решение трябва да намали вероятността проблемът да се върне.

Ако всеки месец поправяме едни и същи продуктови данни, не сме решили проблема.

Ако служител постоянно трябва да проверява дали две системи са синхронизирани, не сме решили проблема.

Ако всяка нова категория изисква ръчно заобикаляне на ограниченията на старата структура, не сме решили проблема.

Просто сме изградили процедура за справяне със симптома.

Затова понякога правилната промяна по един онлайн магазин започва далеч от екрана, който клиентът вижда.

Започва с това да проследим работата назад.

Да разберем кой създава информацията, как тя преминава през системата и къде се губят време, яснота, качество или отговорност.

Едва тогава можем да решим коя част действително трябва да бъде променена.

Защото сайтът може да показва проблема.

Но не е задължително сайтът да го е създал.