Семантика и синтаксис интерфейса

Есть простой шаблон:
В заголовок — что призошло
Основным текстом — причина и что делать дальше
Кнопкой — действия
Код ошибки, если необходим

Заголовок должен быть понятным и человечным. Задача — сразу сообщить, что ключевое действие не было выполнено. Люди читают заголовок первым и он сразу должен объяснить что произошло.

Если пользователь отправлял письмо, а оно не отправилось, то так и пишем: Письмо не отправлено

Хорошо:
✅ Не удалось загрузить сообщения
✅ Фотографии не отправлены
✅ Платёж не прошел

Плохо:
❌ Что-то пошло не так
❌ Ошибка!
❌ Память не может быть read

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

✅Хорошо для простого человека:
Не удалось сохранить документ. Документ слишком большой. Уменьшите размер документа до 800 символов или разбейте на части.
Разбить на 3 части
Закрыть

✅Хорошо для профессионала.
Не удалось сохранить документ. Размера файла подкачки не хватает для сохранения. Увеличьте размер файла подкачки до 1 ГБ или уменьшите размер вашего документа до 800 символов.
Увеличить файл подкачки
Разбить на 3 части
Закрыть

❌ Плохо:
Не писать причину
Писать профессиональным языком для непрофессионалов

Если причина неизвестна, то можно так и писать: Ошибка произошла по неизвестной причине. Помогите нам разобраться, отправьте отчёт.

Кнопки должны повторять действия, которые вы описали в основном тексте. Не обязательно в основном тексте описывать все кнопки, достаточно описать только предпочтительное действие.

✅Хорошо
Вы ввели неверный пароль слишком часто. Чтобы восстановить пароль, обратитесь в службу поддержки.
Позвонить в службу поддержки
Написать в службу поддержки
Закрыть

❌Плохо:
Вы ввели неверный пароль слишком часто. Чтобы восстановить пароль, обратитесь в службу поддержки.
Закрыть

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

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

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

Но есть ещё личные качества или мягкие навыки, они же soft skills. Глобально выделяют довольно капитанские навыки: умение работать в команде, гибкость, эмпатия, широта взглядов, стрессоустойчивость, управление временем и т.п.
Я не люблю слово "капитанские", но здесь оно прекрасно подходит — очевидно же, что мало кому нужен закостенелый угрюмыш, не умеющий разговаривать с людьми.

Мягкие навыки остаются с человеком и могут применяться, даже при кардинальной смене hard skills. Например, если в продуктовой команде программист стал дизайнером, то его hard skills изменились глобально, а soft skills при этом нужны те же самые, но, возможно, в других пропорциях.

Это было краткое вводное в понятия hard/soft skills.

А теперь к делу — какие же мягкие навыки нужны тем, кто работает в продуктовых командах?
Помимо очевидных, я бы выделил следующий ТОП-5:
1. Любопытство и тяга к знаниям
2. Умение доставать нужную информацию
3. Решительность и находчивость
4. Структурирование информации
5. Умение вовремя остановиться

Могу рассказать по каждому навыку с примерами из опыта- почему навык важен и как его проверить/проявить.
Надо?

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

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

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

Таким образом, получился бы сервис, который с одной стороны собирает заказчиков-исследователей: они назначают задания и указывают стоимость за их выполнение; а с другой стороны имеются исполнители — ребята полевики, которые заинтересованы заработать и прокачаться в урбанистике.

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

Представьте, что вы как заказчик, оставляете заявку и вам за считанные дни проводят целое исследование. Прелесть!

Первое домашнее задание Саши было в его стиле — нужно было организовать командную активность: собраться вечером с командой и весело провести время. Он даже объявил конкурс на самую классную идею вечеринки, победителей он собирался выбирать по видео, которые мы выложим в соцсеть. Призами были книги по продукту и менеджменту.

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

Но многим все же удалось: кто-то пошёл в кофейню, кто-то в бургерную, кто-то на каток, самые смелые пошли в караоке или на скалодром.

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

Как ребята из команды Material Design пересобрали текстовые поля для Google.
Огромное исследование и куча инсайтов.

Почему поля

Казалось бы, текстовое поле, что думать то? Но не все так просто.

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

Команда Material Design провели исследование текстовых полей и выяснили, что куча народа, видя поле с чертой и плейсхолдером (серым текстом подсказкой внутри) не понимали, что оно кликабкльное. Как следствие отваливались и не заполняли формы.

Перекладываем на масштаб Google и сразу становятся понятны причины такой дотошности в мелочах. На таком огромном трафике изменение в 1% дает тебе колоссальное бабло.

Цель состояла в том, чтобы определить, как улучшить текстовое поле. Сделать его заметнее, читабельнее и понятнее – с более четкой целью касания.

Процесс

Исследование проходило в два этапа:

- сперва участникам оценивали разные варианты дизайна
- потом тюнинг конкретных элементов

Участникам предлагалось взаимодействовать с различными вариантами текстовых полей. Собирались прототипы и задавались уточняющие вопросы. Задействовали 600 человек.

Выводы

Результаты двух исследований показали, что следующие элементы текстовых полей имеют наибольшую ценность:

- Закрытые текстовые поля с прямоугольной формой, лучше, чем те, которые имели подчеркивание в виде линии
- Рамка текстового поля должна быть с полупрозрачной заливкой и нижней линией или без заливки, но с непрозрачной чертой.
- Цветовой контраст линий текстового поля с фоном соответствовал минимальным коэффициентам контрастности 3: 1.
- Текст метки должен быть помещен в пределы рамки текстового поля.
- Текстовые поля должны иметь закругленные углы

После того, как работа была проведена Google обновил у себя все текстовые формы.
Под постом бвдет гифка До и После апдейта.