В разработке много теорий, методов и подходов. Вот один из способов на это посмотреть: с точки зрения главенства дизайна или кода. Вот два подхода:
- Code First — сначала код, потом всё остальное.
- Design First — сначала проектирование, потом всё остальное.
В наших учебных проектах в «Коде» мы действуем по первому принципу, потому что наша задача — запустить что-то работоспособное как можно быстрее. Сначала у нас считается логика, запускаются функции и нажимаются кнопочки, а уже потом мы придумываем интерфейс и наводим красоту.
Подход Design First работает наоборот: проектировщики сначала придумывают, как продукт должен выглядеть со стороны и работать, а потом уже программисты придумывают, как это оживить. Они смотрят на экраны и на логику работы и пишут код, который будет работать именно так, как хотят дизайнеры.
У каждого подхода есть свои плюсы и минусы.
🤔 Что есть дизайн
В обывательском понимании дизайн — это внешний вид продукта: как выглядят кнопочки, какие тени, какие цвета и подобное.
В более широком смысле дизайн — это как продукт устроен. Например, как работает вход в личный кабинет: по паролю, по отпечатку пальца, через соцсети или входа как такового вообще нет, а приложение просто каким-то волшебным образом узнаёт человека? Это дизайн.
Или, например, покупка товара: помнит ли сайт ваш адрес и номер карты? Есть ли покупка в один клик? А если есть — куда доставляется товар? Как изменить адрес доставки, если уже оплатил? Последовательность окон, кнопок, разных путей по продукту — всё это тоже дизайн.
В русском языке слово «дизайн» часто связывают именно с красотой, но в мире ИТ оно скорее означает «проектирование», то есть «как эта вещь устроена».
Code first
В подходе «от кода» продукт разрабатывают как бы изнутри: сначала пишут ту часть, которая делает основную полезную работу, а потом к ней прикручивают интерфейс. Например, если ваше приложение должно отправлять и получать данные с сервера, сначала вы напишете отправку и получение JSON-запросов. Когда вы убедитесь, что всё работает, вы будете думать, как эти запросы выводить для пользователя.
Главное преимущество здесь — скорость. Мы не проектируем интерфейс, не рисуем прототипы в графическом редакторе, не обращаем внимание на шрифты, цвета и оформление. Наша задача — быстро понять, будет ли работать технология.
✅ Плюс подхода — продукт работает почти сразу.
❌ Минус — в том виде, в котором он работает, им может быть неудобно пользоваться. Чтобы стало удобно, нужно спроектировать интерфейс и отдать на доработку программистам, а это для них может означать переработку кода.
Design first
В подходе Design First проектировщики сначала придумывают продукт извне: что и как должно работать с точки зрения человека. Может быть, собирают прототип и тестируют его на пользователях.
Когда дизайн проверен, программисты пишут для него код.
✅ Плюс в том, что продукты получаются более дружелюбными и удобными.
❌ Минус — делать такие продукты дольше.
Вы тут понарисовали, как нам это реализовывать?
Главная сложность подхода Design First — когда проектировщик мало что знает о технических ограничениях разработки, поэтому придумывает очень сложные в реализации вещи. И случается конфликт: дизайнер это нарисовал, а разработчик не может это сделать в отведённое время.
Например:
- Дизайнер придумал, что приложение рекомендует товары определённым образом. У нас есть модуль товарных рекомендаций, но дизайнер нарисовал для него нестандартное поведение. Перепилить модуль рекомендаций — это работы на месяц.
- Дизайнер придумал нестандартный элемент интерфейса. Он нужен по смыслу в этом приложении, но его нет в библиотеках и гайдлайнах для разработчиков под эту ОС. Один этот элемент стоит нескольких недель работы.
- Приложение должно хранить данные о пользователе для его удобства. Но чтобы их хранить, нужно становиться оператором персональных данных и организовывать инфраструктуру в России, а мы на это не рассчитывали. Придётся пересчитывать экономику и переделывать бэкенд с учётом российских серверов.
Это одна из причин, почему в разработке так важны общение и управление. Когда случаются такие столкновения, у разработчиков должен быть тимлид или директор по разработке, а у дизайнеров — главный дизайнер, которые договорятся между собой, что из дизайна должно пойти под нож, а где должны напрячься разработчики.
Так и живём: тут компромисс, там невозможно, тут слишком дорого, там некрасиво, и такая ерунда целый день.
