Сегодня вспоминаем про подсказки в интерфейсах. У NNGroup вышла заметка неплохая Принцип золотой эпохи дизайна интерфейсов — если нужна под…

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