Блог

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

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

Семь советов проектировщику на фрилансе

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

— Чтобы повысить качество своей услуги, отстроиться от конкурентов и увеличить поток входящих заказов, стоит однажды самому оказаться на месте заказчика и посмотреть его глазами на то безобразие, которое творится на нашем рынке. Попробуйте заказать себе корпоративный сайт или блог и прочувствовать на себе мысль: «А зачем мне проектировщик? Здесь и так всё понятно!»;

— Не надо сравнивать себя с профессионалами, работающими в Яндексах, Контактах, Авито и прочих гигантах. Также не надо сравнивать себя с основателями и руководителями студий. К ним никогда не придут те клиенты, с которыми вы работаете на фрилансе. У вас своя доля рынка, у неё свои потребности. Большие люди, перечисленные выше, эти потребности удовлетворять не будут. Хотите быть программистом за 500 000 в месяц в команде Контакта? Вперёд на должность помощника левой руки джуниора и стройте карьеру. Хотите зарабатывать столько же на фрилансе? Начинайте работать над персональным брендом и сервисом;

— Ваша оперативность, фиксированное ценообразование и дисциплинированность ценятся значительно выше сотен проектов в портфолио и опыта работы с государством и крупняками. Хорошие специалисты видны издалека даже в начале своего пути;

— В проектировании на фрилансе сервис и прозрачное ценообразование приносит больше прибыли, чем качество интерфейсов (которое само по себе субъективно на этом этапе);

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

— Упакуйте свою услугу таким образом, чтобы она была понятна вашей целевой аудитории. «UX-проектирование» и «Юзабилити аудита» — это настолько абстрактные процессы, что даже наши коллеги по-разному представляют себе их результаты. Продавайте более понятные и конкретные «Прототипы мобильных приложений» или «Рекомендации по исправлению ошибок на сайтах»;

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

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

Одна из бед представителей 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. Это правило сработает только с прямыми клиентами. На субподряде между проектировщиком и клиентом может оказаться менеджер, который не будет заинтересован в результате так же, как клиент. Когда мы работали с компаниями-партнёрами, зачастую у нас вообще не было прямого доступа к клиенту. В таких условиях, разумеется, нельзя работать по принципу бесконечных итераций, потому что они и правда могут стать бесконечными.

Распродажа электронных книг для проектировщиков

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

Они-то думают, что раздают ненужные старые книги по программированию. Но для проектировщиков это возможность положить в свою электронную библиотеку всё ещё актуальную классику вроде «Об интерфейсе» Купера или «Как сделать сайт удобным» Круга (за которую на литресе просят 250 рублей) и при этом не разориться.

Опытные проектировщики и наши постоянные читатели знают, кого качать. Для всех остальных — контрольный список: Алан Купер, Билл Скотт и Тереза Нейл, Джесс Гарретт, Джеф Раскин, Джоэл Спольски, Дмитрий Кирсанов, Расс Унгер и Кэролайн Чендлер, Стив Круг, Якоб Нильсен.

Что нужно изучить, чтобы стать проектировщиком интерфейсов?

Два популярных вопроса покупателей наших курсов по прототипированию звучат так:

1. Насколько востребована профессия проектировщика? Насколько это перспективное направление?
2. Ваш курс был про использование инструментов. А что нужно пройти, чтобы научиться проектированию? UX-курсы?

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

Ответ на второй вопрос уже сложнее и отражает моё персональное мнение. Но я попробую обосновать свою позицию.

Сначала лирическое отступление номер один. Профессия эта сравнительно молодая и похожа на растущее ветвистое дерево, где каждая веточка отвечает за своё направление. Есть толстые ветки профессий вроде UX, UI, аналитиков, AB-тестировщиков, маркетологов и других. Есть такие же толстые ветки с тематиками: сайты, мобильные приложения, интерфейсы терминалов и прочие. Из толстых ветвей растут более тонкие веточки вроде «AB-тестировщик мобильных приложений на яблочной платформе» или «UI-дизайнер и верстальщик тем для вордпресса». Это дерево живое: оно находится в фазе быстрого роста. Каждый год появляются новые технологии, направления и методы работы. Точно так же какие-то из них исчезают, словно опадающие с дерева листья.

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

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

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

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

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

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

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

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

Программирование. Речь идёт об основах. Принципах объектно-ориентированного программирования, базовом синтаксисе, условных операторах, циклах, массивах и матрицах. Работе с базами данных. Понимании ключевых особенностей разных языков программирования.

SEO-оптимизация. Как проекты индексируются поисковыми системами, как происходит поисковая выдача, что такое мета-данные и прочие базовые штуки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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