Обичайният метод на работа при уеб дизайна

Всеки дизайнер и агенция си имат “метод на работа” така казано на английски workflow. Тези методи зависят изключително от личните предпочитания и това което работи за един не необичайно да не работи за друг. Тук ще имате възможността да се запознаете с един примерен workflow. Целта е да видите вариант, възможен пример като след това може да нанесете корекции или изцяло да го промените.

Промените може да се наложат и в зависимост от естеството на проектите по които ще работите. С времето нарастват знанията и възможностите от технологична гледна точка и не само. Тези фактори също биха могли да определят начина ни работа. Дори може да се твърди, че непременно го правят.

В повечето случаи може да обособим 4 отделни сегмента по които да работим при всеки проект.

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

Планиране, дизайн, разработка и “пибликуване”/publishing/. Често по време на изпълнението на проекта преминаването между тези етапи би могло да става съвсем плавно или твърде рязко. Така че ние трябва да сме уверени, че методите ни на работа са достатъчно гъвкави за да улавяме прекъсванията, които ги има при всеки проект.

Да ги разгледаме поетапно.

Обзор на проекта/create a project brief/. Това обхваща основните неща при почти всеки проект – какъв е обхвата на проекта и съответно какви са целевите резултати които искаме да достигнем в края му. Извършването на това още в самото начало на проекта ни уверява, че нашите очаквания съвпадат с очакванията на клиента. Това е наистина важно! Ако това ви звучи като нещо излишно, вие може/ще/ да останете много изненадани колко често се получават разминавания в разбиранията между нас и клиента. Следващата стъпка е да направим “обход” или преглед на съдържанието на уеб сайта. Това е изчерпателен списък с цялото съдържание, което ще участва в уеб сайта – проекта. Това не означава, че трябва да разполагаме с въпросното съдържание. Това се прави за да определим типовете съдържание, което ще е необходимо, неговият обем и други. В крайна сметка трябва да добием много ясна представа за това за да можем да преминем към следващият етап. Създаване на стратегия около съдържанието/content strategy/. Определяйки какво съдържание ще има на сайта бихме могли да приоритизираме и планираме как дизайна да доведе потребителите до това да достъпят по възможно най-удобния и лесен за тях начин въпросното съдържание. На този етап е нужно да направим чернови на изначалния план на сайта които включват “скици”, карта на сайта и функционалности/wireframes, sitemaps, and feature lists/. Тук не правим никакъв дизайн! След като приключим с това вече преминаваме към фазата с дизайна. Обикновено най-продуктивния начин за започването на това е със скицник или нещо подобно. Скицирането по този начин се извършва много по-бързо и лесно и нанасянето на корекции също.

Even though I know plenty of designers that actually prefer to sketch directly in code.

Може би най-голямото предимство на този метод е, че така можем да видим възможностите “от птичи поглед” – във вид на наредени скици на плота. В електронен вариант това е твърде трудно осъществимо. Ако проекта го налага след това се прототипизира. Това са визуални елементи, които представят съвсем нагледно какво ще представлява проекта в краен вариант. Това позволява на клиента не само да добие представа за визуализирането на проекта но също така и за функционалността. Прототипите не са непременно задължителни за всеки проект но биха могли да бъдат изключително ефективно средство за “синхронизиране” на идете и вижданията между нас и клиента преди да преминем към същинското изпълнение на проекта. Чак когато сме уверени, че имаме съвсем ясна представа относно заданието и знаем че клиента е удовлетворен до момента преминаваме към същинската разработка. Обикновено това се отнася до започването на изработката на “прилежащите материали/assets/”. Това може да включва изображения, шрифтове, видеа, други графики или други неща които са необходими. Не винаги ще е възможно да се набавят всички нужни асети/assets/ по време на разработката. Всъщност това се случва твърде рядко. Но когато е възможно обикновено това улеснява процеса на разработка. След това вече започваме разработката на сайта.

If I’ve done my planning properly, I already know how the site is going to be structured and what type of functionality is going to need to be programmed.

Now, typically, I’ve got a really good idea of how my code is going to look before I ever start.

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

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

Разбира се по време на целия този процес кода който пишем трябва да се тества на множество браузъри. ?! Обикновено тестването ни подсигурява за това, че малките грешки/бъгове/ няма да доведат след себе си такива но по-големи. Когато сайта става с все повече и повече функционалности наистина е много добра идеята да извършим така нареченото “тестване за ползваемост/usability testing/”. Особено ако времевите рамки и бюджета на проекта го позволяват това.

И стигаме до края на процеса, на всичките тези 4 сегмента за които говорим до момента. Публикуването на сайта. След този момент в зависимост от договорката с клиента работата може и да продължи. В повечето случаи даже е така. След публикуването на сайта, така че да бъде обществено достъпен и да може да се ползва по предназначение следва да се наблюдава за бъгове и поведение. Какво натоварване издържа и претърпява и други.

В заключение ще завършим с това с което започнахме – а именно за всеки човек и екип работният модел е строго индивидуален – за едни работи едно, за други нещо съвсем различно. Вие трябва да си намерите своят метод на работа, който приляга на вас самите. Да звучи сложно и трудно, но всъщност не е – след като знаете какво търсите то намирането му не е толкова трудно – вече всичко(в това отношение) е общо достъпно. Да и като започнете работа в екип това също ще е в списъка на задълженията но пък по този начин може да ви се отворят врати за много други възможности,  което пък е нещо чудесно.

Вижте още:

Какво е да си Уеб дизайнер в днешно време?

Различните области при уеб дизайна

Очаквайте скоро:
Част втора от серията "Инструменти за уеб програмисти"
Запиши се за да разбереш първи, когато е готов материала!