Dramatic ang title, alam ko. Hindi naman biglang mawawala ang UI/UX designers at frontend developers sa susunod na quarter. Pero yung basic work ng pag-convert ng static design into an interface, mabilis nang nagiging mas mura.
Halos araw-araw akong gumagamit ng AI, at mas napapansin ko na ngayon ang difference ng mga taong gumagamit ng parehong tools. May nakakapag-ship ng bagay na hindi nila kayang gawin isang taon lang ang nakalipas. Meron din namang mas dumami lang ang output pero hindi talaga gumanda ang trabaho. Parehong tools lang, pero sobrang layo ng results.
Designers yung group na lagi kong tinitingnan. Kapag marunong na ang isang tao sa hierarchy, spacing, typography, interaction, at product behavior, kaya na niyang dalhin ang idea nang mas malayo sa isang Figma screen. Maaari niya itong paganahin, i-test sa phone, sirain, baguhin ang isip niya, at subukan ulit bago pa man sumali ang engineer sa usapan.
Mukhang design engineer na ang taong iyon. O baka designer lang siya na kaya nang tapusin ang mas malaking bahagi ng trabaho nang mag-isa. Hindi pa ako sure kung mahalaga talaga ang title.
hindi na kailangang tumigil sa Figma
Pamilyar naman yung dating handoff. Tatapusin ng designer ang screens, lalagyan ng notes, tapos ipapasa sa developer. Doon magsisimula ang pabalik-balik na tanong. Ano ang mangyayari kapag disabled ang button? Saan magwa-wrap ang card? Kasama ba talaga sa design ang animation o gumalaw lang iyon sa prototype? Ang dami palang product decisions na ginagawa pagkatapos ma-handoff ang tinatawag nating “final” design.
Pinapaikli ng GPT at mga tool gaya ng Fable ang loop na iyon. Puwedeng ilarawan ng designer ang behavior, gumawa ng rough implementation, at magpatuloy habang sariwa pa ang idea. Hindi niya kailangang maging expert sa database o infrastructure para makagawa ng convincing prototype. Pero kailangan niyang sapat na maintindihan ang frontend para mapansin kapag nonsense ang code na binigay ng AI. Mas madalas mangyari iyon kaysa sa ipinapakita ng demos.
Ang gusto ko rito, mas may oras ang designer para pag-isipan ang totoong experience. Kasama na yung awkward states na hindi magandang tingnan sa presentation pero siguradong lalabas sa actual product.
mas mahalaga pa rin ang taste kaysa prompting
Paulit-ulit kong naiisip si Adrian, ang creator ng Keeby. May malinaw na personality yung product niya. Yung orange, yung maliit na keycap character, pati yung paraan ng pag-demo ng product, parang galing lahat sa iisang tao. Puwedeng hindi mo trip ang style, pero hindi mo masasabing aksidente lang iyon.
Nakikita ko rin yung instinct na iyon sa teammate kong si Angelo Manalo. Kayang paglaanan ni Angelo ng mahabang oras ang detail na baka i-skip lang ng iba, tapos kaya niyang ipaliwanag kung bakit mahalaga iyon sa brand o sa taong gagamit ng product. Binibigyan siya ng AI ng implementation speed. Pero sa kanya pa rin nanggagaling ang dahilan sa likod ng decision.
Dito bumabagsak para sa akin yung idea na “kahit sino designer na ngayon.” Oo, kahit sino puwedeng mag-generate ng malinis na card, dashboard, o panibagong tasteful na landing page. Pero karamihan sa mga iyon, madaling makalimutan. Ang mahirap pa rin ay malaman kung ano ang dapat mabuo, ano ang dapat tanggalin, at aling maliit na detail ang worth ipaglaban.
nagbabago na ang handoff namin
Sa isa sa mga kumpanyang pinagtatrabahuhan ko, gumagawa na ng Storybook components ang COO at CEO namin. Hindi sila traditional software engineers. Pero kilala nila ang product, at tinutulungan sila ng AI na gawing clickable component ang nasa isip nila sa halip na isa na namang mahabang paragraph sa ticket.
Aaminin ko, medyo weird makita ito noong una. Parang engineering territory dati ang Storybook. Ngayon puwedeng magdala ang product leader ng component at sabihing, “Ganito yung ibig kong sabihin.” Mas magandang conversation iyon kaysa hulaan namin kung ano ba talagang dapat gawin ng screenshot.
Kadalasan, hindi pa ready i-ship ang generated component. May kulang na state. Okay siya sa sample data pero nasisira sa real data. Lumalabas pa rin ang accessibility, performance, error handling, at lahat ng boring edge cases. May nire-rewrite kami, may ikinokonekta sa backend, at minsan mas marami pa ang tinatapon kaysa sa natitira.
Kahit ganoon, mas okay pa rin ang starting point. Mas dala ng rough component ang original intent kaysa sa static frame.
ano ang dapat aralin ng designers ngayon
Hindi kailangan ng designers ng mahabang detour sa computer science. Kailangan lang nila ng sapat na technical range para kontrolado pa rin nila ang experience na dini-design nila. Para sa akin, dapat kaya nilang gawin ang ilang bagay.
- Gumawa ng prototype na kumikilos gaya ng idea, hindi lang magandang tingnan sa recording.
- Mag-isip in terms of components at states. Kasama sa design ang empty, loading, error, at disabled.
- Maglagay ng useful work sa Storybook para ma-inspect, magamit ulit, at mapag-usapan ng ibang tao.
- Magbasa ng sapat na code para mapansin kapag nag-iimbento ng API ang AI, ini-ignore ang accessibility, o ginagawang 600 lines ang maliit na component.
Hindi mo kailangang mahalin ang code. Pero hindi puwedeng laging problema ng ibang tao ang implementation.
gusto ko ang direksiyong ito para sa frontend developers
Kung ang buong value mo ay gawing divs ang Figma screens, delikado ka. Wala akong mas magandang paraan para sabihin iyon. Okay na ang AI sa predictable na frontend work, at patuloy pa itong gagaling. Pero sa totoo lang, gusto ko yung direksiyong ito.
Isa sa pinakacommon na misconception tungkol sa frontend ay yung frontend developer din daw ang nagdi-design ng screens. Minsan iisang tao nga ang gumagawa ng dalawa, lalo na sa maliit na team. Pero magkaibang skills ang design at frontend engineering. Designer ang nagde-decide kung ano ang itsura at pakiramdam ng experience. Frontend engineer naman ang gumagawa ng paraan para gumana iyon sa totoong product.
Kung makakapagdala ang designer ng working component sa halip na static screen, mas makakapag-focus ang frontend developer sa integration. Ikokonekta niya ang real data at APIs, hahawakan ang state at authentication, aayusin ang loading at error cases, iche-check ang accessibility at performance, at sisiguraduhing gumagana pa rin ang lahat kapag wala na sa happy-path demo.
Ito yung frontend work na mas gusto kong paglaanan ng oras. Makakatulong ang AI, pero hindi nito pananagutan ang consequences kapag nasira ang system. Mas mahirap ang matitirang trabaho para sa frontend engineers at, sa totoo lang, mas interesting din. Mas mataas nga lang ang expectation. Humihina na yung excuse na “wala naman sa design” kapag kayang magbigay ng designer ng working version ng ibig niyang sabihin.
baka hindi mahalaga ang title
Hindi ko alam kung bawat company ay kukuha ng taong may “Design Engineer” sa job description. Marami nang tech titles ang nauso tapos nawala rin makalipas ang dalawang taon. Ang malinaw sa akin, natututo nang mag-build ang mga taong may malakas na design judgment. Samantala, nawawalan ng leverage ang mga taong obvious execution lang ang kayang gawin.
Tawagin mo ang role kung ano ang gusto mo. Kung may isang designer na dumating na may panibagong Figma link at may isa namang may working component na malinaw nang ipinapakita ang interaction, alam ko kung kaninong idea ang mas madaling maintindihan. Alam ko rin kung kaninong opinion ang mas pakikinggan sa room.
Comments