Менеджер проекта: как дружить с дизайнером и не потерять клиента (или инвестора)

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

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

Первые макеты, полученные от дизайнера выявили первые проблемы. Я не слишком люблю неконтрастные решения в пастельных тонах. Хотя как раз клиентам они оказались по вкусу. Я не люблю примитив, мне все время чего-то не хватало, какой-то фишки, какого-то собственного лица.

Но это было вовсе не главным. Главным оказалось то, что мои задумки по дизайну были слишком конкретными. Я хотел конкретную модель взаимодействия с пользователем, далекую от идеала, просто привычную мне.

Оказалось, что я не умею делать технические задания, на основании которых мог бы получить ожидаемый результат. Удивительно. Я легко перегружал ТЗ деталями, но не уделял внимания главному. Что именно пользователю нужно сделать и в каком порядке.

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

Я все еще не умею составлять техническое задание, которое дизайнер сможет прочитать с первого раза, понять и не переплеваться. Но я уже начинаю понимать, за что стоит себя бить по рукам и для чего бить себя палкой пониже спины.

Вот примерно такие выводы сложились за последний год.

1. Начинать нужно с понимания пользователя и его окружения, в котором ему придется работать. Если это приложение для мобильного телефона, нужно понимать, в каком случае пользователь достанет телефон и в каких условиях он это сделает. Понимая окружение можно избежать многих штампов проектирования «от архитектуры»

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

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

4. Лучше всего не пытаться сразу смоделировать некий общий интерфейс. Но описывая вложенность контекстов мы даем дизайнеру хорошую основу для проектирования. Результат получается более зрелым и менее перегруженным привычными шаблонами

5. Неплохо иметь представление о приложениях, которые нравятся эстетически или функционально, но бывает крайне трудно выразить, что именно нравится. Лучше сразу заложить время на несколько итераций, пока сложится именно то, что хочется.

6. Скорее всего, лучший дизайн сложится не с первого раза. Он сложится, скорее всего, с неизвестного раза. Причем, когда он сложится, он все еще не будет казаться лучшим. Еще будет несколько попыток, пока придет осознание.

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

Я довольно начинающий менеджер для проектов, в которых не используется готовая платформа с жестким оформлением. Мне впервые приходится увязывать между собой сотни потенциальных пользователей, дизайнера, веб-разработчика, разработчика сервисов и базы данных. Ну, если точнее, «повторно». Первый проект уже пройден к финишной прямой и первые уроки усвоены.

Надеюсь, выводы окажутся полезными начинающим и продолжающим менеджерам в том, чего ожидать от общения с впервые нанятым дизайнером и начинающей складываться командой разработчиков.
Share post

Comments 8

    +2
    Не так давно прочел книгу: «Алан Купер об интерфейсе. Основы проектирования взаимодействия» (ISBN 978-5-93286-132-5, 978- 0-470-08411-3;). Примерно 700 страниц о том, о чем вы тут написали. Очень рекомендую, книжка поможет разобраться в том, что же такое интерфейс, что такое взаимодействие, что такое ментальная модель, и чего собственно хочет пользователь. Понимая это, и ещё кучу вещей, вы легко определите границу компетенции дизайнера, заказчика и проектировщика (т.е. свою), и сможете концентрироваться в ТЗ на тех вещах, которые действительно важны. Книгу можно купить за рубль на буксах, была ссылка на хабре на акцию, она ещё действует.
      0
      А можно чуть более понятным языком — какой именно сайт, ссылку на акцию?
        +2
        Коль настаиваете: books.ru :) Просто негоже рекламу писать первым комментом… хотя на таких условиях, какая к черту реклама!
          0
          Спасибо за ссылку, почитаю.
        0
        Спасибо за комментарий и наводку на книгу. Я про нее слышал, но найти пока не сподобился. Теперь купил, читаю.
        +1
        Запомнил формулировку «ложное согласие».
          0
          Частая проблема менеджеров в том, что они хотят сделать так, как хочет клиент. А не так, как будет лучше для пользователей.
            0
            Ну, вообще вопрос клиента, заказчика, пользователя — довольно запутан. Есть проект, где подрядчик делает что-то для заказчика, не имея контакта ни с клиентом (тем, кто платит за продукт), ни с пользователем (тем, кто использует продукт в интересах клиента). Я бывал в разных позициях. Как клиент, могу сказать, что далеко не все интересы пользователя я готов удовлетворять за свой счет. Если меня интересует определенный функционал, меня может мало волновать мнение пользователя (моего сотрудника) о том, насколько ему хочется этот функционал использовать (ему может быть вообще не хочется эту работу делать)

            Поэтому не проблема, а задача менеджера проекта, понимать, кто клиент и за что он платит деньги, что должен делать пользователь и в каком случае его нужно слушать, а в каком — отправлять к руководителю за взбучкой. Если же я подрядчик, у меня есть заказчик, который заказывает систему, представляя для меня и клиента, и пользователя, то тут, конечно же, от меня требуется, прежде всего, правильное взаимодействие с заказчиком (т.е. полезные советы, хорошая исполнительность и документальная защищенность от произвола)

          Only users with full accounts can post comments. Log in, please.