apavlyut (deppkind) wrote,
apavlyut
deppkind

Как проектируется полезный сайт или система. Гид для чайников, или как уволить своих туполенивых раз

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



NOTE: В жж верстка просто какой ад и израиль - нет желания с ней бороться, жж использую как хранилище черновиков. Нормально прочитать и обсудить можно у меня в фейсбуке - https://www.facebook.com/notes/alexander-pavlyut/как-проектируется-полезный-сайт-или-система-гид-для-чайников-или-как-уволить-сво/10205278553112242


Как я делаю архитектурное описание проекта - или в средневековом простолюдье “техническое задание”.

У системы есть назначение (функция) - что она выдает окружающий мир своим существованием.

У системы есть архитектура которая реализует это назначение.

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

Когда мы перечисляем по пунктам ответ на вопрос - как сайт выполняет назначение, то мы просто получаем список разделов или ключевых экранов (страниц) сайта.

Дальше мы подходим к кажой странице как к системе - у нее есть назначение (то что выходит внаружу) и как она это делает (архитектура внутри).

У каждой страницы есть два вида целей (логистики информации) - выдача или получение.

1. Выдача информации (не просто показать, а достчичь пользу в голове читающего) - как достичь - выполнить пункты по раскрытию : как? почему? для чего? цена? как получить? сколько стоит? почему доверять? кто вы такие? примеры в контексте моей проблемы? статьи? видеозаписи?
2. Получение информации от пользователя. Тут все про формы и прочие кнопки воздействия на сайт.

Цели эти живут часто вместе.

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

Элементы отранжированы по важности - самый важный большой и первый (заголовок, суть), потом поменьше (подзаголовок и картинка) и поменьше.

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

Задаем себе вопрос - какой информацией находящейся в элементе мы выполним это назначение?

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

Если все хорошо - переходим к технической части сайта.

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

Отвечаем на вопрос - что делать дальше с элементом - как информация этого элемента должна оказаться на странице?

Как часто эта информация планируется изменяться на сайте?

Если это телефон - можно один раз ввести при верстке и забыть, это стоит например 1 рубль.

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

Если есть понимание что это нужно добавлять на сайт менеджером - нужно описать сценарий добавления / удаления / изменения / публикации / снятия с публикации / классификации (категоризации) этого элемента.

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

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

На каждом экране описываются следующие сценарии поведения:

1. Планируемое движение по информации - оно должно быть логично, просто и комфортно - результат должен быть удовлетворение ответа на искомый вопрос (назначение информационной страницы).

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

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

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

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

Одна страница - одна цель для пользователя.

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

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

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

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

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

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

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

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

Я тут не воду лью в уши - я это спроектировал, запрограмировал и работую с этой системой уже несколько лет над своими проектами:



http://www.pavlyut.com/cases/artefactor
Tags: архитектурное описание, польза, система, техническое задание, тз, требования
Subscribe

Recent Posts from This Journal

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your IP address will be recorded 

  • 0 comments