Показываешь макет команде — и вместо полезного разбора слышишь «что-то не цепляет» или «я бы сделал по-другому». Знакомо? Такой фидбек трудно применить: непонятно, что именно не работает и для кого. А если в ответ на замечания сразу хочется защищать каждую кнопку, обсуждение быстро превращается в спор о вкусах.
Мне помогает сначала договориться о задаче: кто пользователь, что он должен сделать и какие ограничения важны. Тогда комментарии можно привязывать к конкретному сценарию: «На этом экране не замечаю главное действие» полезнее, чем «цвета странные». Хорошо, когда рядом есть причина и вопрос: «Правильно ли я понял, что здесь нужно выбрать тариф? Если да, кнопку стоит выделить сильнее».
Принимая критику, стараюсь не объяснять решение до того, как выслушал замечание целиком. Уточняю, где человек запутался, а потом решаю, менять ли макет: фидбек — это сигнал, не приказ. Но что делать, если мнения расходятся? Как вы отделяете полезные замечания от вкусовщины и задаёте тон обсуждению, чтобы новичок тоже не боялся показать работу?
Мне помогает сначала договориться о задаче: кто пользователь, что он должен сделать и какие ограничения важны. Тогда комментарии можно привязывать к конкретному сценарию: «На этом экране не замечаю главное действие» полезнее, чем «цвета странные». Хорошо, когда рядом есть причина и вопрос: «Правильно ли я понял, что здесь нужно выбрать тариф? Если да, кнопку стоит выделить сильнее».
Принимая критику, стараюсь не объяснять решение до того, как выслушал замечание целиком. Уточняю, где человек запутался, а потом решаю, менять ли макет: фидбек — это сигнал, не приказ. Но что делать, если мнения расходятся? Как вы отделяете полезные замечания от вкусовщины и задаёте тон обсуждению, чтобы новичок тоже не боялся показать работу?
Комментарии 9
Обсуждение темы — по порядку