Начинаем разработку: сначала код или дизайн?

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

Сначала код

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

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

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

Вполне может случиться и так, что при попытке связать фронтэнд и бэкэнд возникнут сложности, и разработчикам придется менять код. Сэкономленное ранее время будет потрачено на доработку.

Сначала дизайн

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

Прототип проходит юзабилити-тестирование, чтобы команда убедилась, что было спроектировано удобное и подходящее пользователям решение. После этого программисты начинают работу над кодом: фронтенд и бэкенд объединяются.

Сильная сторона design first подхода в том, что продукт сразу получается дружелюбным к пользователю. Не идеальным, но гораздо более удобным в сравнении с первыми версиями софта, созданного по методу code first.

Минус этого подхода — в меньшей скорости разработки. Пока дизайнеры создают прототип, тестируют его и дорабатывают, программисты не могут в полной мере приступать к работе.

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

Как выбрать?

Если нужно быстро выпустить работающую версию, а красота и интерфейсы не важны, то подходит метод code first. Первые версии продукта будут суровые, зато появятся они быстро и можно будет оценить общую эффективность системы.

Если есть возможность потратить время на разработку прототипа, то на помощь приходит метод design first. Дав дизайнерам возможность создать и протестировать прототип, вы с большей долей вероятности получите более дружелюбный интерфейс продукта уже на ранних этапах разработки.

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

Минимизируйте риски возникновения конфликтов на стыке фронтенда и бэкенда — работайте с системными аналитиками. Они помогут сформулировать требования к продукту, поставить задачи не упустить из виду ничего важного.