Блог

О целях интерфейсов

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

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

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

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

Как я делаю аудиты интерфейсов

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

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

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

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

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

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

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

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

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

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

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

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

Почему каждый второй из наших прототипов для новых проектов уходит в стол, а не в продакшен?

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

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

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

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

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

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

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

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

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

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

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

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

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

Видеообзор бета-версии Axure 10

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

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

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

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

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

Видеообзор бета-версии Axure 9

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

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

Заработок на фрилансе: зачем повышать уровень сервиса?

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

Рабочие дни против календарных

Как-то раз мне задали вопрос, почему в коммерческих предложениях (КП) я называю сроки выполнения работ в календарных, а не рабочих днях. Сейчас как раз подходящее время для ответа. Представьте себе: ко мне пришёл клиент 20 декабря. И получает КП, в котором сказано, что окончательный результат, удовлетворяющий всем функциональным требованиям, он увидит через 27 рабочих дней после начала работ. Допустим, мы планируем начать и начинаем 23 декабря. Вопрос: когда он получит этот результат? Ответы можете оставить в комментариях.
 
А пока вы, открыв календарь, считаете даты с учётом выходных и праздничных дней, вы можете прочувствовать на себе то, что будет чувствовать клиент, получивший такое КП.
 
Так как то, что я заявляю, является личным опытом, основанным на определённых жизненных обстоятельствах, также предлагаю поискать примеры ситуаций, когда клиенту действительно будет важно знать, сколько дней я работал в течение названного календарного срока. Потому что у моих заказчиков таких ситуаций не возникало. Всем поголовно на этапе КП было важно две цифры: когда они получат результат и сколько этот результат стоит.
 
Напоминаю, что в КП Проектората финальная дата — это дата релиза, удовлетворяющего всем обозначенным перед началом работ функциональным требованиям. В количестве комментариев после этой даты клиент не ограничен. А значит и сроки могут растянуться на любое время. Но т.к. процесс проектирования выстроен таким образом, что мы вместе с клиентом короткими итерациями движемся к одной цели, то в 6 проектах из 10 финальная дата из КП совпадает с реальным завершением работ, в 2 проектах этап комментариев занимает ещё до плюс 30% затраченного времени, а в оставшихся 2 работа принимается до финальной даты. По статистике за 2016-2017 гг.
 
Спасибо за внимание. Приятно видеть, что многие вещи, которыми я делился в течение этого года, коллеги внедряют в свои процессы.

Когда не хватает времени на новые входящие проекты

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

Итак. Стоимость часа в рамках оказания услуги по прототипированию или дизайну значительно ниже стоимости часа в рамках привлечения нового клиента. Это контр-интуитивно, потому что привлечение клиента и оценка проекта делаются условно бесплатно.

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

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

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

Проект на 100 часов, каждый час из которого будет стоить на 10% дороже старого ценника, принесёт вам 10 часов профита. Стоимость этих 10 часов и будет равняться стоимости тех пары «бесплатных» часов, которые вы потратите на общение и первичную оценку клиента. То же касается и делегирования излишков проектов. А если цена возрастёт не на 10%, а на 100%?

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

И, как всегда: воспринимайте этот текст, как мои личные мысли, основанные на специфическом опыте. Надеюсь, они послужат вам пищей для размышлений. На экспертность не претендую. Ваш Егор Камелев.

Secured By miniOrange