Серйозне проектування серйозних сайтів. Частина 1. Аналітика

Майже 4 роки тому ми написали одну з самих популярних статей в рунеті про проектування великих проектів з такою ж назвою, як і ця: частина 1 і частина 2. Тільки на Хабре її прочитало понад 170 тис. осіб, а взагалі вона публікувалася в самих різних виданнях світу. Більше 1000 стартапів використовували напрацювання з цієї статті для проектування, і це тільки ті, про яких я чув і які нам писали. Але час не стоїть на місці, а ми постійно розвиваємося. З тих пір наша технологія проектування значно еволюціонувала і стала ще краще. У цій статті ми опишемо нашу оновлену технологію проектування і покажемо багато живих прикладів для кожної стадії.

Проектування — це перший етап розробки будь-якого великого проекту. Це основа його успішності. Коли ми будуємо хмарочос, нам потрібно продумати все до кожного гвинтика: зовнішній вигляд будівлі, кількість поверхів, локації всередині, використовувані матеріали. А ще потрібно зробити його стійким до землетрусів, подбати про екологію, зробити в ньому офіси та магазини. Це все вирішується на етапі проектування хмарочоса. І проектування в даному випадку — це гарантія якості майбутньої будови, що воно не розвалиться і не поховає під уламками людей. Цей етап дозволяє зрозуміти владі міста і власникам, як саме виглядатиме споруда у підсумку, побачити попередню проектну модель, провести точні розрахунки.



У статті буде багато картинок. Хабр, на жаль, не дозволяє завантажувати великі картинки, тому їх можна подивитися в повній версії статті на нашому сайті: http://seclgroup.ru/article_serious_design_of_the_serious_websites.html

Деякі стверджують, що проектування і Agile суперечать один одному. Але чомусь хмарочоси не будуються за класичним Agile, коли все відбувається одночасно. Спочатку робиться проект будівлі. Тяжкохворого в лікарні не лікують за Agile, коли лікування та обстеження йдуть одночасно. Спочатку потрібно зрозуміти, що хворий пацієнт. Несправний автомобіль не лагодять по Agile. Спочатку потрібно дізнатися, яка саме деталь поламалася. А коли ми вже пройшли перший етап, тоді можна робити все одночасно, робити з Agile. У всіх 3-х прикладах є аналогічний проектування етап. Все це частина правильного планування, яке дозволяє знайти єдино правильний шлях і вирішити поставлене завдання максимально ефективно.

Не зрозумійте мене неправильно, я не противник Agile, навпаки, ми завжди його застосовуємо в розробці своїх проектів. Але Agile — це не чарівна таблетка на всі випадки життя. Це методологія зі своїми цілями і правилами. Не можна бездумно брати її і застосовувати, як описано в теоретичній книжці. Подивіться на будь-яку ІТ компанію, яка застосовує Agile, і зокрема Scrum. Хто з них застосовує класичний Scrum, за всіма правилами? Я думаю, майже ніхто. У всіх цей підхід оптимізовано під реалії компанії. У нас, до речі, теж не класичний Scrum, є елементи XP, а кілька проектів йдуть по Kanban. Проектування НЕ суперечить Agile, давайте відокремлювати мух від котлет.

Переважна більшість великих проектів робляться з Agile, і це чи не єдиний шлях до успіху. Якщо брати теорію, то потрібно сідати і робити все одночасно. На практиці, якщо ми почнемо все одночасно, включаючи проектування і програмування, то нам доведеться багато чого переробляти. Більш ефективне рішення — спроектувати основу (етап аналітики, зазвичай 1-2 тижні), щоб побачити весь проект, а потім сідати проектувати перші інтерфейси, поки програмісти будуть продумувати архітектуру, вибирати технології, писати ядро системи. Тобто першої ітерацією за Agile у нас буде голе проектування, аналітична його частина, а вже з другої (через 1-2 тижні) можна починати програмувати, а ще через 2 тижні, коли буде спроектований перший у Axure інтерфейс, можна підключати дизайнерів і т. д. тобто проект ведемо з Agile, але думаємо головою замість дупи. З таким підходом вже через місяць після старту проекту у нас будуть видні межі проекту, обрані технології, архітектура і навіть перша сторінка в дизайні, і що найважливіше, все це не доведеться переробляти по 10 разів.

Переконав? Гадаю, не всіх. У коментарях до кожної моєї статті завжди знаходяться люди, які стверджують, що це необгрунтовано дорого. Зазвичай це програмісти, які звикли писати код, вони не думають підприємницькими масштабами. Уявімо, що ми вирішили працювати без проектування. Посадили програміста, він почав щось робити. Посадили дизайнера, показали йому опис на кілька сторінок, сказали «малюй». Програміст думає технічно: яку мову обрати, яку архітектуру закласти, як БД буде влаштована. Дизайнер думає творчо: який стиль вибрати, які кольори, де який блок розташувати. В результаті у нас буде красива картинка від дизайнера і правильний код від програміста, але працювати на досягнення кінцевої мети це не буде, доведеться коригувати логіку, рухати блоки, додавати функціонал. І в таких випадках часто виходить перші 90% проекту і другі 90% проекту. Будь-яка зміна в логіці тягне за собою правки дизайну, верстки та програмування, а після це все тестується і знову змінюється / допрацьовується. Знайома картина? Я думаю, більша половина читачів цієї статті її бачила. Саме проектування може захистити від нескінченних переробок, тобто це не зайвий етап в навантаження, це теж саме, як проектування при будівництві, обстеження хворого або діагностика несправностей автомобіля. Іншими словами, це — обов'язковий етап розробки будь-якого великого сайту, і пора до цього звикати.

Глобально є два підходи до проектування: 1. Mobile first — коли ми починаємо проектувати з версії під мобільні пристрої, а потім повнофункціональну версію. 2. Desktop first — коли ми починаємо проектувати повнофункціональну версію, а після робимо спрощені для мобільних пристроїв. В обох підходів є свої плюси і мінуси, я волію другий варіант, спрощувати завжди легше, особливо маючи за плечима класну аналітику, яку я опишу нижче. Крім того, другий варіант більш прийнятий у всьому світі, хоча Mobile first останнім часом активно розвивається.

Нижче в статті буде багато прикладів з нашої практики, і я покажу поетапно, як саме проектується великий проект і для чого потрібен кожен етап.

Вихідні вимоги


Для початку потрібно зібрати всі вимоги по проекту. Проблема в тому, що ці перші вимоги приходять в дуже різному вигляді: від простого опис ідеї на одну сторінку до динамічного прототипу. У будь-якому випадку, за 10 років роботи я не бачив жодного правильного ТЗ. Найчастіше роботу потрібно починати майже з нуля. Навіть якщо і є напрацювання, їх все одно потрібно перевірити і ще раз пройтися по всіх етапах, щоб не була порушена технологія, в якій кожен новий етап пов'язаний з попередніми.

Проект — це завжди особливе бачення його творця. Тому для початку потрібно задати правильні питання. З одного боку, це допоможе зрозуміти, що саме хоче творець проекту, з іншого, дасть розуміння зрілості ідеї в його голові. Як правило, кожна друга ідея ще не дозріла у самого творця, а тому, за неї братися рано і місцями навіть небезпечно для команди. Нижче я розділив всі питання на групи, які треба опрацювати, перш, ніж приступати до проектування. Якщо в якійсь із груп відповідей у творця не буде — це вірний сигнал недозрелой ідеї.

1. Мета і основна ідея. У будь-якого починання має бути мета та критерії успіху. У інвесторів є дуже класний прийом, вони просять сформувати ідею проекту в одному реченні. Якщо стартапер може це зробити, з них кажуть далі, якщо не може — ідея дуже сира, і її потрібно допрацьовувати.

2. Цільова аудиторія. Будь-який підприємець або менеджер повинен знати, хто саме буде використовувати проектом. Визначення: «Всі, від 18 до 60 років» — нам точно не підходить. Портрет ЦА повинен бути досить чітким, від цього залежить, що саме буде спроектовано. Потрібно розуміти, хто буде користуватися, хто платити, хто важливий для просування проекту і т.д. В ідеалі підкріпити здогадки дослідженнями.

3. Ринок. У будь-якого продукту є свій ринок. Це може бути ринок обмежений географією окремої країни, мовою, тематикою і т. д. Від цього також залежить майбутнє проекту. Сегментації при цьому може бути декілька, наприклад, країна і тематична ніша в цій країні. В ідеалі треба дізнатися не тільки межі ринку, але і його особливості і правила, якщо такі є. Багато чого залежить від культури: наприклад, у Росії та Україні, користувачі не звикли платити за якісь послуги в Інтернеті, чого не можна сказати про США та інших розвинених країнах. Тобто при одній і тій же ідеї і розмір аудиторії, ми можемо отримати зовсім різні особливості проекту і розмір кінцевої прибутку від нього.

4. Конкуренти. Їх потрібно знати набагато глибше, ніж просто назва, і взагалі наявність їх на ринку. Чим вони дихають, які у них проблеми, які плани. Тобто потрібна людина з ринку, який його знає досконально. Це дуже сильно допоможе створити дійсно сильне рішення. Часто бувають прямі і непрямі конкуренти — знати треба всіх. Я дуже люблю проекти, які замислюються в профільних компаніях для своїх ринків. Якась оцифровка реального бізнесу. Такі проекти дуже часто стають дуже успішними, тому що: а) вони знають ринок; б) вони мають достатньо ресурсів; в) нішевих проектів в Інтернеті досі дуже мало.

5. Монетизація. Велика проблема власників продукту в тому, що у них є класна ідея, але немає розуміння, як з цього заробляти. Це — одна з основних причин смерті стартапів. Варіант «подумаємо про це пізніше» абсолютно не підходить. Це — те, з чого потрібно починати думати. Рідше бувають випадки, коли проект створюється не для заробітку, а для продажу великої компанії, і інструменти монетизації там апріорі не потрібні. Але це 1 випадок із 100. Так і продатися, будучи прибутковими, все одно набагато легше. При цьому майже завжди нові проекти стартують без інструментів монетизації, їх доопрацьовують потім, але планувати монетизацію потрібно відразу.

6. Слабкі і сильні сторони. Дуже часто знання ринку і конкурентів є настільки сильною перевагою, що його вистачає на створення проекту. Сильні і слабкі сторони зазвичай народжуються з таких ось знань, або з минулих напрацювань компанії або конкретної людини.

7. Терміни. Це те, на що варто звернути особливу увагу. Якщо інноваційна ідея, і робиться щось нове, чого немає ніде в світі або на конкретному ринку — терміни будуть критичними, потрібно зробити максимально швидко, щоб зайняти нішу. Якщо робимо щось стандартне, як, наприклад, інтернет-магазин, то це робиться для реального бізнесу, у якого є чітке планування. У будь-якому випадку, навіть незважаючи на те, що ми будемо робити проект з Agile, і терміни у нас розмиті, нам потрібно дізнатися часові рамки та контрольні точки.

Цілі проекту

Рис. 1. Цілі проекту «Маркетплейс».

Раніше ми ділили цілі на цілі клієнта і мети проекту. Зараз ми пішли від цього і залишили тільки цілі проекту, однак клієнта все одно потрібно запитати, куди він хоче прийти і навіщо робиться проект. Це пов'язано з тим, що цілі клієнта, найчастіше, типові. Потрібно буквально перейнятися баченням клієнта, стати з ним на один рівень і подивитися його очима. Тоді тільки приходить правильне розуміння цілей і з'являється можливість правильно керувати продуктом.

З моменту написання минулій статті ми розробили декілька власних продуктів і розробляємо їх зараз. У якийсь момент прийшло розуміння, що нам недостатньо Project мападег'ів, нам потрібні Product мападег'и. Тобто люди, які можуть керувати продуктом, а не тільки ставити завдання з написання коду і малювання картинок. Теж саме відноситься і до UX / UI Designer'ам або на російський манер, до проектувальників. Потрібні люди, які зможуть зрозуміти бізнес клієнта. Я не дарма про це написав у блоці про цілі, саме тут починається робота, і потрібні правильні люди, з абсолютно іншим складом розуму, які не просто здатні усвідомити, що взагалі потрібно зробити, але і домогтися цього.

Цілі проекту можуть бути самі різні, все залежить від проекту. Зазвичай все це зводиться до глобальних цілей: гроші, користувачі, дії, увага, частка ринку і т. д. Для досягнення кожної глобальної мети потрібно досягти багато дрібних, локальних цілей. І тут зазвичай є безліч продуманих механік, як це робиться. Але це все одно не конструктор. Навіть якщо проектувальник та менеджер продукту знають багато базових механік досягнення тих чи інших цілей, це всього лише механіки, а не сама реалізація і досягнення якихось результатів.

Крім самих цілей важливо з'ясувати критерії успіху. Якийсь набір KPI, який покаже нам, чи ми досягли цілей чи ні.

Цілі — це напрямок руху, якась відправна точка. Від їх правильної постановки залежить усе проектування, та й взагалі весь проект. Треба, не поспішаючи, їх продумати і контролювати в міру розвитку проекту.

В результаті у нас виходить перший документ зі списком цілей і критеріїв успіху. У ньому варто виділити пріоритетні напрямки. Етап зробити неможливо без власника продукту та його постійного фітбеку, втім, як і багато інші етапи.

Цільова аудиторія


Щоб зробити якісний продукт, потрібно детально розуміти, хто буде його користувачами. І зрозуміти це, потрібно з самого початку. Опитування власника продукту дасть нам не більше, ніж припущення, реальна картина зазвичай прихована. Проводити свої повноцінні маркетингові дослідження та опитування зазвичай немає ні часу, ні ресурсів. Тому дослідити цільову аудиторію можна кількома простими способами, яких буде достатньо для проектування.

Для початку, всю ЦА потрібно розділити на групи по цілям і основним ознаками. Набір таких ознак в кожному проекті буде різний. Наприклад, якщо ми робимо проект по фотографії, то нашій ЦА можуть бути: професійні фотографи, фотографи-любителі, замовники послуг фотозйомки, моделі і т. д. У кожного з них є свої параметри, за якими ми можемо їх групувати. Це важливо зробити, щоб спроектувати корисний сайт для основних груп ЦА, який буде вирішувати завдання кожної з них. У великих проектах зазвичай таких груп до 10, і вони повинні відображати цілі для 98% користувачів майбутнього сайту. Одна з груп при цьому буде основною, до неї увійде найбільший відсоток користувачів майбутнього проекту, на неї слід звернути особливу увагу.

При цьому важливо не забути, що крім зовнішніх користувачів, у проекту є ще й внутрішні, наприклад, контент-менеджери, менеджери з продажу, менеджер з підтримки та інші. Для цих користувачів не обов'язково робити докладний портрет, але їх цілі все одно потрібно врахувати. Саме для цих користувачів буде розроблятися адмінка. Величезний шматок роботи, про який більшість навіть не замислюється, але який в деяких проектах навіть складніше, ніж зовнішній сайт.

Далі, для кожної з цих груп треба скласти опис, якийсь портрет. Тут вже складніше. Добре, якщо команда проекту досконально знає ринок і може досить точно описати ЦА, але це рідкість. Я б рекомендував скласти список важливих для проекту питань, і піти з ним спілкуватися до представників різних груп. Це можна зробити на різних професійних івентах або в соціальних мережах. Причому зробити абсолютно безкоштовно. В даному випадку ми говоримо про якийсь аналог глибинного інтерв'ю, яке дає змогу зрозуміти мотиви людини і передбачити його поведінку. Мета — зрозуміти нашу цільову аудиторію, чим вона живе і як думає. В кожній з груп достатньо опитати по 20-30 чоловік, хоча, чим більше людей ми будемо питати, тим краще.

Після таких інтерв'ю ми повинні досить добре розуміти нашу ЦА. Всю інформацію потрібно систематизувати. В ідеалі згадати класику маркетингових досліджень, і для кожної групи скласти опис у 4-х площинах:

Соціально-демографічні характеристики: стать, вік, освіта, рівень доходів, рід занять, сім'я, діти і т. д. Це базова інформація, від неї ми будемо відштовхуватися. Поведінку (потреби, очікування і т. д.) людини з доходом до 300$ явно буде відрізнятися від поведінки людини з доходом в 30000$, тобто в рамках однієї групи параметрів можуть бути дуже різні люди, і зробити проект однаково цікавим всім просто неможливо. Для цього ми і повинні виділити основні групи ЦА, а після оптимізувати сайт під них.

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

Поведінкові характеристики: привід для реєстрації, шукані вигоди, частота відвідуваності конкурентів, ступінь готовності до переходу на інший сайт, ставлення до проекту (якщо він не новий), прихильність до існуючих сайтів і т. д. Цю групу ми трохи переробили від класичних маркетингових досліджень у бік Інтернету, тобто нам тут цікаво, як користувач поводиться саме в Інтернеті. У деяких випадках, коли ми робимо проект, пов'язаний з офф-лайном, нам також важливо поведінку користувачів і в реальному світі. З'ясувати це буде найскладніше, однак саме тут криється ключ до успіху проекту. 5-7 років тому була мода на копіювання Facebook, так от всі ті, хто копіював, взагалі не думали про поведінку користувачів. Всі сприймали Facebook, як сайт зі зручними інструментами взаємодії, а насправді, люди користувалися і користуються Facebook зовсім з інших мотивів. Знаючи хоча б щось про проектуванні, дуже багато компаній могли б не викидати гроші на клони Facebook, але немає, лаври Марка Цукерберга досі не дають спати деяким людям.

Географічні характеристики: країна, місто, район. У нових проектах я часто чую, що їм будуть користуватися «всі». Насправді, у кожної країни не тільки свою мову, але й своя культура. Так що навіть в інтернет-проектах нам важливо розуміти, на які країни ми орієнтуємося. А якщо проект буде пов'язаний з офф-лайном, тоді ця група набуває особливого значення. Користувачі з США явно будуть відрізнятися від користувачів з Тайланду, причому відрізнятися майже в усьому.

До речі, якщо хтось ще не здогадався: на етапі опитувань ЦА питання в анкетах повинні відповідати 4-м групам, описаним вище. Вони повинні розкривати кожну з цих груп.

В кінці цього етапу у нас буде документ з групами ЦА, і до кожної буде опис. Також, при дослідженні ЦА з'явиться багато корисних ідей, які потрібно буде виписати в окремий документ.

Персонажі і Empathy Map

Рис. 2. Персонажі проекту «Маркетплейс».

Цільова аудиторія у нас розбита на групи, і кожна з них описана. На попередньому етапі ми навіть зробили опитування кожної з груп. Але цього ще недостатньо. Далі нам потрібно зайнятися розробкою персонажів до кожної з груп ЦА. Персонаж — це якийсь типовий образ конкретної групи, яким потрібно розробити цілий портрет з описом хто він, де живе, чим захоплюється і т. д. Це допоможе нам більш глибоко зрозуміти нашу ЦА і оптимізувати проект під неї. Проектувальник повинен буде поставити себе на місце кожного персонажа і подумати про проект з його точки зору. Все це допоможе згенерувати ідеї для проекту.

В описі персонажа повинно бути:

  • ПІБ
  • Фото
  • Вік
  • Країна і місто
  • Рід занять
  • Сімейний стан
  • Поведінкові характеристики
Тобто багато в чому ми повторюємо попередній етап, коли описували кожну групу по заданим параметрам. Опис одного персонажа має бути до 1000 знаків, час на ці роботи теж має цінність. Фото має бути реальне, але при цьому незнайомої людини, щоб персонаж не сприймався нами через призму знань про кого-то.

Найважливіше після портрета — це завдання-проблеми-вирішення кожного користувача. Саме тут ми генеруємо основну частину ідей для нашого проекту. Ідеї попереднього етапу, в якому ми описали першу частину ЦА, ми можемо додати в задачі-проблеми-рішення, щоб розуміти, як саме ці ідеї з'явилися і з чим пов'язані.

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


Рис. 3. Карта эмпатий проекту «Маркетплейс».

Суть карти эмпатий в тому, щоб розділити ставлення користувача на 4 блоки:

  • Думаю і відчуваю.
  • Кажу і роблю.
  • Бачу.
  • Чую.
Потім проаналізувати їх та зробити висновки в двох площинах:

  • Проблеми та больові точки.
  • Цінності і досягнення.
Цей інструмент стане в нагоді не тільки в проектуванні, але й в маркетингу.

На виході ви отримаєте документ з низкою персонажів і до кожного з них свою карту эмпатий. Також після цього етапу повинно бути багато ідей для подальшого проектування.

Ринок і конкуренти

Рис. 4. Порівняння конкурентів проекту «Маркетплейс».

Після того, як ми визначилися з цілями і цільовою аудиторією, можна переходити до вивчення ринку і конкурентів. При оцінці будь-якого стійкого бізнесу або стартапу завжди оцінюється сам ринок, його обсяг, перспективи і т. д. Для цього потрібно відстежувати тренди і дослідження, відчувати ринок. Зазвичай власник продукту в курсі загальних тенденцій, інакше він починав проект. Але тут важливо вивчити ситуацію на сьогодні і знайти прогнози по зростанню ринку.

Є три ситуації на ринку: 1. Ринок падає. 2. Ринок стагнує. 3. Ринок зростає. Якщо ринок падає — на ньому взагалі нічого не варто починати, за дуже рідкісним винятком. Якщо він стагнує, тобто стабільний, швидше за все, всі основні вільні ніші вже зайняті, і влізти туди буде складно. Найвигідніша ситуація — це коли ринок росте. І чим швидше він зростає, тим більше шансів зірвати куш. Успішні проекти зазвичай з'являються при зростанні ринку. Є ще одна ситуація, четверта, коли проект створює ринок. Тобто власник продукту придумав щось зовсім нове, чого немає в світі. Ця найскладніший варіант і найбільш ризикований. Коли ринку немає, проект створюється в повному нерозумінні, наосліп. Саме у такій ринковій ситуації ховаються єдинороги, проекти на мільярди.

Щоб зрозуміти, де ми, нам потрібно ще раз подивитися на цілі і згадати, які саме потреби вирішує проект. У будь-якого ринку є межі. Знову ж таки, сказати, що наш ринок — весь інтернет, тому що у нас інтернет-проект, це в корені неправильно: у ринку повинні бути більш чіткі межі. І чим вже ринок, тим зрозуміліше, що саме потрібно спроектувати. Зазвичай ми описуємо ринок по 3-м параметрам: 1. Продукти (споживчі властивості, групи продуктів, замінники, ціни, комплект поставки тощо) 2. Географія (країни, міста). 3. Час (сезонність, перманентний або тимчасовий). З першими двома групами більш-менш зрозуміло, потрібно лише вивести критерії для проекту і описати його. Параметр «час» буває досить рідко і властивий деяким типам проектів, які зав'язані на сезонності. Наприклад, сезонність може бути важлива в туристичних проектах, і від розуміння цього феномена в проектуванні ми зможемо закласти певні «сезонні» функції, типу сезонних пропозицій / розсилок / активностей.

Часто онлайн ринок конкурує з оффлайн ринком. Наприклад, кредити онлайн — це окремий ринок зі своїми правилами та особливостями. Конкуруючим ринком буде кредити оффлайн. У даному випадку параметри ринку будуть відрізнятися тільки по першій і по другій категорії: по продуктам та географії. Продукт буде відрізнятися тим, що онлайн кредит отримати швидше, зручніше, інша процентна ставка і т. д. З географії: у нас немає прив'язки до відділення кредитної організації, тому отримувати такі кредити може кожен у будь-якій точці країни. При цьому, найчастіше, сама країна буде мати значення, але онлайн сервіс можна значно легше масштабувати. З першого погляду і там, і там кредити, хіба що один кредит видається готівкою, а інший на пластикову карту. Але якщо вдивитися в ринок, виявиться, що все різне. І онлайн кредити набагато зручніше старих добрих оффлайн, бо сервіси онлайн кредитування ростуть як гриби.

Говорячи про ринках і стратегіях я завжди згадую чудову книжку «Стратегія блакитного океану». Розуміння ринку і нашого місця на ньому дасть можливість розставити правильні акценти в проектуванні і зробити такий продукт, який зможе конкурувати з іншими. Поки багато хто не замислюються про це, так як в інтернеті ще немає такої великої конкуренції, як в офлайні. Але час йде, проектів стає більше, а вільних ніш все менше. Тому, вивчення ринку і конкуренції з кожним роком буде тільки посилюватися в проектуванні.

Знаючи ринок, ми можемо дослідити конкурентів. Мета — бути кращими. Особливо це важливо, коли ми виходимо на вже існуючий ринок, на якому є схожі проекти. І класного дизайну нам буде недостатньо, нам потрібно бути на кілька порядків краще, інакше конкурентну боротьбу не виграти. В ідеалі придумати унікальну «фішку», яка буде відрізняти нас від конкурентів, а насамперед, потрібно дізнатися кожну клітинку кожного конкурента.

Для початку потрібно зробити список конкурентів, розбити його на прямих і непрямих. Прямі — це проекти, які вирішують ту ж потребу, що і ми. Непрямі — це проекти-замінники, вони часто вирішують частину потреб, або ті, на яких перебуває наша цільова аудиторія, і ми з ними будемо конкурувати за користувачів. Зазвичай ми запитуємо визнаних експертів на ринку, гуглим за ключовими словами, шукаємо рейтинги, тематичні каталоги і т. д. Якщо наш ринок обмежений географічно, дуже допомагає вивчення подібних проектів на заході і в сусідніх країнах. Ці проекти не є нашими конкурентами, але можуть бути джерелом корисних ідей. Наприклад, ми зараз робимо один державний сайт. В цілях вивчити досвід подібних організацій ми подивилися такі сайти в сусідніх країнах, а також в США і Великобританії, що дозволило почерпнути багато корисних ідей.

Прямих конкурентів потрібно проаналізувати методом SWOT-аналізу. Для кожного буде табличка з описом сильних сторін, слабких сторін, можливостей і загроз. Це чимось нагадує Empathy Map, яку ми робили при аналізі цільової аудиторії, тільки для конкурентів. Сильні сторони і можливості в нас в проекті повинні бути не гірше, ніж у конкурентів. На слабких сторонах і загрози ми можемо зіграти, вони повинні бути значно краще, ніж у конкурентів. Результати цього аналізу вплинуть, як проектування, так і будуть корисними в маркетингу. Він дозволить зрозуміти, на що саме зробити акцент у проектуванні, і допоможе згенерувати багато корисних ідей.


Рис. 5. SWOT-аналіз для проекту «Маркетплейс».

Є ще один чудовий спосіб — конкурентна розвідка. Коли ми під виглядом клієнта йдемо до конкурентів і отримуємо багато цікавої інформації. Іноді без такої розвідки взагалі неможливо провести нормальне дослідження.

Коли ми досліджували основну інформацію про конкурентів, ми все це можемо зібрати гарний зведений аналіз — велику таблицю, в якій виведемо основні цікавлять нас параметри і порівняємо всіх конкурентів. Параметри формуються в залежності від проекту, адже порівнювати ми завжди будемо дуже різні проекти.

Окремо варто зробити таблицю порівняння функціоналу прямих конкурентів. Тобто виписати всі типові функції конкурентів в одну таблицю і галкамі проставити, у кого яка функція є. Причому кожну функцію оцінювати по балах (від 1 до 10), так як якість реалізації функції теж може відрізнятися. В кінці вивести загальну кількість балів, щоб зрозуміти, який з конкурентів найбільш пророблений. Всі розрахунки потрібно робити за методом зважених коефіцієнтів, так як важливість усіх функцій для нас різна. Також можна застосовувати принцип «розумного запозичення» і копіювати деякі функції у конкурентів, якщо вони будуть дійсно затребувані в нашому проекті. Найчастіше це робиться для великих блоків базового функціоналу або для окремих стандартних дрібниць в інтерфейсі, щоб користувач бачив те, до чого вже звик, і краще розумів новий проект. При цьому унікальний функціонал зазвичай не копіюється, саме в цій частині проект повинен відрізнятися, адже наше завдання зробити не клон, а конкурента на порядок краще вже працюючого проекту.

На цій стадії ми чітко уявляємо, що хочемо зробити, що потрібно нашої цільової аудиторії і що відбувається на ринку, в тому числі у конкурентів. Тобто це сама базова інформація, на якій будуються всі подальші рішення. Від якості цих етапів буде залежати успіх всього проекту. Якщо подивитися на сучасні стартапи, то більшість з них не проводять подібних досліджень і ґрунтуються на припущеннях засновників. Саме тому найпоширенішою причиною смерті стартапів є незатребуваність ринком (42%), про що я писав раніше. Тобто все це нам потрібно не для красивих картинок, які можна показати інвестору, а для гарантованого успіху всього починання.

В кінці цього етапу у нас буде короткий документ, опис ринку та порівнянням конкурентів. Зазвичай ми аналізуємо 5-7 прямих конкурентів і кілька західних аналогів. Крім того, в нашому проекті додасться нових ідей, підглянутих у конкурентів.

Завдання-Проблеми-Рішення

Рис. 6. ЗПР для проекту «Маркетплейс».

Один з найважливіших етапів для генерації ідей майбутнього проекту. При вивченні цільової аудиторії та ринку у нас вже є багато корисних ідей, але тут їх стане набагато більше. У кожної людини є свої потреби (завдання), при вирішенні яких кожен з нас зазвичай стикається з якимись труднощами (проблемами). Мета проектувальника придумати такі механіки (рішення), які зможуть вирішити завдання і проблеми користувачів. Наприклад, у людини може бути завдання придбати новий акумулятор для свого автомобіля, при цьому проблемою може бути незнання, який саме акумулятор підійде і який з них якісний. Рішеннями в цьому випадку можуть бути функції з рейтингом запчастин, відгуками користувачів, функція підбору запчастин по марці автомобіля і т. д. Таким чином, ми не просто придумаємо функції для проекту, а зробимо його корисним саме для нашої вузької цільової аудиторії.

Етап ЗПР бере свій початок в персонажах і Empathy Map. До кожного персонажу ми повинні створити таблицю з трьома колонками: Завдання-Проблеми-Рішення. Вживаючись в роль наших персонажів, ми зможемо уявити, що саме вони хочуть і з якими проблемами стикаються. Саме з цієї причини дуже важливо якість самих персонажів, щоб вони максимально відповідали реальності. Сама таблиця вийде у нас дуже великий, адже у нас буде близько 8-10 персонажів, і в кожного з них може бути по 5-7 завдань і проблем, які можуть спричинити за собою 20-30 ідей для майбутнього проекту. Вийде таблиця із сотнею ідей. Всі їх реалізовувати буде дуже довго і витратно, тому тут потрібно вибрати і поділити на етапи. Для першого етапу потрібно відібрати найважливіше, функціонал MVP. Але як вибрати найважливіше? З відповіддю на це питання нам допоможе Empathy Map.

Карта эмпатий для кожного персонажа дозволить доповнити ЗПР і виявить найбільш важливі функції для користувачів. Для цього нам потрібно досконало вивчити у всіх персонажів «проблеми та больові точки», а також «цінності та здобутки». Самі по собі ці групи несуть загальну інформацію і за ним генерувати конкретні функції деколи буває досить складно. Але зате, вони нам можуть підказати, на яких саме функціях варто зробити акцент. Наприклад, у цінностях може значитися «прагнення до самовираження», особливо, якщо ми проектуємо соціальну мережу або сайт знайомств. На перший погляд згенерувати конкретні функції з цієї особливості ЦА досить складно, але, з іншого боку, вона нам показує, що для нашої ЦА будуть важливі функції, пов'язані з самовираженням. Тобто проектуючи подібний сайт, нам потрібно виносити ці функції на більш помітні і центрові місця в інтерфейсі, приділити особливу увагу їх деталізації.

Роблячи ЗПР, багато припускаються помилки і починають вписувати спільні завдання. Я бачив інтернет-магазини, корпоративні сайти, в яких намагалися всунути форуми чи ще щось дуже загальне. Все це мотивувалося тим, що «люди в звичайному житті спілкуються, так чому вони не будуть робити це в нашому проекті!?». Подібні ідеї не просто марна трата ресурсів, це пряма шкода проекту, розмивання основної ідеї. У будь-якого проекту має бути спеціалізація, і чим вона вже, тим простіше його просувати і доносити користувачам його цінність. Саме для цього ми і обмежили себе цільовою аудиторією і ринковими кордонами, щоб за них не виходити. Тому ЗПР мають бути тільки ті завдання, які пов'язані з нашим проектом. Можу посперечатися, що при правильному підході їх буде дуже багато, більше, ніж ресурсів.

В кінці цього етапу у нас повинна вийти велика таблиця з 3-ма колонками, і всі вони будуть прив'язані до конкретних персонажів. Найбільшою з них буде колонка з рішеннями. Це і будуть основні функції нашого майбутнього проекту.

Customer Development

Три роки тому ми окремо не виділяли цей етап. У нас майже в будь-якому проектуванні розроблявся документ «Монетизація» або подібний. В інтерфейсах ми враховували платіжні інструменти. Та й взагалі одна з основних наших спеціалізація — це електронна комерція, досить широке поняття, яке зводиться до продажу-покупок через Інтернет всього, чого завгодно, ми добре розбираємося в цих питаннях, але системно підходити до питань CustDev почали лише нещодавно.

На попередніх етапах ми отримали багато інформації про майбутніх споживачів і ринках. Ми знаємо, чого вони хочуть, які у них проблеми і знаємо, як їх вирішити. Саме час зрозуміти, за що можна брати з нашої ЦА гроші. В цьому і є суть Customer Development — створити настільки велику цінність, за яку готові будуть платити. Це дуже складний, але і шалено важливий етап. Саме тут лежить відповідь на питання: чи стане стартап бізнесом і як швидко. Зробити популярний проект недостатньо, з нього потрібно навчитися заробляти.

Існує кілька популярних моделей монетизації:

  1. Реклама — показ реклами користувачам, основні функції для них безкоштовні. Наприклад, контекстна реклама в Google.
  2. Передплата — платна підписка на преміум функціонал або просто доступ. Наприклад, платні додатки в App Store.
  3. Freemium — базовий функціонал безкоштовно, а решта за гроші. Наприклад, VIP анкета на сайтах знайомств.
  4. Платформа — проект виступає платформою, на якій люди (компанії) один одному щось платять, а проект з цього бере відсоток. Наприклад, фріланс сайти, які беруть відсоток від транзакцій.
  5. Послуги — разова або постійна оплата за якісь послуги. Наприклад, за відкриття якоїсь інформації або можливість виділиться.
  6. Реальні товари — продаж товарів реального світу, класична електронна комерція. Наприклад, будь-який інтернет-магазин.
  7. Віртуальні товари — продаж віртуальних товарів. Наприклад, продаж віртуальних товарів в іграх.
Багато моделей можуть перетинатися один з одним. Наприклад, Facebook і Google 80% своїх доходів отримують від реклами, але у них також є багато різних продуктів, які можна купити за передплатою, є цілі платформи і т. д.

Крім популярних моделей є і досить унікальні. Наприклад, можна збирати і продавати особисту інформацію користувачів для рекламних цілей, що багато хто і роблю в США сьогодні. У будь-якому випадку, не потрібно бігти за модою, потрібно пропонувати нашим користувачам той інструмент, за який вони готові платити.

Для початку проектувальник повинен зрозуміти, за що люди готові платити. Для цього краще всього використовувати Empathy Map, яка показує нам найцінніше для користувачів. Потім потрібно продумати, як саме застосовується та чи інша модель монетизації. І третім кроком, треба зробити розрахунки по виручці, при цьому прив'язуючись до користувачів. Наприклад, є ми вирішили робити платформу і брати 3% ос всіх транзакцій, то нам потрібно добитися обігу хоча б в 1 млн. дол. в міс., щоб проект запрацював 30 тис. дол. А ще у нас є поточні витрати на підтримку такого сайту, команда розробки, якої потрібно платити і т. д.

Окремо варто задуматися над тим, скільки клієнти готові платити за ту цінність, яку ми пропонуємо. Для цього нам потрібно зрозуміти, скільки зараз вони витрачають грошей і часу на вирішення своєї потреби або скільки вони зекономлять, скориставшись наші продуктом. Наприклад, якщо у нас SaaS сервіс, скажімо CRM, то ми допомагаємо клієнтам продавати більше, значить, заробляємо для них більше грошей. Як з'ясувати, наскільки більше наші клієнти заробляють з нами? Для цього можна: 1. Зробити розрахунок. 2. Запитати клієнтів. 3. Зробити порівняння конкурентів. У кожного з методів є проблеми: 1. При розрахунку можна помилитися, так і даних зазвичай недостатньо. 2. Клієнти не завжди кажуть правду, хай і хочуть платити якомога менше. 3. Конкуренти не завжди є. Але в будь-якому випадку ми повинні на чомусь засновувати в ціноутворенні, і це теж частина правильного проектування, в якій нам можуть допомогти професійні маркетологи.

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

Mind map

Рис. 7. Mind Map для проекту «Маркетплейс».

Отже, у нас купа ідей. У будь-якому великому проекті ідей на цьому етапі у нас має бути за сотню, може навіть кілька сотень. В такій масі ідей можна просто загубитися. Крім того, ми не бачимо ієрархію ідей, зв'язків і що на що впливає. Далі нам потрібно зібрати всі ці ідеї в один великий Mind map, де буде видно вкладеність і зв'язку. Це перший крок до візуалізації.

Основна частина ідей у нас у великій таблиці ЗПР. Беремо колонку рішення і по порядку вписуємо всі ідеї в нашу Mind map, паралельно їх групуючи. Виписувати слід короткі, але зрозумілі формулювання, весь текст у Mind map запихати не потрібно. При цьому, якщо є ідея якоїсь функції, яка має різні параметри, ми їх повинні виписати, як продовження карти розуму. Наприклад, якщо у нас є функція «онлайн-оплата» і у неї є варіанти: кредитна карта, PayPal і готівкою, то карті розуму так і показуємо, гілка «Онлайн-оплата», вкладеності — 3 варіанти оплати. Деталізувати карту дуже важливо, місцями аж до полів у всіх формах. Проблема в тому, що поки ми працюємо з аналітикою, ми добре пам'ятаємо, що потрібно зробити. Як тільки ми перейдемо на роботу з окремими інтерфейсами, все почне забуватися. І якщо ми не деталізуємо карту, нам доведеться проектувати інтерфейси не по карті (як правильно робити), а ритися в минулих етапах аналітики і згадувати, що ми придумали. Також, крім ЗПР, нам потрібно внести ідеї в нашу карту та інших документів, які у нас накопичилися. Абсолютно всі ідеї повинні бути відображені в картці.

Зазвичай робиться одна велика карта, але проекти бувають настільки великими, що для зручності доводиться ділити карти на кілька. Зазвичай в карті є 7-10 основних гілок і все пишеться в них, створюючи довгі логічні ланцюжки з вложенностями. В них ми відразу можемо цифрами розділити функції на етапи впровадження та важливість. Також ми повинні показати стрілками всі зв'язки. Наприклад, функція реєстрації часто пов'язана з дуже багатьма функціями в проекті, і, як мінімум, після реєстрації користувачеві стають доступні особливі функції — все це потрібно відобразити на карті. Також припустимі і інші мітки. Завдання можуть бути найрізноманітнішими, і в цих сотнях ідей, навіть розбитих на логічні зв'язки, можна загубитися. У будь-якому випадку, проробляючи цю процедуру, ми перетворимо хаос в систему і, насамперед, зробимо це для себе в своїй голові.

Ми робимо карти в спеціальній програмі — Xmind, хоча є багато альтернативних програм і онлайн сервісів. Тут не принципово.

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

Всі попередні етапи та сама карта не займають багато часу. Це нульова ітерація у проекті, після якої вже можна починати програмувати, поки проектувальник буде працювати над першими інтерфейсами. Навіть якщо проект великий, етап аналітики у нас в середньому займає 40-60 годин. Невелика ціна, щоб закласти правильну основу, і не переробляти пізніше.

Далі потрібно буде проектувати інтерфейси. І робити це потрібно на основі Mind map. Якщо карта настільки деталізована, що проектувальнику не потрібно повертатися до минулих етапів аналітики, значить карта зроблена добре.

В кінці цього етапу у нас буде одна Mind map або кілька на різні частини проекту, етапність впровадження фіч і пріоритети.

Структура сайту

Рис. 8. Структура сайту для проекту «Маркетплейс».

Зробивши мапу по функціоналу, в теорії можна приступати до інтерфейсів. Але на першому ж інтерфейсі виникне проблема — яку структуру і яке головне меню зробити? У нашій Mind map у нас 7-10 основних розділів, а ще є безліч важливих другорядних. Золоте правило юзабіліті («Гаманець Міллера») проголошує: в одному блоці не може бути більше 5-7 елементів. Це ж поширюється і на головне меню. Втім, є й виключення, якщо всі пункти меню несуть однакове смислове навантаження, то можна і більше. Наприклад, сайти ЗМІ або інтернет-магазинів, де меню — це тематичні розділи. Всередині кожного пункту меню статті, просто різної тематики. Бувають і інші виключення, але це рідкість.

Для початку потрібно зрозуміти, що не всі функції нашої Mind map — це розділи. Навіть основні. Розділи сайту повинні бути прості, зрозумілі, і кожен повинен нести користь нашим юзерам. Тому для структури зазвичай робиться окрема Mind map, в якій ми відображаємо тільки сторінки і розділи майбутнього сайту. В ідеалі, не перевищувати 3-х рівневу структуру, хоча сучасні сайти вже не так суворо дотримуються цього правила. Всі розділи і підрозділи повинні бути інтуїтивно зрозумілими, по кожній назві людина повинна відразу розуміти, що його чекає за цим посиланням і які підрозділи там можуть ховатися. Часто у великих проектах є основне меню і кілька допоміжних. Наприклад, в інтернет-магазинах основним меню каталог товарів, а допоміжним інформація про оплату, доставку, контакти, про магазині і т. д. Буває, що окремо потрібно відобразити меню особистого кабінету для різних ролей або інші приховані від усіх користувачів розділи.

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

Це кінець першої частини статті. Те, що ми називаємо аналітичною частиною проектування. У наступній статті ви дізнаєтеся, як перетворити всю цю аналітику в інтерфейси і зокрема в динамічний прототип.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.