Ukabidhiano wa muundo kwa wahandisi – zaidi ya maoni ya Figma
Kwa nini maoni ya Figma pekee hayawezi kuziba pengo la ukabidhiano wa muundo kwa wahandisi, na nini kinachofanya kazi kwa timu ndogo.
By Ellis Keane · 2026-04-06
Zana bora ya ukabidhiano wa muundo kwa wahandisi ni ile ambayo wahandisi hawafungui kamwe
Wabunifu wanavyowekeza zaidi katika kuboresha ukabidhiano wao wa Figma – auto-layout, tokeni za muundo, vidokezo vya hali ya msanidi, nyaraka za vipengele – ndivyo ukabidhiano halisi wa muundo kwa wahandisi mara nyingi unavyozidi kuwa mbaya. Si kwa sababu kazi ya muundo ni mbaya – kawaida ni bora sana – bali kwa sababu juhudi zote hizo zinaishi katika zana ambayo wahandisi wanatembelea kwa kusita, wanasoma haraka, na kisha wanafunga ili kwenda kujenga kile wanachofikiria waliona.
Nimekuwa pande zote mbili za hili. Nilianza kama mbunifu (vizuri, "mbunifu" – nilikuwa nikijega tovuti za maduka ya rehani huko New Hampshire, kwa hivyo tukubaliane kuhusu jina hilo), na sasa naandika msimbo wengi wa uhandisi wa Sugarbug. Tatizo la ukabidhiano wa muundo kwa wahandisi si tatizo la zana, ni tatizo la mtiririko wa kazi. Habari ipo, iko tu mahali pabaya wakati usio sahihi.
Ukabidhiano wa kawaida wa muundo kwa wahandisi unaonekana hivi: mbunifu anatumia siku tatu kuboresha fremu ya Figma, anaongeza maoni kumi na mawili yanayoeleza maamuzi ya nafasi na hali za pembezoni, anamtaja mhandisi, na kisha anasubiri. Mhandisi anafungua Figma, anaangalia fremu kwa takriban sekunde tisini, anafikiria "sawa, nimepata," anafunga kichupo, na anajenga kitu ambacho ni sahihi kwa 80% na kibaya kwa 20% kwa njia ambazo zitachukua wiki nyingine ya mawasiliano ya huku na huko kutatua. Maoni kumi na mawili? Alisoma labda manne.
Ukabidhiano wa muundo kwa wahandisi si faili unayoitupa kupitia ukuta. Ni muktadha unaohitaji kuishi mahali ambapo mhandisi anafanya kazi – katika suala, katika PR, katika msimbo – si katika zana ya muundo anayotembelea mara moja.
Kwa nini maoni ya Figma yana umbo lisilo sahihi kwa ukabidhiano
Ninatumia Figma kila siku na kweli naifurahia (ambayo pengine ni kasoro ya tabia kwa wakati huu). Lakini maoni ya Figma yameboreshwa kwa ushirikiano wa mbunifu-kwa-mbunifu, si kwa ukabidhiano wa muundo kwa wahandisi, na tofauti hiyo ina umuhimu zaidi kuliko timu nyingi zinavyotambua.
Kutofautiana kwa msingi ni huku: maoni ya Figma yamefungwa kwa nafasi kwenye fremu na vipengele. Yanaishi ndani ya faili ya muundo. Lakini wahandisi hawafanyi kazi ndani ya faili za muundo – wanafanya kazi katika masuala ya Linear, PR za GitHub, na IDE yao. Mbunifu anapoachia maoni kwenye fremu akisema "hii dropdown inapaswa kujifunga kwenye mitazamo ya simu chini ya 640px," habari hiyo sasa imekwama katika Figma. Haibadiliki kuwa kazi. Haionekani katika mtiririko wa kazi wa mhandisi. Inaishi katika ulimwengu sambamba ambao mhandisi lazima akumbuke kutembelea, na (hapa ndipo jambo muhimu) kutembelea Figma si sehemu ya kitanzi cha kazi cha kawaida cha mhandisi jinsi kuangalia Linear au kupitia PR kulivyo.
Matokeo yanatabiriwa: maamuzi muhimu ya muundo yanapotea, si kwa sababu mtu yeyote ni mzembe, bali kwa sababu habari iko katika zana isiyo sahihi. Ni kama kuacha karatasi ya kumbukumbu kwenye dawati la mtu anayefanya kazi kutoka nyumbani.
Mahali ambapo wabunifu wanaacha muktadha
- Maoni ya Figma – Ya nafasi, yamefungwa kwenye fremu
- Vidokezo vya hali ya msanidi vya Figma – Vya kina lakini vinahitaji kufungua Figma
- Mikufu ya Slack – Ya mazungumzo, haiwezi kutafutwa baada ya wiki
- Nyaraka za mfumo wa muundo – Kamili lakini mara chache zinaangaliwa katikati ya sprint
Mahali ambapo wahandisi kweli wanaangalia
- Maelezo ya suala la Linear – Kitu cha kwanza wanachosoma kabla ya kuanza
- Maelezo ya PR ya GitHub – Rejea wakati wa utekelezaji
- Maoni katika msimbo – Yanagunduliwa wakati wa ukaguzi
- IDE – Mahali wanapotumia 90% ya muda wao
Kinachofanya kazi kweli (kutoka kwa mtu anayefanya vyote viwili)
Katika mwaka uliopita wa kujenga Sugarbug, nimekuwa mbunifu na (hasa) mhandisi, ambayo inamaanisha nimekuwa na uzoefu usio wa kawaida wa kujikabidhi mwenyewe na bado kupoteza muktadha. Ikiwa siwezi kukumbuka maamuzi yangu mwenyewe ya muundo ya Jumanne iliyopita, hakuna njia mhandisi tofauti atakayopata kila kitu kutoka kwenye mkufu wa maoni ya Figma.
Hiki ndicho kilichofanya kazi kweli kwa mchakato wa ukabidhiano wa muundo kwa wahandisi wa timu yetu – na hakuna kinachohusisha kuandika maoni bora ya Figma.
1. Andika uamuzi wa muundo katika suala, si katika faili ya muundo
Kabla ya mhandisi kuanza kujenga, muktadha wa muundo unahitaji kuishi katika suala la Linear (au chochote timu yako inachotumia). Si kiungo cha faili ya Figma chenye "tazama muundo" – hiyo ni kukwepa, na kila mtu anajua. Suala linapaswa kujumuisha:
- Nini: Picha ya skrini au fremu iliyosafirishwa (si kiungo cha Figma – PNG ambayo mhandisi anaweza kuona bila kufungua zana nyingine)
- Kwa nini: Sababu nyuma ya maamuzi muhimu. "Tulichagua paneli ya kuteleza badala ya modal kwa sababu mtumiaji anahitaji kurejelea orodha wakati wa kuhariri" – sentensi moja inayookoa duru tatu za "kwa nini si modal?"
- Hali za pembezoni: Nini kinatokea kwenye simu? Nini kinatokea na maandishi marefu? Nini kinatokea wakati hakuna data? Ikiwa umefikiria kuhusu hilo, liandike. Ikiwa hujafikiria, sema hivyo (kwa uaminifu, "sijapata suluhisho la hali tupu bado" ni muhimu zaidi kuliko ukimya)
2. Ukaguzi wa muundo unafanyika katika suala, si katika Figma
Ninapopata maoni ya muundo wakati wa utekelezaji, nayataka katika mkufu wa suala la Linear, si kama maoni ya Figma ambayo huenda nisiyaone kwa siku mbili. Suala ni chanzo changu pekee cha ukweli kwa kazi – ikiwa maoni yanaishi hapo, nitayaona wakati mwingine ninapoangalia suala, ambayo ni mara kadhaa kwa siku. Ikiwa yanaishi katika Figma, nitayaona ninapofungua faili hiyo kwa bahati, ambayo inaweza kuwa kamwe.
Hii haimaanishi kutotumia maoni ya Figma kamwe. Ni bora kwa ushirikiano wa mbunifu-kwa-mbunifu, kwa kuweka alama za maelezo mahususi ya kuona, na kwa mazungumzo kuhusu muundo wenyewe. Lakini wakati maoni yanakuwa "mhandisi anahitaji kubadilisha kitu," yanahitaji kuhamia kwenye mtiririko wa kazi wa uhandisi.
stat: "Mengi" headline: "ya maoni ya Figma hayakuonekana kwa zaidi ya masaa 48 tulipoyategemea kwa ukabidhiano" source: "Uzoefu wa timu yetu kwa miezi 3 ya ufuatiliaji usio rasmi"
3. Funga kitanzi kwa picha za skrini, si kwa mawazo
Njia ya bei nafuu zaidi ya kuthibitisha ukabidhiano wa muundo kwa wahandisi ni picha ya skrini. Mhandisi anapomalize kutekeleza kipengele, anabandika picha ya skrini katika PR au suala na kumtaja mbunifu. "Hii inalingana?" inachukua sekunde kumi na inakamata tofauti ya 20% kabla ya kutolewa. Hakuna mkutano, hakuna ibada ya kulinganisha na Figma – PNG tu na swali.
Tulianza kufanya hivi kwa kila PR ya UI, na idadi ya mazungumzo ya "hii hailingani na muundo" ilishuka hadi karibu sifuri. Mazungumzo yanayobaki ni hali halisi za pembezoni ambazo muundo haukuzishughulikia, ambayo ni sawa – hiyo ndiyo aina ya jambo linalopaswa kujadiliwa, si mambo ya msingi kama "ulitumia padding ya 16px badala ya 12px".
4. Acha muktadha utiririke kati ya zana kiotomatiki
Hapa ndipo nitakapotaja Sugarbug, kwa sababu tuliunda kwa kweli kutatua tatizo hili mahususi. Mbunifu wetu anaachia maoni katika Figma kuhusu mabadiliko ya nafasi. Sugarbug inachukua maoni hayo, inaiunganisha na suala husika la Linear na PR ya GitHub, na mhandisi anaiona katika mtiririko wake wa kazi bila kufungua Figma. Ukabidhiano wa muundo kwa wahandisi unaacha kuwa ibada ya kunakili kwa mkono na unakuwa kitu kinachotokea tu.
Lakini ikiwa hutumii Sugarbug (na wengi wenu hamtumii, bado tuko kabla ya uzinduzi), toleo la mkono ni hili: teua mtu kuwa "daraja la ukabidhiano" anayeangalia maoni ya Figma kila siku na kunakili maoni muhimu katika masuala ya Linear. Ni kazi ya kuchosha, lakini inafanya kazi, na ni bora kwa mbali zaidi kuliko kutumaini kwamba wahandisi watakumbuka kuangalia Figma.
Ikiwa siwezi kukumbuka maamuzi yangu mwenyewe ya muundo ya Jumanne iliyopita, hakuna njia mhandisi tofauti atakayopata kila kitu kutoka kwenye mkufu wa maoni ya Figma. attribution: Chris Calo
Orodha yako ya ukaguzi wa ukabidhiano wa muundo kwa wahandisi
Ikiwa utachukua kitu kimoja kutoka kwenye makala hii, kiwe hiki: suluhisho si zana bora (vizuri, si hasa – ingawa ninaunda moja, kwa hivyo pokea kwa tahadhari). Suluhisho ni kuanzisha kanuni kuhusu mahali ambapo maamuzi ya muundo yanaishi, na kuhakikisha kuwa "mahali" hapo ni ndani ya mtiririko wa kazi wa kawaida wa mhandisi.
- [ ] Safirisha fremu muhimu kama PNG katika suala la Linear (si kiungo cha Figma tu)
- [ ] Andika "kwa nini" kwa kila uamuzi mkubwa wa muundo katika maelezo ya suala
- [ ] Orodhesha hali zinazojulikana za pembezoni (simu, hali tupu, maandishi marefu) – au weka alama wazi ya kile ambacho bado hujatatua
- [ ] Hamisha maoni ya utekelezaji kutoka maoni ya Figma kwenda mkufu wa suala
- [ ] Hitaji picha ya skrini katika kila PR ya UI kabla ya idhini ya mbunifu
- [ ] Teua mtu "daraja la ukabidhiano" ikiwa huna zana ya kuunganisha Figma na Linear kiotomatiki
Maswali yanayoulizwa mara kwa mara
Q: Kwa nini maoni ya Figma yanashindwa kama zana ya ukabidhiano wa muundo kwa wahandisi? A: Maoni ya Figma yanaishi ndani ya faili ya muundo, yakiwa yametenganishwa na mtiririko wa kazi wa uhandisi. Wahandisi wanafanya kazi katika Linear, GitHub, na IDE yao – si katika Figma. Maoni kwenye fremu hayawi kazi isipokuwa mtu anakili kwa mkono, na hatua hiyo ya mkono ndipo ukabidhiano wa muundo kwa wahandisi unapovunjika. Si tatizo la watu, ni tatizo la mpaka wa zana.
Q: Je, Sugarbug inaunganisha maoni ya Figma na masuala ya Linear kiotomatiki? A: Ndiyo – hiyo ni moja ya matatizo mahususi tuliyounda kutatua. Sugarbug inakusanya maoni ya Figma na kuyaunganisha na masuala husika ya Linear na PR za GitHub, hivyo maoni ya muundo yanaonekana katika mtiririko wa kazi wa mhandisi bila kunakili kati ya zana. Tunatumia sisi wenyewe kila siku, na tofauti ni (kwa uaminifu) ya aibu kidogo kwa kuzingatia jinsi wazo lilivyo rahisi.
Q: Mchakato bora wa ukabidhiano wa muundo kwa wahandisi kwa timu ndogo ni upi? A: Andika uamuzi wa muundo katika suala la Linear kabla ya mhandisi kuanza kujenga. Jumuisha sababu, si tu mwonekano. Ikiwa hali za pembezoni zinatokea wakati wa utekelezaji, zijadili katika mkufu wa suala – si katika maoni ya Figma ambayo mhandisi atalazimika kutafuta. Mchakato rahisi zaidi mara nyingi ndio wa kudumu zaidi.
Q: Unashughulikiaje mabadiliko ya muundo baada ya uhandisi kuanza? A: Yachukulie kama mabadiliko ya upeo: yandike mabadiliko katika suala na ulinganisho wazi wa kabla/baada, eleza sababu, na mruhusu mhandisi kutathmini gharama ya utekelezaji kabla ya kujitolea. Kushindwa vibaya zaidi kwa ukabidhiano kunatokea wakati mabadiliko ya muundo yanafika kama maoni ya kawaida ya Figma kwenye kazi ambayo tayari imejengwa – ndivyo unavyopata wahandisi wenye chuki na wabunifu wenye kukata tamaa.
Pokea akili ya ishara moja kwa moja kwenye kikasha chako.