• Анализ методики проектирования: ошибки, ситуации и полезные выводы из них

      Последний раз я писал статью о проектировании в 2011 году. Тогда я собирался написать гораздо больше, но подумал: «Методика есть, но она не проверена временем, клиентами и проектами. Какого беса я буду писать о ней?». И не стал. Прошло два года, за которые мы с командой спроектировали полсотни разных проектов: корпоративные сайты и каталоги товаров, личные кабинеты, системы управления, сервисы, посадочные страницы, мобильные приложения. Многое поменялось: у меня есть статистика, данные по конверсии, отзывы пользователей и клиентов, сделано и исправлено много ошибок в методике и процессе. Теперь можно и написать.

      Начну с обзора этих ошибок и выводов за последние два года. Надеюсь, это будет вам полезно. Отдельно надеюсь получить отклики из вашего личного опыта.
      Читать дальше →
    • Сравнение подходов к созданию сайта: проектирование, бриф и agile

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

        На всякий случай договоримся о терминах:

        • Проектирование — это детальная проработка с исследованием: задачи, концепция, коммуникация, архитектура, оценка ресурсов. Об этом я писал ранее неоднократно (можно посмотреть в списке моих постов) и буду продолжать писать.
        • Бриф (иногда его называют ТЗ, что неправильно по сути)— требования, общая структура сайта на уровне разделов верхнего уровня и их краткого описания. Об этом писали хабра-авторы в разных статьях: Техническое задание на сайт, Техническое задание: как уберечь себя от ошибок и рисков или Типовой шаблон технического задания на разработку сайта
        • Agile — определили общую идею, общие требования, провели в меру желания и способностей проектирование — сценарии, пользователи, архитектура — и понеслась. Никто не знает, когда сайт можно будет запускать; это решается по ходу.

        NB. Прошу обратить внимание, уважаемые agile-адепты! Я сознательно использую термин Agile не так, как об этом написано в Википедии или в Манифесте. Я использую его для обозначения подхода, когда команда разработчиков не знает, что получится в итоге и действует короткими пробежками с оценкой промежуточных результатов. Именно это я имел «удовольствие» несколько раз наблюдать как подход к созданию сайта.

        Методология сравнения проста как пареная репа: рассматриваем каждый метод с точки зрения его плюсов и минусов, применимости. Всё субъективно, основано на личном опыте и опыте коллег. Рассматривать я буду каждый подход применительно к двум самым распространённым типам сайтов — корпоративный сайт компании и коммерческий стартап-сервис.

        Буду очень признателен, если кто-то будет со мной спорить, поделиться собственными мыслями. Ради этого и пишу, собственно. Если кому-то покажется, что я за проектирование — вам не показалось.
        Читать дальше →
      • Как поставить задачу для простого (шаблонного) сайта

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

          Помнится, кстати, что в комментариях к статьям о проектировании мне задавали такие вопросы вроде «А что делать, когда нет времени и денег на проектирование?». Ответ ниже.
          Читать дальше →
        • Концепция сайта: как и зачем её создавать

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

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

            Читать дальше →
            • +1
            • 19,3k
            • 3
          • Обработка результатов предпроектного исследования

              Прошлую статью о методике самостоятельного исследования перед проектированием сайта я закончил тем, что перечислил, что необходимо сделать при обработке результатов:
              1. Дать общую характеристику среды;
              2. Описать целевую аудиторию, создать персонажей и сценарии их поведения на сайте;
              3. Написать концепцию сайта: каким он будет, чем будет отличаться от конкурентов и как будет развиваться.
              Далее я раскрою каждый пункт. Для наглядности рекомендую сверяться с приложенным примером обработки результатов для сайта бутика ХХХ.

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

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

                  Написать эту статью нас побудила отличная статья Данила Снитко «Как хороший договор спасает нервы и монетку».

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

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

                  Правила решают следующие задачи:
                  1. Информировать клиента о процессе работы: как будет проходить работа, что от него потребуется в процессе и когда. В результате мы получим более образованного клиента и необходимые для работы материалы вовремя.
                  2. Информировать клиента об ограничениях, которые мы на него накладываем в процессе работы, чтобы они не были для него сюрпризом. В результате мы получим более спокойного и удовлетворённого клиента.
                  3. Юридически зафиксировать договорённости, чтобы потом на них можно было сослаться. Если клиент пытается сказать, что дизайн-концепция — это свёрстанный HTML-прототип, нам есть, на что сослаться.
                  Правила исключительно полезны, потому что они организуют процесс с самого начала, что позволяет избежать потерь времени и ресурсов.

                  Читать дальше →