Видеообзор бета-версии Axure 10

28 января появилась бета-версия Axure 10. Она доступна всем пользователям 9 версии программы. Разработчики поработали над множеством улучшений, связанных с созданием всё более сложных динамических взаимодействий в интерактивных прототипах. Теперь создавать динамику стало ещё проще.

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

Программа стала работать быстрее, немного обновился интерфейс.

Дата релиза ещё не анонсирована, однако мы уже точно знаем, что Axure 10 будет доступна исключительно по подписке.

Ознакомиться более подробно с новыми функциями и мнением проектировщика Егор Камелева насчёт будущего программы можно в этом видео:

Видеообзор бета-версии Axure 9

Axure 9 beta наконец-то стала доступна для скачивания владельцами лицензионных восьмёрок. Хотя обещали нам это событие до конца лета. Ну да ладно, пять дней погоды не делают.

Первые впечатления смешанные, но пока что никаких выводов не делаем. Нужно сначала поработать в ней немного. Смотрим экспресс-обзор от Егора Камелева, где он освещает около 40% перечисленных разработчиками возможностей, которые он посчитал действительно важными.

Рабочие дни против календарных

Как-то раз мне задали вопрос, почему в коммерческих предложениях (КП) я называю сроки выполнения работ в календарных, а не рабочих днях. Сейчас как раз подходящее время для ответа. Представьте себе: ко мне пришёл клиент 20 декабря. И получает КП, в котором сказано, что окончательный результат, удовлетворяющий всем функциональным требованиям, он увидит через 27 рабочих дней после начала работ. Допустим, мы планируем начать и начинаем 23 декабря. Вопрос: когда он получит этот результат? Ответы можете оставить в комментариях.
 
А пока вы, открыв календарь, считаете даты с учётом выходных и праздничных дней, вы можете прочувствовать на себе то, что будет чувствовать клиент, получивший такое КП.
 
Так как то, что я заявляю, является личным опытом, основанным на определённых жизненных обстоятельствах, также предлагаю поискать примеры ситуаций, когда клиенту действительно будет важно знать, сколько дней я работал в течение названного календарного срока. Потому что у моих заказчиков таких ситуаций не возникало. Всем поголовно на этапе КП было важно две цифры: когда они получат результат и сколько этот результат стоит.
 
Напоминаю, что в КП Проектората финальная дата — это дата релиза, удовлетворяющего всем обозначенным перед началом работ функциональным требованиям. В количестве комментариев после этой даты клиент не ограничен. А значит и сроки могут растянуться на любое время. Но т.к. процесс проектирования выстроен таким образом, что мы вместе с клиентом короткими итерациями движемся к одной цели, то в 6 проектах из 10 финальная дата из КП совпадает с реальным завершением работ, в 2 проектах этап комментариев занимает ещё до плюс 30% затраченного времени, а в оставшихся 2 работа принимается до финальной даты. По статистике за 2016-2017 гг.
 
Спасибо за внимание. Приятно видеть, что многие вещи, которыми я делился в течение этого года, коллеги внедряют в свои процессы.

Когда не хватает времени на новые входящие проекты

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

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

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

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

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

Проект на 100 часов, каждый час из которого будет стоить на 10% дороже старого ценника, принесёт вам 10 часов профита. Стоимость этих 10 часов и будет равняться стоимости тех пары «бесплатных» часов, которые вы потратите на общение и первичную оценку клиента. То же касается и делегирования излишков проектов. А если цена возрастёт не на 10%, а на 100%?

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

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

Задатки к проектированию

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

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

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

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

Мысли вслух, сужу по себе, на экспертность не претендую, ваш Егор Камелев.

Каким проектом вы гордитесь?

Если вы проектировщик или дизайнер и вам нечего ответить на вопрос «Каким проектом вы гордитесь?», то не нужно этого стыдиться.

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

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

Ответ «Я горжусь не конкретными проектами, а тем, что любую работу сдаю в срок и в том качестве, которое делает клиента довольным» удовлетворит любого здравомыслящего работодателя.

Коллеги бранятся — только тешатся

Много лет назад я работал проектировщиком в компании Вебмастер.спб. Однажды мы проводили переговоры с клиентом, где я собирал технические требования к проекту. В переговорах участвовал сам заказчик в лице генерального директора, Андрей Рябых (генеральный директор компании Вебмастер.спб), ну и ваш покорный слуга. В процессе переговоров мы с заказчиком нашли общий язык, а Андрей периодически вворачивал мысль, которая противоречила нашему с клиентом видению ситуации. Я пару раз поправлял Андрея и мы двигались дальше.

После переговоров, на пути в офис, Андрей сказал мне примерно следующее: «Я могу быть неправ в своих мыслях, но в будущем воздержись от того, чтобы поправлять человека из твоей команды (если, конечно, речь идёт не о фактологических ошибках). Для клиента мы должны представлять собой единый дружный организм, не противоречащий сам себе». Я замечание услышал и в дальнейшей работе, если моё мнение расходилось со мнением шефа, держал рот на замке во время переговоров. Зато после переговоров мог говорить что угодно.

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

В итоге продуктивные переговоры так и закончились на тех первоначальных двадцати минутах, хотя продлились чуть дольше часа. Эта история повторилась ещё пару раз, после чего программиста больше не допускали к нашим переговорам.

«Ну и что такого?» — спросите вы. А то, что из-за такой мелочи могла остановиться вся работа. Я прямо сказал собственнику, что мне не хотелось бы участвовать в дальнейшем в подобных переговорах. Если бы мы не были знакомы лично, это поставило бы под угрозу наши отношения. И не забудем, что в этой истории я был исполнителем. А представляете, что чувствует заказчик, вкладывая несколько сотен килорублей в работу команды специалистов и видя, как они не могут прийти к согласию?

Выводы:

— Участвуя в переговорах в составе собственной команды, не перечьте друг другу в рамках субъективных решений;

— Сначала приходите к согласию внутри команды, и только потом транслируйте решение клиенту, чтобы получить обратную связь;

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

Ценообразование и процесс работы над адаптивными прототипами в Проекторате

Во-первых, мы не закладываем стоимость адаптивного прототипа в первоначальную оценку. То есть, сначала делаем прототип под определённое разрешение (какое именно — зависит от преобладающей аудитории (или потенциальной аудитории) тех или иных устройств). Сейчас это разрешение чаще всего — 1024 или 1200 пикселей по ширине. Метод mobile first использовался нами лишь однажды. Когда речь идёт о сложных проектах, стоимость прототипа может измениться в процессе работы, т.к. на лету появляются новые функциональные требования, поэтому неразумно включать в этот этап и оценку адаптивки.

Во-вторых, стоимость адаптивного прототипа будет зависеть от сложности интерфейсов. И речь идёт не о количестве страниц, а об их функциональной насыщенности. От 10% от стоимости проекта до 30%. За каждое дополнительное разрешение.

В-третьих, цена будет зависеть от количества брейкпойнтов, то есть от количества разных внешних видов для разных разрешений. Сейчас чаще всего они таковы: 320 (телефон в портретной ориентации), 480 (телефон в горизонтальной ориентации), 768 (планшет в портретной ориентации), ну а планшеты в горизонтальной ориентации уже входят в первоначальный прототип.

Итого, прототипирование адаптивки составит дополнительные 10—90% от стоимости первоначального прототипа.

Откуда берутся эти проценты?

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

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

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

По срокам: мы берём за основу процентную стоимость работы над адаптивкой и превращаем её в процентные сроки. То есть, от 10% до 90% от времени работы над основной версией будут затрачены на адаптивный прототип.

О переговорах и переписках

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

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

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

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

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

Я: Настя, с тех пор, как вы написали мне первое сообщение, я так и не понял, представляете ли вы официально Epic Skills или являетесь их студентом.
Настя: Все, кто работает в Эпике — это бывшие студенты какого-либо курса) Я училась на курсе веб-дизайна

То есть, мне стоило спросить: «Настя, вы сотрудник Эпика?» Потому что ответа на свой вопрос я так и не получил. А человек старался, отвечал.

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

Тут правильно было бы написать «Я подумаю и сообщу о своём решении позже». Моя формулировка оказалась слишком сложной для понимания.

А вот примеры вопросов, на которые ответить было бы возможно, только задав встречные вопросы:

«Ребята подскажите пожалуйста — ненашла нигде инфы. В инлайн фрейм вставила паралакс а вот как прокрутку сделать в рамках этого фрейма — чет не разбирусь. Спасибо»
Параллакс — это эффект, а не объект, который можно вставить в инлайн-фрейм. Что имела в виду автор — загадка.

«Друзья! Кто знает, можно ли в акшуре сделать работающий поиск с отображением быстрых результатов в виде дропдауна?»
Вероятно, имелась в виду эмуляция автоподстановки быстрых результатов при вводе поискового запроса в текстовом поле. А не создание работающего поиска.

«Друзья, я к вам за помощью. Столкнулся с острой потребностью потестировать прототип, сделанный в Axure. Помогите избрать самый лучший способ. Есть ли в самом Axure инструмент тестирования?»
Любой тест чего угодно проводится с какой-то целью. Можно протестировать медную ложку. Тест на содержание в ложке меди будет отличаться от теста на плавучесть ложки.

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

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

Чтобы качественно оказать услугу своему клиенту, нужно хоть раз оказаться на его месте

Пара слов о сервисе. Мы, покупая или используя бесплатно те или иные товары и услуги, сталкиваемся с определёнными неудобствами, которые нам хотелось бы исправить. Девушкам иногда сложно открыть крепко закрученную бутылку воды, мы ненавидим очереди, мы пачкаем одежду о пороги большинства автомобилей, нам не нравится, что в банках мы сначала ставим подпись о получении денег, а затем уже получаем деньги. Со временем эти неудобства превращаются в прекрасные маркетинговые ходы со стороны провайдеров. «Мы сделали легкооткручиваемую крышку». «Мы ввели электронные очереди и два дополнительных окна». И так далее.
У покупателей услуг проектирования есть свой список неудобств, с которыми они сталкиваются, заказывая эту услугу. И среди читающих этот текст список смогут назвать в основном те, кто выступал в роли таких покупателей. А проектировщикам многие пункты неведомы по естественным причинам. Чтобы с ними столкнуться, нужно взять свой проект (даже самый маленький подойдёт: лэндинг, портфолио или бложик) и обратиться к профессионалам за проектированием и дизайном.
Можем попробовать перечислить некоторые из таких неудобств в глазах клиента.
— Исполнитель просит заполнить типовой бриф до начала неведомой работы или прислать ТЗ;
— Исполнитель запрашивает информацию, относящуюся к коммерческой тайне;
— Исполнитель сразу спрашивает, какой у вас бюджет на проектирование;
— Непонятно, что получится в результате, а также какой простор для комментариев будет в процессе;
— Исполнитель очень хорошо аргументирует все свои решения, но они вам не нравятся. Однако ваше мнение за экспертное не считают и переходят в поле «ладно, мы сделаем, как вы сказали, но и ответственность за это решение мы с себя снимаем».

Secured By miniOrange