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

  Во-вторых, публикация и откат версий должны быть продуманы изначально. Повседневная ситуация: одновременно разрабатываем новую функцию и исправляем баги, публикуем легко и непринуждённо. Откатываем тоже. Деплой туда-сюда, тыры-пыры. В-третьих, систему надо строить так, чтобы не составляло труда прикрутить статистику к любой кнопке или событию, провести А/Б-тест, проверить гипотезу.

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

  В-пятых, продукт должен хорошо работать. Больше всего на свете я ненавижу баги, глюки, косяки и поломки, потому что мне стыдно за них перед пользователями. Значит, у нас должна быть выстроена лучшая система профилактики и лечения.

Пример применения принципа «сделать невидимое видимым» в дизайне.