Мы решили не усложнять интерфейс и разработали новый подход к навигации по сложной иерархии функций, в которой зачастую таятся проблемы с производительностью. В результате первый выпуск TrueTime принёс нам премию «Best of Show», присуждаемую журналом Comdex/Byte Magazine. Основным фактором успеха была концентрация усилий команды на решении определённых задач.
• Точность
Одна из самых серьёзных проблем при разработке программы — переделки по причине многократных изменений конструкции и реализации пользовательского интерфейса. Чтобы уложиться в сроки, нужно исключить крупные переделки. Хотя получить совершенный продукт с первого раза практически невозможно, надо как можно раньше скомпоновать основные элементы пользовательского интерфейса. Мелкие изменения вполне допустимы, но большие изменения могут привести к катастрофическим последствиям, негативно отражаясь на времени разработки, качестве продукта и документации.
• Планирование
Нельзя составить точный план, не зная структуры пользовательского интерфейса. Если интерфейс будет изменяться по ходу цикла разработки, то в план проекта также придётся вносить соответствующие изменения. Кроме того, необходимо предохранять план от перенапряжения , которое возникает, когда работа тестировщиков и технических писателей сдерживается изменениями пользовательского интерфейса. Таким образом, перенапряжение плана ведёт к задержке работы над проектом в целом. Помните: следует вести работу над всеми частями проекта в параллели с разработкой программы. Планирование требует чёткого понимания структуры пользовательского интерфейса уже в начале работы над проектом.
• Документация
Вам обязательно понадобится документация, описывающая работу с программой. Очевидно, что документация тесно связана с интерфейсом программы. Команда технических писателей должна быть в курсе проблем, с которыми предстоит столкнуться пользователям, а также знать, как их решить с помощью программы. Если интерфейс не довести до ума в начале работы над проектом, техническим писателям придётся постоянно нагонять разработчиков, что сделает их параллельную работу невозможной.
• Тестирование
Тестирование программы также сильно зависит от её интерфейса. Традиционно тестировщики просят разработчиков предоставить им подробные спецификации функций программы, точно описывающие все особенности её работы. К сожалению, полностью описать пользовательский интерфейс, особенно современный, практически невозможно. Лучшая замена описанию — прототип. Если предоставить тестировщикам прототип интерфейса, то, ознакомившись с программой и разобравшись в основах и принципах работы её функций, предназначенных для конечных пользователей, они смогут улучшить разработанные ими планы тестирования. Это не значит, что описание функций не имеет значения или можно пренебречь им, просто я хочу подчеркнуть, что прототип — один из лучших способов демонстрации особенностей продукта. Обладая прототипом пользовательского интерфейса, тестировщики смогут изучить продукт вдоль и поперёк, а разобравшись в работе функций программы, команда сможет подготовить лучшие планы тестов и испытаний до окончания разработки программы.
Создание прототипа
Возможно, дочитав до этого места, вы спросите: «Все это здорово, но как создать прототип?» Подход к созданию прототипов пользовательского интерфейса, который исповедует NuMega, основан на трёх простых принципах. Сначала мы определяем наиболее важные задачи, которые приходится решать пользователям. Затем мы быстро моделируем эти задачи на ранних стадиях работы над проектом, ещё до подготовки плана проекта в окончательном виде: это увеличивает шансы правильно оценить объём предстоящей работы. Наконец, мы очень быстро доводим прототип, внося в него ряд последовательных изменений, демонстрируя как внутренние, так и внешние его особенности. Такой подход позволяет тестировать прототип вместе с пользователями. Возможность быстрой доработки прототипа — ключевой фактор успеха, позволяющий как можно раньше привести его к окончательному виду.
Решив эти задачи, команда получит прототип пользовательского интерфейса, понятный всем её участникам ещё до создания самой программы. Только подумайте, какое значение это имеет для проекта: разработчики, тестировщики, технические писатели — короче, все получат чёткое представление о внешнем виде программы даже раньше, чем она будет создана. Представьте, насколько возрастёт эффективность и производительность труда каждого участника команды благодаря прототипу пользовательского интерфейса. Кроме того, администраторы, менеджеры по продукции, работники из отделов сбыта и технической поддержки смогут «увидеть» программу раньше, чем она появится на свет. Это поможет устранить равнодушное отношение к проекту, создать уверенность в его успехе и предвидеть возможные проблемы — в общем, создать особую атмосферу работы с высокими технологиями, направляющую усилия всех участников проекта в единое русло. И не будем забывать о самом важном: чем раньше будет протестирован интерфейс, тем больше шансов на то, что получится хороший продукт, так как тогда множество людей смогут познакомиться с программой и опробовать её прежде, чем она будет написана.
Хотя описанный сценарий очень похож на идеал, его можно реализовать при наличии соответствующих усилий и навыков. Давайте познакомимся с каждым из трёх этапов этого сценария поближе.
Определение ключевых задач
На первом этапе создания пользовательского интерфейса нужно определить самые важные задачи, которые потребуется решать пользователям. Число задач может варьироваться в зависимости от сложности продукта; попробуйте выделить хотя бы следующие категории:
• Задачи, которые скорее всего придётся решать новым пользователям программы
Здесь надо понять потребности новичков и сделать так, чтобы они как можно скорее преуспели в решении своих проблем с помощью вашей программы. Программа должна вызывать у пользователей не ощущение беспомощности, а стимулировать их к дальнейшей работе с ней. Если известен набор вероятных действий пользователя, то можно оптимизировать интерфейс под их потребности.
• Задачи, которые чаще всего решают постоянные пользователи программы
Нужно постараться не разочаровать постоянных пользователей, безошибочно определив их ключевые задачи. Успех здесь даёт замечательный шанс удовлетворить потребности пользователей на долгое время. Соответственно следует сосредоточить основное внимание команды разработчиков на этих задачах, которые нужно максимально обогатить полезными возможностями, качественно реализовать и хорошо описать в документации.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73
• Точность
Одна из самых серьёзных проблем при разработке программы — переделки по причине многократных изменений конструкции и реализации пользовательского интерфейса. Чтобы уложиться в сроки, нужно исключить крупные переделки. Хотя получить совершенный продукт с первого раза практически невозможно, надо как можно раньше скомпоновать основные элементы пользовательского интерфейса. Мелкие изменения вполне допустимы, но большие изменения могут привести к катастрофическим последствиям, негативно отражаясь на времени разработки, качестве продукта и документации.
• Планирование
Нельзя составить точный план, не зная структуры пользовательского интерфейса. Если интерфейс будет изменяться по ходу цикла разработки, то в план проекта также придётся вносить соответствующие изменения. Кроме того, необходимо предохранять план от перенапряжения , которое возникает, когда работа тестировщиков и технических писателей сдерживается изменениями пользовательского интерфейса. Таким образом, перенапряжение плана ведёт к задержке работы над проектом в целом. Помните: следует вести работу над всеми частями проекта в параллели с разработкой программы. Планирование требует чёткого понимания структуры пользовательского интерфейса уже в начале работы над проектом.
• Документация
Вам обязательно понадобится документация, описывающая работу с программой. Очевидно, что документация тесно связана с интерфейсом программы. Команда технических писателей должна быть в курсе проблем, с которыми предстоит столкнуться пользователям, а также знать, как их решить с помощью программы. Если интерфейс не довести до ума в начале работы над проектом, техническим писателям придётся постоянно нагонять разработчиков, что сделает их параллельную работу невозможной.
• Тестирование
Тестирование программы также сильно зависит от её интерфейса. Традиционно тестировщики просят разработчиков предоставить им подробные спецификации функций программы, точно описывающие все особенности её работы. К сожалению, полностью описать пользовательский интерфейс, особенно современный, практически невозможно. Лучшая замена описанию — прототип. Если предоставить тестировщикам прототип интерфейса, то, ознакомившись с программой и разобравшись в основах и принципах работы её функций, предназначенных для конечных пользователей, они смогут улучшить разработанные ими планы тестирования. Это не значит, что описание функций не имеет значения или можно пренебречь им, просто я хочу подчеркнуть, что прототип — один из лучших способов демонстрации особенностей продукта. Обладая прототипом пользовательского интерфейса, тестировщики смогут изучить продукт вдоль и поперёк, а разобравшись в работе функций программы, команда сможет подготовить лучшие планы тестов и испытаний до окончания разработки программы.
Создание прототипа
Возможно, дочитав до этого места, вы спросите: «Все это здорово, но как создать прототип?» Подход к созданию прототипов пользовательского интерфейса, который исповедует NuMega, основан на трёх простых принципах. Сначала мы определяем наиболее важные задачи, которые приходится решать пользователям. Затем мы быстро моделируем эти задачи на ранних стадиях работы над проектом, ещё до подготовки плана проекта в окончательном виде: это увеличивает шансы правильно оценить объём предстоящей работы. Наконец, мы очень быстро доводим прототип, внося в него ряд последовательных изменений, демонстрируя как внутренние, так и внешние его особенности. Такой подход позволяет тестировать прототип вместе с пользователями. Возможность быстрой доработки прототипа — ключевой фактор успеха, позволяющий как можно раньше привести его к окончательному виду.
Решив эти задачи, команда получит прототип пользовательского интерфейса, понятный всем её участникам ещё до создания самой программы. Только подумайте, какое значение это имеет для проекта: разработчики, тестировщики, технические писатели — короче, все получат чёткое представление о внешнем виде программы даже раньше, чем она будет создана. Представьте, насколько возрастёт эффективность и производительность труда каждого участника команды благодаря прототипу пользовательского интерфейса. Кроме того, администраторы, менеджеры по продукции, работники из отделов сбыта и технической поддержки смогут «увидеть» программу раньше, чем она появится на свет. Это поможет устранить равнодушное отношение к проекту, создать уверенность в его успехе и предвидеть возможные проблемы — в общем, создать особую атмосферу работы с высокими технологиями, направляющую усилия всех участников проекта в единое русло. И не будем забывать о самом важном: чем раньше будет протестирован интерфейс, тем больше шансов на то, что получится хороший продукт, так как тогда множество людей смогут познакомиться с программой и опробовать её прежде, чем она будет написана.
Хотя описанный сценарий очень похож на идеал, его можно реализовать при наличии соответствующих усилий и навыков. Давайте познакомимся с каждым из трёх этапов этого сценария поближе.
Определение ключевых задач
На первом этапе создания пользовательского интерфейса нужно определить самые важные задачи, которые потребуется решать пользователям. Число задач может варьироваться в зависимости от сложности продукта; попробуйте выделить хотя бы следующие категории:
• Задачи, которые скорее всего придётся решать новым пользователям программы
Здесь надо понять потребности новичков и сделать так, чтобы они как можно скорее преуспели в решении своих проблем с помощью вашей программы. Программа должна вызывать у пользователей не ощущение беспомощности, а стимулировать их к дальнейшей работе с ней. Если известен набор вероятных действий пользователя, то можно оптимизировать интерфейс под их потребности.
• Задачи, которые чаще всего решают постоянные пользователи программы
Нужно постараться не разочаровать постоянных пользователей, безошибочно определив их ключевые задачи. Успех здесь даёт замечательный шанс удовлетворить потребности пользователей на долгое время. Соответственно следует сосредоточить основное внимание команды разработчиков на этих задачах, которые нужно максимально обогатить полезными возможностями, качественно реализовать и хорошо описать в документации.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73