Комментарии 20
Чтобы без внутреннего сопротивления приступить к работе
Это самое сложное )
Здравствуйте, реагирую на просьбу в начале статьи - благодарю за проделанную работу, как по мне статья довольно полезная и информативная. Если вам не трудно, будьте любезны уделить немного времени, что бы ответить мне. Фактически, все что я знаю на данный момент из IT это школьная база Python и информация полученная со статей, таких как ваша, но мне хотелось бы развиваться далее в этой сфере. Мне 17 лет, я студент экономического фк, хочу изучить все необходимое для того что бы в будущем быть способным: 1. Автоматизировать работу с документами и базами данных (вроде как это называют макросами) 2. Создавать свои сайты с развернутым функционалом 3. Писать программы для анализа финансов(бух. учет.) 4. Программировать так скажем для души, написать себе условного Jarvis на пк, бота в телеграмме и радоваться) В чем, собственно говоря, к вам вопрос, что я должен изучать для этого? Какие языки лучше подходят, с чего лучше начинать, сколько лет потребуется на изучение всего этого если тратить примерно полчаса-час в день? Учить я хочу для себя, не для того что бы работать в этой сфере. С заранее благодарю за ваш ответ.
Здравствуйте. Ваш вопрос лучше адресовать разработчику, а не проектировщику. Но могу пофантазировать.
1. Что именно нужно изучать — будет зависеть от того, что конкретно вы собираетесь разрабатывать;
2. Выбор языка также будет зависеть от программного комплекса, который вы собираетесь разрабатывать;
3. Время на изучение будет зависеть от вашей персональной способности к обучению, а также от того, будет у вас преподаватель (и какой именно) или нет.
То есть я бы сказал, что на ваши вопросы невозможно ответить, пока они настолько абстрактны.
В школах учат Python? o0
Напиши в ТГ, ник. Azazaki
Подскажу
Эх, как бы это все облегчило мою жизнь прочти нечто подобное 3-4 месяца назад. Хотя это только часть из моего проекта (у меня разработка программы). Продолжайте делиться своим опытом, у вас она несомненно есть и получается.
То есть проектируете без исследований и тестов с пользователями? Хм
Можете уточнить, что именно вы вкладываете в понятия «исследование» и «тесты с пользователями»?
Возьмём, к примеру, проектирование сервиса, который автоматизирует процесс оформления договора на размещение и маркировку рекламы (пользователь заполняет форму с реквизитами сторон и некоторыми дополнительными данными — и на выходе получает pdf для подписи). Клиент — стартапер, который технически хочет автоматизировать собственный устоявшийся бизнес-процесс.
В моём случае клиент получит интерактивный прототип, который «пощёлкает» сам и, возможно, покажет паре знакомых с вопросом «как тебе?».
Как будет выглядеть этап исследования и тестов у вас и сколько займёт по времени и ресурсами?
Отличный пример, спасибо! У данного сервиса будет как минимум два пользователя: стартапер и его клиент. Допустим, вы очень качественно забрифовали стартапера и через правильные вопросы смогли увидеть за его "я хочу" реальные бизнесовые задачи и проблемы, которые он хочет решить данным сервисом. Как быть с пользователем? Кто он? Какие у него ожидания от взаимодействия с проектируемым сервисом? Какую задачу решает он? В каком контексте он будет пользоваться сервисом (десктоп/моб? в офисе утром или в пробке в машине? сам или его сотрудник? это разовый процедура или сервис должен уметь сохранять реквизиты и подставлять их при следующем заполнении? и тд...)? Предлагаемый сервис будет для пользователя чем-то новым и неизвестным или из категории "ну наконец-то вы до этого додумались - весь рынок уже 10 лет так делает" (в первом случае будет не лишним выявить его ментальную модель, во втором - бэнчмарк-анализ рынка мастхэв). Это ответ на вопрос, что вкладываю в понятие "исследования"
Далее, прототип готов, стартапер покликал по нему, показал своим знакомым с вопросом "как тебе?". Они сказали "прикольно" (они не пользователи, поэтому оценивать будут по картинка: красиво/не красиво). А клиенту будет удобно? Как мы можем быть уверены, что он разберется в интерфейсе? А пограничные сценарии предусмотрели? Ведет ли себя пользователь в интерфейсе так как мы рассчитывали или идет по не запланированному сценарию? Это ответ на вопрос, что я вкладываю в понятие "тесты с пользователями"
В сухом остатке:
серия коротких интервью с пользователями (5-7 = 2-3 дня)
серия ux-тестов по основным сценариям взаимодействия с интерфейсом (5 штук = 2-3 дня)
В случае с моим примером у вас получилось дополнительных 4-6 дней работы. Клиент получит какие-то дополнительные артефакты в результате этих работ?
Как минимум анализ конкурентов даёт понимание особенностей ниши и могут получится весьма полезные инсайты которые положительно повлияют на продукт. Поэтому резонный вопрос, делает ли вы анализ конкурентов, ЦА, использует ли методики персон, CJM, JTBD и т.п.?
Клиент получит продукт, который а) решает задачу бизнеса б) понятен и удобен для пользователя. Но если вопрос в том, чем отчитаться перед клиентом и как показать ему свою работу, тогда по итогам исследований и тестов можно получить следующие артефакты: персоны пользователей, CJM, отчет о UX-тестировании (время выполнения задачи, error rate, success rate)
Нам надо сделать форму для клиента. С данными для договора. Заполняем тип заказчика и его реквизиты и тип исполнителя и его реквизиты. Указываем, кто берёт на себя ответственность за маркировку рекламы, сколько стоит размещение и на какой планируется срок.
Клиент хотел на выходе pdf, но я предложу ему на выходе doc, который можно легко подредактировать уже после генерации. Это сразу избавляет нас от сценариев, связанных с хранением и изменением данных, и удешевляет разработку без потери функций.
Проектируем набор полей, их валидацию, сообщения об ошибках и успехе. Берём актуальный договор, продумываем и показываем, какие данные и как туда попадают из нашей формы. Согласовав внешний вид формы, описываем её в функциональной спецификации.
Несколько раз в процессе предлагаем не усложнять проект. Первоначальная задача — автоматизировать часть небольшого процесса, который будет актуален для человека, занимающегся оформлением договоров (в нашем случае это сам заказчик или один из его менеджеров). Поэтому нам не нужны системы аутентификации, связи с внешними сервисами (например, запрос по api данных о юрлицах после заполнения ИНН), так как первое — избыточно, а последнее — потребует техподдержки в дальнейшем.
После этого передаём проектную документацию дизайнеру и программисту. От первого получаем пару-тройку позитивных правок плюс что-то всплывёт при адаптации формы под разные вьюпорты. От последнего — набор технических ограничений в связи с определившимся стеком технологий и просьбу использовать какой-нибудь конкретный фреймворк для вёрстки (бутстрап, например). На основе этой обратной связи актуализируем проектную документацию и корректируем дизайн.
— Персоны пользователей — не нужны, т.к. мы ещё перед началом проектирования точно знаем, кто будет пользоваться продуктом, как и в каких условиях;
— CJM — не нужна. Прототип будет состоять из пяти-шести экранов, показывающих разные динамичные состояния формы. Плюс будет договор с выделенными и описанными динамическими участками. Сам по себе этот прототип и будет представлять собой самую наглядную CJM;
— Отчёт о UX-тестировании — не нужен. Прототип и дизайн будут готовы в течение недели (два дня на прототип, два дня на функциональуню спецификацию). Ещё за неделю форму закодят и сверстают. И после этого начнётся настоящее «UX-тестирование».
Разумеется, перед началом работ мы проверим, нет ли чего-нибудь похожего уже в готовом виде. Возможно даже найдём и посмотрим, нельзя ли чего-нибудь из него позаимствовать.
Для каждого проекта, за который я берусь, я подбираю набор методик, подходящий ему по смыслу. Поэтому в статье я и не описываю эту часть. Она совершенно не универсальна. У меня не раз бывали клиенты, которые уходили довольные после первых переговоров-знакомства. Когда я в ответ на их запрос просто скидывал ссылку на сервис или набор сервисов, которые уже завтра могут решить его задачу — и проектировать ничего не надо.
Часть артефактов, которые вы перечислили — они либо для студентов, которым пока что нужны такие вспомогательные опорные штуки из-за отсутствия опыта, либо адресованы от специалистов к специалистам. Дайте мне проработанную CJM по проекту — и мне она поможет быстро въехать в суть дела. Дайте такой артефакт клиенту — и он оказывается в ситуации, когда ему нужно согласовать что-то, в чём ему трудно разобраться. Поэтому своим клиентам я не показываю и не предлагаю чего-то более сложного и абстрактного, чем интерактивный прототип. А сбор данных по проекту устроен таким образом, что клиент считает, что просто болтает со мной, а не помогает описывать чьи-то портреты или фиксировать процессы.
Даже функциональные требования я уже сколько лет подряд стараюсь упрощать и упрощать — а всё равно сложный документ, всё равно не читают его до конца, подписывают, а затем создают новые функциональные требования на лету. И это нормально, так и должно быть.
Исчерпывающий ответ. Ваш подход к проектированию мне стал предельно понятен. Спасибо и удачи в проектах!
Пожалуйста. Хочу поделиться с вами двумя моментами, когда мой подход к проектированию сильно менялся.
Первый — примерно через пять лет после начала карьеры. Году в 2010. Я был на острие передовых методов проектирования и внедрял их в свои процессы. Тогда в России только-только набирали популярность персонажи, jtbd, cjm. Я работал с несколькими студиями. Частные клиенты только-только появлялись в моей жизни. Моими самыми частыми проектами в тот период были интернет-магазины. И я тогда сделал около 40 таких магазинов в течение нескольких лет, с каждым проектом продавая всё больше дополнительных артефактов. Это несколько затягивало этап проектирования, но перформанс в глазах клиента был замечательным. Много документации, много оснований для принятия решений.
Но в какой-то момент я сравнил два прототипа. Один из первого десятка, а второй из последнего. И разница между ними была ну максимум процентов в двадцать. Процесс поиска и покупки товара в интернете был достаточно универсальным для того, чтобы с совершенно разными персонажами и сценариями в итоге стремиться к одинаковой форме. Там я прочувствовал, сколько ненужной работы продаю за деньги, и мне стало стыдно. После этого я вынес все эти дополнительные артефакты за скобки. И если мне нужно было воспользоваться одним из них для себя в каком-то особом случае, клиент об этом даже не догадывался.
Второй — когда я в течение пяти лет поднял собственный проект. Там-то круг и замкнулся. Во-первых, я убедился на практике, насколько хорошо работают мои подходы к работе (и окончательно распрощался с синдромом самозванца). А, во-вторых, увидел, насколько важны те вещи, которые мне раньше казались неважными. Как важно описывать всё в функциональной спецификации. Как важно иметь эталонный дизайн. Как важно учитывать стек технологий, если он нам известен на этапе проектирования. Проектировщику, который ни разу не запускал собственного проекта (или который ни разу не работал внутри команды, поднимающей проект), сложно получить эти знания. А я много лет проработал именно таким проектировщиком: проектировал информационные системы и махал клиенту ручкой. А ведь настоящая работа начинается где-то после релиза.
Я продуктовый дизайнер. Возможно вы не работали в большом продукте. На маленьких задачках UX исследования не так нужны, спорить не буду. Представьте если это большой сервис и вы хотите уменьшить время обработки заявок (например). Чтобы приложение начало больше зарабатывать денег. Что вы будете делать? Как вы найдете проблему? Основываясь на своём опыте, он может быть искажен и это не есть хорошо. Нужно идти к пользователям и проводить UX исследования.
а почему именно axure? разве теперь не все поголовно в фигме?
Спасибо, статья интересная. Сохраню в закладки.
Спасибо за статью!
Сфера у меня несколько другая, но несколько пунктов из Вашей статьи обязательно использую в своей работе.
Как я проектирую интерфейсы