По одежке встречают, по уму провожают. Первичные переговоры на фрилансе

Сейчас я расскажу об очень важной вещи: целеполагании. Когда я только начинал работать на фрилансе, я странно вёл себя на первичных переговорах с заказчиками. Я держал в голове мысль: «Мне нужно заполучить этого клиента и заработать максимально возможное количество денег в рамках работы с ним». И я искренне считал, что это и являлось целью первичных переговоров. Как же я ошибался! Читать далее По одежке встречают, по уму провожают. Первичные переговоры на фрилансе

Точность — вежливость королей и долг всех добрых людей

Я повторял, повторяю и буду повторять ещё неоднократно в будущем: называйте сроки с точностью до часа! Ещё раз: называйте сроки с точностью до часа.

Теперь проиллюстрирую на живом примере. Представьте себе: вы клиент, который заказывает что-то у специалиста. На самом деле это не так просто представить, особенно если речь идёт о рынке IT. Не самые бедные люди решают вкладывать свои кровные 10-20-50-100 тысяч рублей в проектирование-дизайн-вёрстку-программирование. С высокой вероятностью эти люди зарабатывают больше, чем исполнители подобных заказов. Хотя, знаете что? Так ли это важно? Мне кажется, уважения достойны часы любого человека на этой планете.

Вы внесли предоплату и вам назвали срок в такой форме: «К следующей пятнице будет готово». Что это означает? Что готово будет в любой момент от сегодняшнего дня до 23:59 четверга. Вы находитесь в состоянии неопределённости все эти дни. Это может быть не так важно, но где-то в подсознании у вас назойливо будет работать программа: «Мне могут в любой момент показать результат». Эта программа создаёт дискомфорт.

Или вам сказали: «Результат будет в следующую среду». Это означает, что в среду с 00:00 до 23:59 вы получите результат. 24 часа! А если этот результат требует демонстрации на переговорах, даже коротких, вы понимаете, что они могут произойти в любой момент в этом диапазоне времени. Вы не можете их запланировать, поставить в свой стройный календарь, не можете подготовиться к этому событию. Это тоже создаёт дискомфорт.

Если вы клиент и вам назвали сроки таким образом, вы для себя решите так: «Результат будет в среду? Ну, ок. Значит, среда под вопросом, буду ориентироваться на четверг. Переговоры придётся самому назначать. Зато этот исполнитель явно с пониманием отнесётся к постоплате в четверг, после завершения банковского дня».

А теперь из шкуры клиента перенесёмся в шкуру исполнителя и подведём итоги:

— Называйте срок сдачи работы с точностью до часа. В формате: 23 февраля, в 14:00;

— Говорите, что произойдёт в момент сдачи. Например: «23 февраля, в 14:00, на ваш email я пришлю закрывающий акт». Или «23 февраля, в 14:00 предлагаю провести переговоры с презентацией результата моей работы. Либо назовите любое удобное для вас время».

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

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

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

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

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

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

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

Выводы:

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

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

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

Об иконках

Иконки экономят место и выглядят свежо. Иконки — это быстрый ответ на сложные вопросы:

  • Как сделать красивее?
  • Как нам это забрендировать?
  • Как сделать веселее?

Мы любим иконки. Пока не начинаем в них путаться.

Иконки бывают разные: на продуктах, в архитектуре, в компьютерах, в списках, на кнопках, для веба и приложений, для iOS и Android. Иконки на панелях инструментов, подписанные и неподписанные, стилизованные и стандартизованные, цветные и монохромные, в иконочных шрифтах, файлах PNG или SVG…

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

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

Читать далее Об иконках

Скидка на Sketch

Update от 13 февраля 2017: способ больше не работает.

Предыстория

Я собрался купить Sketch. На странице оформления заказа увидел поле для ввода промокода и решил проинвестировать немного времени в поиск скидки. При сегодняшнем курсе доллара даже 20-процентная скидка — это больше 2000 рублей. Хватит хорошенько сходить в бар или купить в «Проекторате» курс про адаптивные прототипы (и ещё останется).

Проектировщикам на заметку: уберите акцент с поля для ввода промокода, например, спрятав его под ссылкой «Указать промокод», чтобы не подталкивать покупателя к поиску купона на скидку.

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

Читать далее Скидка на Sketch

Что такое шнафтели и с чем их едят?

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

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

Рассказ о том, что нервные клетки не восстанавливаются, — шнафтель. Дефибриллятором можно запустить остановившееся сердце? Шнафтель! Мобильный телефон зарядится в микроволновке? Шнафтель, да ещё какой! Кипрского Деда Мороза зовут Василий? Шнафтель!

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

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

Чем отличаются модальные окна от pop-up’ов

Давайте немного разъясним про модальные окна и pop-up’ы.
 
1. Модальное окно — это окно, которое блокирует работу пользователя с родительским приложением до тех пор, пока это окно не закроют. К этой категории относятся современные лайтбоксы (например, просмотр фоток в фб или вк) и древние модальные окна, вызываемые командами alert, prompt и confirm, которые мы чаще всего называем алертами. Проблема алертов в том, что они перекрывают возможность работы не только с текущей вкладкой, но и со всем браузером до тех пор, пока их не закроешь.
 
2. Pop-up — всплывающее окно. Раньше, когда вкладок в браузерах не было, некоторые страницы открывались в новых окнах. Чаще всего этим злоупотребляли создатели баннеров. Кликнешь по какому-нибудь элементу и у тебя весь рабочий стол в окнах разного размера. А ещё были злостные варианты открытия pop-up’а за границей экрана, чтобы усложнить задачу по его поиску и закрытию. Соответственно, такие окна делились на pop-up’ы, которые появлялись поверх других окон и pop-under’ы, которые, соответственно открывались под другими окнами. Сейчас с pop-up’ами борются сами браузеры и мы их встречаем всё меньше.
 
Пока писал, прям испытал ностальгические чувства.

О неумении называть сроки

Одна из бед представителей IT-профессий — неумение называть сроки. Если вы в своей работе используете выражения «Сегодня к вечеру будет готово», «Покажу в среду», «К утру скину результат», то срочно избавляйтесь от этой привычки.

Строго: время и ожидаемый результат. «В 14:00 опубликую новую версию прототипа», «макеты будут на вашей почте в 17:45, в среду», «в полдень я свяжусь с вами для уточняющих вопросов».

Тогда и люди, с которыми вы работаете, глядя на вас, не будут позволять себе оплатить ваши счета «в конце недели» или озвучить комментарии «в течение рабочего дня».

Почему опытные проектировщики превращаются в хороших менеджеров

protomanager

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

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

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

2. «Схожесть системы с реальным миром. Система должна общаться с пользователем на понятном ему языке. Использование слов, фраз и понятий, знакомых пользователю в реальном мире, намного предпочтительнее, чем использование специализированных терминов».
В процессе работы я редко использую термины «UX», «cjm», «источники трафика», «интерактивность». Разве что при работе с теми людьми, которые живут и работают в IT. Вместо этого я говорю «удобство использования», «то, как люди будут пользоваться проектом», «как посетители попадут на ваш проект» и «как будут двигаться блоки на страницах». Я стараюсь избегать абстракций и любое обсуждение провожу в рамках разговора о конкретном пользователе конкретной части интерфейса продукта.

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

4. «Единообразие и стандарты. Не путайте пользователя, описывая одни и те же вещи разными словами и терминами. Придерживайтесь единообразия и следуйте стандартам».
В процессе работы я использую ту же терминологию, что и на первых переговорах. Все переговоры проходят в одном формате (Скайп с демонстрацией экрана).

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

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

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

8. «Эстетичный и минималистичный дизайн. Тексты не должны содержать бесполезной или устаревшей информации. Каждое лишнее слово делает восприятие все более трудным и лишает посетителя возможности найти то, за чем он пришел на сайт».
Этот пункт — упрощать всё и вся — проходит красной нитью сквозь всю мою работу. Функциональные требования и функциональные спецификации из огромных монстров превращаются в небольших понятных зверьков. Личные переписки становятся всё лаконичнее и предметнее. И, главное, — переговоры. Много лет назад я предлагал клиентам заполнять трёхстраничные брифы. Теперь же ту же информацию я получаю в течение получаса во время непринуждённой личной беседы. Причём, за эти полчаса я успеваю ещё узнать те вещи, о которых ни в одном брифе спросить невозможно.

9. «Понимание проблем и их решение. Сообщения об ошибках должны быть выражены на понятном пользователю языке, как можно более точно описывать проблему и предоставлять возможные варианты ее решения».
В работе встречается много мест, где необходимо принимать совместные решения. В этом случае я со своей стороны описываю все потенциальные последствия обоих решений, которые вижу, а клиент описывает своё видение. Мы принимаем во внимание все эти данные и склоняемся к варианту, который устраивает обоих. Здесь следовало бы многое рассказать о принципах работы «по одну сторону баррикад», но об этом ждите рассказа в одной из следующих статей Проектората.

10. «Справочные материалы и документация. Даже если система может использоваться без документации, в процессе работы с ней все же может потребоваться справочная информация. Подобные документы должны составляться таким образом, чтобы в них легко было найти необходимое».
Этот пункт даётся мне сложнее всего. На сегодняшний день существует небольшое количество статей, на которые я мог бы дать ссылки клиентам. Пример такой статьи: «Как в Проекторате оценивается адаптивное проектирование».

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

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

Автор — Егор Камелев, собственник Проектората.

Список эвристик взят с Прожектора Rokee.

О количестве итераций с правками на этапе проектирования

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

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

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

Чтобы эта заметка не казалась оторванной от реальности, обратим внимание на две важные вещи:

1. Речь идёт о попроектной оценке, а не о почасовой;
2. Это правило сработает только с прямыми клиентами. На субподряде между проектировщиком и клиентом может оказаться менеджер, который не будет заинтересован в результате так же, как клиент. Когда мы работали с компаниями-партнёрами, зачастую у нас вообще не было прямого доступа к клиенту. В таких условиях, разумеется, нельзя работать по принципу бесконечных итераций, потому что они и правда могут стать бесконечными.