Сегодня вспоминаем про подсказки в интерфейсах. У NNGroup вышла заметка неплохая
Принцип золотой эпохи дизайна интерфейсов — если нужна подсказка, работа над дизайном не проделана. Дизайнер не разобрался в задаче, а буквально подпёр костылём
Почему подсказка симптом плохо сделанной работы?
Подсказка — симптом: дизайнер не облёк смысл в поток самодостаточного взаимодействия с интерфейсом. Не переосмыслил задачу
Это часто болезненная штука в нашей работе: разница между выполнить формулировку и решить проблему
Задача почти всегда написана языком организации, а не пользователя. Там много скрытых допущений: юридических, маркетинговых, KPI-ных, исторических («у нас так принято»), технических («это уже сделано вот так»). Если дизайнер просто реализует буквальный текст задачи — он обслуживает эти допущения, не проверяя, ведут ли они к ясности взаимодействия
Как решить задачу? Сделать шаг назад: переформулировать задачу как пользовательскую цель:
• объяснить ценность и дать контроль
• помочь быстро и без ошибок завершить сценарий
И интерфейс строить так, чтобы поведение пользователя вытекало из формы, а не из «прочитай инструкцию»
Подсказка— часто это признание, что механизм не работает сам.
Если действие требует пояснения, значит:
• либо аффорданс (намёк формы на действие) слабый
• либо модель (что здесь вообще происходит) у пользователя не совпала с тем, что придумали
• либо сценарий перегружен чужими целями, и дизайнер «не имел права» упростить — но тогда честнее признать, что дизайн не нужен
