Заморожен. С 2022 года новых функций не появляется. Это мой стартап, который я начал проектировать в 2017 году. Когда-нибудь напишу об этом опыте большой пост.
Представляете, я дописал и опубликовал книгу в начале 2023 года. И пишу об этом регулярно и здесь, и в Телеграме, и на Проекторатовских ресурсах. И до сих пор не все знают.
Это наглядный пример того, насколько важно постоянно рассказывать о своих делах, а не один-два раза. Не бояться повторяться и не думать, что все всё сами узнают.
С удовольствием послушал бы о вашем проектике в личке.
Я не ограничиваю клиентов в количестве правок. Почему так — написал об этом целую главу в Книге нормального фрилансера: https://normfreelancer.ru/book/beskonechnye-pravki/
Я тоже сталкивался с такими людьми. Более того, сам по-человечески понимаю это чувство. Но я считаю такое поведение незрелым и стараюсь не взаимодействовать с подобными специалистами до поры до времени (видел, как у многих с возрастом и опытом этот подход менялся).
Я начал работать в Axure за десять лет до того, как появилась Фигма. А когда она появилась, никто не заставлял меня на неё переходить. Это просто инструменты.
Пожалуйста. Хочу поделиться с вами двумя моментами, когда мой подход к проектированию сильно менялся.
Первый — примерно через пять лет после начала карьеры. Году в 2010. Я был на острие передовых методов проектирования и внедрял их в свои процессы. Тогда в России только-только набирали популярность персонажи, jtbd, cjm. Я работал с несколькими студиями. Частные клиенты только-только появлялись в моей жизни. Моими самыми частыми проектами в тот период были интернет-магазины. И я тогда сделал около 40 таких магазинов в течение нескольких лет, с каждым проектом продавая всё больше дополнительных артефактов. Это несколько затягивало этап проектирования, но перформанс в глазах клиента был замечательным. Много документации, много оснований для принятия решений.
Но в какой-то момент я сравнил два прототипа. Один из первого десятка, а второй из последнего. И разница между ними была ну максимум процентов в двадцать. Процесс поиска и покупки товара в интернете был достаточно универсальным для того, чтобы с совершенно разными персонажами и сценариями в итоге стремиться к одинаковой форме. Там я прочувствовал, сколько ненужной работы продаю за деньги, и мне стало стыдно. После этого я вынес все эти дополнительные артефакты за скобки. И если мне нужно было воспользоваться одним из них для себя в каком-то особом случае, клиент об этом даже не догадывался.
Второй — когда я в течение пяти лет поднял собственный проект. Там-то круг и замкнулся. Во-первых, я убедился на практике, насколько хорошо работают мои подходы к работе (и окончательно распрощался с синдромом самозванца). А, во-вторых, увидел, насколько важны те вещи, которые мне раньше казались неважными. Как важно описывать всё в функциональной спецификации. Как важно иметь эталонный дизайн. Как важно учитывать стек технологий, если он нам известен на этапе проектирования. Проектировщику, который ни разу не запускал собственного проекта (или который ни разу не работал внутри команды, поднимающей проект), сложно получить эти знания. А я много лет проработал именно таким проектировщиком: проектировал информационные системы и махал клиенту ручкой. А ведь настоящая работа начинается где-то после релиза.
Нам надо сделать форму для клиента. С данными для договора. Заполняем тип заказчика и его реквизиты и тип исполнителя и его реквизиты. Указываем, кто берёт на себя ответственность за маркировку рекламы, сколько стоит размещение и на какой планируется срок.
Клиент хотел на выходе pdf, но я предложу ему на выходе doc, который можно легко подредактировать уже после генерации. Это сразу избавляет нас от сценариев, связанных с хранением и изменением данных, и удешевляет разработку без потери функций.
Проектируем набор полей, их валидацию, сообщения об ошибках и успехе. Берём актуальный договор, продумываем и показываем, какие данные и как туда попадают из нашей формы. Согласовав внешний вид формы, описываем её в функциональной спецификации.
Несколько раз в процессе предлагаем не усложнять проект. Первоначальная задача — автоматизировать часть небольшого процесса, который будет актуален для человека, занимающегся оформлением договоров (в нашем случае это сам заказчик или один из его менеджеров). Поэтому нам не нужны системы аутентификации, связи с внешними сервисами (например, запрос по api данных о юрлицах после заполнения ИНН), так как первое — избыточно, а последнее — потребует техподдержки в дальнейшем.
После этого передаём проектную документацию дизайнеру и программисту. От первого получаем пару-тройку позитивных правок плюс что-то всплывёт при адаптации формы под разные вьюпорты. От последнего — набор технических ограничений в связи с определившимся стеком технологий и просьбу использовать какой-нибудь конкретный фреймворк для вёрстки (бутстрап, например). На основе этой обратной связи актуализируем проектную документацию и корректируем дизайн.
— Персоны пользователей — не нужны, т.к. мы ещё перед началом проектирования точно знаем, кто будет пользоваться продуктом, как и в каких условиях; — CJM — не нужна. Прототип будет состоять из пяти-шести экранов, показывающих разные динамичные состояния формы. Плюс будет договор с выделенными и описанными динамическими участками. Сам по себе этот прототип и будет представлять собой самую наглядную CJM; — Отчёт о UX-тестировании — не нужен. Прототип и дизайн будут готовы в течение недели (два дня на прототип, два дня на функциональуню спецификацию). Ещё за неделю форму закодят и сверстают. И после этого начнётся настоящее «UX-тестирование».
Разумеется, перед началом работ мы проверим, нет ли чего-нибудь похожего уже в готовом виде. Возможно даже найдём и посмотрим, нельзя ли чего-нибудь из него позаимствовать.
Для каждого проекта, за который я берусь, я подбираю набор методик, подходящий ему по смыслу. Поэтому в статье я и не описываю эту часть. Она совершенно не универсальна. У меня не раз бывали клиенты, которые уходили довольные после первых переговоров-знакомства. Когда я в ответ на их запрос просто скидывал ссылку на сервис или набор сервисов, которые уже завтра могут решить его задачу — и проектировать ничего не надо.
Часть артефактов, которые вы перечислили — они либо для студентов, которым пока что нужны такие вспомогательные опорные штуки из-за отсутствия опыта, либо адресованы от специалистов к специалистам. Дайте мне проработанную CJM по проекту — и мне она поможет быстро въехать в суть дела. Дайте такой артефакт клиенту — и он оказывается в ситуации, когда ему нужно согласовать что-то, в чём ему трудно разобраться. Поэтому своим клиентам я не показываю и не предлагаю чего-то более сложного и абстрактного, чем интерактивный прототип. А сбор данных по проекту устроен таким образом, что клиент считает, что просто болтает со мной, а не помогает описывать чьи-то портреты или фиксировать процессы.
Даже функциональные требования я уже сколько лет подряд стараюсь упрощать и упрощать — а всё равно сложный документ, всё равно не читают его до конца, подписывают, а затем создают новые функциональные требования на лету. И это нормально, так и должно быть.
Можете уточнить, что именно вы вкладываете в понятия «исследование» и «тесты с пользователями»?
Возьмём, к примеру, проектирование сервиса, который автоматизирует процесс оформления договора на размещение и маркировку рекламы (пользователь заполняет форму с реквизитами сторон и некоторыми дополнительными данными — и на выходе получает pdf для подписи). Клиент — стартапер, который технически хочет автоматизировать собственный устоявшийся бизнес-процесс.
В моём случае клиент получит интерактивный прототип, который «пощёлкает» сам и, возможно, покажет паре знакомых с вопросом «как тебе?».
Как будет выглядеть этап исследования и тестов у вас и сколько займёт по времени и ресурсами?
Здравствуйте. Ваш вопрос лучше адресовать разработчику, а не проектировщику. Но могу пофантазировать.
1. Что именно нужно изучать — будет зависеть от того, что конкретно вы собираетесь разрабатывать; 2. Выбор языка также будет зависеть от программного комплекса, который вы собираетесь разрабатывать; 3. Время на изучение будет зависеть от вашей персональной способности к обучению, а также от того, будет у вас преподаватель (и какой именно) или нет.
То есть я бы сказал, что на ваши вопросы невозможно ответить, пока они настолько абстрактны.
1. Как давно у вас там существует аккаунт? 2. Вы получили 7 заказов за семь дней или семь заявок? 3. В каких числах это произошло? 4. Как вас там найти? (Очень интересно взглянуть на пример оформленного профиля) 5. За какой срок вы сумели выполнить эти семь заказов? 6. Получили ли вы новые заказы, пока выполняли те семь?
Конечно, бывают. В этом плане мне нравится пример с наглыми водителями на дорогах. Кто-то подрезает тебя или перекрывает целый ряд на светофоре в пробку. И такие товарищи очень хорошо врезаются в память и создают ощущение низкого уровня культуры вождения в целом. А на деле-то их единицы. Во время поездки вокруг мельтешат сотни, а то и тысячи порядочных водителей, а запоминаются непорядочные единицы. Так и здесь. В целом всё не так и плохо.
Антон, согласен, не хватало. Добавил!
Ух ты, прям диаметрально противоположная позиция!
Заморожен. С 2022 года новых функций не появляется. Это мой стартап, который я начал проектировать в 2017 году. Когда-нибудь напишу об этом опыте большой пост.
Спасибо за поддержку!
Представляете, я дописал и опубликовал книгу в начале 2023 года. И пишу об этом регулярно и здесь, и в Телеграме, и на Проекторатовских ресурсах. И до сих пор не все знают.
Это наглядный пример того, насколько важно постоянно рассказывать о своих делах, а не один-два раза. Не бояться повторяться и не думать, что все всё сами узнают.
С удовольствием послушал бы о вашем проектике в личке.
Ой, а что будет с Фигмой после 12 сентября? Я какую-то новость пропустил?
Даже боюсь спросить, за что вас так минусанули.
Я не ограничиваю клиентов в количестве правок. Почему так — написал об этом целую главу в Книге нормального фрилансера: https://normfreelancer.ru/book/beskonechnye-pravki/
С какой целью создавали игру?
Ролики на YouTube можно публиковать без дополнительной обвязки в виде Телеграма. Вы не ошибались.
Я тоже сталкивался с такими людьми. Более того, сам по-человечески понимаю это чувство. Но я считаю такое поведение незрелым и стараюсь не взаимодействовать с подобными специалистами до поры до времени (видел, как у многих с возрастом и опытом этот подход менялся).
Я начал работать в Axure за десять лет до того, как появилась Фигма. А когда она появилась, никто не заставлял меня на неё переходить. Это просто инструменты.
Пожалуйста. Хочу поделиться с вами двумя моментами, когда мой подход к проектированию сильно менялся.
Первый — примерно через пять лет после начала карьеры. Году в 2010. Я был на острие передовых методов проектирования и внедрял их в свои процессы. Тогда в России только-только набирали популярность персонажи, jtbd, cjm. Я работал с несколькими студиями. Частные клиенты только-только появлялись в моей жизни. Моими самыми частыми проектами в тот период были интернет-магазины. И я тогда сделал около 40 таких магазинов в течение нескольких лет, с каждым проектом продавая всё больше дополнительных артефактов. Это несколько затягивало этап проектирования, но перформанс в глазах клиента был замечательным. Много документации, много оснований для принятия решений.
Но в какой-то момент я сравнил два прототипа. Один из первого десятка, а второй из последнего. И разница между ними была ну максимум процентов в двадцать. Процесс поиска и покупки товара в интернете был достаточно универсальным для того, чтобы с совершенно разными персонажами и сценариями в итоге стремиться к одинаковой форме. Там я прочувствовал, сколько ненужной работы продаю за деньги, и мне стало стыдно. После этого я вынес все эти дополнительные артефакты за скобки. И если мне нужно было воспользоваться одним из них для себя в каком-то особом случае, клиент об этом даже не догадывался.
Второй — когда я в течение пяти лет поднял собственный проект. Там-то круг и замкнулся. Во-первых, я убедился на практике, насколько хорошо работают мои подходы к работе (и окончательно распрощался с синдромом самозванца). А, во-вторых, увидел, насколько важны те вещи, которые мне раньше казались неважными. Как важно описывать всё в функциональной спецификации. Как важно иметь эталонный дизайн. Как важно учитывать стек технологий, если он нам известен на этапе проектирования. Проектировщику, который ни разу не запускал собственного проекта (или который ни разу не работал внутри команды, поднимающей проект), сложно получить эти знания. А я много лет проработал именно таким проектировщиком: проектировал информационные системы и махал клиенту ручкой. А ведь настоящая работа начинается где-то после релиза.
Нам надо сделать форму для клиента. С данными для договора. Заполняем тип заказчика и его реквизиты и тип исполнителя и его реквизиты. Указываем, кто берёт на себя ответственность за маркировку рекламы, сколько стоит размещение и на какой планируется срок.
Клиент хотел на выходе pdf, но я предложу ему на выходе doc, который можно легко подредактировать уже после генерации. Это сразу избавляет нас от сценариев, связанных с хранением и изменением данных, и удешевляет разработку без потери функций.
Проектируем набор полей, их валидацию, сообщения об ошибках и успехе. Берём актуальный договор, продумываем и показываем, какие данные и как туда попадают из нашей формы. Согласовав внешний вид формы, описываем её в функциональной спецификации.
Несколько раз в процессе предлагаем не усложнять проект. Первоначальная задача — автоматизировать часть небольшого процесса, который будет актуален для человека, занимающегся оформлением договоров (в нашем случае это сам заказчик или один из его менеджеров). Поэтому нам не нужны системы аутентификации, связи с внешними сервисами (например, запрос по api данных о юрлицах после заполнения ИНН), так как первое — избыточно, а последнее — потребует техподдержки в дальнейшем.
После этого передаём проектную документацию дизайнеру и программисту. От первого получаем пару-тройку позитивных правок плюс что-то всплывёт при адаптации формы под разные вьюпорты. От последнего — набор технических ограничений в связи с определившимся стеком технологий и просьбу использовать какой-нибудь конкретный фреймворк для вёрстки (бутстрап, например). На основе этой обратной связи актуализируем проектную документацию и корректируем дизайн.
— Персоны пользователей — не нужны, т.к. мы ещё перед началом проектирования точно знаем, кто будет пользоваться продуктом, как и в каких условиях;
— CJM — не нужна. Прототип будет состоять из пяти-шести экранов, показывающих разные динамичные состояния формы. Плюс будет договор с выделенными и описанными динамическими участками. Сам по себе этот прототип и будет представлять собой самую наглядную CJM;
— Отчёт о UX-тестировании — не нужен. Прототип и дизайн будут готовы в течение недели (два дня на прототип, два дня на функциональуню спецификацию). Ещё за неделю форму закодят и сверстают. И после этого начнётся настоящее «UX-тестирование».
Разумеется, перед началом работ мы проверим, нет ли чего-нибудь похожего уже в готовом виде. Возможно даже найдём и посмотрим, нельзя ли чего-нибудь из него позаимствовать.
Для каждого проекта, за который я берусь, я подбираю набор методик, подходящий ему по смыслу. Поэтому в статье я и не описываю эту часть. Она совершенно не универсальна. У меня не раз бывали клиенты, которые уходили довольные после первых переговоров-знакомства. Когда я в ответ на их запрос просто скидывал ссылку на сервис или набор сервисов, которые уже завтра могут решить его задачу — и проектировать ничего не надо.
Часть артефактов, которые вы перечислили — они либо для студентов, которым пока что нужны такие вспомогательные опорные штуки из-за отсутствия опыта, либо адресованы от специалистов к специалистам. Дайте мне проработанную CJM по проекту — и мне она поможет быстро въехать в суть дела. Дайте такой артефакт клиенту — и он оказывается в ситуации, когда ему нужно согласовать что-то, в чём ему трудно разобраться. Поэтому своим клиентам я не показываю и не предлагаю чего-то более сложного и абстрактного, чем интерактивный прототип. А сбор данных по проекту устроен таким образом, что клиент считает, что просто болтает со мной, а не помогает описывать чьи-то портреты или фиксировать процессы.
Даже функциональные требования я уже сколько лет подряд стараюсь упрощать и упрощать — а всё равно сложный документ, всё равно не читают его до конца, подписывают, а затем создают новые функциональные требования на лету. И это нормально, так и должно быть.
В случае с моим примером у вас получилось дополнительных 4-6 дней работы. Клиент получит какие-то дополнительные артефакты в результате этих работ?
Можете уточнить, что именно вы вкладываете в понятия «исследование» и «тесты с пользователями»?
Возьмём, к примеру, проектирование сервиса, который автоматизирует процесс оформления договора на размещение и маркировку рекламы (пользователь заполняет форму с реквизитами сторон и некоторыми дополнительными данными — и на выходе получает pdf для подписи). Клиент — стартапер, который технически хочет автоматизировать собственный устоявшийся бизнес-процесс.
В моём случае клиент получит интерактивный прототип, который «пощёлкает» сам и, возможно, покажет паре знакомых с вопросом «как тебе?».
Как будет выглядеть этап исследования и тестов у вас и сколько займёт по времени и ресурсами?
Здравствуйте. Ваш вопрос лучше адресовать разработчику, а не проектировщику. Но могу пофантазировать.
1. Что именно нужно изучать — будет зависеть от того, что конкретно вы собираетесь разрабатывать;
2. Выбор языка также будет зависеть от программного комплекса, который вы собираетесь разрабатывать;
3. Время на изучение будет зависеть от вашей персональной способности к обучению, а также от того, будет у вас преподаватель (и какой именно) или нет.
То есть я бы сказал, что на ваши вопросы невозможно ответить, пока они настолько абстрактны.
Ню-ню!
Можете поделиться опытом по Kwork'у?
1. Как давно у вас там существует аккаунт?
2. Вы получили 7 заказов за семь дней или семь заявок?
3. В каких числах это произошло?
4. Как вас там найти? (Очень интересно взглянуть на пример оформленного профиля)
5. За какой срок вы сумели выполнить эти семь заказов?
6. Получили ли вы новые заказы, пока выполняли те семь?
Конечно, бывают. В этом плане мне нравится пример с наглыми водителями на дорогах. Кто-то подрезает тебя или перекрывает целый ряд на светофоре в пробку. И такие товарищи очень хорошо врезаются в память и создают ощущение низкого уровня культуры вождения в целом. А на деле-то их единицы. Во время поездки вокруг мельтешат сотни, а то и тысячи порядочных водителей, а запоминаются непорядочные единицы. Так и здесь. В целом всё не так и плохо.