Figma настолько успешно захватила рынок, что в десятой Axure такие привычные и любимые мной «мастера» превратились в «компоненты». Зато теперь могу исключать термин «мастер» из своего лексикона и вспоминать его только когда олдскулы сводит.
О чём хотят узнать люди, прежде чем купить обучающий курс?
Сегодня провожу аудит сайта, на котором продают курсы по ретуши.
Это было весело: к интерфейсу всего пара-тройка замечаний. А вот к ответам на потенциальные вопросы посетителей… В общем, смотрите сами.
О целях интерфейсов
Как можно проводить аудит интерфейса, не зная его целей? Да никак. Даже если цели не озвучены, всё равно они будут как-то сформированы в голове у аудитора. Одному ему понятным образом.
Фишка в том, что во многих случаях цели владельца интерфейса будут отличаться от целей пользователей. Да, когда речь идёт, например, о посадочных страницах, у всех почти всегда одна цель — чтобы сделка состоялась. Ну или, на худой конец, целевое действие было совершено (например, заявка улетела на почту).
Сегодня же у меня на аудите интерфейс мобильного приложения производственного календаря. И цель его создателя (помимо прочего) — заработать на рекламе. А цель пользователей — … ну, их несколько. И чьи же цели учитывать аудитору и как?
Об этом рассказываю в новом ролике.
Записал небольшой видеоролик с рассказом о том, как я провожу аудиты интерфейсов
Вкратце опишу схему:
Аудит не может быть беспредметным. Предмет моих аудитов — это то, насколько эффективно интерфейс достигает поставленных перед ним целей. Поэтому первый шаг — выявить и озвучить эту самую цель (или несколько целей).
Цели достигаются благодаря набору функций в интерфейсе. Например, если цель — продажа, а в интерфейсе нет функции оплаты заказа в рамках некой оферты — то она недостижима. И, возможно, ошибка крылась в терминологии. Например, истинная цель была не продажа, а формирование лида. Из цели можно вывести набор функциональных требований, на который и ориентироваться.
Но даже если есть цель и все необходимые функции для её достижения, то проблема может крыться в информационных ожиданиях. Когда у пользователей интерфейса банально не хватает ответов на вопросы, которые хотелось бы получить перед принятием решения.
И как ни парадоксально это звучит, самая маловажная составляющая моих аудитов — это как раз юзабилити, UX. Эргономика, доступность, эстетика, вот это всё. Точнее, не так. Она, конечно, важна. Но только после того, как решены предыдущие три вопроса.
В результате аудита я всегда выделяю какую-то одну рекомендацию, которая, по моему мнению, повлияет на результат больше всего. Можно перекрасить пятьдесят кнопок и расставить элементы в нужные места, а можно дать пользователю ответ на волнующий его вопрос. Например, есть ли доставка в его регион.
Приятного просмотра!
Недавно я сильно упростил себе жизнь. Сделал так, чтобы экран любого приложения на моём айфоне переводился на русский язык всего лишь по одному двойному тапу. Сегодня поделюсь этим способом и с читателями Хабра.
Всего три шага:
Устанавливаем (или обновляем) приложение Яндекс Переводчик на айфон. К сожалению, не каждое приложение для перевода подойдёт, потому что оно должно уметь принимать картинки из системы и переводить их. Например, DeepL и Google Translate такое не поддерживают.
Добавляем быструю команду (shortcut) по ссылке (или создаём свою).
Переходим в Настройки → Универсальный доступ → Касание → Касание задней панели → Двойное касание. И в самом конце списка выбираем только что добавленную команду Translate screen.
Готово. Теперь по двойному тапу по спинке айфона весь текст на экране будет автоматически переводиться. Это может быть удобно в разных ситуациях. Например, если приложение использует в интерфейсе незнакомый язык.
Кстати, можно пойти дальше и переводить любой текст, который вы отправили в буфер обмена. Для этого есть другая быстрая команда, которую можно привязать к тройному касанию.
А как быть на Андроиде? На некоторых телефонах доступно Circle to Search: нужно нажать и подержать полоску по центру внизу экрана, а потом нажать на кнопку переводчика (скрин). Или запустить Google Assistant (скрин). Ну а если ничего не сработает, то всегда остаётся вариант сделать скриншот и пошарить его в переводчик вручную.
Знаете другие удобные способы? Делитесь в комментариях.
Чек-аут
В интерфейсах интернет-магазинов это экран, который пользователь видит перед тем, как перейти на страницу оплаты.
Это то место, где он уже принял решение о покупке, и указывает последние необходимые параметры для заключения сделки.
Можно найти много чек-листов о том, как оформлять чек-ауты. Я же здесь озвучу самое главное:
Не надо показывать пользователю ничего, что поможет ему уйти с этой страницы или поменять решение о сделке.
— Здесь уже не нужно основное меню навигации, ведь в нём есть ссылки, по которым пользователь может кликнуть и уйти со страницы куда-то ещё. Поэтому шапку можно смело убирать;
— Подвал тоже;
— Не стоит просить заполнить больше данных, чем нужно для оформления сделки. Если есть какие-то необязательные поля, то они, скорее всего, навредят;
— Кнопка с призывом к действию должна быть только одна и с ней ничего не должно визуально конкурировать.
Я бы предположил, что это всё и так очевидно, однако сам начал убирать шапки с подвалами со страниц чек-аутов года два-три назад. А ведь, казалось бы, опытный специалист.
Вообще подобные страницы уже давно спроектированы и оттестированы в любом крупном маркетплейсе и как две капли воды похожи друг на друга.
В продолжение моего поста от 20.12.2023... Да, я до сих пор пытался продолжать пользоваться Evernote... Но сегодня понял, что:
моя десктоп‑версия не синхронизируется уже как минимум месяц(!) — из‑за какой‑то ошибки синхронизации, которую даже не понятно где смотреть (просто восклицательный знак на кнопке синхронизации)
меня достало постоянное напоминание каждый день об очередном обновлении (и ладно бы хотя бы ушла ошибка синхронизации — нет, обновляется каждый день. а что‑то полезное не появляется)
из всего Evernote я по факту пользуюсь WebClipper, потому что из‑за ошибок синхронизации и тормознутости десктопный клиент почти бесполезен (особенно, когда что‑то нужно найти)
оказалось, что и веб‑клиент Evernote теперь жутко тормозит даже просто чтобы вывести список заметок
Ну и понял, что уже все совсем созрело для перехода на Obsidian...
И что же ? Перейти можно сейчас только через десктоп-версию (потому что загрузить в Obsidian можно через enex-файл, а он выгружается только из десктопа Evernote). Т.е. новые заметки, созданные за последний месяц, нужно переносить "ручками".
В общем ладно - запустил я выгрузку из десктоп-версии в enex... и думаю - проверю, а место у меня хватит ? Иду в папку с данными evernote, и вижу, что она занимает 20ГБ (думаю - ничего так я за 10+ лет насобирал)... потом погружаюсь внутрь и понимаю, что сама база занимает ~5ГБ, а остальные ~14ГБ - это папка с копиями установочных пакетов (см. скрин ниже)... В общем адьос Evernote - десктоп удаляю!
Приходит потенциальный клиент к разработчику…
— Мне бы сайт разработать! Можете сказать, сколько это будет стоить?
— А проектная документация у вас есть?
— Не-а.
— Она нужна для оценки. Попробуйте сходить к проектировщику интерфейсов. Возвращайтесь с проектной документацией — и я оценю разработку.
И клиент идёт к проектировщику интерфейсов. Например, ко мне.
— Мне бы сайт спроектировать! Можете сказать, сколько это будет стоить?
— А задание на проектирование у вас есть?
— Не-а. Только не говорите, что опять надо к кому-то идти?!
— Нет. Давайте с вами созвонимся такого-то числа во столько-то — и я за час соберу у вас все необходимые сведения для составления этого задания. Дальше вы проверите, нигде ли я не ошибся — и если всё ок, то я смогу оценить проектирование.
Вот примерно так я обычно и создаю документы под названием «Функциональные требования» (ФТ). По ним я могу оценить объём работ по проектированию. Вот вам видеоролик, в котором показываю пример такого документа и рассказываю о некоторых нюансах его подготовки.
Q-OTP - двухфакторная аутентификация на VueJS.
Поддерживается темная тема, валидация, хинты, вставка через буфер обмена, дополнительные слоты, выбор числа блоков и стилизация.
Компонент подключается как Quasar App Extension:
quasar ext add q-otpПример подключения:
<template>
<QOtp
field-classes="q-ml-xs q-mr-xs"
@complete="(code) => alert(code)"
/>
</template>
<script lang="ts" setup>
import QOtp from 'quasar-app-extension-q-otp'
</script>Исходный код доступен на Гитхаб под лицензией MIT.
Этот ляп в последнем обновлении Evernote сегодня "сделал мой день"...
Программа долго что-то делала после обновления, как обычно обещая, что "осталось 2 минуты"
Через полчаса мне надоело ждать - нажал "крестик"... И вид окна мгновенно изменился:
собственно дальше программа продолжила "висеть", но уже обещая, что "закроется" через "1 минуту 15 секунд".
К ее чести можно сказать, что в итоге она все-таки завершила прерывание за примерно 10 минут :-)
Как документ назовёшь…
…так его потом и найдёшь!
Один из этапов моей работы — составление документа с функциональными требованиями к проекту. И поначалу я их называл примерно так: «Функциональные требования к приложению Нэмо». Храню я их в гугл.доках и в отдельных папках на своём компе.
Через какое-то время я понял, что функциональные требования в заголовке можно сократить до «ФТ». Более короткие названия лучше умещались во вьюпортах и в них было проще ориентироваться: «ФТ к приложению Нэмо».
Ещё через какое-то время документов поднакопилось и я стал всё чаще по ним искать, когда нужно было продемонстрировать новому клиенту что-то из своего портфолио. Я не держал в голове все названия проектов, поэтому мне было проще всего отфильтровать список по слову ФТ — и пробежаться по нему глазами.
Но с моим подходом все названия начинались на «ФТ». От этого было мало толку. Я сделал правильные выводы и с того момента называю документы так: «Нэмо, ФТ». Здесь не осталось ничего лишнего, название проекта на первом месте, а также есть атрибут, по которому можно отфильтровать список. Например, у функциональных спецификаций атрибут «ФС».