- Я не встречал на этом пути этап «разработка интерфейса». Графический дизайнер делал макет, затем верстальщик его реализовывал (очень часто pixel perfect — пиксель-в-пиксель). А графический дизайнер мог быть отличным иллюстратором, но как же часто я при таком подходе видел огромные дыры в юзабилити.
- При pixel perfect дизайн получался не гибким (например, разрешения экранов — обычно брали 1280х1024 и 1920х1080, больше никаких). «Резиновая» верстка была уделом дорогих специалистов.
- Я всегда считал и считаю, что Фотошоп необходим для редактирования фотографий, а не для макетов. Для макетов подходят другие вещи, например, тот же Illustrator — векторная графика, на самом деле, отличная вещь.
Адаптивный дизайн
screensiz.es наглядно демонстрирует огромное количество touch-устройств и их разрешения экранов.
Да, мир изменился — здесь теперь не господствуют desktop с 1280x1024, в нем теперь есть огромное количество ноутбуков, но чего еще больше (субъективное мнение) — планшетов и смартфонов. Я не буду в этом посте рассказывать, почему сложилось именно так, ответ очевиден — большинству людей не нужны мощные рабочие станции, им достаточно планшетов и мобильных устройств для потребления контента.
Photoshop-way не особо подходит для такого мира — нужно делать несколько макетов, что весьма трудозатратно по времени и бюджету.
Развитие веба
Веб изменился, стал интереснее и сложнее домашних страничек, и весьма сложно этого не заметить. Пока Фотошоп предлагает лишь графический дизайн, в вебе появились как минимум анимации и прочие интерактивные вещи. Single page application туда же относятся — если правильно подойти к этой технологии, можно сделать удивительной отзывчивости и некой приятности интерфейс. Да, в фотошопе есть анимации, но вы же не будете, простите, писать на PHP работающие сервисы, а не небольшие скрипты, вы предпочтете Scala или какой-нибудь другой язык, потому что под каждую задачу нужен свой инструмент.
Решение проблемы
С учетом тех факторов, которые я написал выше, я предлагаю другой workflow разработки сервисов и интернет-проектов, который позволит сделать качественный и в то же время достаточно экономный по тратам бюджета конечный продукт.
На данный момент в мире процветает подход API first. На самом деле, он мне нравится, это весьма интересный подход, но и его можно улучшить.
Цикл разработки продукта
- Product manager собирает требования к функциональности, собирает полное ТЗ по проекту.
- UX Developer оценивает это ТЗ, предлагает свои улучшения — кому, как не человеку, который занимается интерфейсами, знать, как должен выглядеть конечный продукт. И, конечно же, делает прототипы — для этого годится Balsamiq, Axure, NinjaMock и другие сервисы и технологии.
- После нескольких итераций по обсуждению базовой функциональности получаем готовое ТЗ, которое идет для первой версии.
- Архитектор на основе этого ТЗ продумывает архитектуру сервиса, а верстальщик верстает макет финального прототипа с помощью фреймворков — Twitter Bootstrap, Foundation и тому подобное. Они экономят время, позволяя сосредоточиться на работе.
- …которую затем реализовывают backend-программисты с учетом подхода API first.
- Если API изначально было задокументированно, то параллельно с backend-программистами frontend-разработчики делают клиентскую часть, а графический дизайнер реализовывает конечный дизайн продукта (верстка-то готова уже).
А затем цикл повторяется в каждой итерации, улучшая функциональность. Как видите, такой подход позволяет сократить издержки и вот почему:
- Нет постоянного уточнения ТЗ, оно полностью готово и необходимо лишь ему следовать.
- Несколько команд работают одновременно:
- UX Developer и Product Manager обсуждают и формируют ТЗ
- Затем архитектор разрабатывает архитектуру, параллельно верстальщик верстает финальный прототип
- Backend-разработчики делают API, параллельно frontend-разработчики делают клиентскую часть. Иллюстратор (человек, не программа от Adobe) реализовывает графический дизайн сервиса.
Конечно, я не вдавался в огромное количество деталей (например, что UX Developer, по моему опыту, должен выработать гайдлайны по типографике, UI-части и т.п., с чем будет работать уже графический дизайнер), но в целом общую схему работы я описал. По-моему мнению, такая схема достаточно удобна, никого не тормозит (к примеру, фронтэнд-разработчики не ждут, пока будет готов бэкэнд) и позволяет разграничить области воздействия.
This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.
Комментариев нет:
Отправить комментарий