Что потыкать
Привет, это Плавучая редакция!
Много новых людей, поэтому давайте расскажу, о чём мы тут. Это канал про текст в интерфейсе и про редакторские лайфхаки. Разбираем всякие UX кейсы, собираем хорошие и плохие примеры. Есть что-то типа рубрик:
#совет — cамая мясная рубрика: советы по редактуре,
#мысливслух — размышления, не претендующие на совет,
#ответ — ответы на вопросы, которые мне пишут в личку.
P. S. если вы присоединились в последние 3 дня, напишите, пожалуйста, как узнали про канал? 🙃
Привет, это Плавучая редакция!
Много новых людей, поэтому давайте расскажу, о чём мы тут. Это канал про текст в интерфейсе и про редакторские лайфхаки. Разбираем всякие UX кейсы, собираем хорошие и плохие примеры. Есть что-то типа рубрик:
#совет — cамая мясная рубрика: советы по редактуре,
#мысливслух — размышления, не претендующие на совет,
#ответ — ответы на вопросы, которые мне пишут в личку.
P. S. если вы присоединились в последние 3 дня, напишите, пожалуйста, как узнали про канал? 🙃
«Укажите» или «введите»?
#ответ
Ольга К: Какое слово лучше использовать в ошибке под полем ввода — «Укажите» или «Введите»? Например, «Укажите ИНН полностью» или «Введите ИНН полностью». Разная ли окраска у этих слов?
——
Если речь про ввод какой-то информации, то разница есть:
«Укажите» — более неформально, ближе к повседневному миру. Это больше про сам факт передачи информации. «Введите» — ближе к миру техническому. Это про способ.
Во фразе «Укажите ИНН полностью» слово «укажите» кажется странным — ты либо указываешь либо нет. Тогда причем тут «полностью»? Здесь бы как раз подошло «Введите», потому что оно про детали процесса. Логика такая: «Вам нужно указать ИНН, а для этого вы вводите в поле текст».
Ещё писать «Введите» может быть более полезно, когда не очевидно с первого раза, как именно мне нужно указать инфу (может быть нужно выбрать какой-то пункт в выпадающем меню?). «Введите» — более точное слово по процессу.
А что насчёт самого требования вводить ИНН полностью? Вряд ли кто-то всерьез рассчитывает, что хватит только части номера (как это бывает например с ФИО — впишу только имя, авось прокатит). Скорее всего это просто ошибка, значит надо подсказать, что ты где-то потерял несколько цифр (а сколько?).
#ответ
Ольга К: Какое слово лучше использовать в ошибке под полем ввода — «Укажите» или «Введите»? Например, «Укажите ИНН полностью» или «Введите ИНН полностью». Разная ли окраска у этих слов?
——
Если речь про ввод какой-то информации, то разница есть:
«Укажите» — более неформально, ближе к повседневному миру. Это больше про сам факт передачи информации. «Введите» — ближе к миру техническому. Это про способ.
Во фразе «Укажите ИНН полностью» слово «укажите» кажется странным — ты либо указываешь либо нет. Тогда причем тут «полностью»? Здесь бы как раз подошло «Введите», потому что оно про детали процесса. Логика такая: «Вам нужно указать ИНН, а для этого вы вводите в поле текст».
Ещё писать «Введите» может быть более полезно, когда не очевидно с первого раза, как именно мне нужно указать инфу (может быть нужно выбрать какой-то пункт в выпадающем меню?). «Введите» — более точное слово по процессу.
А что насчёт самого требования вводить ИНН полностью? Вряд ли кто-то всерьез рассчитывает, что хватит только части номера (как это бывает например с ФИО — впишу только имя, авось прокатит). Скорее всего это просто ошибка, значит надо подсказать, что ты где-то потерял несколько цифр (а сколько?).
Как шутить и не обидеть?
#ответ
Татьяна: Как не переступать грань между заботливым и обидным юмором? Хочется чтобы текст был нескучным, но вдруг шутка кого-то оскорбит?
——
Здесь нет другого секрета, кроме как проверять. Боитесь переступить грань? Покажите шутку 10 пользователям или на худой конец друзьям и попросите оценить, насколько их обижает ваш юмор и насколько заботливым кажется. Получите оценку. Если слишком низкая — попробуйте другие заходы.
Другое дело, что одна и та же шутка про баскетболиста в бане может быть нейтральной для одних людей и обижать других, например, баскетболистов. С этим тоже можно работать. Для начала исключить любые шутки, которые строятся на отличии одних людей от других. Да, это большой пласт шуток, но и мы с вами не стендаперы. (Если вы стендапер — пожалуйста, продолжайте шутить над баскетболистами).
А вообще — шутка не единственный способ сделать текст нескучным. Игра слов, разговорные обороты, даже просто лёгкий слог — сделают ваш текст нескучным. Без шуток.
#ответ
Татьяна: Как не переступать грань между заботливым и обидным юмором? Хочется чтобы текст был нескучным, но вдруг шутка кого-то оскорбит?
——
Здесь нет другого секрета, кроме как проверять. Боитесь переступить грань? Покажите шутку 10 пользователям или на худой конец друзьям и попросите оценить, насколько их обижает ваш юмор и насколько заботливым кажется. Получите оценку. Если слишком низкая — попробуйте другие заходы.
Другое дело, что одна и та же шутка про баскетболиста в бане может быть нейтральной для одних людей и обижать других, например, баскетболистов. С этим тоже можно работать. Для начала исключить любые шутки, которые строятся на отличии одних людей от других. Да, это большой пласт шуток, но и мы с вами не стендаперы. (Если вы стендапер — пожалуйста, продолжайте шутить над баскетболистами).
А вообще — шутка не единственный способ сделать текст нескучным. Игра слов, разговорные обороты, даже просто лёгкий слог — сделают ваш текст нескучным. Без шуток.
Спрашивайте
Люблю отвечать на вопросы, но их почему-то мало.
Для этого достаточно написать мне в личку @maratele, в комментариях к этому посту или вот в формочку, если хотите анонимно.
Про редакторские проблемы, работу в команде, UX, айтишку — anything goes.
Постараюсь ответить на все, а на самые интересные отвечу постом под тегом #ответ — можете пока почитать прошлые ответы 😌
Люблю отвечать на вопросы, но их почему-то мало.
Для этого достаточно написать мне в личку @maratele, в комментариях к этому посту или вот в формочку, если хотите анонимно.
Про редакторские проблемы, работу в команде, UX, айтишку — anything goes.
Постараюсь ответить на все, а на самые интересные отвечу постом под тегом #ответ — можете пока почитать прошлые ответы 😌
Как извиняться в сервисе
#ответ
Дина: Как извиняться в интерфейсе, если нельзя приписывать пользователю эмоции? Ведь нельзя говорить «не расстраивайтесь» и т.д.? Можно писать о чувствах от первого лица, чтобы смягчить ситуацию: «сожалеем» и прочее? Например, если доставка задерживается и нужно попросить подождать определённое время
———
Итак, вы накосячили. Курьер задерживается, хотя вы обещали, что будет вовремя. А может быть накосячили не вы, но пользователю всё равно неприятно. Вот что может в этом случае сделать сервис, от самого важного к менее важному:
Минимизировать проблему. Лучшее, что можно сделать, если у человека проблема — помочь снизить её вред, если это возможно:
— решить проблему на месте,
— предложить другой путь,
— объяснить, как сделать, чтобы проблема не повторялась.
Любые извинения не имеют смысла, если вы даже не попытались минимизировать последствия.
Проявить эмпатию. Как и в повседневном общении, эмпатия в том, чтобы «отзеркалить» эмоции и показать, что вы их понимаете. Не нужно пытаться управлять чужими эмоциями. Фразы типа «Не переживайте» и «Всё будет хорошо» не работают.
А вот извинения, если они звучат искренне, работают — почему нет? По сути это тоже эмпатия: мы показываем, что понимаем, что человеку плохо, и плохо по нашей вине. Другое дело, что их используют как универсальную затычку, поэтому никто не верит, что это искреннее.
Но ведь в языке есть и другие способы показать понимание. Например — «Понимаем, что вы очень расстроены» или «Наверное, это очень неприятно».
Тут есть тонкий момент. Чтобы «отзеркалить» эмоции, нужно быть уверенным, что вы их понимаете правильно. Если пользователь в ярости, ему явно не понравится ваш «Упс, сорян :)». Поэтому так важно картировать эмоции в СJM: разговаривать с пользователями и выяснять, что они на самом деле чувствуют в той или иной ситуации.
Компенсировать вред. После того как помогли с решением проблемы и показали, что понимаем эмоции, можно попробовать их компенсировать.
Единственный работающий способ управлять негативными эмоциями — сделать что-то, что принесёт позитивные. Например, подарок, промокод, скидка, совет, шутка (лучше, конечно, самоироничная).
Тут на что хватит вашей фантазии и сервиса.
#ответ
Дина: Как извиняться в интерфейсе, если нельзя приписывать пользователю эмоции? Ведь нельзя говорить «не расстраивайтесь» и т.д.? Можно писать о чувствах от первого лица, чтобы смягчить ситуацию: «сожалеем» и прочее? Например, если доставка задерживается и нужно попросить подождать определённое время
———
Итак, вы накосячили. Курьер задерживается, хотя вы обещали, что будет вовремя. А может быть накосячили не вы, но пользователю всё равно неприятно. Вот что может в этом случае сделать сервис, от самого важного к менее важному:
Минимизировать проблему. Лучшее, что можно сделать, если у человека проблема — помочь снизить её вред, если это возможно:
— решить проблему на месте,
— предложить другой путь,
— объяснить, как сделать, чтобы проблема не повторялась.
Любые извинения не имеют смысла, если вы даже не попытались минимизировать последствия.
Проявить эмпатию. Как и в повседневном общении, эмпатия в том, чтобы «отзеркалить» эмоции и показать, что вы их понимаете. Не нужно пытаться управлять чужими эмоциями. Фразы типа «Не переживайте» и «Всё будет хорошо» не работают.
А вот извинения, если они звучат искренне, работают — почему нет? По сути это тоже эмпатия: мы показываем, что понимаем, что человеку плохо, и плохо по нашей вине. Другое дело, что их используют как универсальную затычку, поэтому никто не верит, что это искреннее.
Но ведь в языке есть и другие способы показать понимание. Например — «Понимаем, что вы очень расстроены» или «Наверное, это очень неприятно».
Тут есть тонкий момент. Чтобы «отзеркалить» эмоции, нужно быть уверенным, что вы их понимаете правильно. Если пользователь в ярости, ему явно не понравится ваш «Упс, сорян :)». Поэтому так важно картировать эмоции в СJM: разговаривать с пользователями и выяснять, что они на самом деле чувствуют в той или иной ситуации.
Компенсировать вред. После того как помогли с решением проблемы и показали, что понимаем эмоции, можно попробовать их компенсировать.
Единственный работающий способ управлять негативными эмоциями — сделать что-то, что принесёт позитивные. Например, подарок, промокод, скидка, совет, шутка (лучше, конечно, самоироничная).
Тут на что хватит вашей фантазии и сервиса.
Как новичку ворваться в UX-writing
#ответ
Юлия: Как новичку ворваться в профессию, если только закончил курсы, а везде ищут сразу мидлов?
———
Нужно понимать две вещи про UX-writing:
1) это компетенция не стартового уровня,
2) относительно редкая.
Компаниям сложно оценивать новичков без опыта, ведь для этого нужно, чтобы внутри уже были люди с такой компетенцией. Рискнуть, взяв «кота в мешке», тоже опасно, потому что компетенция недешевая.
Поэтому почти любая компания, кроме самых крупных, с уже существующими командами писателей, будет фильтровать вас по опыту.
Курсы и учебные работы, конечно, помогут поднять необходимый скилл. Но одних только курсов недостаточно, чтобы компания доверила вам интерфейсы.
Как же тогда становятся UX-писателями? А обычно из других должностей. Как обычно выглядят позиции для входа:
— сотрудник поддержки (кстати, отлично помогает понять клиента, что потом пригодится в работе над текстом),
— SMM-менеджер,
— копирайтер (на неспецифические тексты обычно требования к опыту ниже),
— UX/UI-дизайнер.
Стандартный путь выглядит так: устроиться на стартовую позицию, а уже внутри компании постараться попасть в команду продуктового UX, попутно поднимая скиллы и набирая смежный опыт.
#ответ
Юлия: Как новичку ворваться в профессию, если только закончил курсы, а везде ищут сразу мидлов?
———
Нужно понимать две вещи про UX-writing:
1) это компетенция не стартового уровня,
2) относительно редкая.
Компаниям сложно оценивать новичков без опыта, ведь для этого нужно, чтобы внутри уже были люди с такой компетенцией. Рискнуть, взяв «кота в мешке», тоже опасно, потому что компетенция недешевая.
Поэтому почти любая компания, кроме самых крупных, с уже существующими командами писателей, будет фильтровать вас по опыту.
Курсы и учебные работы, конечно, помогут поднять необходимый скилл. Но одних только курсов недостаточно, чтобы компания доверила вам интерфейсы.
Как же тогда становятся UX-писателями? А обычно из других должностей. Как обычно выглядят позиции для входа:
— сотрудник поддержки (кстати, отлично помогает понять клиента, что потом пригодится в работе над текстом),
— SMM-менеджер,
— копирайтер (на неспецифические тексты обычно требования к опыту ниже),
— UX/UI-дизайнер.
Стандартный путь выглядит так: устроиться на стартовую позицию, а уже внутри компании постараться попасть в команду продуктового UX, попутно поднимая скиллы и набирая смежный опыт.
Как писать знаки валют?
#ответ
Vadim: Где правильнее ставить знак валюты, будь то $, € или Рубль? Просто в новостных текстах, например, пишется $8 тыс, а в карточках товара в интернет-магазине может быть указано 200$. С какой стороны верно? Насколько вообще важны такие мелочи и детали?
———
1. Я так понимаю, решение использовать знак валюты уже принято. Но всё-таки напомню, что иногда лучше писать валюту словами. Например, в нефинансовых медиа и литературе:
99 франков, а не 99 ₣
2. В интерфейсах обычно придерживаемся правил региона, в котором живёт большая часть аудитории. В РФ принято ставить знаки валют после числа через пробел. Это касается любых валют, не только рубля:
50 $, 2750 ₽
3. Если пользователи из разных регионов, высший класс — подстраивать типографику под особенности выбранного региона.
4. Если валют у вас много, есть всякие реалы, дхармы и криптовалюты, то забудьте значки и используйте буквенные коды:
25 USD, 100 CNY, 5 KWD
5. Однажды слышал такой аргумент: перед числом валюта сразу заметна, не ошибёшься. Не подтверждается, никто не ошибается. Да и противоестественно читается:
₽ 500 — «рублей пятьсот»?
6. Когда-то мы пытались привязывать положение знака к конкретным валютам: доллары перед, а рубли — после через пробел. Не рекомендую, смотрится криво и непоследовательно.
7. И да, эти мелочи важны, потому что влияют на ощущение качества вашего IT-продукта. Вы бы доверили свои деньги приложению, увидев в нём:
общая сумма - $ 10тыс ?
Ну вот.
#ответ
Vadim: Где правильнее ставить знак валюты, будь то $, € или Рубль? Просто в новостных текстах, например, пишется $8 тыс, а в карточках товара в интернет-магазине может быть указано 200$. С какой стороны верно? Насколько вообще важны такие мелочи и детали?
———
1. Я так понимаю, решение использовать знак валюты уже принято. Но всё-таки напомню, что иногда лучше писать валюту словами. Например, в нефинансовых медиа и литературе:
99 франков, а не 99 ₣
2. В интерфейсах обычно придерживаемся правил региона, в котором живёт большая часть аудитории. В РФ принято ставить знаки валют после числа через пробел. Это касается любых валют, не только рубля:
50 $, 2750 ₽
3. Если пользователи из разных регионов, высший класс — подстраивать типографику под особенности выбранного региона.
4. Если валют у вас много, есть всякие реалы, дхармы и криптовалюты, то забудьте значки и используйте буквенные коды:
25 USD, 100 CNY, 5 KWD
5. Однажды слышал такой аргумент: перед числом валюта сразу заметна, не ошибёшься. Не подтверждается, никто не ошибается. Да и противоестественно читается:
₽ 500 — «рублей пятьсот»?
6. Когда-то мы пытались привязывать положение знака к конкретным валютам: доллары перед, а рубли — после через пробел. Не рекомендую, смотрится криво и непоследовательно.
7. И да, эти мелочи важны, потому что влияют на ощущение качества вашего IT-продукта. Вы бы доверили свои деньги приложению, увидев в нём:
общая сумма - $ 10тыс ?
Ну вот.
Некому заняться UX-текстом
#ответ
Анна М.: В компании нет UX-редактора, а задач на текст миллион. Видим, что пользователи ничего не понимают и перегружают поддержку. Что делать?
———
Конечно, собраться и всё-таки нанять хорошего редактора на постоянку — это лучший вариант. Но и самый трудный. Потому что даже если удастся выбить ставку, найти человека будет непросто: UX-редакторов, способных поднять компетенцию в компании с нуля, просто очень мало.
Можно обратиться в агентство, которое посмотрит все ваши флоу и сделает по ним стайл-гайд, а дальше вы будете сверяться с гайдом. Но с агентством всё может быть долго и тоже непредсказуемо.
Поэтому я обычно сразу предлагаю более понятный план Ц — попробую продать вам его завтра. А пока интересно, как бы вы сами решали эту проблему. А может, и вправду уже решали?Делитесь опытом 🐈⬛
#ответ
Анна М.: В компании нет UX-редактора, а задач на текст миллион. Видим, что пользователи ничего не понимают и перегружают поддержку. Что делать?
———
Конечно, собраться и всё-таки нанять хорошего редактора на постоянку — это лучший вариант. Но и самый трудный. Потому что даже если удастся выбить ставку, найти человека будет непросто: UX-редакторов, способных поднять компетенцию в компании с нуля, просто очень мало.
Можно обратиться в агентство, которое посмотрит все ваши флоу и сделает по ним стайл-гайд, а дальше вы будете сверяться с гайдом. Но с агентством всё может быть долго и тоже непредсказуемо.
Поэтому я обычно сразу предлагаю более понятный план Ц — попробую продать вам его завтра. А пока интересно, как бы вы сами решали эту проблему. А может, и вправду уже решали?Делитесь опытом 🐈⬛
Новым подписчикам
Вот что произошло. Вы подписались на авторский канал про редактуру. Веду его я, UX-редактор Вова Лалош — раньше редачил в Сбере, МТС и QIWI, а сейчас в свободном плавании.
В основном пишу про редактуру интерфейсов, потому что больше в ней понимаю. Но и об универсальном копирайтерском тоже. Вот какие есть рубрики:
#совет — проверенные опытом советы по редактуре,
#мысливслух — внезапные идеи после утренних пробежек,
#ответ — ответы на вопросы из бота (жду ваших!),
#разбор — перемываю косточки чужим UX-текстам.
welcome, bem-vindo, მობრძანებით 💜
Вот что произошло. Вы подписались на авторский канал про редактуру. Веду его я, UX-редактор Вова Лалош — раньше редачил в Сбере, МТС и QIWI, а сейчас в свободном плавании.
В основном пишу про редактуру интерфейсов, потому что больше в ней понимаю. Но и об универсальном копирайтерском тоже. Вот какие есть рубрики:
#совет — проверенные опытом советы по редактуре,
#мысливслух — внезапные идеи после утренних пробежек,
#ответ — ответы на вопросы из бота (жду ваших!),
#разбор — перемываю косточки чужим UX-текстам.
welcome, bem-vindo, მობრძანებით 💜
Как указать коллеге на ошибку?
#ответ
Jane J.: Корректно ли (и как) сказать об опечатке или фактологической ошибке в тексте коллеги-писателя, если ещё не выпущенный материал случайно попался на глаза, а peer-ревью в команде не в ходу?
———
Давайте разберём вообще, что тут вообще за конфликт. С одной стороны есть общее дело — хочется выпустить хороший продукт (если у вас не так, стоит задуматься о другом месте работы). А значит, любые действия, советы и замечания, которые сделают продукт лучше, должны приветствоваться по умолчанию. Тогда откуда этот страх указать кому-то на ошибку?
Потому что есть ещё отношения. Давать и принимать критику — это навык. Не у всех он развит одинаково: кто-то нормально переносит любую критику, умеет отделять работу от своего эго. Кто-то вспыхивает от любого намёка на ошибку. Если подозреваете, что коллега из второй категории, то лучшее, что можно сделать, чтобы сберечь отношения — давать замечания аккуратно. Например, в виде вопроса:
💔 У тебя времена рассогласованы!
💜А так и должно быть, что мы пишем сначала в настоящем времени, а потом в прошедшем?
Вы ведь тоже можете тоже ошибаться:
— Да, так и должно быть, это же «фолкнеровская инверсия»!
— А, круто!
Или можно просто деликатно направить внимание:
А в этом абзаце всё ок? Факт-чек делали?
Способов смягчить много. А вообще культура прозрачности решает. В моей идеальной команде работает такая формула:
Толерантность к ошибкам + Общая ответственность за результат
Ошибки двигают вперёд, но для этого они должны замечаться и обрабатываться. Любой участник команды должен иметь возможность указать на чужую ошибку, а другой спокойно её принять и исправить.
#ответ
Jane J.: Корректно ли (и как) сказать об опечатке или фактологической ошибке в тексте коллеги-писателя, если ещё не выпущенный материал случайно попался на глаза, а peer-ревью в команде не в ходу?
———
Давайте разберём вообще, что тут вообще за конфликт. С одной стороны есть общее дело — хочется выпустить хороший продукт (если у вас не так, стоит задуматься о другом месте работы). А значит, любые действия, советы и замечания, которые сделают продукт лучше, должны приветствоваться по умолчанию. Тогда откуда этот страх указать кому-то на ошибку?
Потому что есть ещё отношения. Давать и принимать критику — это навык. Не у всех он развит одинаково: кто-то нормально переносит любую критику, умеет отделять работу от своего эго. Кто-то вспыхивает от любого намёка на ошибку. Если подозреваете, что коллега из второй категории, то лучшее, что можно сделать, чтобы сберечь отношения — давать замечания аккуратно. Например, в виде вопроса:
💔 У тебя времена рассогласованы!
💜А так и должно быть, что мы пишем сначала в настоящем времени, а потом в прошедшем?
Вы ведь тоже можете тоже ошибаться:
— Да, так и должно быть, это же «фолкнеровская инверсия»!
— А, круто!
Или можно просто деликатно направить внимание:
А в этом абзаце всё ок? Факт-чек делали?
Способов смягчить много. А вообще культура прозрачности решает. В моей идеальной команде работает такая формула:
Толерантность к ошибкам + Общая ответственность за результат
Ошибки двигают вперёд, но для этого они должны замечаться и обрабатываться. Любой участник команды должен иметь возможность указать на чужую ошибку, а другой спокойно её принять и исправить.
Forwarded from Кремниевая Галина (G RιSHλN-Y4)
Пока на улице холодало, а ноябрь планомерно готовил нас к самым лёдосодержащим месяцам в году, со всех сторон на нас валились словно снег лавины новостей. НО! У гика при себе всегда цифровая лопата, поэтому самые лучшие из них я аккуратно подобрал и взял в наш традиционный аудитодайджест. Это не блины, конечно, но всё равно налетайте.
А в качестве эксперта сегодня у нас Владимир Лалош, UX-писатель и автор канала «Плавучая редакция». Поехали слушать!
А в качестве эксперта сегодня у нас Владимир Лалош, UX-писатель и автор канала «Плавучая редакция». Поехали слушать!
С чего начать первому UX-редактору?
#ответ
Дина: С чего начать работу UX-редактору в компании, если до него их не было?
———
Окей, вот мой список дел, которые я обычно ставлю перед собой в новой команде без редакторов:
1. Найти стейкхолдеров. Вам нужно 2-3 человека, которые лучше других понимают, как устроен продукт, его цели и проблемы. Чаще всего это владелец продукта, дизайнер, но может быть и аналитик, исследователь. Кроме этого, узнайте, кто уже участвует в создании коммуникаций или заинтересован в них (юристы, менеджеры поддержки, маркетологи) — они вам тоже скоро пригодятся.
2. Объяснить свою роль. Команда может думать, что UX-редактор просто будет править текст, переписывать его лаконично. Лучше сразу сломать этот стереотип. Сделайте небольшую презентацию, расскажите, как будете строить общение с пользователем (вы ведь будете, правда?).
3. Начать изучать продукт. Обычно это значит: стать пользователем самому (если есть возможность); просмотреть исследовательские и маркетинговые отчеты; попросить дизайнера объяснить всё, что у него уже есть в макетах; заглянуть в продукты конкурентов.
4. Приоритизировать проблемы. Нет смысла бросаться за всё подряд. Фокусируемся на срочном + важном; несрочное + важное — откладываем; срочное + неважное — делегируем тем, кому важно; несрочное + неважное — не делаем вообще. Сначала можно довериться приоритизации дизайнера или продакта, но с ростом вашего авторитета вы всё больше сможете на неё влиять.
5. Начать систематизировать. Можно просто собирать повторяющиеся проблемы, скриншотить их и категоризировать, фиксировать свои решения. Такая коллекция может потом перерасти в редполитику или контентную дизайн-систему. А может остаться набором примеров, которые удобно вставлять в свои презентации. Но в любом случае упростит вам жизнь. Вот тут писал подробнее про проторедполитику.
🫵 Вы тоже можете задать свой вопрос через бота. На интересные обязательно отвечу.
#ответ
Дина: С чего начать работу UX-редактору в компании, если до него их не было?
———
Окей, вот мой список дел, которые я обычно ставлю перед собой в новой команде без редакторов:
1. Найти стейкхолдеров. Вам нужно 2-3 человека, которые лучше других понимают, как устроен продукт, его цели и проблемы. Чаще всего это владелец продукта, дизайнер, но может быть и аналитик, исследователь. Кроме этого, узнайте, кто уже участвует в создании коммуникаций или заинтересован в них (юристы, менеджеры поддержки, маркетологи) — они вам тоже скоро пригодятся.
2. Объяснить свою роль. Команда может думать, что UX-редактор просто будет править текст, переписывать его лаконично. Лучше сразу сломать этот стереотип. Сделайте небольшую презентацию, расскажите, как будете строить общение с пользователем (вы ведь будете, правда?).
3. Начать изучать продукт. Обычно это значит: стать пользователем самому (если есть возможность); просмотреть исследовательские и маркетинговые отчеты; попросить дизайнера объяснить всё, что у него уже есть в макетах; заглянуть в продукты конкурентов.
4. Приоритизировать проблемы. Нет смысла бросаться за всё подряд. Фокусируемся на срочном + важном; несрочное + важное — откладываем; срочное + неважное — делегируем тем, кому важно; несрочное + неважное — не делаем вообще. Сначала можно довериться приоритизации дизайнера или продакта, но с ростом вашего авторитета вы всё больше сможете на неё влиять.
5. Начать систематизировать. Можно просто собирать повторяющиеся проблемы, скриншотить их и категоризировать, фиксировать свои решения. Такая коллекция может потом перерасти в редполитику или контентную дизайн-систему. А может остаться набором примеров, которые удобно вставлять в свои презентации. Но в любом случае упростит вам жизнь. Вот тут писал подробнее про проторедполитику.
🫵 Вы тоже можете задать свой вопрос через бота. На интересные обязательно отвечу.
Может ли UX-редактор быть интровертом?
#ответ
Алиса: Интроверту совсем плохо будет ux-редактором, да?) Прям совсем-совсем?
———
Это почти не играет роли. Я сам ближе к интровертам, но мне это мешало только первые месяц-два. Когда нужно решить задачу, ты совсем по-другому начинаешь относиться к общению. Это же не про болтовню на любые темы: ты идешь за информацией. От других способов получения инфы это отличается только тем, что нужно вслух задавать вопросы.
За годы работы насмотрелся на интровертов, которые замечательно взаимодействуют с коллегами и пользователями. Наоборот, это может быть плюсом: интроверт не отвлекается на посторонние темы, лучше держит фокус, соблюдает регламент 🙂
Если сильный страх именно от знакомства с новыми людьми, то это тоже не проблема. Чаще всего взаимодействие будет в кругу уже знакомых коллег. Не журналистика же всё-таки.
А ещё мне кажется, что интровертность у многих — это обычный страх от недостатка навыков общения. А навыки — дело наживное.
#ответ
Алиса: Интроверту совсем плохо будет ux-редактором, да?) Прям совсем-совсем?
———
Это почти не играет роли. Я сам ближе к интровертам, но мне это мешало только первые месяц-два. Когда нужно решить задачу, ты совсем по-другому начинаешь относиться к общению. Это же не про болтовню на любые темы: ты идешь за информацией. От других способов получения инфы это отличается только тем, что нужно вслух задавать вопросы.
За годы работы насмотрелся на интровертов, которые замечательно взаимодействуют с коллегами и пользователями. Наоборот, это может быть плюсом: интроверт не отвлекается на посторонние темы, лучше держит фокус, соблюдает регламент 🙂
Если сильный страх именно от знакомства с новыми людьми, то это тоже не проблема. Чаще всего взаимодействие будет в кругу уже знакомых коллег. Не журналистика же всё-таки.
А ещё мне кажется, что интровертность у многих — это обычный страх от недостатка навыков общения. А навыки — дело наживное.
Неверное время
#ответ
Sasha: Пишу текст для бота. Пользователю нужно вводить время события вручную. Разделитель — точка или двоеточие — не важен, хоть запятая:
Это точно верное время? 🤔 Напиши его в формате часы/минуты. С точкой 22.00 или двоеточием 22:00 — как тебе удобнее
———
Если дело в формате, то «верное время» не подходит. «Неверное время» — это 13:15 вместо 15:00. А если человек вводит «78», то лучше сказать, что он вводит что-то не то.
Не могу разобрать время 🤔
При этом в ботах важно данные обрабатывать не только в удобном вам формате, а научить понимать как можно больше вариантов. Чтобы пользователь мог написать и «13» и «три десять», и бот не жаловался на формат.
Не могу разобрать время 🤔 Попробуй написать так: 22:00 или «в семь вечера»
#ответ
Sasha: Пишу текст для бота. Пользователю нужно вводить время события вручную. Разделитель — точка или двоеточие — не важен, хоть запятая:
Это точно верное время? 🤔 Напиши его в формате часы/минуты. С точкой 22.00 или двоеточием 22:00 — как тебе удобнее
———
Если дело в формате, то «верное время» не подходит. «Неверное время» — это 13:15 вместо 15:00. А если человек вводит «78», то лучше сказать, что он вводит что-то не то.
Не могу разобрать время 🤔
При этом в ботах важно данные обрабатывать не только в удобном вам формате, а научить понимать как можно больше вариантов. Чтобы пользователь мог написать и «13» и «три десять», и бот не жаловался на формат.
Не могу разобрать время 🤔 Попробуй написать так: 22:00 или «в семь вечера»
Нужно ли убирать «вы»?
#ответ
David: «Есть мнение некоторых райтеров, что в банковской сфере стоит избегать большого количества "вы", "ваш", "вас". чем меньше - тем лучше. На чем базируется это мнение?».
———
Да, такое негласное правило есть. Но оно касается не только банков.
Дело даже не в подчёркнутой вежливости. Если в тональности обращение на «ты», будет то же самое.
Каждый раз, когда вы говорите о пользователе во втором лице, вы задаёте дистанцию. Типа есть «вы», пользователь, а есть «мы» — приложение. Вот это твои штуки: профиль, аватарка, избранное, а вот все остальные, получается, наши.
Чисто технически в этом нет ничего аномального. Обычный диалог. Но если вы хотите вовлекать, хотите, чтобы пользователь ощущал приложение как продолжение себя, то лучше не подчёркивать эту разницу «вы-мы» слишком активно. Лучше пусть это будут мысли самого пользователя или что-то нейтральное.
Кто-то возразит, что «ну как же, люди больше любят слушать о себе, чем о чём-то ещё». Наверное, лучше это использовать как-то иначе. На практике постоянное выканье и тыканье подбешивает.
Я поставил приложение — понятно, что здесь будет про меня. Так дайте мне заниматься моими делами.
#ответ
David: «Есть мнение некоторых райтеров, что в банковской сфере стоит избегать большого количества "вы", "ваш", "вас". чем меньше - тем лучше. На чем базируется это мнение?».
———
Да, такое негласное правило есть. Но оно касается не только банков.
Дело даже не в подчёркнутой вежливости. Если в тональности обращение на «ты», будет то же самое.
Каждый раз, когда вы говорите о пользователе во втором лице, вы задаёте дистанцию. Типа есть «вы», пользователь, а есть «мы» — приложение. Вот это твои штуки: профиль, аватарка, избранное, а вот все остальные, получается, наши.
Чисто технически в этом нет ничего аномального. Обычный диалог. Но если вы хотите вовлекать, хотите, чтобы пользователь ощущал приложение как продолжение себя, то лучше не подчёркивать эту разницу «вы-мы» слишком активно. Лучше пусть это будут мысли самого пользователя или что-то нейтральное.
Кто-то возразит, что «ну как же, люди больше любят слушать о себе, чем о чём-то ещё». Наверное, лучше это использовать как-то иначе. На практике постоянное выканье и тыканье подбешивает.
Я поставил приложение — понятно, что здесь будет про меня. Так дайте мне заниматься моими делами.
Свитчер с двумя опциями?
#ответ
Анна: Сначала подумала, что хорошо сделано, но потом засомневалась) Интересно почитать мнения.
В гайдлайнах Google и Apple ничего не сказано про такое использование свитчера. Переключатель обычно просто подтверждает или опровергает утверждение в тексте слева от него.
Если у вас есть две опции, которые аннигилируют друг дружку, но про каждую отдельно очень хочется что-то сказать, то платформы советуют использовать радиокнопки (как на втором скрине).
Другое дело — кто вам такие эти создатели гайда Android или Apple? Если элемент смотрится нормально в вашем внеплатформенном дизайне и пользователям понятен, то вы всё делаете правильно. В играх вон вообще миллионы видов управляющих элементов — никто же к ним не цепляется.
Гендер-нейтральность только можно вернуть: Найду сам → Найду самостоятельно
#ответ
Анна: Сначала подумала, что хорошо сделано, но потом засомневалась) Интересно почитать мнения.
В гайдлайнах Google и Apple ничего не сказано про такое использование свитчера. Переключатель обычно просто подтверждает или опровергает утверждение в тексте слева от него.
Если у вас есть две опции, которые аннигилируют друг дружку, но про каждую отдельно очень хочется что-то сказать, то платформы советуют использовать радиокнопки (как на втором скрине).
Другое дело — кто вам такие эти создатели гайда Android или Apple? Если элемент смотрится нормально в вашем внеплатформенном дизайне и пользователям понятен, то вы всё делаете правильно. В играх вон вообще миллионы видов управляющих элементов — никто же к ним не цепляется.
Гендер-нейтральность только можно вернуть: Найду сам → Найду самостоятельно
Должны ли дизайнеры проверять ошибки
#ответ
Nina: Дизайнерам пофиг на русский язык или они столько работают, что не замечают? Кто-то вообще еще верит в то, что тексты должны быть грамотными и это ответственность дизайнеров в том числе?
———
Согласен, орфографические ошибки и опечатки в приложениях всегда расстраивают. Но одних только дизайнеров обвинить не получится. И вот почему.
🔹В процессе дизайна возникает множество итераций текста, если каждый причёсывать и проверять — можно сойти с ума. Поэтому обычно на ошибки проверяют в конце, когда уже всё готово. Часто за это отвечают другие люди — из маркетинга или контентщики. Но этот этап в релизной горячке может выпасть.
🔹Если зовут проверить копирайтера, он тоже может в спешке проверить только смысловую часть, а ошибки пропустить. Потому что корректура — отдельный процесс, который плохо смешивать с проверкой по смыслу.
🔹Много ошибок возникает в процессе не дизайна, а разработки. Текст мог быть хорошо проверен, но разработчик что-то переносил вручную, где-то дописывал — буква потерялась. Потому что никто не чекнул предрелизный контент.
Участники команды могут быть все грамотными, но в хаосе часто можно пропустить ошибку. Конечно, здорово, если все стараются писать без ошибок, но проблему это не решит.
А решат проблему специально выделенные в рабочем флоу проверки:
1) перед тем как отдать дизайн разработчикам,
2) перед релизом.
Кто должен проверять? Понятно, что профессионального корректора (а это профессия!) в команде чаще всего нет. Но можно попробовать восполнить инструментами — прогонять через спелчекеры, просить чатгпт проверить, проверять вдвоём и так далее. Было бы желание.
#ответ
Nina: Дизайнерам пофиг на русский язык или они столько работают, что не замечают? Кто-то вообще еще верит в то, что тексты должны быть грамотными и это ответственность дизайнеров в том числе?
———
Согласен, орфографические ошибки и опечатки в приложениях всегда расстраивают. Но одних только дизайнеров обвинить не получится. И вот почему.
🔹В процессе дизайна возникает множество итераций текста, если каждый причёсывать и проверять — можно сойти с ума. Поэтому обычно на ошибки проверяют в конце, когда уже всё готово. Часто за это отвечают другие люди — из маркетинга или контентщики. Но этот этап в релизной горячке может выпасть.
🔹Если зовут проверить копирайтера, он тоже может в спешке проверить только смысловую часть, а ошибки пропустить. Потому что корректура — отдельный процесс, который плохо смешивать с проверкой по смыслу.
🔹Много ошибок возникает в процессе не дизайна, а разработки. Текст мог быть хорошо проверен, но разработчик что-то переносил вручную, где-то дописывал — буква потерялась. Потому что никто не чекнул предрелизный контент.
Участники команды могут быть все грамотными, но в хаосе часто можно пропустить ошибку. Конечно, здорово, если все стараются писать без ошибок, но проблему это не решит.
А решат проблему специально выделенные в рабочем флоу проверки:
1) перед тем как отдать дизайн разработчикам,
2) перед релизом.
Кто должен проверять? Понятно, что профессионального корректора (а это профессия!) в команде чаще всего нет. Но можно попробовать восполнить инструментами — прогонять через спелчекеры, просить чатгпт проверить, проверять вдвоём и так далее. Было бы желание.
Используют ли неразрывные пробелы в UX?
#ответ
Sasha R: А где и как в интерфейсах используются неразрывные пробелы?
———
Используются очень активно. Коротко напомню: неразрывный пробел не даёт делать переносы по строкам там, где вам не нужно. Ставится сочетанием ⌥ + Пробел, а в винде: Ctrl + Shift + Пробел.
Когда пригодится
— После предлога, союза, притяжательного местоимения, чтобы не было висячих строк.
— Между разрядами в числах: 1 000 000, чтобы сумма не ломалась.
— Между числом и единацами измерения, значками процента, валют.
— В сокращениях типа «и т. д.»
— Перед тире — чтобы строка с него не начиналась.
— В датах.
Все применения вы можете найти в справочниках типа Мильчина и Чельцовой. Но важнее помнить не букву закона, а его суть: всё, что составляет некий цельный объект в тексте, имеет смысл скрепить неразрывными пробелами, чтобы сохранить цельность.
Иногда я ставлю неразрывный пробел просто между двумя словами, если мне нужно, чтобы они легче прочитались:
Пополните баланс и пользуйтесь
кошельком
↓
Пополните баланс
и пользуйтесь кошельком
Подводные камни
1. Если переборщить, на маленьких экранах будут странные лесенки из слов, по слову в строке → Придётся ставить только в самых важных местах. Какими-то переносами придётся жертвовать.
2. Разработчик может увидеть странный символ и заменить его на обычный пробел → Значит надо заранее всех предупредить, что бывают неразрывные пробелы. Можно дополнительно помечать в файлах, но мне кажется, это ненадёжно. Обучение и авторский надзор решают вопрос.
3. Просто задалбывает ставить → Пользуйтесь плагинами, которые расставляют автоматически: SBOL Typograph, Text Prettier и прочими. Но тогда тем более не забудьте проверить, что в узком экране у вас не появляется лесенка из слов.
#ответ
Sasha R: А где и как в интерфейсах используются неразрывные пробелы?
———
Используются очень активно. Коротко напомню: неразрывный пробел не даёт делать переносы по строкам там, где вам не нужно. Ставится сочетанием ⌥ + Пробел, а в винде: Ctrl + Shift + Пробел.
Когда пригодится
— После предлога, союза, притяжательного местоимения, чтобы не было висячих строк.
— Между разрядами в числах: 1 000 000, чтобы сумма не ломалась.
— Между числом и единацами измерения, значками процента, валют.
— В сокращениях типа «и т. д.»
— Перед тире — чтобы строка с него не начиналась.
— В датах.
Все применения вы можете найти в справочниках типа Мильчина и Чельцовой. Но важнее помнить не букву закона, а его суть: всё, что составляет некий цельный объект в тексте, имеет смысл скрепить неразрывными пробелами, чтобы сохранить цельность.
Иногда я ставлю неразрывный пробел просто между двумя словами, если мне нужно, чтобы они легче прочитались:
Пополните баланс и пользуйтесь
кошельком
↓
Пополните баланс
и пользуйтесь кошельком
Подводные камни
1. Если переборщить, на маленьких экранах будут странные лесенки из слов, по слову в строке → Придётся ставить только в самых важных местах. Какими-то переносами придётся жертвовать.
2. Разработчик может увидеть странный символ и заменить его на обычный пробел → Значит надо заранее всех предупредить, что бывают неразрывные пробелы. Можно дополнительно помечать в файлах, но мне кажется, это ненадёжно. Обучение и авторский надзор решают вопрос.
3. Просто задалбывает ставить → Пользуйтесь плагинами, которые расставляют автоматически: SBOL Typograph, Text Prettier и прочими. Но тогда тем более не забудьте проверить, что в узком экране у вас не появляется лесенка из слов.
Можно ли писать на кнопке от первого лица?
#ответ
Элина: Кнопка всегда должна быть с действием пользователя или возможны исключения? Например, на картинке кнопка «Читать кейс», но очень хочется ее переименовать в «Рассказываем как». Допустимо ли это, и если нет, то почему?
———
Да, обычно принято на кнопке писать то, что пользователь мог бы сказать вслух. Чтобы получался такой воображаемый диалог сервиса и человека:
— Вот тут говорим мы, авторы
— А здесь ты отвечаешь!
Если нарушать форму диалога, получается неловко. Как будто меня заставляют отвечать сервису чужим голосом. Поэтому редакторы обычно так делать не советуют.
К счастью, люди не роботы. Они в состоянии отличить кнопку на лендинге от простого текста. И не актёры, которые упадут в обморок, воскликнув «О нет, мне подсунули чужие слова!». Скажу шокирующую вещь — многие пользователи смогут догадаться, что кнопка делает, даже если текст убрать СОВСЕМ.
Будут ли они нажимать на кнопку с «Рассказываем»? Да будут, если всё остальное на лендинге их убедило и кнопка органично вписывается.
Вон гиперссылки тоже далеко не на текст от лица пользователя вешают, хотя нажимаются они как кнопки. Почему-то никто не умирает, кликая на «читайте полный обзор».
Так что если вы уверены, что ваш кнопочный текст идеально ложится в остальной контент, то забейте на любые редакторские правила и делайте по своим. Может быть даже зададите новый тренд в UX 😈
#ответ
Элина: Кнопка всегда должна быть с действием пользователя или возможны исключения? Например, на картинке кнопка «Читать кейс», но очень хочется ее переименовать в «Рассказываем как». Допустимо ли это, и если нет, то почему?
———
Да, обычно принято на кнопке писать то, что пользователь мог бы сказать вслух. Чтобы получался такой воображаемый диалог сервиса и человека:
— Вот тут говорим мы, авторы
— А здесь ты отвечаешь!
Если нарушать форму диалога, получается неловко. Как будто меня заставляют отвечать сервису чужим голосом. Поэтому редакторы обычно так делать не советуют.
К счастью, люди не роботы. Они в состоянии отличить кнопку на лендинге от простого текста. И не актёры, которые упадут в обморок, воскликнув «О нет, мне подсунули чужие слова!». Скажу шокирующую вещь — многие пользователи смогут догадаться, что кнопка делает, даже если текст убрать СОВСЕМ.
Будут ли они нажимать на кнопку с «Рассказываем»? Да будут, если всё остальное на лендинге их убедило и кнопка органично вписывается.
Вон гиперссылки тоже далеко не на текст от лица пользователя вешают, хотя нажимаются они как кнопки. Почему-то никто не умирает, кликая на «читайте полный обзор».
Так что если вы уверены, что ваш кнопочный текст идеально ложится в остальной контент, то забейте на любые редакторские правила и делайте по своим. Может быть даже зададите новый тренд в UX 😈
Показать или посмотреть?
#ответ
Яна: Возник спор, как назвать кнопку, которая показывает все результаты поиска: «Показать все результаты» или «Посмотреть все результаты»? Вроде как от лица пользователя логичнее «посмотреть», диалог пользователя с интерфейсом и все-такое. С другой стороны, кнопка же в итоге покажет все результаты и это прямое указание системе, что ей надо сделать — «показать». Есть ли тут правильный ответ или просто вкусовщина?
———
Разница почти не заметная, но есть. «Показать результаты» — более формальный вариант, действительно ближе к команде пользователя системе: «давай, показывай». Получается такая схема:
я хочу посмотреть → система показывает → я смотрю
Вот только в глубине души вы не хотите, чтобы вам «показали результаты». Вы просто хотите их просто посмотреть, верно?
я хочу посмотреть → я смотрю
Система как бы удаляется из цепочки. Получается более простой, интуитивный вариант.
Представьте ребёнка, который хочет посмотреть мультик. Как он будет просить? «Покажи мне мультик» или «Хочу, чтобы ты показал мне мультик»? Вряд ли. Ребёнок скажет «Хочу смотреть мультик!» или просто «Хочу мультик!».
Это не значит, что вариант с явным участием системы хуже, чем без. Скорее это про особенности голоса вашего продукта:
🪄 Должны ваши пользователи чувствовать себя настолько интуитивно, что сам сервис будто ни при чём? — Тогда пишите «посмотреть», «хочу», «получить», «мои файлы».
🧑🏭 Важно сберечь диалог и фигуру помощника, который всё ищет и делает за пользователя? — Больше подойдут «показать», «требуется», «отправить», «ваши файлы».
Читайте также связанный пост про Личные вещички
#ответ
Яна: Возник спор, как назвать кнопку, которая показывает все результаты поиска: «Показать все результаты» или «Посмотреть все результаты»? Вроде как от лица пользователя логичнее «посмотреть», диалог пользователя с интерфейсом и все-такое. С другой стороны, кнопка же в итоге покажет все результаты и это прямое указание системе, что ей надо сделать — «показать». Есть ли тут правильный ответ или просто вкусовщина?
———
Разница почти не заметная, но есть. «Показать результаты» — более формальный вариант, действительно ближе к команде пользователя системе: «давай, показывай». Получается такая схема:
я хочу посмотреть → система показывает → я смотрю
Вот только в глубине души вы не хотите, чтобы вам «показали результаты». Вы просто хотите их просто посмотреть, верно?
я хочу посмотреть → я смотрю
Система как бы удаляется из цепочки. Получается более простой, интуитивный вариант.
Представьте ребёнка, который хочет посмотреть мультик. Как он будет просить? «Покажи мне мультик» или «Хочу, чтобы ты показал мне мультик»? Вряд ли. Ребёнок скажет «Хочу смотреть мультик!» или просто «Хочу мультик!».
Это не значит, что вариант с явным участием системы хуже, чем без. Скорее это про особенности голоса вашего продукта:
🪄 Должны ваши пользователи чувствовать себя настолько интуитивно, что сам сервис будто ни при чём? — Тогда пишите «посмотреть», «хочу», «получить», «мои файлы».
🧑🏭 Важно сберечь диалог и фигуру помощника, который всё ищет и делает за пользователя? — Больше подойдут «показать», «требуется», «отправить», «ваши файлы».
Читайте также связанный пост про Личные вещички