А кто сказал, что задокументировать значит составить большой объемный текст?
В идеале если вы найдете в каком-то фильме ваш сценарий, то показать этот кусок самое лучшее.
А вообще надо искать фотки, истории из жизни, вещи, окружающие моделируемого персонажа.
Да и кстати, читать хорошие тексты описания даже интереснее, чем худ. литературу, так как начинаешь видеть того, для кого ты сайт делаешь. Все равно что знакомишься с человеком.
Бывает.
Но во-первых, если вы утвердите и согласуете персонажа, то 2 и 3 фразу клиент просто не сможет вам сказать. Потому что оценивать работу будет не клиент, а персонаж (клиент должен об этом знать и понимать, если вы согласуете)
А во-вторых, иногда следует и правда включать самого клиента в ключевые персонажи. Например, так:
-Его цель — получить красивый и модный дизайн.
-Он смотрит поверхностно, не вникая в функционал системы.
Можно для такого персонажа нарисовать красивую картинку на главную страницу, например. А все остальное — для реальных пользователей.
Надо будет только делать так, чтобы задачи клиента и пользователя не мешали друг другу.
Необходимо представить, (а лучше задокументировать, хотя бы для внутреннего пользования) какие будут основные сценарии его поведения
… клиентам мы тоже активно пытаемся донести все эти мысли (т.е. мысли статьи), но пока с переменным успехом. К сожалению, многие продолжают судить о работе дизайнеров по «количеству вываленной на экран краски», а не по смыслу и решенным задачам.
Необходимо не просто представить, а тщательно задокументировать ключевого персонажа, его цели, задачи и сценарии, причем это должно являться основным документом проверки интерфейса и донесения до клиента того, что важно, а что нет.
Если-же основываться на абстрактных принципах, которые клиенту ничего не стоят, естественно «успех будет переменным»
Самое важное вы тут очень слабо выявили.
Главное — не какие-то шаблоны интерфейса, логический маршрут и прочее. Все это лишь средства, они не могут быть главным.
Вы не сможете доказать ваше интерфейсное решение директору, (скажем), если будете аргументировать его какими-то правилами юзабилити и GUI. Все ваши аргументы будут сводиться к вашему авторитету профи, который естественным образом ниже директора.
Главное — это достижение целей пользователей.
Именно целей, так как они обычно состоят из группы задач. Если решать просто задачи, это приведет к малосвязному набору функций, каждая из которых решает свою задачу. Цель-же подразумевает сценарий, состоящий из последовательности этих задач, таким образом, задачи становятся связанными одной последовательностью.
Если вы смоделируете персонажа, максимально реального человека, для которого вы делаете интерфейс, утвердите его со всей группой разработки, то цели этого персонажа будут бесспорным аргументом.
А вы не пробовали использовать метод Алана Купера?
Почитайте его «Психбольницу в руках пациента».
Я вот попробовал и дико рад.
Любое интерфейсное решение можно легко аргументировать задачами ключевого персонажа, вкусы ЛПР (лица, принимающего решения) становятся просто бессильны против очевидных вещей. Иначе просто вся ответственность за неуспех ложится на конкретное и сразу явное решение ЛПР, в чем эти лица обычно не заинтересованны.
Могу только догадываться, что психологический эффект отзывчивости перевешивает надобность сортировки.
Честно говоря, даже не задумывался и не чувствовал неудобств до вашего комментария)
Я к тому, что почему бы не выработать критерии «удовлетворения», наравне с критериями «отказа»? Оценка заказа-то должна быть комплексной, а не просто «отсутствием негатива».
Например, если заказчик имеет техзадание и внятно пишет условия сотрудничества, и т. п.
Иначе получается, что заказчик не должен говорить лишних слов, и вообще пройти тест на «достойность».
Работа в реальном времени — очень здорово, очень понравилось.
Но позвольте немного критики.
1. «Выбрать категории» и «выбрать биржи» — всплывающие окна, бррр. Зачем вы притянули в веб устаревшую идиому? Сделайте их выпадающими, это же так просто на jQuery.
2. Курсив для чтения сложноват, особенно на разных фонах, почему не сделать регулярный?
3. Непонятно, исходя из чего вы решили делать собственный паттерн интерфейса? Вроде-бы сайт не резиновый, на мобильных устройствах не сожмешь эту левую колонку нормально, а на десктопе она ущербно узкая. Да и тут просто просится одна колонка всего, это же очевидно самое простое и поэтому самое лучшее решение.
4. Не понял, чем вы руководствовались, раскрашивая проекты в разные цвета? Одинаковый стиль списка и солиднее был-бы, и читабельнее, за счет постоянного контраста. Посмотрите пример аналогичного проекта, я считаю, один из лучших в плане интерфейса.
5. Почему бы не сделать поиск динамичным? Зачем лишние телодвижения, типа нажатия enter? Тут объем информации небольшой, актуально всего пару дней проектов, можно было-бы просто динамически фильтровать, как «все друзья» вконтакте.
6. Пользователям, поверьте, совершенно не нужна опция «выделять» при поиске. Смело фильтруйте, не задавая лишних вопросов. Функция «поиск» в любом браузере уже это делает.
7. Ссылки всегда открывайте в новом окне, не спрашивая.
В идеале если вы найдете в каком-то фильме ваш сценарий, то показать этот кусок самое лучшее.
А вообще надо искать фотки, истории из жизни, вещи, окружающие моделируемого персонажа.
Да и кстати, читать хорошие тексты описания даже интереснее, чем худ. литературу, так как начинаешь видеть того, для кого ты сайт делаешь. Все равно что знакомишься с человеком.
Но во-первых, если вы утвердите и согласуете персонажа, то 2 и 3 фразу клиент просто не сможет вам сказать. Потому что оценивать работу будет не клиент, а персонаж (клиент должен об этом знать и понимать, если вы согласуете)
А во-вторых, иногда следует и правда включать самого клиента в ключевые персонажи. Например, так:
-Его цель — получить красивый и модный дизайн.
-Он смотрит поверхностно, не вникая в функционал системы.
Можно для такого персонажа нарисовать красивую картинку на главную страницу, например. А все остальное — для реальных пользователей.
Надо будет только делать так, чтобы задачи клиента и пользователя не мешали друг другу.
Необходимо не просто представить, а тщательно задокументировать ключевого персонажа, его цели, задачи и сценарии, причем это должно являться основным документом проверки интерфейса и донесения до клиента того, что важно, а что нет.
Если-же основываться на абстрактных принципах, которые клиенту ничего не стоят, естественно «успех будет переменным»
Главное — не какие-то шаблоны интерфейса, логический маршрут и прочее. Все это лишь средства, они не могут быть главным.
Вы не сможете доказать ваше интерфейсное решение директору, (скажем), если будете аргументировать его какими-то правилами юзабилити и GUI. Все ваши аргументы будут сводиться к вашему авторитету профи, который естественным образом ниже директора.
Главное — это достижение целей пользователей.
Именно целей, так как они обычно состоят из группы задач. Если решать просто задачи, это приведет к малосвязному набору функций, каждая из которых решает свою задачу. Цель-же подразумевает сценарий, состоящий из последовательности этих задач, таким образом, задачи становятся связанными одной последовательностью.
Если вы смоделируете персонажа, максимально реального человека, для которого вы делаете интерфейс, утвердите его со всей группой разработки, то цели этого персонажа будут бесспорным аргументом.
Почитайте его «Психбольницу в руках пациента».
Я вот попробовал и дико рад.
Любое интерфейсное решение можно легко аргументировать задачами ключевого персонажа, вкусы ЛПР (лица, принимающего решения) становятся просто бессильны против очевидных вещей. Иначе просто вся ответственность за неуспех ложится на конкретное и сразу явное решение ЛПР, в чем эти лица обычно не заинтересованны.
Честно говоря, даже не задумывался и не чувствовал неудобств до вашего комментария)
Например, если заказчик имеет техзадание и внятно пишет условия сотрудничества, и т. п.
Иначе получается, что заказчик не должен говорить лишних слов, и вообще пройти тест на «достойность».
Но позвольте немного критики.
1. «Выбрать категории» и «выбрать биржи» — всплывающие окна, бррр. Зачем вы притянули в веб устаревшую идиому? Сделайте их выпадающими, это же так просто на jQuery.
2. Курсив для чтения сложноват, особенно на разных фонах, почему не сделать регулярный?
3. Непонятно, исходя из чего вы решили делать собственный паттерн интерфейса? Вроде-бы сайт не резиновый, на мобильных устройствах не сожмешь эту левую колонку нормально, а на десктопе она ущербно узкая. Да и тут просто просится одна колонка всего, это же очевидно самое простое и поэтому самое лучшее решение.
4. Не понял, чем вы руководствовались, раскрашивая проекты в разные цвета? Одинаковый стиль списка и солиднее был-бы, и читабельнее, за счет постоянного контраста. Посмотрите пример аналогичного проекта, я считаю, один из лучших в плане интерфейса.
5. Почему бы не сделать поиск динамичным? Зачем лишние телодвижения, типа нажатия enter? Тут объем информации небольшой, актуально всего пару дней проектов, можно было-бы просто динамически фильтровать, как «все друзья» вконтакте.
6. Пользователям, поверьте, совершенно не нужна опция «выделять» при поиске. Смело фильтруйте, не задавая лишних вопросов. Функция «поиск» в любом браузере уже это делает.
7. Ссылки всегда открывайте в новом окне, не спрашивая.