Что такое Design first и Code first

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

В разработке много теорий, методов и подходов. Вот один из способов на это посмотреть: с точки зрения главенства дизайна или кода. Вот два подхода:

1. Code First — сна­ча­ла код, потом всё осталь­ное.
2. Design First — сна­ча­ла про­ек­ти­ро­ва­ние, потом всё осталь­ное.

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

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

У каждого подхода есть свои плюсы и минусы.

🤔 Что есть дизайн

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

В более широком смысле дизайн — это как продукт устроен. Например, как работает вход в личный кабинет: по паролю, по отпечатку пальца, через соцсети или входа как такового вообще нет, а приложение просто каким-то волшебным образом узнаёт человека? Это дизайн.

Или, например, покупка товара: помнит ли сайт ваш адрес и номер карты? Есть ли покупка в один клик? А если есть — куда доставляется товар? Как изменить адрес доставки, если уже оплатил? Последовательность окон, кнопок, разных путей по продукту — всё это тоже дизайн.

В русском языке слово «дизайн» часто связывают именно с красотой, но в мире ИТ оно скорее означает «проектирование», то есть «как эта вещь устроена».

Code first

В подходе «от кода» продукт разрабатывают как бы изнутри: сначала пишут ту часть, которая делает основную полезную работу, а потом к ней прикручивают интерфейс. Например, если ваше приложение должно отправлять и получать данные с сервера, сначала вы напишете отправку и получение JSON-запросов . Когда вы убедитесь, что всё работает, вы будете думать, как эти запросы выводить для пользователя.

Главное преимущество здесь — скорость. Мы не проектируем интерфейс, не рисуем прототипы в графическом редакторе, не обращаем внимание на шрифты, цвета и оформление. Наша задача — быстро понять, будет ли работать технология.

✅ Плюс подхода — продукт работает почти сразу.

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

Design first

В подходе Design First проектировщики сначала придумывают продукт извне: что и как должно работать с точки зрения человека. Может быть, собирают прототип и тестируют его на пользователях.

Когда дизайн проверен, программисты пишут для него код.

✅ Плюс в том, что продукты получаются более дружелюбными и удобными.

❌ Минус — делать такие продукты дольше.

Вы тут понарисовали, как нам это реализовывать?

Главная сложность подхода Design First — когда проектировщик мало что знает о технических ограничениях разработки, поэтому придумывает очень сложные в реализации вещи. И случается конфликт: дизайнер это нарисовал, а разработчик не может это сделать в отведённое время.

Например:

• Дизай­нер при­ду­мал, что при­ло­же­ние реко­мен­ду­ет това­ры опре­де­лён­ным обра­зом. У нас есть модуль товар­ных реко­мен­да­ций, но дизай­нер нари­со­вал для него нестан­дарт­ное пове­де­ние. Пере­пи­лить модуль реко­мен­да­ций — это рабо­ты на месяц.
• Дизай­нер при­ду­мал нестан­дарт­ный эле­мент интер­фей­са. Он нужен по смыс­лу в этом при­ло­же­нии, но его нет в биб­лио­те­ках и гай­длай­нах для раз­ра­бот­чи­ков под эту ОС. Один этот эле­мент сто­ит несколь­ких недель рабо­ты.
• При­ло­же­ние долж­но хра­нить дан­ные о поль­зо­ва­те­ле для его удоб­ства. Но что­бы их хра­нить, нуж­но ста­но­вить­ся опе­ра­то­ром пер­со­наль­ных дан­ных и орга­ни­зо­вы­вать инфра­струк­ту­ру в Рос­сии, а мы на это не рас­счи­ты­ва­ли. При­дёт­ся пере­счи­ты­вать эко­но­ми­ку и пере­де­лы­вать бэкенд с учё­том рос­сий­ских сер­ве­ров.

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

Так и живём: тут компромисс, там невозможно, тут слишком дорого, там некрасиво, и такая ерунда целый день.