Блог

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

И думаю, что лучше всего обо мне расскажут мои клиенты.

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

— Максим, за что вы платите мне деньги?

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

— А что вам нужно для этой оценки?

— Хватает твоих интерактивных прототипов. И мы, и финальный клиент, смотрим на набор перелинкованных экранов — и однозначно понимаем, что нужно получить на выходе (в отличие от абстрактной документации).

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

— А вам важно, в чём я делаю прототипы? А то многие говорят, что Axure уже устарела…

— Абсолютно по-барабану. Хоть Axure, хоть Фигма, хоть Protopie. Главное, чтобы это был интерактивный перелинкованный прототип, который показывает всю основную логику работы проекта.

— А как вам мои функциональные спецификации?

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

— Что ещё хорошего обо мне скажешь?

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

— А плохого что-нибудь вспомнишь в сотрудничестве со мной?

— Да, смутила стопроцентная предоплата на первом проекте. Мы подумали: «Ничего себе, какой наглый, а вдруг что-то пойдёт не так?». А потом, когда поработал вместе, вроде, уже ничего не смущало.

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

Сегодня провожу аудит сайта, на котором продают курсы по ретуши с помощью нейросетей.

Это было весело: к интерфейсу всего пара-тройка замечаний. А вот к ответам на потенциальные вопросы посетителей… В общем, смотрите сами:

Как можно проводить аудит интерфейса, не зная его целей? Да никак. Даже если цели не озвучены, всё равно они будут как-то сформированы в голове у аудитора. Одному ему понятным образом.

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

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

Об этом рассказываю в новом ролике.

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

Вкратце опишу схему:

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

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

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

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

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

Приятного просмотра!

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

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

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

А по этой ссылке информация для тех, кто хотел бы купить аудит за деньги.

Короткий ответ: потому что когда заказчики по прототипу получают оценку у разработчиков, они понимают, что не потянут разработку по деньгам.

Речь идёт исключительно о новых проектах, а не доработках в существующие. Самый распространённый сценарий выглядит так. Человек придумывает идею для своего продукта и решает его разработать. Он ищет по знакомым контакты программиста. Находит и в двух словах объясняет ему задачу. Программист тыкает пальцем в небо и называет стоимость разработки. Допустим, два миллиона. И намекает, что оценка примерная и было бы неплохо посмотреть на техническое задание.

Кто пишет технические задания? Заказчики. Кто умеет писать технические задания? Проектировщики. Некоторые заказчики отказываются сами писать технические задания и приходят к проектировщикам. Некоторые приходят к нам в Проекторат. Мы объясняем, что наши технические задания называются «функциональными спецификациями» и что мы готовим эти документы сразу после создания интерактивного прототипа.

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

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

Клиент вздыхает и решает пока не делать проект. Проектная документация уходит в стол. Так за 300 000 рублей можно предотвратить потерю двух миллионов рублей и вернуться к этому вопросу позже, когда появятся деньги. Либо пересмотреть свой подход к проекту. Например, избавиться от 90% функций для того, чтобы создать mvp и проверить жизнеспособность бизнес-гипотезы. Но это уже совсем другая история.

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

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

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

Тултип, от английского tooltip. Это такая короткая всплывающая подсказка, появляющаяся при наведении курсора на элемент. Или при фокусировании на элементе с помощью клавиатуры. Или при длительном разглядывании элемента, если вы в шлеме виртуальной реальности с трекингом глаз.

Привет, меня зовут Егор Камелев. Я занимаюсь проектированием интерфейсов с 2006 года. Сегодня хочу поделиться чек-листом вопросов, связанных с проектированием тултипов.

Читать далее Тултипы (tooltips). Что это такое и как их проектировать

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

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

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

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

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

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

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

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

Взял интервью у Антона Григорьева о работе проектировщиком на фрилансе.