В 2024 году на рынке существует довольно большое количество экосистем цифровых продуктов: как для B2C-сегмента, так и для B2B. И если просто в поисковике вбить «как создать экосистему», вы получите кучу статей от аналитиков, продактов, бизнеса. Однако, если попробовать сформулировать запрос с конкретикой по дизайну (например, «как создать дизайн для экосистемы продуктов»), мы получаем классную выдачу, в которой экосистемой называют дизайн-систему. И это ужасная подмена понятий, так как дизайн-система является всего лишь одним (хоть и очень значимым) из ингредиентов вкуснейшего экосистемного дизайн-борща.

Что же входит в этот борщ?

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

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

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

Ниже по тексту я распишу трудности, с которыми сталкивается специалист в IT на всём протяжении своего роста, и о которых очень мало говорят.