Руководство по созданию описание

При создании проекта вы также должны подготовить документ, в котором подробно описывается, что он включает. Этот документ, в котором рассматривается объем проекта, является важным компонентом вашего процесса, поскольку он помогает всем в команде увидеть, что необходимо сделать и что было обещано. Но сначала давайте рассмотрим, каков объем проекта и как вы можете составить документ, который будет держать вас и вашу команду в нужном русле. Мы также увидим пример заявления о содержании проекта, который будет служить руководством при его написании.

Что такое Масштаб проекта?

Масштаб проекта представляет собой подробное описание усилий по проекту, необходимых для удовлетворения ожиданий заинтересованных сторон. Обсуждается, что входит. Однако рассмотрение того, что исключено, может значительно повысить ясность требуемой работы. Существует два вида объема: 1) объем продукта и 2) объем проекта.

Область применения продукта

Объем продукта является подмножеством объема проекта. Он определяет усилия, необходимые для достижения требований к результатам проекта. Управление содержанием проекта важно, потому что продукты являются основными результатами проекта. Специальные проектные документы и методы используются для проверки того, что конечный результат соответствует критериям приемлемости заинтересованных сторон проекта. План управления требованиями и Матрица отслеживания требований — это два уникальных проектных документа, посвященных только объему продукта.

Управление конфигурацией — это отдельная процедура, созданная для обработки изменений функциональных или физических свойств Продукта. Прежде чем они могут быть признаны и распределены среди нужных заинтересованных сторон, товары также должны пройти процессы проверки и проверки.

Объем проекта

Объем проекта содержит объем продукта, а также определяет все остальные работы, которые должны быть выполнены в рамках проекта. Он указан в Плане управления содержанием, а также в Базовом плане содержания и задокументирован в Плане управления проектом. План управления содержанием описывает, как содержание будет планироваться, выполняться и контролироваться. Базовый план содержания описывает содержание проекта в трех документах:

1. Заявление о сфере применения
2. Структура распределения работ (WBS)
3. Словарь ВБС.

Базовый план области — это документ, по которому они измеряют эффективность области.

Что такое Заявление о содержании проекта?

Описание содержания, которое часто составляется руководителем проекта, охватывает весь проект, включая любые результаты и их характеристики, а также список заинтересованных сторон, которые будут затронуты. Он также будет включать любые основные цели проекта, результаты и цели, чтобы помочь количественно оценить производительность.

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

Сегодня я хотел бы продемонстрировать, как более надежно управлять областью видимости, на реальном примере.

Пример реального описания содержания проекта

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

(Я изменил названия предметов и клиентов.)

Идеи управления содержанием проекта будут одинаковыми для любого проекта. Даже большой будет иметь все те же компоненты.

Так что не усложняйте управление областью действия.

Также стоит отметить, что это слишком просто. Кроме того, вам не обязательно включать все, что рекомендует Руководство PMBOK. Просто убедитесь, что Scope Baseline выполняет свою работу.

Краткое описание содержания проекта

Как и в случае Пять W журналистики— Кто, что, когда, где и почему — чтобы правильно написать описание содержания проекта, вы должны учесть следующие семь пунктов:

№1. Обоснование

Ни один проект не начинается без существующей потребности, так что используйте это как аргумент. Начните заявление о содержании проекта, указав потребность в вашем проекте и то, как конечный результат будет соответствовать этому требованию.

Примеры потребностей включают в себя:

• Конкурент запустил новый продукт, который в настоящее время не имеет конкуренции на рынке.
• Отзывы клиентов показали, что они хотят, чтобы новый инструмент стал частью вашего продукта.
• Возможность вертикальной интеграции/периодический доход появился.

№ 2. Объем работ

Это может показаться простым шагом, но он является одним из самых важных в описании содержания проекта. Перечислите, что входит и не входит в рамки вашего проекта на высоком уровне. Это поможет установить границы проекта. Он также обрабатывает ожидания/вклад ваших заинтересованных сторон и предоставляет членам вашей команды некоторые творческие ограничения для работы.

Программное обеспечение для управления проектами может помочь вам лучше управлять заинтересованными сторонами.

№3. Бизнес-цели

Обрисуйте свои бизнес-цели, указав цели, которых вы хотите достичь с помощью этого проекта. Это может включать в себя даты запуска продукта, новую бизнес-стратегию, обеспечивающую больший процент регулярного дохода, более высокий уровень удовлетворенности клиентов, увеличение количества новых клиентов и другие вещи.

№ 4. Результаты проекта

Составьте список результатов, которые члены вашей команды должны создать для достижения целей компании. Это может включать сам продукт, инструкции по эксплуатации и установке, маркетинговые материалы, выпуски новостей, рекламные кампании, а также другие ресурсы.

№ 5. Исключения проекта

Хотя очень важно с самого начала указать границы проекта, важно также указать, что проект не включает. Например:

• Обновления приложений, запланированные для следующего проекта, но не включенные в этот проект.
• Доступ клиентов к определенным линиям поддержки/функциям продукта, которые были ограничены или перенесены.

№ 6. Ограничения

Ограничения проекта — вот что делает управление проектом такой сложной проблемой. Обычно тремя главными ограничениями в управлении проектами являются время, деньги и объем. Они взаимосвязаны, а это означает, что если вы нажмете один рычаг на «сфере», другой рычаг на «деньгах» или «времени» также сдвинется.

Однако в любое время могут возникнуть дополнительные ограничения проекта, такие как риск, ресурсы, организация, подход, клиенты и т. д. Перечислите все ограничения, которые вы ожидаете в своем проекте, чтобы вы могли стремиться к готовым решениям, когда они возникают.

№ 7. Предположения

Предположения вашего проекта обычно вращаются вокруг тех самых элементов, которые в конечном итоге становятся ограничениями, такими как время, деньги и объем. Например, в этой части вы можете написать: «Команда разработчиков интерфейса будет доступна в течение этого периода проекта» или «Группа обслуживания клиентов пройдёт обучение по новому продукту к x времени». Крайне важно упомянуть об этом, поскольку это не только проинформирует основные заинтересованные стороны о ваших основных потребностях в ресурсах для завершения проекта, но также даст вам немедленное представление о том, где находятся ваши самые большие факторы риска.

Схема описания содержания вашего проекта будет служить ориентиром при создании всеобъемлющего описания содержания. Потому что, хотя предсказать будущее проекта на этом уровне невозможно, это первый шаг к тому, чтобы максимально приблизить ваш проект к результату. Вы можете получить преимущество в успешном проекте, начав с семи критических утверждений, перечисленных выше.

Читайте также: Заключительное заявление: определение и советы по написанию эффективного заявления

Что отличает описание содержания проекта от других документов по управлению проектом?

Хотя описание содержания проекта необходимо для успеха проекта, некоторые аспекты проекта рассматриваются в отдельных документах. Вот два ярких примера.

Заявление о содержании продукта Точно так же, как существуют небольшие различия между работой менеджера по продукту и менеджера проекта, существуют некоторые различия между содержанием проекта и содержанием продукта. Объем продукта содержит больше информации о характеристиках и функциях продукта, услуги или решения, которое будет создано в рамках проекта. В содержании проекта может быть указано: «Поставка нового планшетного ПК к концу 2020 года», но в содержании продукта будет указана такая информация, как размер экрана, тип процессора, объем оперативной памяти и так далее.

Генеральный план проекта. Если описание содержания проекта является основой, на которой они строят проект, то генеральный план проекта является остальной частью структуры. По словам Алексиса, генеральный план проекта включает в себя подробный график проекта и организацию работы, а также политики и процедуры для управление рисками, управление качеством и управление коммуникациями. С другой стороны, сила вашего заявления о содержании проекта определяет успех вашего генерального плана проекта, говорит он.

Как отточить свои навыки управления проектами

Получение степени магистра в области управления проектами является одним из вариантов получения знаний и навыков в области управления проектами в профессиональном контексте. Наряду с изучением того, как составить описание содержания проекта, вы также узнаете, как взаимодействовать с руководителями и спонсорами проекта, попрактикуетесь в использовании навыков межличностного общения для управления командами и подготовитесь взять на себя повышенную ответственность, управляя большей командой и/или большим бюджетом. .

Часто задаваемые вопросы о содержании проекта

Что не должно быть включено в ваше описание содержания проекта?

Исключения, допущения и ограничения проекта (помимо другой информации) представлены в Заявлении о содержании проекта.

Каковы шесть элементов типичного описания области?

Типичные компоненты описания содержания проекта включают цель проекта, обоснование, описание продукта, прогнозируемые результаты, предположения и ограничения.

Статьи по теме

1. Управление содержанием проекта: примеры определения и плана управления содержанием
2. 6 простых шагов для разработки схемы бизнес-плана [Скачать бесплатно]
3. Государственные финансы: определение, объем, важность, типы и примеры (+ бесплатные pdf-файлы)
4. Управление маркетингом: все, что вам нужно знать

Писать руководство пользователя по шаблону. Удобно? Удобно

Команда, разрабатывающая софт для создания пользовательской документации, делится лайфхаками на тему написания идеальной пользовательской документации для тех, кто далёк от написания руководств к программе.

Для чего мы сами конструируем некоммерческие образцы документации и инструкций для пользователей

Наш проект существует и развивается уже долгое время, практически шестнадцать лет, если быть точнее. За этот срок была сформирована определенная база, где собраны самые актуальные и насущные вопросы, которые возникают перед людьми, создающими справочные элементы к своему проекту.

Ведя диалог с нашими клиентами, мы смогли выделить их потребности и понять основную «боль». Если обобщить, основная проблема заключалась в том, что ни одна программа для создания файл-справок и инструкций не могла выполнить самую нудную, энергозатратную часть проекта — само разрабатывание и оформление этой пользовательской документации

Даже имея осознание того, что файл-справка — неотъемлемый и действительно полезный элемент для пользователя, очень редко возникает мотивация оформить его грамотно и качественно. Еще реже желание возникает, когда в написании пользовательской документации нет опыта или специалистов, которые бы этот опыт имели. Обычно, эта обязанность с легкой руки падает на плечи самих создателей программы, людей, занимающихся тестированием, аналитикой, специалистам поддержки или даже руководителей компании, которые тоже не совсем понимают, как грамотно создать что-то подобное.

Отсюда вытекает еще одна загвоздка. Люди, у которых нет опыта и в принципе понимания, как начать и что туда вносить, просто не знают, как создать качественное руководство для пользователей. В таких случаях большинство следует привычному пути: загуглить определение и найти готовый шаблон.

И с какой-то стороны, это разумно. Мы достаточно часто сталкиваемся с такими запросами, пользователи просят у нас пошаговое руководство или хотя бы костяк готовой инструкции.

Так вышло, что потребности наших клиентов практически на сто процентов входят в нашу экспертную сферу. И мы приняли решение по возможности помочь всем, кто хочет (или вынужден) заниматься созданием файл-справок и инструкций к своему продукту и предоставить возможность получить образцы, которые могут послужить базой и легко быть адаптированными под конкретный запрос.

В связи с этим, мы сами создали готовые образцы и костяки шаблонных проектов в программе. Что входит в нашу базу:

• Руководство пользователя программного обеспечения.

• Руководство пользователя web-сервиса.

• Корпоративная база знаний компании.

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

Вы бережете своё время.

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

Вы сосредотачиваете внимание на вашей программе, а не на создании файл-справки

В шаблоне уже есть текстовые и графические вставки, вы можете сами добавлять нужный контент в предложенные места и не продумывать вариант оформления.

Наглядность.

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

 Адаптация шаблонов и образцов под ваш проект.

Всё, что находится в шаблонах, можно назвать нашим советом, который был создан на основе многолетнего опыта в данной сфере и выработанной экспертностью. Абсолютно всё в этих шаблонах может быть подвержено адаптации, так как для пользовательской документации нет жестких стандартов, она должна быть выстроена персонально под ваш продукт.

О шаблонах

За 15 лет мы смогли подвергнуть аналитике более сотни разных файл-справок, инструкций и технических документаций, что дало нам возможность сделать вывод и определить шаблонные разделы, которые могут быть применены к огромному количеству программ, после чего мы интегрировали их в наши образцы. Давайте немного подробнее поговорим о структуре.

Обзор возможностей программ. Здесь идет краткое содержание сути вашего продукта. Где вы рассказываете о том, для чего нужна ваша программа. Какие боли и потребности она удовлетворяет, на что способна.

Пользовательский интерфейс. Здесь вы можете наглядно показать вашему клиенту интерфейс, ознакомить его со всеми режимами, дополнительными кнопками и.т.д. Если пользователь может персонализировать интерфейс под себя, об этом тоже лучше указать именно в этом разделе.

Типовые задачи. Здесь нужно максимально подробно познакомить пользователя со всеми основными возможностями программы и детально описать ряд задач и вопросов, которые клиент сможет решить с её помощью. В нашем образце этот блок сформирован из двух подразделов. В подразделе «Примеры использования» лучше всего рассказать пользователю, как ваш продукт будет решать его вопросы и задачи. Если обобщить, то в этом подразделе вы рассказываете про клишированные проблемы, с которыми сталкивается большинство пользователей. В подразделе «Лучшие практики» лучше разместить максимально полезную информацию о том, как упростить свою работу в программе и как пользоваться ей максимально эффективно.

Особые случаи. Здесь нужно рассказать пользователю про то, какие трудности могут возникнуть и как их решить, выделить часто задаваемые вопросы и дать на них самый доступный ответ. Подразделы: «FAQ» и «Устранение типовых проблем»

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

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

P.S. Мы будем рады, если наши образцы помогут вам закрыть вопрос и успешно реализовать документацию в своем проекте.

Всем доброго времени суток, кто решил прочитать статью, посвященную документации. Здесь вы найдёте как общие, так и довольно специфические советы по созданию руководства пользователя. Надеюсь, они будут вам полезны.

Приятного чтения.

Если перед вами стоит вопрос – нужно ли вашему продукту пользовательское руководство, то отвечу сразу – да, нужно. Почему? На это есть две причины:

1. Качественная документация повышает лояльность клиента и ценность продукта в целом.

Как это не странно, но люди до сих пор читают пользовательскую документацию. Конечно, не просто так, а когда сталкиваются с проблемой. И если с руководством все хорошо, то пользователь быстро найдет ответ на свой вопрос – это будет ещё один балл в копилку вашего проекта!

2. Руководство пользователя экономит время и силы техподдержки.

Данный факт напрямую зависит от первого. Если документация качественная, то пользователи будут редко обращаться в техподдержку, и ваша команда будет работать с действительно нестандартными ситуациями. Ну а если руководство «так себе», то поддержка будет завалена однотипными вопросами. Из-за этого пользователям придется дольше ждать ответа, поддержке больше работать, а это в свою очередь будет злить как пользователя, так и команду.

А теперь к советам!

Общие советы по созданию руководства пользователя

Прежде чем начинать писать руководство пользователя нужно ответить на несколько вопросов. — Для кого вы пишите? Кто будет пользоваться файлом справки? (ваша целевая аудитория)

— Где скорее всего пользователи будут прибегать к документации? (дома, на работе, в машине)

— Насколько объективно сложен для понимания продукт и как часто пользователь будет обращаться к документации?

И так, вы ответили на эти вопросы и теперь можете сделать вывод какого размера документация вам нужна, какой стиль изложения в ней использовать, и как часто пользователь будет читать документ.

(Для изложения лучше всего выбрать нейтрально-формальный стиль)

Структура руководства пользователя

У любого качественной документации продуманная и логичная структура. Представьте, что вы сами работаете в программе и сталкиваетесь с проблемой. Открываете файл справки – а там просто сплошной текст. Такая документация вам не поможет.

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

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

Во второй «главе» укажите основные элементы интерфейса. Клиент вряд ли сможет достичь своей цели в программе, если не будет знать для чего служат различные детали интерфейса. Объясните предназначение всех окон, кнопок и так далее.

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

В любом руководстве желательны разделы «Частые вопросы» и «Устранение типовых проблем». Расскажите о проблемах, с которыми часто сталкиваются клиенты и о путях их решения.

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

И последний «обязательный» раздел, которой точно должен быть в любой документации – «контактная информация». Данный раздел даст пользователю возможность связаться с разработчиком. Если руководство вдруг не закрывает потребность читателя, то он может обратиться в поддержку. Кроме того, клиент может дать совет, поделиться опытом или предложить выгодное вам сотрудничество.

Профессиональный совет: если вы хотите максимально облегчить ношу клиента при чтении документации создайте контекстно-зависимую справку. Что это такое?

Представьте, что вы работаете в программе для создания пользовательской документации. Открываете меню основных настроек и видите раздел «аннотирование экрана» Заходите в него, там показаны разные стили аннотации, тени, фон и так далее. Но что такое аннотация? Допустим вы не знаете — нажимаете кнопку F1 и перед вами открывается руководство именно на той странице, где рассказано об «аннотировании экрана»

Как ее сделать? Смотрите ниже.

Контент

И так, мы создали «каркас» нашей документации, но чтобы руководство стало полезным нужно наполнить её компетентной информацией.

Конкретного совета дать невозможно, так как все продукты разные. Поэтому расскажу про общие положения, которые делают документацию лучше.

1. Понятность.

Помните, что руководство будут читать люди, которые не сильно знакомы с вашим продуктом. Пишите простым языком, избегайте профессиональных терминов. Руководство пользователя должно быть написано на языке этого самого пользователя, а не на языке писателя.

2. Наглядность.

Добавляйте в руководство побольше графики и скриншотов с аннотациями. Читателю будет проще и приятнее решать проблему, если будет наглядно показано как это делать.

3. Видео.

Лучше один раз увидеть, чем сто раз услышать. Продемонстрируйте пользователю последовательность действий для достижения конкретной цели. Документация, содержащая видео вставки будет пользоваться большей популярностью, чем обычный текстовый документ.

Но как добавить в документацию видео? Смотрите ниже.

Больше советов!

Когда документация будет готова, чтобы она стала «полноценной» её нужно опубликовать. Иначе какой от неё толк, если клиент не может её прочитать. У «юзера» всегда должен быть доступ к документации, и не важно где он. Такую потребность легко закрывают три формата: HTML, PDF и CHM.

Создайте файл справки и загрузите его прямо в вашу программу в формате CHM. Таким образом, у пользователя будет возможность открыть документ, не выходя из программы. Не забудьте добавить элемент вызывающий руководство в меню программы.

Выложите руководство на сайт в формате HTML, чтобы клиент мог обратиться к документации, даже не работая с программой. Кроме того, документация, выложенная на сайт, повышает SEO факторы сайта.

И напоследок, переведите пользовательскую документацию в формат PDF, чтобы клиенты могли скачать и распечатать руководство.

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

Инструменты

Для того, чтобы написать, а затем опубликовать документацию одного Wordа не хватит, но и пользоваться большим количеством программ тоже не хочется.

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

Dr.Explain – программа для создания руководств пользователя для ПО, web-сервисов и баз знаний.

Благодаря «доктору» вы сможете опубликовать и обновлять документацию в востребованных форматах (CHM; HTML; PDF; DOC), не выходя из программы.

В программе есть шаблоны документации, ведь по образцу работать проще.

Импортируйте в программу заранее написанные фрагменты документации.

Вы сможете создать контекстно-зависимую документацию, настроить визуальный стиль руководства, добавить в него видео и многое другое!

Какой можно сделать вывод

Если вы хотите создать по-настоящему хорошую документацию – придется потрудиться, потому что это займет много времени и усилий всей команды. Но игра стоит свеч, так как после этого вы получите лояльных и довольных клиентов.

Руководство пользователя должно стать персональным гидом по продукту для клиента. Если пользователь останется недовольным после работы с документацией, то это может повлиять на решение отказаться от продукта.

Работая с Dr.Explain, можно быстро написать пользовательскую документацию, которая будет помогать клиентам разбираться в продукте, а вам позволит сосредоточить свои силы на более важных задачах — разработке и продвижении программного продукта.

Спасибо за внимание!

Со всеми возможностями Dr.Explain можно ознакомиться здесь:

Описание страницы – это текст с общими данными о ней, который показывается в результатах поиска Google и в других сервисах, например в Google Новостях. Для автоматического создания описаний в результатах поиска используются разные источники, в том числе информация из тега метаописания, который есть на странице, или представленные на такой странице материалы. В некоторых случаях мы также создаем расширенные результаты на основе контента и разметки страницы.

Мы не изменяем вручную описания отдельных сайтов, созданные в Google автоматически, однако делаем все, чтобы пользователям было проще понять, есть ли на странице нужная им информация. Вы можете улучшить описания ваших страниц, следуя рекомендациям по созданию эффективных метатегов описаний.

Как Google создает описания

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

Контент, который вы предпочитаете показывать в качестве описаний, можно отметить двумя способами:

• Расширенные результаты. Вы можете добавить на сайт структурированные данные, чтобы нам было проще определить, какой контент размещен на странице (отзывы, рецепты, компании, анонсы мероприятий и т. д.). Подробнее о том, как расширенные результаты влияют на рейтинг вашего сайта в результатах поиска…
• Теги метаописаний. В некоторых случаях Google создает описания на основе тега <meta>, если мы полагаем, что это поможет пользователям получить более точное представление о странице.

Как запретить автоматическое создание описаний страниц или ограничить их длину

Чтобы запретить Google автоматически создавать описания для ваших страниц в результатах поиска,
добавьте на них метатег nosnippet. А с помощью метатега max-snippet:[number] вы можете задать максимальную длину описаний. Кроме того, к некоторым обычным тегам в разметке страницы можно добавить атрибут data-nosnippet, и тогда содержащийся в них текст не будет использоваться для создания описаний.

Если мы полагаем, что содержание метатега <meta name="description"> точнее всего отражает контент страницы, то можем использовать его в качестве описания в результатах поиска. В теге метаописания постарайтесь кратко изложить содержание страницы таким образом, чтобы вызвать у пользователей к ней интерес и убедить их перейти по ссылке на ваш сайт. Метаописание не имеет ограничений по длине, однако описания в результатах поиска могут быть сокращены, чтобы уместиться на экране устройства.

Создавайте разные описания для разных страниц

Это поможет пользователям, если по одному и тому же запросу появится несколько результатов с вашего сайта. Старайтесь сделать так, чтобы каждое описание точно отражало контент конкретной страницы. Однако для главной страницы и для других разделов, в которых агрегируется контент, можно добавить более общие описания, относящиеся ко всему сайту. Если у вас нет времени на создание описаний для всех страниц, начните с основных, например главной и самых популярных.

Сделайте описание максимально информативным

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

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

<meta name=»description» content=»Автор: А. В. Тор. Художник: В. Гог. Цена: 17,99 $. Объем: 784 страницы.«>

Создавая описания, используйте автоматические средства

Для некоторых сайтов (например, новостных) создать точные и уникальные описания каждой страницы довольно просто, поскольку контент на них разнообразен и его не очень много. Гораздо сложнее обстоит дело с веб-ресурсами, которые работают на основе баз данных (например, агрегаторами информации о товарах). В этом случае рекомендуем воспользоваться автоматизированными средствами. Хорошие описания должны легко читаться и отличаться друг от друга. Описания для отдельных страниц с указанием конкретных данных лучше создавать с помощью программных средств.

Обратите внимание, что метаописания, состоящие только из ключевых слов, не дают пользователям четкого представления о содержании страницы и вряд ли будут использоваться в качестве описания.

Описания должны однозначно характеризовать контент

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

Ниже показано, как можно улучшить метаописания:

Нежелательный вариант (список ключевых слов):

<meta name=»description» content=»Швейные принадлежности, пряжа, цветные карандаши, швейные машинки, нитки, катушки, иглы«>

Более эффективный вариант (обозначение типа магазина и полезная информация о часах работы и расположении):

<meta name=»description» content=»У нас вы можете купить все необходимое для пошива одежды своими руками. Мы открыты с понедельника по пятницу, 08:00–17:00, на ул. Моды.«>

Нежелательный вариант (одно и то же описание для всех новостных статей):

<meta name=»description» content=»Самые свежие новости города Н. Узнавайте о важных событиях раньше всех.«>

Более эффективный вариант (фрагмент из конкретной новостной статьи):

<meta name=»description» content=»Накануне важного события в городе Н местный житель похитил все подарки. Следите за новостями в реальном времени.«>

Нежелательный вариант (неточно отражает контент страницы):

<meta name=»description» content=»Те, кто не любит яйца, многое теряют.
Помню, как детьми мы собирали яйца в курятнике и приносили их на кухню. Хорошее было время.«>

Более эффективный вариант (однозначно характеризует контент):

<meta name=»description» content=»Прочитав наше полное руководство, вы всего за 1 час или даже меньше научитесь готовить яйца. Мы включили в него все известные рецепты: обычную и перевернутую глазунью и разные способы варки, в том числе пашот.«>

Нежелательный вариант (слишком короткое описание):

<meta name=»description» content=»Механический карандаш«>

Более эффективный вариант (развернутое описание):

<meta name=»description» content=»Самозатачивающийся механический карандаш с функцией автоматического улучшения почерка. Оснащен системой автоматической подачи стержней твердости 2B. Продается в магазинах на улицах Розовая и Желтая. При заказе 50 штук и больше доставка осуществляется бесплатно.«>