Аврора Харли написала о непредсказуемой работе крестиков, закрывающих окна с формами.

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

Чтобы продукт вёл себя предсказуемо:

1. Запрашивайте подтверждение перед деструктивным действием, когда могут пропасть пользовательские данные. Например, если пользователь закрывает фильтр, не применив его, отобразите диалоговое окно: «Вы хотели бы применить фильтр перед возвращением в список товаров? Да / Нет».

2. Замените крестик на текстовую кнопку, которая чётко даст понять, что произойдёт: отмена или закрытие.

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

https://ux.pub/otmenit-ili-zakryt-dizayn-neodnoznachnyh-deystviy/

Думай как Билл Гейтс

Смотрю сейчас на Netflix документальный сериал про Гейтса. Очень увлекательно! В последней серии зацепил диалог следующего содержания:
— Билл, как ты думаешь, Microsoft монополист?
— Если монополия это большая доля рынка и краткосрочная власть над ним, то ответ да. Если вы подразумеваете, что у нас непобедимая позиция и никакой более удобный и эффективный продукт не может её пошатнуть, ответ нет.

И ведь правда. У слова монополия очень сильная негативная составляющая. Но разве это плохо? На свободном рынке, если не рассматривать государственные и прочие нечестные монополии, большая доля рынка говорит о том ,что продукт хорошо решает проблемы пользователя. Да, он может быть кривой и показывать вам периодически "синий экран сметри". Но он, чёрт побери, работает! В сериале есть вставки из хрорники, где народ расхватывает коробки с Windows 95, буквально сметает её с полок :)

Сейчас модно ругать Windows. Но ведь именно эта ОС сделала революцию на рынке персональных компьютеров. Сначала её, конечно, сделал Apple в сфере железа. Именно два Стива сделали компьютер персональным (Джобс и Возняк). Но они были нацелены на определенную ЦА. А вот Майкрософт сделал ПК по-настоящему массовым.

Сейчас Гейтс много времени уделяет проблемам энергетики и климата. Они с женой потратили кучу денег (28 миллиардов долларов) на стартапы и инициативы, которые пытаются сделать жизнь лучше в масштабах планеты. Крутой сериал про крутого бизнесмена и просто очень умного человека. Советую!

Три правила организации процесса дизайна

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

Командообразование

В итоге, Саша Мемус провел с нами всего два занятия в этом семестре, и все его внимание было посвящено сплочению ребят внутри команды.

В том числе для этого мы прошли тесты на определение наших типов личности и сильных сторон: чтобы сопоставить сильные и слабые стороны внутри команды и распределить роли так, чтобы мы могли перекрыть слабые стороны друг друга.

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

Внутри команды мы поделились на несколько ролей: менеджер, аналитик и дизайнер (нас как раз было трое). Аналитик мог пользоваться только браузером, дизайнер мог искать референсы и рисовать прототипы, менеджер не мог делать ничего кроме как говорить и координировать.

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

С каждой новой итерацией мы менялись ролями внутри команды и брифами с другими командами. Чтобы мы не расплавлялись Саша закручивал гайки: сначала на работу отвели 7 минут, потом урезали речь менеджера на защите до 3 предложений, а в самом конце от начала работы до презентации прошло всего три минуты.

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

Как писать сообщения об ошибках

Как писать сообщения об ошибках

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Прокачка

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

Одна из таких прокачек была посвящена теме транспорта: необходимо было выбрать бренд автопроизводителя и с привязкой к их айдентике сделать концепт приложения.

Я выбрал мототему и хонду в виде бренда. Это концепт, который графически завязан на логотипе, тут практически нет продукта и UX-а.

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

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

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

Шот на дриббле:
https://dribbble.com/shots/4714587-Honda-s-app-concept-for-motorcycle