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

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

Трябва да се каже, че техническите спецификации по принцип не трябва да засягат условията на проектиране, тъй като е много трудно този резултат да се оцени обективно. „Красотата“ е изключително субективно понятие, както и „удобството“. Ето защо е необходимо техническите спецификации да се третират задълбочено и ясно да се посочат всички нюанси, за да се избегнат противоречиви ситуации в края на работата.

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

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

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

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

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

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

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

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

Специфичните изисквания към техническите спецификации не са определени от закона (точно както не е дефинирана примерна форма на технически спецификации за 44-FZ), което означава, че клиентът трябва да подходи много отговорно към нейната подготовка. В крайна сметка зависи от това какъв продукт ще бъде доставен, какво качество ще бъде извършена работа или ще бъде предоставена услуга. Ще анализираме подробно етапите на изготвяне на технически спецификации, а в края на статията можете да изтеглите пример за технически спецификации за 44-FZ (образец).

Основни етапи на изготвяне на технически спецификации

Изготвянето на техническите спецификации се състои от три етапа.

Етап 1, подготвителен.

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

Етап 2, основен.

Ето го клиента:

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

Етап 3, финал.

На този етап техническата спецификация преминава необходимите одобрения в заинтересованите служби на клиента. При несъгласие се дооформя. След одобрение се поставя в Единната информационна система заедно с останалата тръжна документация.

Съгласно нормите на 44-FZ, клиентът не трябва да разработва примерна техническа спецификация в съответствие с GOST. Но на всички следващи етапи, от разработването и подписването на документация до изпълнението на договора, клиентът в по-голяма или по-малка степен се позовава на техническите спецификации. Той придобива особено значение на етапа на приемане на продукта. Ето защо е препоръчително да имате такъв документ и да разберете основните правила и принципи на неговото разработване.

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

Главна информация. Тук са посочени първоначалните данни за поръчката и условията на договора, както и използваните термини и съкращения.
Описание на обекта на поръчката. Този раздел е уреден с чл. 33 от ЗЗД и трябва да съдържа пълното наименование на предмета на поръчката, качествени, технически и количествени характеристики на закупуваните стоки. Той може също така да определя изисквания за контейнери и опаковки, безопасност на продукта, разходи за поддръжка и оперативни разходи, изисквания за гаранционния период и обхвата на гаранциите за качество. В съответствие със законовите изисквания описанието трябва да е обективно и да не съдържа препратки към конкретни производители. В този случай трябва да се използват изискванията и характеристиките на техническите регламенти и националните стандарти на Руската федерация по отношение на обектите на обществени поръчки. Този раздел може също да съдържа спецификации, чертежи, планове, снимки на артикула, който се закупува. При описване на обект е важно клиентът да спазва изискванията за технически спецификации съгласно 44-FZ, а именно съответствието на описанието с член 33 от 44-FZ и да запази принципа за осигуряване на конкуренция. Този принцип е, че по конкретна техническа спецификация е възможно да се доставят стоки от няколко марки. Също така е забранено закупуването на технологично и функционално несвързани стоки в една покупка (освен в определени случаи).
Изисквания към доставчика. Може да има изисквания за лицензи, разрешителни, одобрения и др.
Място на изпълнение на договора.
Други условия (например гаранционни декларации).

Наскоро те се обърнаха към мен, за да ме посъветват относно стандарти за писане на технически спецификации (TOR) за разработване на автоматизирани системи (AS) и софтуер (софтуер). Затова мисля, че сега ще отида в Yandex, ще намеря подходяща статия и ще я изпратя. Но го нямаше! Не намерих нито една статия, която да изброява стандарти за технически спецификации, включително шаблони и примери за готови документи. Ще трябва да направите тази статия сами...

И така, основните стандарти, методологии и знания, които споменават TK или SRS (спецификация на софтуерните (или системните) изисквания):

ГОСТ 34
ГОСТ 19
IEEE STD 830-1998
ISO/IEC/IEEE 29148-2011
RUP
SWEBOK, BABOK и др.

ГОСТ 34

ГОСТ 34.602-89 Техническото задание за създаване на автоматизирана система регулира структурата на техническите спецификации за създаване на СИСТЕМАТА, която включва софтуер, хардуер, хора, които работят със софтуера, и автоматизирани процеси.

Съгласно GOST 34 техническата спецификация трябва да включва следните раздели:

1. Обща информация
2. Предназначение и цели на създаване (развитие) на системата
3. Характеристики на обектите за автоматизация
4. Системни изисквания
5. Състав и съдържание на работата по създаване на системата
6. Ред за контрол и приемане на системата
7. Изисквания за състава и съдържанието на работата за подготовка на обекта за автоматизация за въвеждане в експлоатация на системата
8. Изисквания към документацията
9. Източници на развитие

При разработването на технически спецификации за държавни проекти, Клиентите, като правило, изискват съответствие с този конкретен стандарт.

ГОСТ 19

„GOST 19.xxx Единна система за програмна документация (USPD)“ е набор от държавни стандарти, които установяват взаимосвързани правила за разработване, проектиране и разпространение на програми (или софтуер) и програмна документация. Тези. Този стандарт се прилага специално за разработката на софтуер.
Съгласно GOST 19.201-78 Технически спецификации, изисквания за съдържание и дизайн, техническите спецификации трябва да включват следните раздели:

1. Въведение;
2. Причини за развитие;
3. Цел на разработката;
4. Изисквания към програмата или софтуерния продукт;
5. Изисквания към програмната документация;
6. Технико-икономически показатели;
7. Етапи и етапи на развитие;
8. Ред за контрол и приемане;
9. Приложения.

Естествено, GOST 34 (и 19) вече са остарели и не обичам да ги използвам, но с правилното тълкуване на стандартите можете да получите добри технически спецификации, вижте Заключение.

IEEE STD 830-1998

Доста добра дефиниция на стандарт 830-1998 - IEEE Recommended Practice for Software Requirements Specifications е дадена в самото му описание:

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

Съгласно стандарта техническото задание трябва да включва следните раздели:

1. Въведение

1. Цел
2. Обхват
3. Дефиниции, акроними и съкращения
4. Връзки
5. Кратък преглед

2. Общо описание

1. Взаимодействия на продукта (с други продукти и компоненти)
2. Характеристики на продукта (кратко описание)
3. Потребителски характеристики
4. Ограничения
5. Предположения и зависимости

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

1. Изисквания за външни интерфейси
- 1. Потребителски интерфейси
- 2. Хардуерни интерфейси
- 3. Софтуерни интерфейси
- 4. Интерфейси
2. Функционални изисквания
3. Изисквания за изпълнение
4. Ограничения на дизайна (и препратки към стандарти)
5. Нефункционални изисквания (надеждност, достъпност, сигурност и др.)
6. Други изисквания

4. Приложения
5. Азбучен указател

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

Е, за тези, които четат до края, има бонус: пример за технически спецификации, които написах преди много години (сега не работя като анализатор от дълго време, а други по-успешни примери са забранени да бъдат отворен за публично разглеждане от NDA).

Презентация на Юрий Булуй Класификация на софтуерните изисквания и представянето им в стандарти и методологии.
Анализ на изискванията към автоматизираните информационни системи. Лекция 11: Изисквания за документиране.
Правила за изготвяне на спецификация на софтуерните изисквания (прочетете заедно с коментари)
Примери за технически спецификации и друга документация за разработване на АС за Министерството на икономическото развитие
GOST стил на управление. Статия на Gaperton за правилна работа с технически спецификации съгласно GOST
Шаблони за документи на Business Analyst от

Техническо задание „ТЗ“ е документ, който се приема като основа за разработването на всеки проект. И колкото и сложна или мащабна да е задачата, тя винаги трябва да бъде придружена от ясна и разбираема техническа спецификация. Преди всичко клиентът има нужда от това, за да получи точно това, което е искал да види. Но е препоръчително изпълнителят винаги да изисква ясно формулирана задача, за да разбере какво искат от него. Много хора пренебрегват факта на писане на подробни технически спецификации, което впоследствие води до недоразумения, спорове, конфликти и кавги.

Препоръчваме да прочетете:

Аз, авторът на тази статия, в живота си успях да бъда както клиент на няколко големи проекта на стойност десетки хиляди долари, така и изпълнител на не по-малко скъпи поръчки. Преди да стигна до сериозно ниво, трябваше да препрочета стотици „Технически спецификации“ и да съставя няколко десетки свои обяснения за изпълнителя. Всеки път техническите спецификации ставаха все по-ясни и по-ясни, което направи възможно получаването на окончателния вариант на работата, както си представях. В тази статия бих искал да говоря за това как да напиша техническа спецификация, на какво първо да обърна внимание. Ще ви кажа и защо е препоръчително клиентът и изпълнителят да не работят на добра дума, а да документират всичко.

Защо клиентът се нуждае от технически спецификации?

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

Препоръчваме да прочетете:

Защо изпълнителят се нуждае от технически спецификации?

На първо място, това е вашето ръководство за това какво трябва да се направи. Често клиентите измислят нещо по време на процеса на разработка, опитвайки се да ви принудят да изпълнявате ненужни задачи. Искате ли да работите безплатно? Сигурен съм, че не. Моля да поясните, че договорената в самото начало сума се отнася изключително за обема на работата, посочен в заданието. Всичко повече се заплаща отделно. Също така, при предаване на проекта ще можете да отчетете възложените задачи и тяхното изпълнение. Неведнъж съм се сблъсквал с моменти, когато клиентът не искаше да приеме работата с аргумента, че не е напълно завършена. Но когато бяха повдигнати първоначалните технически спецификации, се оказа, че никой изобщо не е поставил въпросните задачи. Още веднъж подчертавам - не работете без технически спецификации, защото мнението на клиента може да се промени по-често от времето и ще трябва да преработвате всичко десетки пъти, губейки си времето и не получавайки допълнително заплащане за това.

Откъде да започнем изготвянето на компетентна техническа спецификация

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

Общи положения на техническите спецификации

Ако имате технически сложен проект или много специфичен, тогава в общи линии трябва да има речник - речник на термини и определения. Разбира се, много е добре, ако клиентът и изпълнителят се разбират и разбират специфична терминология без никакви проблеми. Но това не винаги е така, затова е по-добре да запишете какво означават определени думи, фрази, обозначения. Може би си струва да обясните някои от вашите фрази в речника. Да речем, че използвате определена фраза, тълкувайки я малко по-различно. За да избегнете объркване, веднага поставете всичко на мястото му.

Препоръчваме да прочетете:

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

Цели на проекта

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

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

Функционални изисквания

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

Препоръчваме да прочетете:

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

Срокове

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

Докладване

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

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

Отговорност

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

Препоръчваме да прочетете:

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

Техническите спецификации трябва да бъдат подробни. Не се страхувайте да опишете всеки елемент, всеки елемент, всеки бутон. Напишете всичко, всичко възможно най-подробно. Не се страхувайте да изглеждате педантични. По-добре е да повторите нещо няколко пъти и да го дъвчете, отколкото да го завършите по-късно, да плащате допълнително и да го променяте. Последната техническа задача, която написах, се отнасяше за изработка на уеб сайт. Това беше голям информационен проект. Първо разработихме дизайн, а след това на базата на него описах функционална задача за програмисти. И така, всички спецификации се оказаха 54 страници с шрифт A4 11. Техническото задание беше допълнение към основния договор, което също беше от 7 страници. Но искам да кажа, че дори и в такова подробно техническо задание не можах да взема предвид всичко, тъй като в процеса на разработка бяха подписани още три допълнителни споразумения, с които направих някои корекции в първоначалния вариант на заданието.
Техническите спецификации трябва да са ясни. Не е необходима вода. Всичко е до точката. Ако пишете за крайния срок, тогава конкретна цифра, ако за функционалност, тогава списък с функционални решения, от които се нуждаете и т.н.
Вашата техническа спецификация не е догма, а само един от възможните варианти за изпълнение на задачи. Честно казано, не съм специалист по програмиране. Да, мога да обмисля структурата на проекта, неговата функционалност, някои технически решения, но винаги, когато изготвям окончателния вариант на техническите спецификации, се консултирам с изпълнителите. Те могат да видят нещо, да изразят мнението си и да предложат оптималното решение за изпълнение.

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

Какво си мислите, когато видите банери из града или на уебсайтове (в рекламни блокове) със заглавия: „Сайт за 500 UAH“, „Сайт за 1000 RUR“?

Като разработчик, дълго време си мислех - това е измама! Но броят на тези реклами предполага:

Възможно ли е изобщо това?
Какво качество ще притежава сайта в този случай?
Ще бъде ли възможно да го рекламирате по-късно?
Ще заеме ли достойна позиция?
Ще бъде ли удобно и ще може ли да се редактира?

Разбира се, понякога е приемлив прост набор от HTML файлове: ако има малко страници, те рядко се променят поради темата и собственикът на сайта (или мениджърът на съдържание) знае HTML. И ако не? Ами ако, например, потенциалният собственик не знае нищо за HTML и не направи никакви промени след получаване на сайта? Обикновено малко хора правят промени веднага, защото всичко е уместно. Но след известно време, когато трябва да добавите мета тагове и да актуализирате някаква информация, се оказва, че сайтът е статичен и няма редактор, с който да промените съдържанието му.

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

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

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

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

Техническо задание за изработка на уеб сайт

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

Не се срамувайте или мързеливи да давате примери за сайтове, където харесвате тази или онази функционалност или елементи на дизайна, оформление, ефекти. Но! Не просто предоставяйте връзки, но прикачете екранни снимки. Можете да съставите техническо задание, а собственикът на обекта (който ще дадете за пример) ще промени оформлението, докато техническото задание отиде при изпълнителя. Тогава пак ще трябва да търсиш пример и да обясняваш какво имаш предвид.

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

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

Настолна версия

Главна информация

Ширина на сайта – 1140 px (пример – vizaua.com).
Горният и долният колонтитул се простират по ширината на екрана и са еднакви за всички страници.
Семейство шрифтове: Cambria (предпочитан), Century, Georgia. Можете да посочите други популярни серифни шрифтове.
Размери на шрифта (за Cambria):
Текст под логото в заглавката – 15px
Връзки в заглавката – 14px
Текст в долния колонтитул – 16px

Начална страница – home.png

Текст над лентата за търсене – 25px

Текст под лентата за търсене – 14px

Описание на елементите:

1, 2 – числа с действителния брой магазини и прегледи. Може да се преизчислява веднъж на всеки 24 часа.
3 – категории. Ние ги подреждаме ръчно в същия ред, както на оформлението.
4 – връзки към магазини. До името на магазина показваме броя на прегледите. Ако все още няма отзиви, ние не показваме нищо.
Под всяка категория показваме 6-те най-популярни магазина по брой отзиви. Ако в категорията има повече магазини, към нея води връзката „Още N“, където N е броят на магазините. Ако няма повече магазини, връзката „Покажи всички“ води до категорията.
5 – списък с ниско популярни категории. Показваме ги тук.

Страница с описание на магазина и рецензии – shop-page.png

Заглавие H1 – 30px
Заглавие H2 – 22px

Описание на елементите:
1, 2, 3 – място за рекламни блокове. Трябва да маркирате това място по време на оформлението и да го затворите за индексиране.
4 – съдържание на страница. Дизайнът се променя по такъв начин, че всички промени могат да бъдат направени глобално, без да се редактира всяка страница поотделно:
– добавен сив фон към блока със съдържание;
– добави бяла граница към таблиците (по подразбиране, изглежда, не е написано никъде);
— добавено място за рекламен блок над рецензиите.
5 – заглавие на формуляра. Трябва да поставите отметка в „Добавяне на преглед“.
6 – последни прегледи (блок от край до край за публикации и категории). Това е приблизителен дисплей; приемлив е готов плъгин с подобна визуализация.

Описание на елементите:
1,2 – място за рекламни блокове.
3 – съдържателна част. Трябва да премахнете всички описания на категории (запишете текстовете в отделен .doc файл и качете този файл на сървъра).
4 – връзка към рецензии. Във всички TOR шаблони променяме думата „коментари“ на „отзиви“.

Сервизна страница – page.png

404 грешка – 404.png

404 – шрифт 80px
Текстът под него е 20px
Курсив текст – 15px

Вашият сайт не се класира добре в Yandex или Google,
и всички усилия за популяризирането му не дават желания ефект?

Изпратете заявка за безплатна SEO диагностика и разберете
какво не е наред с вашия сайт.

Мобилно оформление

Сега е по-добре да направите мобилното оформление основно и да „танцувате“ от него. Не е за нищо, че цялата помощ и блогът на Google са пълни с „Mobile first“ (първо мобилно или мобилност). Разказваме ви за това от 2014 г. (статии “” и “”).

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

Контакти. Телефонните номера трябва да могат да се кликват - при кликване панелът за въвеждане на номера трябва да се отваря с вече набрания номер и бутон за повикване.
Меню. Опишете как трябва да се отвори: да излезе отстрани, отгоре и т.н.
Не трябва да има хоризонтално превъртане на страниците на сайта (това се разбира, но все пак реших да ви напомня).

По-долу са представени оформления на страници за показване на сайта на мобилни устройства (адаптивно оформление).

Основни изисквания:
– меню за бургер – разширява се надолу, когато докоснете иконата на менюто: