Сегодня провожу аудит сайта, на котором продают курсы по ретуши с помощью нейросетей.
Это было весело: к интерфейсу всего пара-тройка замечаний. А вот к ответам на потенциальные вопросы посетителей… В общем, смотрите сами:
Рубрика: Без рубрики
О целях интерфейсов
Как можно проводить аудит интерфейса, не зная его целей? Да никак. Даже если цели не озвучены, всё равно они будут как-то сформированы в голове у аудитора. Одному ему понятным образом.
Фишка в том, что во многих случаях цели владельца интерфейса будут отличаться от целей пользователей. Да, когда речь идёт, например, о посадочных страницах, у всех одна цель — чтобы сделка совершилась. Ну или, на худой конец, целевое действие было совершено.
Сегодня же у меня на аудите интерфейс мобильного приложения производственного календаря. И цель его создателя (помимо прочего) — заработать на рекламе. А цель пользователей — … ну, их несколько. И чьи же цели учитывать аудитору и как?
Об этом рассказываю в новом ролике.
Как я делаю аудиты интерфейсов
Записал небольшой видеоролик с рассказом о том, как я провожу аудиты интерфейсов
Вкратце опишу схему:
— Аудит не может быть беспредметным. Предмет моих аудитов — это то, насколько эффективно интерфейс достигает поставленных перед ним целей. Поэтому первый шаг — выявить и озвучить эту самую цель (или несколько целей).
— Цели достигаются благодаря набору функций в интерфейсе. Например, если цель — продажа, а в интерфейсе нет функции оплаты заказа в рамках некой оферты — то она недостижима. И, возможно, ошибка крылась в терминологии. Например, истинная цель была не продажа, а формирование лида. Из цели можно вывести набор функциональных требований, на который и ориентироваться.
— Но даже если есть цель и все необходимые функции для её достижения, то проблема может крыться в информационных ожиданиях. Когда у пользователей интерфейса банально не хватает ответов на вопросы, которые хотелось бы получить перед принятием решения.
— И как ни парадоксально это звучит, самая маловажная составляющая моих аудитов — это как раз юзабилити, UX. Эргономика, доступность, эстетика, вот это всё. Точнее, не так. Она, конечно, важна. Но только после того, как решены предыдущие три вопроса.
В результате аудита я всегда выделяю какую-то одну рекомендацию, которая, по моему мнению, повлияет на результат больше всего. Можно перекрасить пятьдесят кнопок и расставить элементы в нужные места, а можно дать пользователю ответ на волнующий его вопрос. Например, есть ли доставка в его регион.
Приятного просмотра!
Прикол в том, что после каждого такого аудита, если в интерфейс были внесены изменения, можно сделать ещё один аудит и снова найти что-то новое.
Здесь можно взглянуть на документ, который получается в результате.
Тут можно отправить заявку на такой же бесплатный аудит. Или можете обращаться прямо в комментариях к этому посту. Только не забудьте, помимо ссылки на интерфейс, озвучивать его цель.
А по этой ссылке информация для тех, кто хотел бы купить аудит за деньги.
Почему каждый второй из наших прототипов для новых проектов уходит в стол, а не в продакшен?
Короткий ответ: потому что когда заказчики по прототипу получают оценку у разработчиков, они понимают, что не потянут разработку по деньгам.
Речь идёт исключительно о новых проектах, а не доработках в существующие. Самый распространённый сценарий выглядит так. Человек придумывает идею для своего продукта и решает его разработать. Он ищет по знакомым контакты программиста. Находит и в двух словах объясняет ему задачу. Программист тыкает пальцем в небо и называет стоимость разработки. Допустим, два миллиона. И намекает, что оценка примерная и было бы неплохо посмотреть на техническое задание.
Кто пишет технические задания? Заказчики. Кто умеет писать технические задания? Проектировщики. Некоторые заказчики отказываются сами писать технические задания и приходят к проектировщикам. Некоторые приходят к нам в Проекторат. Мы объясняем, что наши технические задания называются «функциональными спецификациями» и что мы готовим эти документы сразу после создания интерактивного прототипа.
Зачем нужен интерактивный прототип? Чтобы заказчики, не являющиеся специалистами в разработке, могли посмотреть и пощупать проект ещё даже до этапа дизайна. И подтвердить, что это именно то, что им нужно. Обычно заказчикам не нужно долго объяснять, что это такое и какую это несёт пользу для общего дела, и они покупают у нас проектирование.
Допустим, прототип обошёлся в 150 000 рублей. Функциональная спецификация ещё в 150 000 рублей. Итого 300 000 рублей. С этой документацией заказчик идёт к своему программисту и тот делает уже точную оценку. И оказывается, что все хотелки клиента стоят не два миллиона, о которых раньше шла речь, а десять-пятнадцать. И разрабатывать это придётся не меньше года-двух.
Клиент вздыхает и решает пока не делать проект. Проектная документация уходит в стол. Так за 300 000 рублей можно предотвратить потерю двух миллионов рублей и вернуться к этому вопросу позже, когда появятся деньги. Либо пересмотреть свой подход к проекту. Например, избавиться от 90% функций для того, чтобы создать mvp и проверить жизнеспособность бизнес-гипотезы. Но это уже совсем другая история.
Я лично столкнулся с десятком случаев, когда клиенты ввязываются в разработку без проектной документации и в какой-то момент у них заканчиваются деньги, а у разработчика силы. Обычно речь идёт о небольших индивидуальных проектах ценой до миллиона, но суть та же. Проектирование, которое можно вместить в 100-тысячный бюджет, в разы повышает шанс на доведение дела до конца.
Раньше мы расстраивались, когда очередной прототип уходил «в стол» и разработка по нему не велась. А сейчас понимаем, что это нормально. Что мы спасли клиента от затяжной тупиковой разработки, где в какой-то момент закончатся деньги, и проект умрёт.
Напоследок, справедливости ради, хочется отметить, что иногда проекты уходят в стол и по другим причинам. Например, все участники посмотрели на то, что получилось, и поняли, что идея оказалась какой-то шляпой и не стоит её разрабатывать. Бывало и такое, что идея норм, прототип норм, ресурсов выше крыши, а руки просто не доходят до запуска этого дела в разработку. Или нет человека, которого можно зарядить деньгами и отправить курировать проект, а у самого клиента уже нет на это личных ресурсов.
Заработок на фрилансе: зачем повышать уровень сервиса?
Рассказ о моих грядущих обучающих роликах, о том, зачем я буду брать интервью у фрилансеров и о том, как и зачем повышать уровень сервиса при самозанятости. Те, кто спрашивали у меня, можно ли зарабатывать проектировщиком на фрилансе, — не проходите мимо.
Интервью с фрилансером. Проектировщик Антон Григорьев
Взял интервью у Антона Григорьева о работе проектировщиком на фрилансе.
По одежке встречают, по уму провожают. Первичные переговоры на фрилансе
Сейчас я расскажу об очень важной вещи: целеполагании. Когда я только начинал работать на фрилансе, я странно вёл себя на первичных переговорах с заказчиками. Я держал в голове мысль: «Мне нужно заполучить этого клиента и заработать максимально возможное количество денег в рамках работы с ним». И я искренне считал, что это и являлось целью первичных переговоров. Как же я ошибался! Читать далее По одежке встречают, по уму провожают. Первичные переговоры на фрилансе
Точность — вежливость королей и долг всех добрых людей
Я повторял, повторяю и буду повторять ещё неоднократно в будущем: называйте сроки с точностью до часа! Ещё раз: называйте сроки с точностью до часа.
Теперь проиллюстрирую на живом примере. Представьте себе: вы клиент, который заказывает что-то у специалиста. На самом деле это не так просто представить, особенно если речь идёт о рынке 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…
Есть много бесплатных и платных наборов иконок, векторных и растровых, плоских и объёмных, и если записывать правила работы с ними, потребуется тетрадка потолще. Чёртовых иконок так много, что Дьявол легко убедит вас в том, что они вытянут даже плохой дизайн.
Но будьте осторожны. Если «иконка» станет вашим ответом на любой вопрос, однажды Дон Норман постучится в вашу дверь, а когда откроете, пристально посмотрит вам в глаза и скажет: