В работе с программистами то же самое: нужно убеждать не только программиста, но и его менеджера (иногда через своего менеджера), тоже приходится сначала заслужить авторитет.
Я очень люблю фидбек именно от команды, тк всплывают то старые инициативы которые с первого раза не были услышаны, конечно же будет еще откопана история изменений (порой нелинейная, и нужно обосновать почему все-таки такое решение правильное, а потом успокоить тех кого волнует что данное решение уже было раньше но потом было изменено).
Гайдлайны и компоненты кто-то должен оунерить. Те языком цифр: кто-то должен выделить свое время на создание и поддержание в актуальном виде компонентов. И далеко не всегда менеджер согласен на эту доп работу для сотрудника, а программист иногда не считает что это важная инициатива и он хочет заниматься этим в свое свободное время.
Доступность (по крайней мере достаточный контраст цветов) тестируются еще на уровне выбора цветов для макета. Вы упоминаете читаемость иконок, тут есть нюанс. Например, если речь об иконках сервиса размером 16х16 внутри дерева. Тут можно только постараться сделать иконку максимально четкой и распознаваемой (она скорее всего будет еще далека от классной читаемости при 128х128). Доступность в размере кликабельных полей - это может проверить дизайнер, но ответственность за эту часть на фронтенде/разработчике. На тему требованиям к размерам кликабельных областей есть гайды/стандарты.
Давление авторитетом это слабый путь. Тк важны критерии конкретной задачи, а не предыдущий опыт.
В работе с программистами то же самое: нужно убеждать не только программиста, но и его менеджера (иногда через своего менеджера), тоже приходится сначала заслужить авторитет.
Я очень люблю фидбек именно от команды, тк всплывают то старые инициативы которые с первого раза не были услышаны, конечно же будет еще откопана история изменений (порой нелинейная, и нужно обосновать почему все-таки такое решение правильное, а потом успокоить тех кого волнует что данное решение уже было раньше но потом было изменено).
Гайдлайны и компоненты кто-то должен оунерить. Те языком цифр: кто-то должен выделить свое время на создание и поддержание в актуальном виде компонентов. И далеко не всегда менеджер согласен на эту доп работу для сотрудника, а программист иногда не считает что это важная инициатива и он хочет заниматься этим в свое свободное время.
Доступность (по крайней мере достаточный контраст цветов) тестируются еще на уровне выбора цветов для макета. Вы упоминаете читаемость иконок, тут есть нюанс. Например, если речь об иконках сервиса размером 16х16 внутри дерева. Тут можно только постараться сделать иконку максимально четкой и распознаваемой (она скорее всего будет еще далека от классной читаемости при 128х128). Доступность в размере кликабельных полей - это может проверить дизайнер, но ответственность за эту часть на фронтенде/разработчике. На тему требованиям к размерам кликабельных областей есть гайды/стандарты.
Давление авторитетом это слабый путь. Тк важны критерии конкретной задачи, а не предыдущий опыт.