Comments 30
Клиентам, увы, донести такие мысли порой нереально…
В своей практике регулярно сталкиваюсь с ситуациями, когда хорошее, продуманное и удобное решение запарывается, а шлак из не-пойми-чего, но выглядящий как яркая картинка (через определенный срок боданий и когда уже просто сдаешься) проходит «на ура».
И как не говори, что и картинка безвкусная, и неудобно это вовсе, и что плеваться будут — нет, не доходит. Нравится и все тут.
В своей практике регулярно сталкиваюсь с ситуациями, когда хорошее, продуманное и удобное решение запарывается, а шлак из не-пойми-чего, но выглядящий как яркая картинка (через определенный срок боданий и когда уже просто сдаешься) проходит «на ура».
И как не говори, что и картинка безвкусная, и неудобно это вовсе, и что плеваться будут — нет, не доходит. Нравится и все тут.
UFO just landed and posted this here
Знаете что самое печальное? Это, как вы выразились, быдло, порой бывает маркетологами/директорами крупных холдингов. Вот как раз сейчас с такими «работаем»…
Моя практика показывает, что вменяемость клиентов растет пропорционально стоимости проекта. Когда за проект приходится платить много — людям уже страшно лезть со своими замечаниями, ибо деньги уплочены. Хотя даже в такой ситуации бывают исключения.
Логично, если продавать свои услуги дешевле, чем их продает клиент — то ваш клиент будет считать быдлом вас (ну или чернорабочими), и соответственно будут считать себя умнее вас, что бы вы не говорили.
Т.е. если работу делать дешево, то клиент считает, что вы делаете грязную работу о которую он сам просто не хочет мараться. В данном случае насаждение своего мнения клиентом будет казаться ему вполне оправданным.
Т.е. если работу делать дешево, то клиент считает, что вы делаете грязную работу о которую он сам просто не хочет мараться. В данном случае насаждение своего мнения клиентом будет казаться ему вполне оправданным.
А вы не пробовали использовать метод Алана Купера?
Почитайте его «Психбольницу в руках пациента».
Я вот попробовал и дико рад.
Любое интерфейсное решение можно легко аргументировать задачами ключевого персонажа, вкусы ЛПР (лица, принимающего решения) становятся просто бессильны против очевидных вещей. Иначе просто вся ответственность за неуспех ложится на конкретное и сразу явное решение ЛПР, в чем эти лица обычно не заинтересованны.
Почитайте его «Психбольницу в руках пациента».
Я вот попробовал и дико рад.
Любое интерфейсное решение можно легко аргументировать задачами ключевого персонажа, вкусы ЛПР (лица, принимающего решения) становятся просто бессильны против очевидных вещей. Иначе просто вся ответственность за неуспех ложится на конкретное и сразу явное решение ЛПР, в чем эти лица обычно не заинтересованны.
«Нам не важно, понравится это пользователям или нет — главное, чтобы понравилось нам», «Не спорьте! Делайте, что вам говорят», «Если вы не нарисуете то, что нам понравится — то мы подадим на вас в суд и отсудим все деньги»
Бывают и такие клиенты, на которых никакие разумные доводы не действуют. Зато они чуть ли не лопаются от ЧСВ.
Бывают и такие клиенты, на которых никакие разумные доводы не действуют. Зато они чуть ли не лопаются от ЧСВ.
Бывает.
Но во-первых, если вы утвердите и согласуете персонажа, то 2 и 3 фразу клиент просто не сможет вам сказать. Потому что оценивать работу будет не клиент, а персонаж (клиент должен об этом знать и понимать, если вы согласуете)
А во-вторых, иногда следует и правда включать самого клиента в ключевые персонажи. Например, так:
-Его цель — получить красивый и модный дизайн.
-Он смотрит поверхностно, не вникая в функционал системы.
Можно для такого персонажа нарисовать красивую картинку на главную страницу, например. А все остальное — для реальных пользователей.
Надо будет только делать так, чтобы задачи клиента и пользователя не мешали друг другу.
Но во-первых, если вы утвердите и согласуете персонажа, то 2 и 3 фразу клиент просто не сможет вам сказать. Потому что оценивать работу будет не клиент, а персонаж (клиент должен об этом знать и понимать, если вы согласуете)
А во-вторых, иногда следует и правда включать самого клиента в ключевые персонажи. Например, так:
-Его цель — получить красивый и модный дизайн.
-Он смотрит поверхностно, не вникая в функционал системы.
Можно для такого персонажа нарисовать красивую картинку на главную страницу, например. А все остальное — для реальных пользователей.
Надо будет только делать так, чтобы задачи клиента и пользователя не мешали друг другу.
А попробуйте сказать заказчику в глаза: «Вы — быдло».
Вы сразу почувствуете эффективность этого маркетингового шага.
Если не ошибаюсь, это бизнес.
И мерило успешности этого бизнеса — не гениальный мегаюзабельный GUI, а _проданный_ гениальный мегаюзабельный GUI.
Стало быть, мало создать продукт, безупречный с точки зрения юзабилити, дизайна и программинга.
Надо ещё слегка поработать с заказчиком.
В том числе — над его культурой.
И над его компетентностью в сферах, от которых зависит успех вашего бизнеса.
В том числе — понимая его потребности и желания и причины этих потребностей и желаний.
В том числе — формируя эти потребности и желания.
В том числе — относясь к заказчику, как к партнёру, а не как к быдлу.
Вы сразу почувствуете эффективность этого маркетингового шага.
Если не ошибаюсь, это бизнес.
И мерило успешности этого бизнеса — не гениальный мегаюзабельный GUI, а _проданный_ гениальный мегаюзабельный GUI.
Стало быть, мало создать продукт, безупречный с точки зрения юзабилити, дизайна и программинга.
Надо ещё слегка поработать с заказчиком.
В том числе — над его культурой.
И над его компетентностью в сферах, от которых зависит успех вашего бизнеса.
В том числе — понимая его потребности и желания и причины этих потребностей и желаний.
В том числе — формируя эти потребности и желания.
В том числе — относясь к заказчику, как к партнёру, а не как к быдлу.
Всё сказанное очень верно, хоть и не очень ново.
Единственное, наверно стоит отметить, что визуальные шаблоны сами по себе уже должны базироваться на определённом понимании пользователя, его опыте и привычках. Это важно для целевых проектов (к примеру, систем бухгалтерской отчётности) и позволяет обеспечить интуитивное, без этапа адаптации, взаимодействие.
Единственное, наверно стоит отметить, что визуальные шаблоны сами по себе уже должны базироваться на определённом понимании пользователя, его опыте и привычках. Это важно для целевых проектов (к примеру, систем бухгалтерской отчётности) и позволяет обеспечить интуитивное, без этапа адаптации, взаимодействие.
Вот именно сейчас сижу и думаю над интерфейсом десктопной утилиты. Как бы все правильно организовать, разместить на форме, чтобы не было нагромождения элементов, и в то же время не надо было в случае необходимости лазать по дополнительным окнам, закладкам и вложенным меню.
Голова пухнет от такого
Голова пухнет от такого
Как я вас понимаю, я сейчас тоже занимаюсь улучшение интерфейса одной утилиты(for developers), поскольку у меня элементов будет не много, я стараюсь сделать максимально простой и понятный интерфейс, без диалоговых окно(!) и чтобы можно было комфортно работать без мышки, это для первой версии утилиты, а там дальше видно будет ;)
Могу предложить бесплатную консультацию от студии Айтроник.
Спасибо за статью, всё по делу.
Редко замечаю, но это бесит меня больше всего, что некоторые разработчики не знакомы с логическим маршрутом, как только у меня начинают бегать глаза в поисках нужного мне элемента и я его не нахожу прибл. за 3 сек., то забываю о таких сервисах или программах очень легко и быстро.
Редко замечаю, но это бесит меня больше всего, что некоторые разработчики не знакомы с логическим маршрутом, как только у меня начинают бегать глаза в поисках нужного мне элемента и я его не нахожу прибл. за 3 сек., то забываю о таких сервисах или программах очень легко и быстро.
Самое важное вы тут очень слабо выявили.
Главное — не какие-то шаблоны интерфейса, логический маршрут и прочее. Все это лишь средства, они не могут быть главным.
Вы не сможете доказать ваше интерфейсное решение директору, (скажем), если будете аргументировать его какими-то правилами юзабилити и GUI. Все ваши аргументы будут сводиться к вашему авторитету профи, который естественным образом ниже директора.
Главное — это достижение целей пользователей.
Именно целей, так как они обычно состоят из группы задач. Если решать просто задачи, это приведет к малосвязному набору функций, каждая из которых решает свою задачу. Цель-же подразумевает сценарий, состоящий из последовательности этих задач, таким образом, задачи становятся связанными одной последовательностью.
Если вы смоделируете персонажа, максимально реального человека, для которого вы делаете интерфейс, утвердите его со всей группой разработки, то цели этого персонажа будут бесспорным аргументом.
Главное — не какие-то шаблоны интерфейса, логический маршрут и прочее. Все это лишь средства, они не могут быть главным.
Вы не сможете доказать ваше интерфейсное решение директору, (скажем), если будете аргументировать его какими-то правилами юзабилити и GUI. Все ваши аргументы будут сводиться к вашему авторитету профи, который естественным образом ниже директора.
Главное — это достижение целей пользователей.
Именно целей, так как они обычно состоят из группы задач. Если решать просто задачи, это приведет к малосвязному набору функций, каждая из которых решает свою задачу. Цель-же подразумевает сценарий, состоящий из последовательности этих задач, таким образом, задачи становятся связанными одной последовательностью.
Если вы смоделируете персонажа, максимально реального человека, для которого вы делаете интерфейс, утвердите его со всей группой разработки, то цели этого персонажа будут бесспорным аргументом.
Отличный комментарий!
С заказчиком надо работать. Работать профессионально и всесторонне.
С заказчиком надо работать. Работать профессионально и всесторонне.
Вы предлагаете в статье про газораспределение в двигателе говорить про то, какие авто-бренды нравятся конечному покупателю? Понятно, что я образно).
Статья как раз и написана не про общение с заказчиком.
Статья как раз и написана не про общение с заказчиком.
Необходимо представить, (а лучше задокументировать, хотя бы для внутреннего пользования) какие будут основные сценарии его поведения
… клиентам мы тоже активно пытаемся донести все эти мысли (т.е. мысли статьи), но пока с переменным успехом. К сожалению, многие продолжают судить о работе дизайнеров по «количеству вываленной на экран краски», а не по смыслу и решенным задачам.
Необходимо не просто представить, а тщательно задокументировать ключевого персонажа, его цели, задачи и сценарии, причем это должно являться основным документом проверки интерфейса и донесения до клиента того, что важно, а что нет.
Если-же основываться на абстрактных принципах, которые клиенту ничего не стоят, естественно «успех будет переменным»
Клиенты часто не любят и не хотят читать, особенно объёмные тексты. Тут уже нужен другой талант или даже специалист по донесению сложной информации до клиента. А с этим совсем туго.
А кто сказал, что задокументировать значит составить большой объемный текст?
В идеале если вы найдете в каком-то фильме ваш сценарий, то показать этот кусок самое лучшее.
А вообще надо искать фотки, истории из жизни, вещи, окружающие моделируемого персонажа.
Да и кстати, читать хорошие тексты описания даже интереснее, чем худ. литературу, так как начинаешь видеть того, для кого ты сайт делаешь. Все равно что знакомишься с человеком.
В идеале если вы найдете в каком-то фильме ваш сценарий, то показать этот кусок самое лучшее.
А вообще надо искать фотки, истории из жизни, вещи, окружающие моделируемого персонажа.
Да и кстати, читать хорошие тексты описания даже интереснее, чем худ. литературу, так как начинаешь видеть того, для кого ты сайт делаешь. Все равно что знакомишься с человеком.
Системная документация просто по определению объёмная. Иначе неизбежно выяснится, что клиент из такого вычитал что-то своё и понял совершенно не то и не так, как разработчики.
Плюс нужно учесть, что самые эффективные интерфейсы часто самые сложные, требуют много времени на вдумчивое изучение. А клиенты часто находятся под влиянием других продуктов, из-за чего всякая зараза типа риббонов из MS OFFICE расползается повсюду, часто совершенно неоправданно. И вот составить нормальную компактную однозначную документацию по интерфейсу очень и очень сложно.
А сейчас ещё одну проблему вспомнил. Есть категория клиентов, которая считает итеративный процесс при разработке (то есть общение клиент-разработчик с последующим уточнением продукта) проявлением слабости и непрофессионализма. Кругом засада, короче. Уже даже кажется, что в штате должен быть специалист по общению с клиентами с двойным техническим и психологическим образованием.
Плюс нужно учесть, что самые эффективные интерфейсы часто самые сложные, требуют много времени на вдумчивое изучение. А клиенты часто находятся под влиянием других продуктов, из-за чего всякая зараза типа риббонов из MS OFFICE расползается повсюду, часто совершенно неоправданно. И вот составить нормальную компактную однозначную документацию по интерфейсу очень и очень сложно.
А сейчас ещё одну проблему вспомнил. Есть категория клиентов, которая считает итеративный процесс при разработке (то есть общение клиент-разработчик с последующим уточнением продукта) проявлением слабости и непрофессионализма. Кругом засада, короче. Уже даже кажется, что в штате должен быть специалист по общению с клиентами с двойным техническим и психологическим образованием.
Минимум общения — это один раз согласовать с клиентом персонажа, и все. Если возникнут какие-то проблемы, то это будет являться виной клиента, отказавшегося от итеративного процесса, а не вашей, «неправильно понявшего» клиента. Ведь персонаж-то останется доволен.
А документация персонажей может быть подана отдельно от системной. Купер, например, утверждает, что для них вообще отдельные документы должны быть.
А документация персонажей может быть подана отдельно от системной. Купер, например, утверждает, что для них вообще отдельные документы должны быть.
На моей практике, чтобы донести до клиента правильность и допустимость итеративного подхода, психолог использовался. Это ппц, но работает!
И для точности вашей аналогии вы все-таки тогда не о газораспределении говорите (чем очевидно занимаются программисты), а об экстерьере и эргономике.
> Основой визуального интерфейса
У вас логическая цепочка нарушена. Вы нигде (от топика до этого заголовка) не упомянули, что речь о графических интерфейсах.
От себя ещё добавлю, что прежде чем кидаться дизайнить GUI, подумайте хорошо, нужен ли он. Нет ничего хуже неинтерактивной программы с одним текстовым полем и одной кнопкой, которая ради этого рисует окно и требует лишних телодвижений с мышкой в руках.
У вас логическая цепочка нарушена. Вы нигде (от топика до этого заголовка) не упомянули, что речь о графических интерфейсах.
От себя ещё добавлю, что прежде чем кидаться дизайнить GUI, подумайте хорошо, нужен ли он. Нет ничего хуже неинтерактивной программы с одним текстовым полем и одной кнопкой, которая ради этого рисует окно и требует лишних телодвижений с мышкой в руках.
> клиентам мы тоже активно пытаемся донести все эти мысли, но пока с переменным успехом
А почему это (дизайн интерфейса) должно быть дискуссионным вопросом? Разве заказчик имеет какую-либо компетенцию, для того чтобы обсуждать этот вопрос?
А почему это (дизайн интерфейса) должно быть дискуссионным вопросом? Разве заказчик имеет какую-либо компетенцию, для того чтобы обсуждать этот вопрос?
Sign up to leave a comment.
Размышления об интерфейсах