А я, как обычно, сделал краткий обзор её новых функций и возможностей.

Если кратко: маловато нововведений для того, чтобы присваивать ей новый номер.

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

Под катом мой видеообзор и текстовый перечень основных нововведений.

В Axure, программе для проектирования интерфейсов, есть неочевидная функция, которая позволяет встроить в прототип почти любой код. При этом не покидая интерфейса самой Axure.

Чаще всего я использую её, если нужно встроить в прототип какой-нибудь iframe. Например, Яндекс.карту. Или видео с Ютуба.

Заметил такую возможность ещё в пятой версии программы, в 2010 году. И она до сих пор с нами в десятой версии, спустя 14 лет.

Сейчас объясню, как это работает, и покажу пример.

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

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

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

Почти что прототип для пользовательского тестирования, только в этот раз для демонстрации идеи и усиления коммерческого предложения.

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

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

В фрилансерских кругах есть любители поржать на эту тему. Я тоже когда-то таким был. До тех пор, пока не осознал две вещи.

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

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

Как уменьшить количество «дичи» от клиента, да ещё и повысить его удовлетворённость от процесса работы и результата?

Я здесь пишу с позиции проектировщика интерфейсов (UX-дизайнера) на фрилансе, но подход в целом довольно универсальный.

Есть такая игра — Diablo. В её третью часть я похоронил много часов своей жизни. Ни о чём не жалею, было весело. Кстати, раз уж об этом зашла речь: когда я раньше в неё заигрывался, то иногда думал, что это что-то плохое — вот так сливать время в компьютерные игры. А сейчас, когда по каким-то необъяснимым физиологическим причинам с каждым годом получаю от них всё меньше радости, с тёплой ностальгией вспоминаю старые добрые тысячи игровых часов, полных веселья и удовольствия. И ни о чём не жалею.

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

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

Как-то раз мне предложили написать статью «Пять главных советов для фрилансера». Но тема мне не понравилась. Главный совет может быть только один. Ведь если все пять главные, то какой из них будет главнее?

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

И в итоге у меня появился такой список. Вверху — главный совет. Каждый следующий основан на предыдущем.

Поделюсь своим опытом. Сразу оговорюсь, что я UX-дизайнер в чистом виде. То есть, со шрифтами не играюсь, цвета не подбираю, картинки не рисую. Делаю интерактивные прототипы в Axure (да-да, даже в 2024 году) и пишу функциональные спецификации.

Уйдя на вольные хлеба в 2008 году, я назначил стоимость своего часа для клиентов. 1 000 рублей. Это было больше, чем в среднем по рынку, но в целом со мной не отказывались работать, ибо я был неплохим специалистом и сарафанное радио отрабатывало очень хорошо. В портфолио уже тогда было около сотни прототипов, оставшихся в наследство от работы в агентстве и до него. Особенно моими услугами интересовались студии. С почасовой оплатой всё было прозрачно и красиво.

Проблема всплыла через десяток проектов.

Этот заголовок я взял из видеоролика американского предпринимателя Алекса Хормози, который в свои ранние тридцать перевалил за сотню миллионов заработанных долларов и теперь рассказывает, как именно он этого добился, и раздаёт бесплатные советы.

Поначалу я скептически относился к материалам Алекса, т.к. от них отдавало инфоцыганщиной, но с каждым новым выступлением (а у этого парня трудно найти что-то короче 20 минут) проникался всё большим доверием к его словам. Эту статью пишу на основе его 24-минутного видеоролика под заголовком: «I'm Broke, What Business Do I Start?» (я вставил его внутрь статьи).

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

И, если верить Алексу, та схема, которую он предлагает, буквально гарантирует мне пять первых клиентов в результате её применения. Что ж, проверим!

Итак, поехали.

В начале карьеры проектирование любой формы казалось мне очень простой и понятной задачей. Особенно когда речь шла о чём-то банальном и незначительном, вроде обратной связи на сайте. А что — выяснил, какие нужны данные и для чего, накидал поля с подписями, приделал кнопку — и готово! На всё про всё — пять минут. Пустяки! Или нет?

Привет, я Егор Камелев, проектировщик интерфейсов (UX-дизайнер). За последние 20 лет я поработал с командами десятков агентств, IT-отделов, действующих проектов и продуктов, стартапов (и запущенных, и незавершённых). Я знаком с сотней команд, не меньше. И среди них не нашлось и двух, использующих одинаковые подходы к работе. Верно говорят: «У каждого додика — своя методика!».

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

Поэтому в этой статье я не буду заявлять, что мой подход к работе — единственно верный. Он один из тысяч и в моём случае прекрасно работает: клиенты не заваливают меня правками, платят 100% предоплату и рекомендуют окружающим. Я распишу во всех деталях свой процесс предоставления услуги проектирования (создания интерактивного прототипа информационной системы на заказ). Уверен, что многим пригодятся мои знания. Погнали!

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

В начале карьеры UX-дизайнера я просто делал интерактивные прототипы, а документацию предпочитал не писать. Почему так:

Во-первых, сложно. Этому навыку никто не обучал, а написать 100 и более страниц текста по проекту — это как диссертацию накатать. Поэтому я говорил клиентам, что, мол, и так справитесь.

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

Продавать это было легко. Достаточно было рассказать о том, как я, заплатив несколько десятков тысяч за документ, экономил несколько сотен тысяч на разработке. И подкрепить рассказ конкретными цифрами и примерами. Чаще всего я рассказываю о том, как пожалел 50к на функциональную спецификацию на участок собственного проекта, и разработчики делали его два с половиной месяца вместо привычного одного. А месяц их работы обходился моей казне почти в 300к рублей. И если бы я не сэкономил на функциональной спецификации, то задача обошлась бы на 400к рублей дешевле.

Или бывало ещё так.

— Супер, нам всё нравится, давайте в ближайшие дни закрывать работу и решать вопрос с остатком оплаты.

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

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

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

Что это за вещи?

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

Каждое такое действие было направлено на то, чтобы у человека как бы возник «моральный кредит» передо мной. Чтобы в тот момент, когда дело дойдёт до принятия решения, у него не было даже и мысли отказаться от моих услуг. Но есть тонкая грань между двумя состояниями, в которых может в итоге оказаться человек:

• Мне теперь неудобно отказываться от работы с этим исполнителем :(

• Я так благодарен ему, что теперь тоже хочу ему чем-нибудь помочь! :)

Чувствуете разницу? А кто-то не чувствует.

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

Я прочувствовал на практике, сколько теряю из-за этого времени и тут же внёс несколько изменений.

В конце этого лета прогуливался с товарищем по набережной Невы, болтали о том, о сём. И внезапно он заявил:

— Сейчас, работая в новой роли, нахожу много полезной информации, которая делает меня лучше как специалиста. И вот почему я не столкнулся с этим лет двадцать назад?

«Новая роль» — это что-то вроде тим-лида. То есть, он теперь работает в том числе и над развитием команды. Я поделился с ним своими мыслями по этому поводу и начал со слов: «Это совершенно неудивительно. И нормально, что раньше ты не искал подобной информации». Вот моя история.

Я рос вместе с рынком. Когда меня взяли проектировщиком в компанию Webmaster.SPB, эта профессия в моём регионе была ещё очень молодой, не старше двух-трёх лет. Я писал технические задания на разработку сайтов и никто меня этому специально не обучал. Начальник отдела занимался своими проектами, я своими. Мне было интересно развиваться, и я постоянно смотрел по сторонам в поисках чего-то нового и полезного. Так, через пару лет работы, я притащил в компанию инструмент по проектированию интерфейсов Axure, и мы одними из первых начали делать интерактивные прототипы.

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

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

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

На переговорах с клиентами я уже автоматически использую такие формулировки, которые предполагают, что ответственность за те или иные события лежит на мне:

Не говорю: «Возможно, вы меня неправильно поняли».
Говорю: «Возможно, я неправильно донёс свою мысль».

Не говорю: «Вы не заметили ссылку на прототип, которую я отправлял в переписке».
Говорю: «Я, видимо, не достаточно привлёк вашего внимания к важной ссылке в нашей переписке».

Не говорю: «В следующий раз постарайтесь не опаздывать на встречу».
Говорю: «В следующий раз постараюсь дополнительно предупредить вас о встрече за пару часов до её начала».

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

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

Этот другой снова задаёт те же вопросы — и ты уже общаешься с ним раздражённый и разочарованный.

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

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

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

Часто ли дизайнеры или проектировщики получают обратную связь от тех, кто дальше работает с документацией и макетами? Вопрос открытый. Когда я сам сдаю работу, то не ленюсь и через клиента спрашиваю, что думают разрабы о моих макетах и документации. Ответ обычно такой: «Мы не знаем. Раньше не сталкивались с такой подробной постановкой задачи. Если вопросы и возникали, то решали их сами».

Получается, что проектировщики и дизайнеры готовят задачу для разработчиков, но обычно не интересуются, насколько последним было удобно работать с макетами и документацией. А разработчики не могут адресовать вопросы по проекту дизайнерам и проектировщикам, потому что… Если честно, не понимаю, почему. Но ко мне за 300+ проектов вопросы от разработчиков прилетали всего два раза.

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

Главная страница сайта — это вишенка на торте. Я буду точно знать, из чего она состоит и как работает после того, как будут спроектированы все остальные разделы.