Код, занает и создавањето на вгнездени папки

Како Figma го промени пристапот кон развојот за да испорача долгонарачувана функција – и што научи на патот

Денес, Figma со гордост ја претставува функцијата вгнездени папки (nested folders) – долгонарачувано подобрување кое им помага на растечките тимови да ги организираат своите датотеки додека го зголемуваат обемот на содржини и се справуваат со сложени проекти.

Иако вгнездените папки на прв поглед звучат како едноставно подобрување на квалитетот на животот, нивното создавање бараше целосно преиспитување на основниот модел на содржини и дозволи во Figma – сè, од прелистувачот на датотеки и административните контроли, до споделувањето, дозволите и основната инфраструктура.

Кога проектот започна пред една година, тимот го следеше традиционалниот процес на развој на производи: Продукт-тимот ги разработуваше барањата, дизајнот го мапираше искуството, а инженерингот започнуваше да гради откако размислувањето се сметаше за завршено.

Но, среде проектот, контекстот се промени. Од една страна, тимот се занимаваше со нови способности засновани на вештачка интелигенција кои ги поделија ресурсите. Од друга страна, алатките како Figma Make, MCP серверот и агентските вештини овозможуваа многу побрзо претворање на идејата во нешто опипливо. Тимот можеше да почне да гради било каде – со прототип, код, па дури и со нешто нацртано во Slack.

За да се прилагодат на овие промени и да ги испорачаат вгнездените папки, тимот се потпре на нов начин на работа:

• Водење со код: Бидејќи кодот стана поевтин за производство, тимот се движеше побрзо со креирање на pull request (PR) за тестирање на идеите, наместо да се губи во теоретски дискусии.

• Промена на одговорностите: Работеа со флексибилност – инженерите носеа дизајнерски одлуки, дизајнерот пишуваше код, а продукт-менаџерот ги замени дневните извршни задачи со поголеми стратешки прашања.

• Размена на предавања за разговори: Замаглувањето на улогите ги правеше сите истовремено ученици и учители. Споделувањето на деловите од занаетот кои претходно ги чуваа за себе ја изгради довербата која работата ја бараше.

Еве како тие промени изгледаа од три перспективи – инженеринг, дизајн и продукт – и како заедно покажуваат како тимот продлабочил односи, комбинирал вештини и останал фокусиран на испорака на вистинското искуство.

Инженерот Итан Адамс: Нова брзина со кодот

Неколку месеци во проектот, Итан сфати дека традиционалниот процес на развој би траел премногу долго. Наместо да дебатираат за барањата во долги Slack-нишки или состаноци, тимот почна да води со кодот како предлог. Овие дискусии беа вредни предуслови кога пишувањето код беше скапо и одземаше време, но сега сме во ерата на агенти.

Наместо да погодуваат дали идејата ќе функционира, едноставно креираа PR за да ја докажат. Спојуваа код се додека не ништо не кршеше. Ова овозможи брзо скицирање на идеи и нивно прикажување на партнерите во живо, вистинско тестирање. Копијата не е совршена? Нема проблем. Функционалноста недостасува? Во ред. Логички празнини? Може да се поправат подоцна!

Во пракса, ова беше огромен поттик за брзината и изгради доверба во предлозите кои на крајот беа избрани. Работен демо во вашата вистинска кодна база го победува документот со барања (PRD) секој пат.

Иако Итан имаше зелено светло да носи продукт-одлуки како инженер, тој сè уште се потпираше на продукт-менаџерот Сачи Шах како партнер за размислување. Нивната соработка претходно личеше на водопад: таа одлучуваше за барање, тој го имплементираше. Овој пат, повеќе личеше на верификационен циклус: тој водеше со предлог, спојуваше прототипови во тестирање, собираше повратни информации од Сачи, ги измазнуваше грубите рабови и конечно го распоредуваше готовиот производ.

Дизајнерот Каи Чарнига: Од пиксели до pull request

Каи признава дека неговиот број на PR за овој проект е прилично мал – два, можеби три. Не магично се претвори во инженер, но сите почнаа да влегуваат во улоги кои претходно исклучиво им припаѓаа на другите.

На овој проект, инженерите имаа силни инстинкти за структура и длабоко разбирање на сложените дозволи за претпријатија, па редовно доаѓаа до Каи со текови и дизајнерски прилагодувања. Кога имате силен дизајн систем кој дава насоки и доволно доверба да се донесе одлука, инженерот може длабоко да се нурне во дизајнерска карактеристика и да ја доведе до цврста состојба.

Ова значеше дека кога некој е на капацитет, работата не застануваше чекајќи вистинската личност да ја преземе. На пример, додека работеа на тековите за споделување папки, инженерката Џени Ју направи неколку опции. Потоа, Каи, заедно со UX-писателката Моли Розен Маринер, ги надградија пристапите на Џени на дизајн-платното на Figma: Џени одржувајќи го текот технички исправен, Моли острејќи го јазикот за дозволи, а Каи обликувајќи ја визуелната хиерархија.

Работеше и обратно. Имаше моменти кога Каи земаше промена, влегуваше во кодот и сфаќаше колку всушност се случува под хаубата – доволно за да се врати кај тимот и да каже: „Искрено, ова не треба да биде мое.“ Знаењето каде ви престанува експертизата е свој вид занает.

Каи смета дека секој дизајнер треба да се обиде да испрати PR. Кога Итан му постави CoderBox, песокот за креирање код-околини, почувствува колку време одземаат одредени промени пред воопшто да може да ги прегледа – и тоа направи повеќе за неговата емпатија отколку било кое предавање.

Инженерите можеа да носат дизајнерска работа, а Каи можеше сам да влезе во кодот. Тоа му даде простор да се нурне длабоко онаму каде што е важно, поминувајќи низ повеќе верзии на интерфејсот за папки отколку што стариот модел на предавање би дозволил.

Продукт-менаџерот Сачи Шах: Размена на контрола за убеденост

Со овој нов начин на работа, првото нешто што Сачи мораше да го остави беше претпоставката дека доброто продукт-размислување мора да доаѓа исклучиво од продукт-менаџерот. Нејзината работа стана: поврзување на вистинските луѓе со вистинските проблеми, давање простор да дејствуваат и знаење кога да се повлече.

Инженерката Џени Ју стана еден од најблиските партнери за размислување за критичните операции со содржини – како луѓето преместуваат, дуплираат и пренесуваат папки низ Figma. Инженерот Рики Зеин го поседуваше искуството за индивидуални корисници и помали тимови, чии потреби често се разликуваат од оние на претпријатијата. А Data-научниците Патрик Кехинде Џуниор и Ерик Абербук мапираа како новиот модел на дозволи ќе влијае на секоја група, помагајќи ѝ на Сачи да ги тестира претпоставките и да се фокусира на најголемите ризици.

Ослободувањето од дневното извршување ѝ даде повеќе време да се фокусира на стратешкото прашање под проектот: Дали подобрата организација на датотеки сè уште е важна во светот на вештачката интелигенција, или папките стануваат застарени како што се подобрува AI-пребарувањето?

Тимот изгради артефакти кои помогнаа да се види како папките можат да бидат уште поважни како луѓето создаваат повеќе работа – давајќи им на идните AI-пребарувања побогата структура и контекст за пребарување.

Најмногу помогна отстапувањето за да се изгради избалансирано портфолио на облози. Заедно со вгнездените папки, тимот работеше на лансирање на вештини во Figma агент, друг дел од AI-стратегијата на Figma. Парадоксално, поминувањето помалку време на секој детал ѝ даде повеќе простор да изгради патоказ каде основните потреби на клиентите и новите AI-искуства можеа да напредуваат заедно.

Во самиот проект, најважното место за пренасочување на вниманието беше кон клиентите. Сачи го водеше програмата за ран пристап (EAP). На Config, заедно со инженеринг-менаџерот Ајуш Мехра, ги „ладеа“ клиентите за системот за организација на датотеки што го градеа. Убедија неколку луѓе да се приклучат на EAP на самото место.

Заедниците на Friends of Figma во Џајпур, Барселона, Мумбаи и Лахор станаа рани корисници. Сачи, исто така, контактираше со лидери на заедници низ целиот свет и со луѓе на X кои беа особено гласни за организацијата на датотеки.

Повратните информации од клиентите покажаа како вгнездените папки се однесуваат во живи организации, со нередовни датотеки и воспоставени навики. Помогнаа да се фатат грешки, да се дотера искуството и да се намали ризикот од мигрирање на клиентите на сосема нов модел на содржини. Времето поминато со клиентите ѝ даде продукт-јасност која не можеше да ја добие само од спецификации.

Градење доверба низ замаглени улоги

Размената на контрола за убеденост бараше Сачи да влезе во работата за која е најдобро позиционирана, додека им верува на другите да го сторат истото. Овој начин на работа функционира само кога тимот си верува еден на друг. Искрено, замаглувањето на улогите беше непријатно: имаше моменти кога си стапуваа на нозе, преминуваа граници несмасно или пробуваа нешто што никогаш претходно не го правеле.

Таа непријатност беше дел од пронаоѓањето на новата нормала, и можеа да се движат низ неа само затоа што инвестираа во односите зад работата. Со текот на времето, станаа помалко претерано заштитнички настроени кон своите индивидуални домени и почнаа активно да се подучуваат еден со друг за деловите од занаетот кои претходно најмногу ги чуваа.

Довербата и контекстот ги одржуваа преку заеднички ритуали: неделни „bug bash“-и, функционални синхронизации, живо спарување помеѓу дизајн и инженеринг, и прослави на големи пресвртници – вклучувајќи го и внатрешното лансирање во цела Figma. Тие ритми ги држеа приковани кон истата цел: испорака на долгоочекуваното ветување кон клиентите без компромис во квалитетот.

Вгнездените папки ќе бидат достапни за сите корисници во текот на следните неколку недели. Посетете го Центарот за помош за да дознаете повеќе за тоа како да започнете.

Оваа статија е инспирирана од оригиналниот напис „Code, craft, and the making of nested folders“ на Етан Адамс (Software Engineer), Каи Чарнига (Product Designer) и Сачи Шах (Product Manager), објавен на официјалниот блог на Figma. Тројцата автори го споделуваат своето искуство од редизајнирањето на работниот процес за да испорачаат сложена функција во ерата на вештачка интелигенција, нагласувајќи ја важноста на довербата, флексибилноста и заедничкото учење.

Извор: Code, craft, and the making of nested folders - Figma Blog