Разработка юзабилити проекта.

Разработка юзабилити проекта.

Разрабатывая новый проект, либо оптимизируя старый, необходимо чётко осознавать суть проекта. Основная сложность, это максимально упростить действия пользователя, при этом не сильно отходя от сложившихся стереотипов восприятия. Особенно это актуально при оптимизации работающего проекта. Зачастую, неаккуратно сделанная перепланировка навигации и логики в иерархии разделов ресурса может привести к тому, что мы потеряем часть постоянных пользователей.

Некоторые проекты, наоборот, требуют создания “окольного пути”, для предоставления информации лишь после просмотра определённых страниц и разделов.

Таким образом, мы получаем некую двойственность в этом вопросе. В частности, Алан Купер в своей книге “Психбольница в руках пациентов” выразил замечательную мысль: “Во всех других конструкторских дисциплинах инженеры создают стратегию, а ремесленники претворяют ее в жизнь.

Инженеры не занимаются строительством мостов, этим занимаются другие специалисты. Только в области программного обеспечения перед инженером ставится задача создать собственно продукт. Только в области программного обеспечения перед «строителем мостов» ставится задача определить, как следует создавать продукт. Только в области программного обеспечения эти две задачи решаются не последовательно, а одновременно. Однако компании, создающие программы, похоже, не осознают существования такой аномалии.

Инженерное дело и конструкторское дело так плотно пересекаются, что специалисты и руководители их не разделяют и, вероятно, не различают. Планированием любого рода здесь пренебрегают или откладывают его до тех пор, пока не станет слишком поздно. Считается нормальным откладывать решение очень сложных инженерных проблем до момента, когда уже экономически слишком накладно откатываться к фазе проектирования, потому что полным ходом пишется код для коммерческой версии продукта.”

И дело обстоит именно так. Когда вы проектируете проект, вам необходимо чётко осознавать что, зачем и почему вы делаете, при этом отрешившись от всего остального. Так же Вы не должны забывать для кого это делается, иначе вся работа пойдёт насмарку.

Идеальный юзабилист не должен разбираться в деталях графического дизайна и программирования, однако это, на сегодняшний день остаётся мечтой. Поэтому давайте определим этапы.

Для себя я вывел некоторую иерархию, которой и придерживаюсь, а именно:

  1. Берём результаты анализа проекта и собираем из них некоторое видение общей картины.
  2. Берём техническое задание и пытаемся его синхронизировать для себя с пунктом
  3. На основании пункта № 2 открываем визуальный редактор (в данном случае я пользуюсь “Axure RP Pro“) и начинаем создавать скелет проекта. Основное, что хотелось бы заметить – не старайтесь представить себе как это должно выглядеть в конечном итоге. Эту часть необходимо выполнить максимально удобно, фактически использовать “правило одного клика”. То есть для достижения определённой цели, пользователю должно быть достаточно сделать одно движение для достижения цели.
  4. Всегда анализируйте что и зачем вы сделали. Каждое ваше решение должно быть принято и обосновано приблизительно так как это сделано в разделе “Анализ готовых интерфейсов”
  5. Разрабатывая графическую часть проекта обратите внимание на акценты и их очерёдность. Это крайне важный момент, без которого можно загубить отличную идею, архитектуры сайта. Информацию нужно выдавать последовательно!
  6. Никогда не игнорируйте этап тестирования интерфейса! Если нет доступа к целевой аудитории – испытывайте на друзьях, знакомых, прохожих – на всех кого поймаете. При этом не принимайте их мнение, как верное. Ищите общее и исправляйте. Не доверяйте мнению профессионалов в штате заказчика. Их мнение искажено излишним профессионализмом, исключение может составлять только проект для профессионалов – они мыслят стереотипами и понимают друг друга с полуслова.

И напоследок, хочу закончить так же цитатой из вышеприведённой книги: “Сроки сдачи в некоторых проектах неразумны по причине произвольности. Рациональные руководители в большинстве своем по-прежнему склонны устанавливать сроки хотя и физически возможные, но возможные лишь ценой больших жертв. Пилот самолета, по аналогии, может заявить: «Успеем в Чикаго во время, но багаж придется выбросить!»

Мне приходилось видеть, как руководители разработки приносят в жертву не только проектирование, но и тестирование, применимость, функции, интеграцию, документацию и даже реальность. Большинство руководителей разработки продуктов, с которыми мне приходилось работать, предпочтут выбросить на рынок неработоспособный продукт, но не опоздать со сдачей этого продукта.”

Постарайтесь объяснить заказчику, что ваша постановка вопроса правильнее, хотя, предупреждаю сразу – если у вас это получится, вы рискуете остаться без заказа.

307
Комментарии (0)
  • Желаете ознакомиться с остальными комментариями или оставить свой? в сеть, чтобы получить полный доступ к функционалу Профессионалов.ru! Еще не участник сети?