SECL Group
Компания
44,58
рейтинг
25 апреля 2013 в 15:05

Дизайн → Серьезное проектирование серьезных сайтов. Часть 1. Аналитика tutorial

Вторая часть: http://habrahabr.ru/company/SECL_GROUP/blog/178049/

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

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

Вступление


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

Прежде всего, давайте разберемся, кто именно должен заниматься проектированием сайтов. Существует особая специальность для этого вида работ, а соответствующий человек называется проектировщик. Я сознательно не употребляю модных понятий типа UI (UX), потому что в статье речь будет идти не только об интерфейсах. Данный специалист должен обладать хорошей логикой, аналитическим складом ума, иметь очень богатый пользовательский опыт, мыслить предпринимательскими (экономическими) масштабами, быть внимательным к деталям. Кроме этого, он должен хорошо разбираться в интерфейсах и юзабилити, технологиях веб-разработки, маркетинге и многих других сферах. В процессе работы проектировщик, конечно, может советоваться с разными экспертами: дизайнерами, верстальщиками, программистами и т.д., дабы спроектировать продукт наивысшего качества. Получился довольно широкий образ идеального проектировщика, однако «из песни слов не выкинуть».

Процесс проектирования


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

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

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

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

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

Третье. Спросите про целевую аудиторию (ЦА): кто именно будет пользоваться сайтом, и какую полезность он получит. Ответ «все пользователи интернета» — недопустим, это будет означать, что инициатор проекта не понимает, для кого именно он создает этот проект, а значит и непонятно, как его делать. Это, как играть в дартс с закрытыми глазами: где цель известна, а прицелиться нет возможности. На этом этапе в идеале выяснить стандартные параметры ЦА: пол, возраст, регион и т.д. Обязательно нужно выделить ядро ЦА. Кроме этого нужно понимать какими устройствами и ПО пользуется ЦА. Этап глубокой работы с ЦА будет в одном из последующих этапов, а пока нужно понимать, как это видит инициатор проекта.

Четвертое. Узнайте, кто являются прямыми и косвенными конкурентами. Ответ «конкурентов нет», скорее всего, говорит о том, что человек не изучил конкурентную среду. Почти всегда есть конкуренты. Даже если идея проекта уникальная, ЦА уже пользуется какими-то сайтами, а значит, как минимум, есть косвенные конкуренты.

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


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


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

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

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

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

Пример:
Проект: социальная сеть владельцев домашних животных.
Цели заказчика: получение прибыли
Цели проекта:
  • Помощь в выборе питомца
  • Помощь в решении проблем с питомцами
  • Создание тематического сообщества
  • Создании базы тематического контента
  • Создание платформы для продаж и покупок тематических товаров


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

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

Социально-демографические характеристики: пол, возраст, образование, уровень дохода, род занятий. Информация, которая нам нужна для закладывания правильной основы. Например, сайт для подростков 15-18 лет будет отличаться от сайта для пожилых людей в возрасте 60+ лет.

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

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

Географические характеристики: страна, город, район. Учитывая то, что мы все же в Интернете, для нас это маловажный критерий, однако иногда стоят задачи по проектированию национальных сайтов или сайтов с геолокацией, тогда важность этого критерия резко вырастает. Кроме этого, если есть географическая привязка, это может повлиять на контент, о котором тоже нужно думать при проектировании.
После подробного портрета ЦА мы можем приступать к персонажам. Это очень полезный прием для дальнейшей генерации идей. Имея понимание, кто наша ЦА в общем, мы её должны разбить на группы типовых пользователей будущего проекта. Исходя из тематики проекта, группы можно объединять по роду деятельности, владению каким-то предметом, потребностям и т.д. Например, для тематической социальной сети ИТ специалистов группы могут быть следующими: системный администратор, программист, директор ИТ компании и т.д. Задача проектировщика создать список основных целевых групп сайта, начиная от самой большой группы пользователей (ядро) и по убыванию. Нужно не забыть, что кроме обычных пользователей могут быть еще собственные сотрудники, партнеры, рекламодатели и многие другие неочевидные пользователи.

Для каждой группы мы придумываем типичного персонажа, некого вымышленного человека, который до мозга костей является типичным представителем именно этой целевой группы. В идеале найти несколько живых людей и пообщаться с ними об их образе жизни. У каждого такого персонажа должно быть: имя-фамилия (использовать известных людей или знакомых – запрещено, чтобы не искажать восприятие), фотография (можно найти красивую аватарку в поиске VK), возраст, город проживания, род занятий, семейное положение, краткое описание его деятельности, привычек, задач, проблем, пользовательского опыта. Описание этого человека должно быть в разрезе его типичной целевой группы, т.е. если он, например, системный администратор, и мы проектируем ИТ портал, то в описании персонажа должна быть информация, какие ИТ порталы он сейчас посещает, что он на них делает, какие у него есть желания и т.д. Пишем без фанатизма, 1000 знаков на одного персонажа хватит с головой. Проектировщику нужно вжиться в роль каждого персонажа, поставить себя на его место. Эта информация поможет нам лучше понять свою целевую аудиторию и в следующем этапе сгенерировать много полезных идей.

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

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

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

Пример:
Проект: социальная сеть владельцев домашних животных.
Рис. 1. Персонаж


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

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

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

Есть разные методы оценки, мне импонирует старый добрый SWOT-анализ, он позволяет увидеть сильные и слабые стороны конкурентов, а что еще важнее – возможности для своего проекта.

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

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

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

На выходе мы получаем файл с полным анализом конкурентов, обычно вполне хватает 5 популярных тематических проектов в рунете и 5 западных. По каждому конкуренту должен быть SWOT-анализ с 4мя разделами. И, конечно, должен появиться первый список идей для проектируемого проекта. Документ с анализом конкурентов должен утвердить заказчик.

Пример:
Проект: социальная сеть владельцев домашних животных.
Конкурентов в рунете почти нет, по крайней мере серьезных. В западном сегменте есть несколько интересных и популярных сайтов подобной тематике. Основными конкурентами будут:
http://www.dogster.com/ — международный, популярный, высокое качество.
http://www.dogster.ru/ — российский, средняя популярность, среднее качество.
http://www.catster.com/ — международный, популярный, высокое качество.
Полный анализ конкурентов по принципу SWOT расписывать не буду, тут и так все понятно, я думаю.

5. Задачи-проблемы-решения (для пользователей).
На основе персонажей с позапрошлого этапа мы можем перейти к задачам-проблемам-решениям. У каждого человека всегда есть какие-то задачи, краткосрочные и долгосрочные. Этих задач может быть несколько, например, у человека может быть глобальная цель – повышение своей квалификации и локальная – найти работу. Если цель у него до сих пор не реализована, значит есть какие-то преграды (проблемы), и значит мы ему можем предложить некие решения, которые ему помогут в реализации этих целей.

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

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

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

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

Пример:
Проект: социальная сеть владельцев домашних животных.
Рис. 2. Задачи-проблемы-решения


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

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

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

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

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

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

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

В комментариях можно задавать вопросы.

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

P.P.S. Чтобы получать наши новые статьи раньше других или просто не пропустить новые публикации — подписывайтесь на нас в Facebook, VK, Twitter

P.P.P.S. Совсем скоро в нашей бизнес-школе Digitov стартует курс: Проектирование серьезных сайтов. Подписывайтесь на курс сейчас и сможете купить его со скидкой.

Оригинал статьи тут: http://seclgroup.ru/article-serjoznoe-proektirovanie-serjoznix-saitov.html

Автор:
Никита Семенов (Facebook, VK, LinkedIn)
CEO
Компания «SECL GROUP» / «Internet Sales Technologies»
В Вашей компании практикуется проектирование сайтов? (опрос для разработчиков)

Проголосовало 430 человек. Воздержалось 237 человек.

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

Автор: @SECL
SECL Group
рейтинг 44,58
Компания прекратила активность на сайте

Комментарии (35)

  • +4
    Мне вот очень понравился подход студии Лебедева, когда они делали сайт для машины какой то русской. Смеялись помню, сайт дороже самой машины :) Так они там макет сайта сделали в прямом смысле на бумаге и как мини театр его показывали заказчику.
    • 0
      Про макеты в следующей статье. Вообще люди сейчас проектируют от бумаги до специальных серьезных софтин. На бумаге дольше всего и нельзя менять сквозные элементы, которые есть на всех макетах.
    • 0
      Чего только ни сделаешь, чтобы оправдать затраты.
      Можно даже из золота макет выковать с каменьми.
      Это я к тому, что лебедевские «нанотехнологии» большей частью выглядят как пассы фокусника перед тем, как достать монетку у заказчика из-за уха.
  • +1
    Интересно. Подписался на Вас. Не могли бы Вы во второй части выложить примеры создаваемых проектных документов.
    Да я бы и в первой не отказался — бриф, цели, персонажи, сценарии, задачи/проблемы/решения — как эта информация группируется в документах, вся ли она показывается клиентам?
    • +2
      Во второй часте мы покажем примеры интерфейсов и конечное ТЗ. Все из перечисленных документов показываются и утверждаются клиентом, но самое важное для последующей разработки — это интерфейсы вместе с текстовым описанием, на это нужно делать упор. Что касается брифа, целей и т.д. — не сильно важно оформление, ведь это промежуточные этапы.
      • 0
        Ок. Я понимаю, что для разработки важны интерфейсы и т.д., но цель статьи, как я понимаю, описать весь процесс. Я считаю, что ошибка на каждом из этапов способна внести нехилые риски, и поэтому каждый этап важен. Мне, как человеку, который как раз сейчас перебирается в веб-разработку очень интересны наглядные иллюстрации документов.

        Короче было бы здорово :)
        • 0
          Тогда по порядку:

          1. Бриф мы делаем в вольном стиле, на усмотрению менеджера
          2. Цели — по сути минидокумент на одну страничку, примеры привел
          3. Пример персонажа привел, в документе один за одним, в статье скрин с ворда, даже с красным подчеркиванием
          4. Пример сценария привел, один за одним
          5. Задачи/проблемы/решения — скрин с экселя, остальные также делаются.

          Во второй части документы обещаю более наглядные :)
  • +1
    Вставлю свои 5 копеек:
    1. Все что говорит клиент для брифа не нужно воспринимать за истину, многие из его предложений и предположений требуют проверки. Это касается целевой аудитории, выделение приоритета по целям, да и сами высокоуровневые требования иногда формулируются в отрыве от реальной ситуации.
    2. Хороший интерфейс это прежде всего качественная аналитика. Чем меньше мы сами (или клиент) придумываем персонажей и сценариев и чем больше у нас возможностей для мониторинга существующих целевых ресурсов клиента, тем точнее мы сможем сформулировать истинные задачи и пути их решения. Особенно уникально-положительная ситуация когда возможно предпроектное A-B тестирование текущего ресурса клиента для фиксации эффективных решений, но это пока уникальные случаи.
    3. Задачи-проблемы-решения очень напоминает стори-мэппинг и в целом достаточно удобная вещь для не очень крупных проектов.
  • +1
    Очень интересная статья, большое спасибо. Ориентировочно 2-ю часть когда ждать?
  • 0
    Когда я слышу про SWOT мой BS детектор начинает звенеть

    Помомо этого, мне в общем и в целом нравится использование персонажей, но действительно ли нам реально важно знать, что Алексей Крамов подрабатывает мерчандайзером. Что мы изменим, если он подрабатывает, скажем эникейщиком? И что более важно, действительно ли такая большая часть наших потенциальных пользователей подрабатывает мерчандайзерами и живет в пригорадах Киева. Может быть нам лучше выбрать в качестве персоны продавщицу Олесю из Крыжополя (которая тоже попадает в целевую аудиторию с подтипом «покупатель первой собаки»)?
    В общем вопрос в том, не провоцирует ли использование проработанных с достаточной детальностью персонажей появление ненужных стереотипов и необоснованных предположений у дизайнеров и разработчиков.
    • +1
      «но действительно ли нам реально важно знать, что Алексей Крамов подрабатывает мерчандайзером»
      Важно вжиться в роль персонажа. Поэтому лучше составить полную картину.

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

      «В общем вопрос в том, не провоцирует ли использование проработанных с достаточной детальностью персонажей появление ненужных стереотипов и необоснованных предположений у дизайнеров и разработчиков. „
      Такой риск есть. Но так как персонажей много, а проектировщик старается сделать каждого из них нейтрального, то скорее всего стереотипов будет немного, если вообще будут.
      • 0
        Боюсь, что если персонажей будет сильно много (десятки), они не вместятся в мозг проектировщика (разработчика, дизайнера).
        В результате он «забьет» на них при проектировании и время и деньги, потраченные на разработку персонажей будут потрачены зря.
        • 0
          Почему же? С каждым персонажем идет отдельная работа, шаг за шагом. Задачи-проблемы-решения делаются для каждого из персонажей, а потом собираются в единую табличку.
          • 0
            Вопрос в том, оправдано ли использование ограниченных ресурсов на проработку десятков персон, и не лучше ли ограничится предполагаемыми потребностями более абстрактного персонажа, каковых наберутся не десятки, а единицы.
            Интересно, что задачи-проблемы-решения в вашем примере не особо зависит от профессии, пола и места жительства «Алексея», они с таким же успехом подходят и «Олесе»
            • 0
              Абсолютно согласен, выдумывание детализированных персонажей не способно повысить качество проектирования по причинам:
              -персонажи придуманы а следовательно могут не совпадать в общем или в деталях с характеристиками основной выборки реальной ЦА
              -излишняя искусственная детализированность добавляет такой же объем искусственных непроверенных условий, которые могут быть по факту абсолютно невостребованными в реальности
              Предпочтительно использование обобщенных персонажей (или даже целевых групп) с теми характеристиками, которые можно максимально точно измерить или оценить по реальной аудитории. Этого будет достаточно.
              • +1
                Зависит от сайта, конечно. Дублировать однотипных персонажей нет никакого смысла, и на последующих этапах работа будет проще если объединить их в архетипы. Но на крупном и сложном проекте действительно может быть 10 и больше совершенно разных групп пользователей.
  • 0
    Спасибо, интересно.
    У нас пока не очень воспринимают проектирование, но я пытаюсь улучшить ситуацию. Проблема в том, что заказчик может быть как раз не увлеченным, он ждет, что ты за него придумаешь себе цели и задачи, а вот отчетности требует строгой — «сделай не знаю что точно в срок и с ограниченным бюджетом». В таком случае приходится идти сразу к пользователям или руководителем меньшего ранга, чтобы собрать требования.
    Заказчик все равно не очень доволен, потому что, по его мнению, надо было с разгону писать код, а не «чесать репу», но хотя бы можно сделать что-то действительно нужное.
    • +1
      Абсолютно согласен. Мы обычно это мотивируем примерно так: «Видите какое у нас портфолио? Хотите также классно? Нужно начинать с проектирования!»
      • +1
        А если еще подогнать табличку с результатами юзабилити тестирований и ростом показателей аналитики по каждому сайту… :)
  • 0
    Спасибо, интересный материал. Буду перечитывать и обращаться снова и снова, так как хоче запускать свой проект.
    Много полезного вспомнил, что со временем подзабылось или давно не использовалось в виду направленности на «штамповку» сайтов, а не на их маштабность и качество.
    С удовольствием на выходных буду читать vol.2 = )

    Ряд вопросов, если позволите:
    1) Какой разброс сроков Аналитики вы можете назвать на основе Вашего опыта? + Сроки сдачи проекта также интересуют (от заказа до запуска)?
    2) Какой процент Ваших клиентов уходил/возмущался/урезал бюджет из-за сроков анализа?
    3) Прекрасно понимаю, что все люди разные, но всё же: Какие аргументы больше всего (чаще?) действуют/используются Вами для аргументации сроков и соответствующих затрат на аналитику? (Кроме портфолио, конечно же)
    4) Какова, если не секрет, средняя зарплата такого специалиста в Вашей компании? (проектировщика)
    5) Больше риторический вопрос:
    У меня сложилось лёгкое впечатление, что данная модель в общем похожа на PR-акцию, т.е. так или иначе (явно или косвенно) мелькают знакомые мне моменты: Концепция, Таргет-группы, Психологические портреты, ожидаемая реакция и т.д.
    Вам так не кажется? и знакомы ли Вы с работой PR-шика? = ))))
  • 0
    Спасибо за отзыв!

    Отвечаю на вопросы:
    1. На аналитику уходит от 2х недель до месяца. Все проектирование от месяца до 3х
    2. Таких не было. Это очень важный этап, мы всегда доносим до клиента, что это необходимо
    3. Мы объясняем зачем это нужно, что принесет, показываем эту статью :)
    4. Информацию не раскрываем)
    5. Возможно, я не пиарщик
  • 0
    Какова стоимость услуг по проектированию интерфейсов?
    • 0
      Смотря у кого)
      • 0
        Например, у вас :-)
  • 0
    Судя по тому, что вы считаете проведение интервью пользователей необязательной работой, возникает закономерный вопрос — а какой источник информации о персонажах и задачах пользователей?

    Похоже, что в вашем случае это всё какие-то домыслы, а не результаты реальных исследований.

    Буду рекомендовать ваш подход как антипример.
    • 0
      А я разве говорил, что с реальными представителями ЦА нельзя общаться? Напротив, очень полезно пообщаться с реальными людьми, мы так часто и делаем…
      • 0
        «Мы должны понять, кто именно наша целевая аудитория»
        «Для каждой группы мы ПРИДУМЫВАЕМ типичного персонажа»
        «Для полного понимания ЦА, ИНОГДА проводят интервью с пользователями, это уже сфера маркетинговых исследований.»

        Если интервью с пользователями для вас ИНОГДА, а не must, то вы делаете интерфейс для себя, а не для пользователей.
        С предсказуемым результатом.
        • 0
          Подсчитайте стоимость глубинного интервью с хотя бы 20ю типичными представителями ЦА, а по хорошему, на каждую группу нужно по несколько глубинных интервью, чтобы получить точный портрет. Посчитали? А теперь ответьте, кто финансово может себе это позволить, кроме Гугла и ряда подобных компаний?

          Да, начинать исследование с правильных маркетинговых исследований очень не плохо, но вот стоимость таких исследований выйдет в 100 тыс. долл. примерно. Мы обычно столько не тратим, Вы правильно заметили.
          • 0
            Я прямо сейчас провожу интервью для компании в 700 человек.

            7 интервью занимают вам один день и могут принести серьёзную пользу.
            Ваш день стоит 100 тыс долларов? Значит, вы не на тот сайт пишете.
            • 0
              Расскажите это GfK или TNS. Если Вы говорите о профессионализме, так следуйте этому принципу до конца. Нет смысла разводить непонятно что и называть это «исследованиями». Если беретесь серьезно с исследованиями, то и делайте это хорошо.
              • 0
                Что именно рассказать TNS?

                Откуда вы взяли про «непонятно что»?
                • 0
                  Я говорю про день на исследования.
  • 0
    Такие вопросы всплыли в голове, пока читал:
    — будет ли пользователь ожидать наличия материалов по выбору породы собаки или отправится за этим в гугл?
    — будет ли эффективен узкоспециализированный сайт по выбору породы собаки или пользователю с такой целью нужен более комплексный сайт?

    Тогда можно ли отложить вторичную функциональность (материалов по выбору породы собаки) и сфокусироваться на ядре сайта? Будет ли это выгодно финансово и по времени?

    Вспоминается Getting Real и идея «сделайте не так много, но качественно».
    • 0
      В целом принцип делать просто и быстро — правильный. Мы спроектировали целого монстра, а начать нужно с небольшой беты и постепенно её развивать.

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

Самое читаемое Дизайн