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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Автор: realbtr

Источник