2026-та е – да, дизайнерите трябва да имат основни познания по уеб програмиране

Disclaimer: за написването на тази статия не бе използван LLM. Рисунките са създадени на ръка – iPad/Procreate (то си и личи) 😀

Ще запозна тази статия със следното: живея и работя в сферата на уеб разработката от вече над 13 години. За този „кратък“ период мога да осчетоводя доста събития, трендове, които са обещавали чудеса, технологии, които „няма да просъществуват“, но десетилетие по-късно все още се използват, дизайнери, които са и девове, девове, които са и дизайнери и какво ли още не.

Спомням си, точно преди 10 години, всичките ми колеги дизайнери бяха и.. разработчици (доколкото могат и им е възможно). Направете експеримент за себе си – огледайте се за някой колега дизайнер с над 10 години опит в сферата, и го запитайте как е постигал ефект на border-radius със CSS2. Или пък как е постигал двуколонен layout в браузър.

Колкото и да е трудно за вярване (особено през погледа на един начинаещ дизайнер или front-end инженер), имаше времена, в които тези две дисциплини се преплитаха в една – уеб дизайнер.

С развитието на технологиите и все по-големия потребителски demand (наложен и от хардуера, които непрестанно се променя), диверсифицирането на отделните направления стана неизбежно. Така, съвсем естествено, се родиха дисциплини като: Front-end developer (и дори още по-специфичните на база технология React developer, Angular developer и др.), UX/UI designer, Product designer, Motion designer…

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

Какви са наблюденията ми от последните години

Всяка компания, колкото и голяма или малка като размер да е, разчита на определени процеси, за да изплнява дадени дейности. Това са така наречените SOP – standard operating procedures. И понеже тук си говорим за създаване на уеб и mobile app продукти, нека вземем една уеб агенция за пример.

При стартиране на нов проект обикновено имаме следните фази:

• discovery – отделя се необходимото време за проучване на бизнеса и целите му – какво следва да изпълнява, да речем, новия уебсайт; какви са конкурентите; кои са потребителите и какви са техните нужди и пр.
• design – след събраната от годната точка информация се пристъпва към създаване на т.нар. wireframes, като тук може да се мине от low към high, или директно към релистични прототипи. Тук е и моментът, в който се създава потребителското преживяване (UX) и начинът, по който даденият продукт ще изглежда (UI).
• development – с вече готови дизайни, реализирани в софтуер, който позволява на разработчиците да вземат прецизно всички стойности (основно Figma), пристъпваме към разработка на дадения продукт.
• QA и delivery – моментът, в който продуктът е вече реализиран и готов за тестване.

На пръв поглед изглежда постъпков и ясен процес, нали?! Да, ама не. Както предполага и заглавието по-горе, това са моите наблюдения (на база дългогодишен опит). Сега ще ти разкажа какво имам предвид.

Това, което виждам, че се случва е заформяне на проблем основно между 2-ра и 3-та фаза – дизайн и разработка.

Тук вероятно гледаш подозрително и си мислиш „е то какво има да се обърква“

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

Именно при фазите discovery и design се определят основни функционалности (UX) и изгражда се начинът, по който продуктът ще изглежда (design system). Затова и можем да ги приемем като начална фаза, а хората, които участват в тях – като основоположници на проекта.

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

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

1. Несъобразен технологичен stack

Нека си представим следната ситуация:

Дизайнерът създава впечатляващ дизайн с комплексни анимации, blur ефекти и нестандартни интеракции (например – преливане на background на секция при скрол от страна на потребителя). Във Figma всичко работи перфектно и клиентът (а и PM-a) е доволен.

Когато проектът стигне до дев фазата, става ясно, че избраният технологичен stack (да речем – custom WordPress блокова тема, която дава възможност на клиента да създава нови страници с налични в custom библиотека блокове) не позволява реализацията на голяма част от тези решения без сериозни компромиси.

Започват добре познатите разговори:

• „Това не може да стане така“,
• „Това ще отнеме двойно повече време“,
• „Трябва да го опростим“.

2. Липса на мисъл за responsive и различни устройства

Хайде, нека си го кажем: живеем във времена, в които софтуера едва смогва на хардуера – сгъващи се устройства, найразнообразни резолюции, умни часовници, мултимедия в автомобили…

Открай години битува една тенденция – дизайните да се подготвят на 1920px x 1080px. Още от времето на Photoshop и Sketch. Факт, говорим и работим и с mobile first, но дори и там ние, инженерите, често се натъкваме на трудно разрешими без преправяне казуси.

Става така, че дизайнът изглежда отлично на desktop (или респективно mobile, ако се подходи през mobile first), но при различни от изрично указаните стойности на резолюцията нещата започват очевидно да куцат. Елементите нямат логично поведение (например ред с две колони – текст вляво, изображение вдясно не пада в две колони една под друга), текстове стават нечетими (ако се чудиш как 100px в дизайн не са 100px в уеб, виж тук), layout-ът не е мислен като гъвкава система, а като статична композиция на Пикасо.

Базови знания по CSS и layout модели като Flexbox и Grid помагат дизайнът да се мисли като жива и взаимодействаща с потребителя система, а не като отделни екрани.

3. Нереалистични или тежки анимации

Признавам си, възможностите на Figma за постигане и демонстриране на анимации са феноменални! Онова, което преди дизайнерите трябваше да ни обясняват с часове (и пак не е сигурно доколко сме схванали), сега се постига с (вероятно) няколко клика. А както се казва – една картина струва 1000 думи.

Но… и това е нож с остриета. Работила съм с дизайнери, които вземат максумума от Figma по отношение на анимиране, за да пресъздадат онова, което е в главата им. И това е чудесно. Клиентът го вижда и се влюбва.

Но липсата на съгласуваност по повод технологичен stack, ограничения (най-често производително – трудно ще подкараш WebGL в браузъра на 10г. лаптоп), дори възможности на дев екипа, могат да се окажат сериозен препъни-камък.

Отделно тук мога да разсъждавам доста по темата необходими ли са изобщо комплексни анимации и дават ли стойност на потребителя, но това е тема на друга статия 🙂

4. Дизайн без мисъл за динамичност на съдържанието

„Любим“ мой сценарий е онзи, в който съдържанието изглежда повече от перфектно по дизайн. Но.. какво се случва, когато имаме по-дълги заглавия? Или пък когато дадена новина няма заглавно изображение? Или когато вместо 3-ма, имаме 5 членове на екип? Или когато няма достатъчо съдържание за втори слайд?

Една от препоръките ми към дизайнери е да изискват реално съдържание (доколкото е възможно), когато започват работа над нов дизайн. Lorem ipsum е прекрасен вариант, но често конците се оплитат именно заради употребата му.

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

5. Подценяване на accessibility и web стандарти

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

Контрастите, hover-only интеракциите, липсата на фокус състояния и семантика често се пропускат още на дизайн ниво. После тези проблеми се оправят трудно или изобщо не се оправят (което освен, че прави уебсайта напрактика неизползваем за не малка група хора, може да доведе и до правни последствия за собственика му).

Основните правила на стандартите не са rocket science и в кратка среща по темата с дев екипа могат да се поставят правила и рамки, които не бива да се нарушават.

Как тези проблеми могат да бъдат избегнати

Тук влизам с едио уточнение: превентирането на горепосочените проблеми не означава дизайнерите да се превърнат в девелопъри. Означава да имат достатъчно техническа култура, за да взимат по-информирани решения още на ниво дизайн.

1. Базови познания по HTML, CSS и JavaScript

Дори минимално разбиране за това как се подрежда една уеб страница, как работят layout моделите на CSS – Flexbox и Grid, responsive поведението и анимациите помага дизайнът да бъде реалистичен, устойчив и по-лесен за имплементация.

2. Съобразяване с технологичния stack още в началото

Дизайнът не трябва да съществува изолирано. Когато дизайнерът знае дали проектът ще се реализира с WordPress, custom build или no-code платформа, решенията стават много по-точни и практични.

3. Мислене в системи, не в статични екрани

Вместо единични „перфектни“ екрани, дизайнът трябва да се изгражда като гъвкава и жива система – компоненти, състояния, вариации и реално съдържание.

4. Ранна комуникация с дев екипа

Кратки технически разговори още на концептуално ниво спестяват часове преработки по-късно. Един прост въпрос „реалистично ли е това?“ често решава половината проблеми.

5. Основни познания за performance и accessibility

Разбирането как дизайнът влияе на скоростта, достъпността и SEO помага да се взимат по-отговорни решения, които работят добре за реални потребители, а не само визуално.

Тази статия май стана доста дълга 😀

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

Сега е и моментът да ти кажа, че Януари 2026-та ще проведа работилница „Code basics for designers„, чиято цел е именно скъсяване надистанцията между двете звена. Спокойно, нямам за цел да превръщам дизайнерите в разработчици. Но за сметка на това мисията ми е да онагледя процесите по изграждане на един уебсайт и да предам на човепки и достъпен език какво се случва с един дизайн, след като попадне в ръцете на девелопър.

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

Използвай промо код „earlyduck“, за да получиш 15% отстъпка от цената (малък подарък за това, че стигна чак до тук хаха) до края на годината.

Хайде, stay blond и до Януари!