Юрий Ветров. Управление проектами и проектирование интерфейсов

Давно известна польза от меньшего количества кликов в интерфейсе. Резать ненужные взаимодействия и упрощать оставшиеся — одно из самых приятных занятий при проектировании. Не всегда получается сделать это сразу, но после нескольких ревью и обсуждений получившегося интерфейса приходит просветление. Хотя бывает, что сперва психологически сложно спроектировать функциональность в упрощенном виде. И только взгляд через некоторое время дает отнестись к урезанию легче.

Читайте продолжение истории →

Сценарии взаимодействия или использования — отличная связка внешних (схемы страниц и визуальный дизайн) и внутренних спецификаций (техническое задание и вспомогательные документы). Они описывают, как и какие функции системы должны работать, чтобы интерфейс воспринимался целостным и логичным. Я собирался написать длинный материал о подходах к написанию таких сценариев, но после новогодней паузы осилить такой объем непросто. Так что для начала — нулевая часть этой тройной статьи, которая выйдет на следующей неделе. И мне раскачаться, и вам убедиться что блог не умер.

Читайте продолжение истории →

Перед новым годом идет плотный поток сдающихся проектов, так что написать что-то интересное никак не успеть. Да и читать сейчас особо некому — все заняты примерно тем же самым. Так что просто сделаю несколько анонсов, а свежие материалы начнутся уже после 14 января.

Читайте продолжение истории →

Ключевая деятельность моего отдела в компании Artics — проектирование пользовательских интерфейсов. В основном это веб-технологии — веб-приложения, порталы, интранет-сайты, веб2.0-сервисы и т.п. Сам по себе процесс проектирования достаточно обширный — и по количеству этапов, и по тем факторам, что учитываются в его ходе, и по используемым инструментам. Многое из этого я описывал в своем блоге. А для IdeaBlog составил обзор всего процесса и его особенностей.

Читайте продолжение истории →

В большинстве случаев мы делаем как раз цветной прототип (я уже писал про классификацию и два основных пути их создания). По сути, это обычная верстка HTML-шаблонов страниц на основе визуального дизайна, включающая в себя JavaScript-взаимодействия. Разница в том, что эти шаблоны еще много раз поменяются и дополнятся.

Читайте продолжение истории →

В первой части материала я расписал цели создания интерактивного прототипа. Теперь расскажу о процессе работы над ним в нашей компании. Работа над интерактивным прототипом начинается после того как спроектированы схемы страниц (wireframes) и отрисован их визуальный дизайн. Процесс в среднем длится пару недель, после чего начинается его самостоятельное плавание. Модель интерфейса изучают и комментируют заказчик, пользователи и разработчики.

Читайте продолжение истории →

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

Тему про особенности итерационной разработки я со временем собирался продолжить. Во-первых, мы в компании выстраиваем гибкий процесс ведения проектов — и я позже напишу об общей сути этого процесса. Во-вторых, в ходе текущей работы решаются множество рабочих моментов, которые обусловлены итеративностью. Ну а недавно появилось и в-третих — плотная дискуссия по поводу последнего материала блога о проектировании системы управления проектами PMC. Которая как раз запускалась в несколько очередей. А многие авторы комментариев забыли о контексте их запуска.

Читайте продолжение истории →

Одним из самых плотных по вовлечению и продолжительности проектов был для меня Project Management Center. Те полгода активных обсуждений, аналитики, проектирования и экспериментов помогли создать мощную базу наработок для всего процесса работы над интерфейсами. Все это в условиях двойного давления по времени — компании нужно было как можно скорее запустить новую версию системы, а мне — не затянуть давно запланированный переезд в Питер.

Читайте продолжение истории →

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

Читайте продолжение истории →