[{"data":1,"prerenderedAt":264},["ShallowReactive",2],{"layout-profile":3,"workflow-page-en":13},{"title":4,"acf":5,"featured_image":11},"Pablo Goris",{"actual_job":6,"role":7,"hero_title":8,"headline":9,"description":10},"Designer at Alea","Senior Product Designer","Hello! I'm Pablo","Designing clarity across products, systems and evolving workflows by combining UX, product thinking and AI accelerated execution to turn complex ideas into scalable experiences with real business impact.","",{"url":12,"alt":4},"/media/2026/02/pablo.webp",{"header":14,"journey":17,"flow":86,"roles":244},{"title":15,"subtitle":16},"A clear process, from initiative to production.","How I work with Digital Workers. People understand the problem, decide and validate. Digital Workers build with the published design system, and every risky step passes through a human gate before moving on.",{"eyebrow":18,"title":19,"intro":20,"thesis":21,"thesisMuted":22,"orLabel":23,"phases":24,"ctaText":84,"ctaLabel":85},"At a glance","The whole journey","Five phases. Every initiative starts the same way and only branches when it is time to build: either it is solved with what the design system already has, or a component is created or changed.","People decide and validate.","Digital Workers prepare proposals, build and document.","or",[25,40,52,64,73],{"label":26,"title":27,"goal":28,"steps":29},"Phase 1","Understand","What the problem is, and for whom.",[30,34,37],{"title":31,"who":32,"kind":33},"The initiative arrives","PO · Product Lead","person",{"title":35,"who":36,"kind":33},"Analyse the initiative","Product Designer",{"title":38,"who":39,"kind":33},"Research","Product Designer, supported by a Digital Worker",{"label":41,"title":42,"goal":43,"steps":44},"Phase 2","Decide","Which proposal solves the initiative.",[45,49],{"title":46,"who":47,"kind":48},"Prepare proposals","Digital Worker, led by the Product Designer","dw",{"title":50,"who":36,"kind":51},"Choose the path","gate",{"label":53,"title":54,"goal":55,"branch":56,"steps":57},"Phase 3","Build","With the system, never drawn by hand.",true,[58,61],{"title":59,"who":60,"kind":48},"A · Iterate screens","Digital Worker · Iterations",{"title":62,"who":63,"kind":48},"B · Evolve components","Digital Worker · Design system",{"label":65,"title":66,"goal":67,"steps":68},"Phase 4","Validate","Two human reviews before moving on.",[69,71],{"title":70,"who":36,"kind":51},"Approve",{"title":72,"who":32,"kind":51},"Second validation",{"label":74,"title":75,"goal":76,"note":77,"steps":78},"Phase 5","Ship","Only when the system has changed.","An iteration on path A ends at phase 4.",[79,81],{"title":80,"who":36,"kind":51},"Publish the library",{"title":82,"who":83,"kind":33},"Implement","Front end","Below, the same journey step by step: who does each thing and where a person decides.","See the flow in detail",{"eyebrow":87,"title":88,"intro":89,"lanes":90,"columns":98,"steps":104,"paths":136,"band":232},"The flow in detail","From initiative to production, step by step","Follow the entry up to the decision and choose a path at the end. The path opens right after it, and from the bar at the top you can go back to the start or switch to the other one. Click any step to see what happens in it.",[91,92,93,95,97],{"label":32,"kind":33},{"label":36,"kind":33},{"label":94,"kind":48},"Iterations",{"label":96,"kind":48},"Design system",{"label":83,"kind":33},[99,100,101,102,103],"1 · Initiative","2 · Analysis","3 · Research","4 · Proposals","5 · Decision",[105,110,115,120,127,131],{"num":106,"lane":107,"col":107,"role":32,"title":31,"hint":108,"detail":109},"01",0,"the problem, and for whom","It comes from the PO or the Product Lead. It can be a screen, a change to a component or a need that has no component yet. It doesn't have to name any piece of the system, but it does have to bring the problem, who it is for and what it should achieve.",{"num":111,"lane":112,"col":112,"role":36,"title":35,"hint":113,"detail":114},"02",1,"scope and goal","The Product Designer turns the initiative into questions: what problem it solves, for whom, what we already know and what we still need to find out. The research plan comes out of this.",{"num":116,"lane":112,"col":117,"role":36,"title":38,"hint":118,"detail":119},"03",2,"led by a person","Research is UX work and the Product Designer leads it. A Digital Worker can help find references or pull quantitative data, always on request. The interpretation and the conclusions belong to the Product Designer.",{"num":121,"lane":122,"col":117,"support":56,"role":123,"title":124,"hint":125,"detail":126},"·",3,"Digital Worker · support","Search and data","on request","Support for the research, not a step of its own. The Digital Worker delivers what it is asked for (searches, quantitative data, summaries of sources) and the Product Designer decides what to do with it.",{"num":128,"lane":122,"col":122,"role":63,"title":46,"hint":129,"detail":130},"04","led by the Product Designer","Building on the research, the Digital Worker prepares solution proposals from the design system: it reads the library registry and the document of each candidate component, and puts the options together. The Product Designer leads them, deciding what gets explored, asking for changes and discarding. The Digital Worker proposes; it doesn't decide. That is how a request like “add a dropdown” reaches the decision as concrete options, for example a split button from the Button family versus a Select variant.",{"num":132,"lane":112,"col":133,"gate":56,"role":36,"title":50,"hint":134,"detail":135},"05",4,"A: iterate · B: evolve","If everything exists, it goes down path A, iterate screens. If a new component has to be created or an existing one changed, down path B, evolve components. Structural changes (renaming, adding or removing variants, turning a frame into a component, deleting, or anything that touches many instances) are approved here, before anything is built. Minor work, like a description or a screenshot, goes ahead and is reported afterwards.",[137,187],{"key":138,"label":139,"title":140,"meta":141,"lane":117,"columns":142,"steps":147,"notes":182},"A","Path A","Iterate screens","7 steps · ends at validation",[143,144,145,54,146,70,66],"Brief","Check","Compose","Verify",[148,153,158,163,168,173,178],{"num":149,"lane":112,"role":36,"title":150,"hint":151,"detail":152},"A1","Write the brief","with the library enabled","The brief comes out of the research and is written in the team's own file, never in the library. Typing @ references a component, a variable or a style. It doesn't have to be perfect: the Digital Worker will ask one specific question if something that changes the layout is missing. On structure and nesting, though, it has to be unambiguous.",{"num":154,"lane":117,"role":60,"title":155,"hint":156,"detail":157},"A2","Check the ground","stop if the library is missing","Before drawing anything, it checks that the library is enabled in the file. Without it, the pieces render almost invisible because the theme variables are missing. If the library is out of date and a template is missing, it stops and asks for a republish instead of building a partial version.",{"num":159,"lane":117,"role":60,"title":160,"hint":161,"detail":162},"A3","Compose, don't draw","template → pattern → atoms","It uses the highest-level piece that fits and works down from there. A full screen starts from a template, composed UI comes from patterns, and atoms only go where nothing higher exists. Assembling atoms by hand into something the system already serves as one piece is the violation.",{"num":164,"lane":117,"role":60,"title":165,"hint":166,"detail":167},"A4","Build and fill","the skeleton through the API","The skeleton always goes through the API: import by key, instance, and detach when needed, but never rebuild. Then come the real copy, the real values and the right variants, with nothing the brief didn't ask for.",{"num":169,"lane":117,"role":60,"title":170,"hint":171,"detail":172},"A5","Verify and hand back","provenance + what's missing","It takes a screenshot and compares it with the brief. The checklist looks at where each thing came from more than at how it looks: whether the page comes from a template, whether the table is the kit's, whether the gutter is still there. It hands back a named, dated frame, the pieces it uses, and everything the brief needed that the system didn't have. That is what opens path B.",{"num":174,"lane":112,"role":36,"title":175,"hint":176,"detail":177,"gate":56},"A6","Approve the iteration","first validation","The Product Designer reviews the iteration against the research and the brief. Only what they approve reaches product.",{"num":179,"lane":107,"role":32,"title":72,"hint":180,"detail":181,"gate":56},"A7","against the initiative","The PO or the Product Lead reviews the approved iteration against the initiative that opened the flow. They accept it or send it back.",[183,185],{"from":179,"to":149,"label":184},"rejected → back to the brief",{"from":169,"to":164,"label":186},"fails verification → rebuild",{"key":188,"label":189,"title":190,"meta":191,"lane":122,"columns":192,"steps":197,"notes":227},"B","Path B","Evolve components","7 steps · reaches production",[193,146,194,70,66,195,196],"Create","Document","Publish","Consume",[198,203,207,211,216,219,223],{"num":199,"lane":122,"role":63,"title":200,"hint":201,"detail":202},"B1","Create in the system","from what already exists","The component is built inside the library from existing components, incrementally, one verifiable step at a time. Nothing the system already has gets drawn again.",{"num":204,"lane":122,"role":63,"title":146,"hint":205,"detail":206},"B2","render, then read","A rendered screenshot plus a structural read of every variant: which token each state binds to, no loose shapes, no primitives, no detached instances and no dependency on another library. A change isn't done because the script ran; it is done when the result has been inspected.",{"num":208,"lane":122,"role":63,"title":194,"hint":209,"detail":210},"B3","in the same task","The component's document and the registry are updated in the same task as the change in Figma, never later. Documentation updated later is documentation nobody trusts.",{"num":212,"lane":112,"role":36,"title":213,"hint":214,"detail":215,"gate":56},"B4","Approve the change","component and document","The Product Designer reviews the component and its documentation together, against the research that opened the change.",{"num":217,"lane":107,"role":32,"title":72,"hint":180,"detail":218,"gate":56},"B5","The PO or the Product Lead checks the approved change against the original initiative. If they reject it, it goes back to the proposals, not to building: if the wrong solution was picked, building faster won't fix it.",{"num":220,"lane":112,"role":36,"title":80,"hint":221,"detail":222,"gate":56},"B6","always a person","A person publishes. The Digital Worker can't, and that is deliberate: publishing is what makes a change real for every file that uses the library at once. Until then, the key doesn't resolve anywhere.",{"num":224,"lane":133,"role":83,"title":82,"hint":225,"detail":226},"B7","published key + contract","The visual half comes from Figma: measurements, the variable bound to each property and the component's description. The contract half comes from the documentation. A component is never rebuilt from values: the published key is instanced.",[228,230],{"from":217,"to":128,"label":229},"rejected → back to the proposals",{"from":204,"to":199,"label":231},"fails → rebuild",{"label":233,"rows":234},"What the Digital Workers read",[235,238,241],{"title":236,"text":237},"Published library · “DS Library”","The only thing a screen can be composed from. It is imported by its published key.",{"title":239,"text":240},"Custom skill · “/figma-agent”","The iterations Digital Worker's: build hierarchy, the clone-and-detach recipe, the padding rule and the checklist.",{"title":242,"text":243},"Registry and documentation","The design system Digital Worker's: the keys, nodes and axes of each component, and one document per component with anatomy, tokens and accessibility.",{"eyebrow":245,"title":246,"intro":247,"items":248},"Responsibilities","Who does what, and what they never do","That is why the gates are where they are.",[249,252,255,258,261],{"kind":33,"title":32,"does":250,"never":251},"Brings the initiative and does the second validation.","Never edits the library.",{"kind":33,"title":36,"does":253,"never":254},"Analyses, leads the research, chooses the path, approves every iteration and every change, and publishes.","Never publishes anything unverified.",{"kind":48,"title":94,"does":256,"never":257},"Builds screens with the published library in the team's file and hands back what is missing.","Never touches the library.",{"kind":48,"title":96,"does":259,"never":260},"Prepares proposals from the system, builds in the library, verifies and documents in the same task.","Never publishes, renames or deletes without approval.",{"kind":33,"title":83,"does":262,"never":263},"Implements against the published key and the written contract.","Never copies values off a screenshot.",1793895644599]