Обзор

Процесс и руководящие принципы для совместного проектирования

Дизайн является важной частью любого программного проекта. Тем не менее, гибкие команды часто борются с «что делать с дизайном?» из-за этих четырех факторов:

• Многие команды сосредотачиваются на проектах с высокой точностью в процессе планирования, что вызывает культуру водопада (waterfall) на протяжении всего внедрения.
• Дизайнеры часто делятся между командами и имеют ограниченное время, чтобы провести с любой командой.
• У дизайнеров не всегда есть простой способ сообщить обратную связь инженерной команде..
• Слои логики и представления не всегда четко разделены в базе кода, что затрудняет изменение стиля.

 

Дизайн: agile, как и разработка

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

ВИДЕО

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

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

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

Разработчики и владельцы продуктов тоже могут проектировать!

Во многих организациях дизайнеры объединяют несколько команд (или даже продуктов!). Это верно и для Atlassian. Поэтому мы решили лучше использовать драгоценное время наших дизайнеров.

Руководящие принципы проектирования Atlassian (Atlassian Design Guidelines)  - это набор принципов, руководств и ресурсов для проектирования и создания потрясающего опыта. Наши рекомендации по дизайну не только охватывают элементы визуального дизайна, они также воплощают наши ценности в дизайне пользовательского опыта. Это позволяет нескольким agile командам вырабатывать единообразные опыты работы для наших семейств продуктов. И, как уже упоминалось выше, мы включаем разработчиков и владельцев продуктов в процесс проектирования. Поскольку вся команда работает вместе, используя Atlassian Design Guidelines, разработчики и владельцы продуктов становятся лучшими дизайнерами. Этот набор навыков затем становится общим для всей команды, что является фундаментальной ценностью в agile культуре.

Хотя общее мышление важно, мы хотели пойти дальше в том, как мы подходим к agile дизайну. Atlassian Design Guidelines поставляется по трем основным каналам:

• Веб-сайт Atlassian Design Guidelines, который содержит идеологию и методологию наших проектных решений.
• Плоский пакет Atlassian User Interface (AUI), набор шаблонов HTML, JavaScript и CSS, которые реализуют все наши элементы дизайна в коде.
• Шаблоны Keynote и PowerPoint с визуальным представлением всех наших компонентов.

Разработчики могут скачать плоский пакет AUI и создавать макеты. Аналогичным образом, владельцы продуктов могут создавать испытания продуктов в виде слайдов, которые выглядят как настоящий продукт, без написания единой строки кода. Это эффективный способ получить значимую и действенную обратную связь по дизайну. Эти активы также укрепляют партнерские отношения во всей agile команде разработчиков. Единственный разработчик играет ведущую роль в процессе планирования, но остальная часть команды вносит свой вклад в принятие решений на протяжении итераций. Это устраняет узкие места при принятии решений о дизайне и позволяет всей команде стать более agile.

 

 

Дизайн для отличного опыта

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

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

Гибкий  дизайн - это будущее

Как и в случае с парадигмами разработки, дизайн со временем меняется. Современные технологии, такие как CSS, позволяют легко отделить внешний вид приложения от логики в приложении. Кроме того, убедитесь, что автоматизированные тесты структурированы так, чтобы они были устойчивыми при развитии визуального дизайна. Дизайн изменится, и важно обеспечить, чтобы кодовая база могла легко следовать новым тенденциям.

По материалам Agile Coach "Design"