Для меня, основной сложностью в переводах является именно сложность правильно передать мысль автора по-русски, подобрать правильные слова и подходящие выражения. То, что я выкладываю на самом деле — это черновики переводов. В идеальном случае все это хорошо было бы просмотреть вместе с редактором или самому перечитать несколько раз.
Но, как всегда — торопишься, ленишься, идешь по пути наименьшего сопротивления. Очень трудно себя заставить остановиться и внимательно перечитать написанное. В принципе, то же самое происходит и в процессе проектирования. Иногда бывает сложно заставить себя останоситься и попробовать объективно посмотреть на уже сделанное.
Плюс, конечно же сказывается отсутствие практики письма в течение нескольких полседних лет. Сложность перевода зависит и от манеры письма автора. Кого-то перевести легче, с кем-то посложнее.
Обещаю, перечитать эту статью и как минимум внести указанные вами исправления. :) Еще, чем больше практики, тем лучше получается. Так что, надеюсь, что переводы следующих частей будут более успешными.
Дмитрий, спасибо. Для меня важна ваша раекция. Я долго думал перед тем как взяться и начать переводить статьи на эту тематику. Потому что дема достаточно провокационная и дискуссионная, как вы заметили в комменте на вчерашнюю статью. Я опасался не навредить.
Вопрос-то ведь не в оспаривании чьих-то подходов и методов, в том, как выбрать метод, соответствующий конкретной ситуации.
Анонс следующих статей из этой серии (предварительный перевод названий):
А интуиция у аналитика (по сути психолога) - это зло, ибо аналитик должен быть зеркалом, с нулевым (минимальным) уровнем собственного шума.
На мой взгляд очень спорное утверждение. Практически каждое слово можно оспорить. И то, что интуиция для аналитика зло. И то, что аналитик - по сути психолог. И то, аналитик должен быть зеркалом...
Мне казалось, что данный раздел рассматривет именно второй вариант, где люди, работающие над проектом, нацелены на успех Продукта на рынке.
Но ведь кто-то же платит зарплату проектировщику. И этот кто-то &mdsh; явно не конечные пользователи. Поэтому &mdsh; первый критерий, является более приоритетным, хотя бы потому, что если начальник направит проект на редизайн, то до пользователей дойдет совсем немного из задуманного.
Да, в реальных проектах именно так и происходит. У вице-президента могут быть собственные взгляды на продукт, которые он не разглашает проектной команде, архитектор может испытывать личную неприязнь к менеджеру продукта...
Дмитрий, Алексей, Александр.
Несколько слов о моих мотивах перевода этой статьи, предыдущей статьи Якоба Нильсена и еще серии статей, которые я перевожу в данный момент.
Вопрос здесь не стоит о целесообразности исследований. Вопрос в методах, в том, как правильно подобрать набор используемых методов и подходов для каждой конкретной ситуации. Пользоваться ли дорогими или дешевыми методами, проводить инспекцию или пользовательское тестирование, получать качественные или количественные результаты, тестировать традиционным методом или с активным вмешательством, тестировать детальный или бумажный прототип... Вопрос в том, что приоритетнее исследования или проктирование...
Меня два года учили применять "правильные" методы юзабилити исследования, потом три года я работаю в ситуации, когда возможности применения традиционных юзабилити методов ограничены, но я вижу, что за счет применения методов "альтернативных" традиционным можно достичь приемлимых результатов. Я работаю над собственным арсеналом используемых методов и ищу то, что будет работать в моей конкретной ситуации.
Я как раз сегодня натолкнулся на неплохую статью, посвященную исключительно найму проектировщиков. Может быть, в течение нескольких недель получится перевести.
Конечно, это просто современная рефлексия на статью Гаррета от 2002 года. Но для меня в чем-то было полезным открытием, именно из-за сформулированных правил.
Немного расскажу об истории User Experience. Через несколько лет (конец 90-х, начало этого века) после появления философии user-centered design, люди котрые практиковали этот подход заметили его ограниченность. Ограниченность заключалась в ортодоксальном следовании подходу, центрировании на пользователе, его нуждах, в том, что потребности пользователя ставились выше бизнес и технологических нужд и потребностей. От этого возникали проблемы с коллегами других специальностей, участвующих в проекте. Более того, такой подход негативно сказывался на образе всей дисциплины. Требовался более сбаланисрованный подход, который бы учитывал интересы не только пользователей, но и разработчиков, и хозяев продукта. Первой моделью была "трехногая табуретка" Дональда Нормана, потом появились более продвинутые модели.
Другим фактором была сама специфика работы, когда специалистам приходилось работать не только с интерфейсами, но понемногу заниматься и другими смежными областями: графическим и информационным дизайном, работой с текстом, бизнес-анализом,...
вопрос контента - это немного другое, задача для людей, которые пишут тексты и т.д.
Похоже, что вы или не знакомы с понятием User Experience или немного отстаете от последних тенденций. Года 3-4 назад, люди пришли к пониманию Umbrella User Experience — тоесть того, что успех продукта у пользователя — дело совместных усилий всех, занятых в проектировании, разработке и продвижении. Где тонко, там и рвется. Если контент слаб, то весьма возможно, что именно это и станет причиной будущей неудачи продукта. А вы говорите, что это задача для людей, которые пишут тексты... Про "Юзабилити Текстов" ничего не слышали?
Почему "так повелось"?
Так и должно быть. Есть несколько критериев успеха:
Краткосрочный: угодить начальнику или заказчику. Ведь именно они платят деньги за разработку. Для большинства занятых в разработке — именно этот критерий и является основным критерием успеха, ведь разработчика то, что произошло с продуктом после выхода на рынок, волнует и касается меньше, чем менеджера или маркетолога.
Долгосрочный: успех продукта на рынке. И тут снова — угодить начальнику/заказчику через удовлетворение конечных пользователей.
хочу, чтобы этим пользовалось максимальное количество людей, для кого этот Продукт предназначен???
Так ведь и я именно об этом писал.
Не все, но многие, скорее всего — большинство, если финансы позволяют. Покупают то, что не совсем нужно. Возьмем тот же пример с телефоном: вы выбрали модель, а вам говорят, что точно такая же, но с радио будет на 10$ дороже, с плеером - на 20$, с камерой - на ..., с дополнительной памятью - ... И очень многие будут готовы немного доплатить именно "про запас", мало кто готов покапать модель с минимальными характеристиками.
Про список функциональности. Про Nero. А зачем вы вообще покупали Nero? Могли бы воспользоваться Open Source аналогом? Как разработчикам продать новую версию, почему пользователи должны её покупать, а не продолжать пользоваться старой? Это достигается в большинстве своем именно за счет увеличения функциональности, даже термин такой есть creeping featurism. :)
Ок, продолжим. И как удастся пользователю достичь свою цель, если система не содержит искомой информации или если она содержит только часть искомой информации? Юзабельна ли такая система?
На самом деле перевод экономических терминов был для меня самой большой сложностью при переводе данной статьи. Давно ничего не переводил, поэтому забыл о необходимости приводить английские аналоги спорных терминов.
Большое спасибо за совет.
Для меня, основной сложностью в переводах является именно сложность правильно передать мысль автора по-русски, подобрать правильные слова и подходящие выражения. То, что я выкладываю на самом деле — это черновики переводов. В идеальном случае все это хорошо было бы просмотреть вместе с редактором или самому перечитать несколько раз.
Но, как всегда — торопишься, ленишься, идешь по пути наименьшего сопротивления. Очень трудно себя заставить остановиться и внимательно перечитать написанное. В принципе, то же самое происходит и в процессе проектирования. Иногда бывает сложно заставить себя останоситься и попробовать объективно посмотреть на уже сделанное.
Плюс, конечно же сказывается отсутствие практики письма в течение нескольких полседних лет. Сложность перевода зависит и от манеры письма автора. Кого-то перевести легче, с кем-то посложнее.
Обещаю, перечитать эту статью и как минимум внести указанные вами исправления. :) Еще, чем больше практики, тем лучше получается. Так что, надеюсь, что переводы следующих частей будут более успешными.
Вопрос-то ведь не в оспаривании чьих-то подходов и методов, в том, как выбрать метод, соответствующий конкретной ситуации.
Анонс следующих статей из этой серии (предварительный перевод названий):
На мой взгляд очень спорное утверждение. Практически каждое слово можно оспорить. И то, что интуиция для аналитика зло. И то, что аналитик - по сути психолог. И то, аналитик должен быть зеркалом...
Но ведь кто-то же платит зарплату проектировщику. И этот кто-то &mdsh; явно не конечные пользователи. Поэтому &mdsh; первый критерий, является более приоритетным, хотя бы потому, что если начальник направит проект на редизайн, то до пользователей дойдет совсем немного из задуманного.
Да, в реальных проектах именно так и происходит. У вице-президента могут быть собственные взгляды на продукт, которые он не разглашает проектной команде, архитектор может испытывать личную неприязнь к менеджеру продукта...
Несколько слов о моих мотивах перевода этой статьи, предыдущей статьи Якоба Нильсена и еще серии статей, которые я перевожу в данный момент.
Вопрос здесь не стоит о целесообразности исследований. Вопрос в методах, в том, как правильно подобрать набор используемых методов и подходов для каждой конкретной ситуации. Пользоваться ли дорогими или дешевыми методами, проводить инспекцию или пользовательское тестирование, получать качественные или количественные результаты, тестировать традиционным методом или с активным вмешательством, тестировать детальный или бумажный прототип... Вопрос в том, что приоритетнее исследования или проктирование...
Меня два года учили применять "правильные" методы юзабилити исследования, потом три года я работаю в ситуации, когда возможности применения традиционных юзабилити методов ограничены, но я вижу, что за счет применения методов "альтернативных" традиционным можно достичь приемлимых результатов. Я работаю над собственным арсеналом используемых методов и ищу то, что будет работать в моей конкретной ситуации.
Я говорю об одной простейшей стратегии: "Чем больше(выше, быстрее, сильнее, дороже...) — тем лучше." Работает в чем-то почти на всех.
Немного расскажу об истории User Experience. Через несколько лет (конец 90-х, начало этого века) после появления философии user-centered design, люди котрые практиковали этот подход заметили его ограниченность. Ограниченность заключалась в ортодоксальном следовании подходу, центрировании на пользователе, его нуждах, в том, что потребности пользователя ставились выше бизнес и технологических нужд и потребностей. От этого возникали проблемы с коллегами других специальностей, участвующих в проекте. Более того, такой подход негативно сказывался на образе всей дисциплины. Требовался более сбаланисрованный подход, который бы учитывал интересы не только пользователей, но и разработчиков, и хозяев продукта. Первой моделью была "трехногая табуретка" Дональда Нормана, потом появились более продвинутые модели.
Другим фактором была сама специфика работы, когда специалистам приходилось работать не только с интерфейсами, но понемногу заниматься и другими смежными областями: графическим и информационным дизайном, работой с текстом, бизнес-анализом,...
Похоже, что вы или не знакомы с понятием User Experience или немного отстаете от последних тенденций. Года 3-4 назад, люди пришли к пониманию Umbrella User Experience — тоесть того, что успех продукта у пользователя — дело совместных усилий всех, занятых в проектировании, разработке и продвижении. Где тонко, там и рвется. Если контент слаб, то весьма возможно, что именно это и станет причиной будущей неудачи продукта. А вы говорите, что это задача для людей, которые пишут тексты... Про "Юзабилити Текстов" ничего не слышали?
Так и должно быть. Есть несколько критериев успеха:
хочу, чтобы этим пользовалось максимальное количество людей, для кого этот Продукт предназначен???
Это вообще от кого вопрос и к кому?
Пожалуйста, не касайтесь темы ROI, если вам нечего об этом сказать. Тема очень скользкая.
Не все, но многие, скорее всего — большинство, если финансы позволяют. Покупают то, что не совсем нужно. Возьмем тот же пример с телефоном: вы выбрали модель, а вам говорят, что точно такая же, но с радио будет на 10$ дороже, с плеером - на 20$, с камерой - на ..., с дополнительной памятью - ... И очень многие будут готовы немного доплатить именно "про запас", мало кто готов покапать модель с минимальными характеристиками.
Про список функциональности. Про Nero. А зачем вы вообще покупали Nero? Могли бы воспользоваться Open Source аналогом? Как разработчикам продать новую версию, почему пользователи должны её покупать, а не продолжать пользоваться старой? Это достигается в большинстве своем именно за счет увеличения функциональности, даже термин такой есть creeping featurism. :)
Разве юзабилити делают?
Большое спасибо за совет.