Лучшие статьи и кейсы стартапов
Включить уведомления
Дадим сигнал, когда появится
что-то суперстоящее.
Спасибо, не надо
Вопросы Проекты Вакансии
Проектирование интерфейсов
Рекомендуем
Продвинуть свой проект
Лучшие проекты за неделю
34
Эбиа

Эбиа

www.ebia.ru

21
YAGLA

YAGLA

yagla.ru

20
2.0

2.0

twozero.ru

17
Venyoo

Venyoo

venyoo.ru

15
Enlite

Enlite

enlited.ru

14
E-Commerce and Venture projects

E-Commerce and Venture projects

Продажа товаров от производителей оптом и в розницу

14
Extrimtour

Extrimtour

extrimtour.com

14
likearea

likearea

smm.li

13
SE Ranking

SE Ranking

seranking.ru

Показать следующие
Рейтинг проектов
Подписывайтесь на Спарк во ВКонтакте

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

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

protomanager.png

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

+1
Первые Новые Популярные
Pragmatika
Продуманные и понятные сайты для продажи товаров и услуг в интернете.
Николай Яковенко
Верно сказано. В равной степени относится к дизайнерам и редакторам. Проектировщик, дизайнер и редактор — пример сервисных профессий, где результат работы зависит от качества коммуникации с клиентом.

Формула результата сервисной услуги: знание - содержание - структура - форма. Получил знание об целях, задачах, аудитории, ограничениях. Сформировал содержание, которое решает задачу по отношению к проекту и аудитории. Спроектировал пути использования содержания. Облёк их в форму. В идеале, проверил боем.
Ответить
Проекторат
Проектирование интерфейсов
Егор Камелев
Совершенно верно.
Ответить
Автоматизация бизнеса.
Разработка ПО на платформе 1С:Предприятие
Нагибович Константин
Забрал в избранное. Спасибо за полезный материал.
Ответить
Проекторат
Проектирование интерфейсов
Выбрать файл
Читайте далее
Загружаем…
Блог проекта
Расскажите историю о создании или развитии проекта, поиске команды, проблемах и решениях
Написать
Личный блог
Продвигайте свои услуги или личный бренд через интересные кейсы и статьи
Написать