# Workflows AI Skill Lead Area · Workflows Move · Decision Map --- ## 1. What the Skill Does The Workflows skill helps teams translate design signals into the language of the business function they are trying to influence. It is the third move inside the Lead area of Glare's Decision Map. This is where a UX finding stops sounding like a design report and starts sounding like something the receiving team already cares about. Every company runs on workflows that are already in motion — sales cycles, marketing campaigns, engineering sprints, finance reviews. Design gets sidelined when it cannot connect to those flows. The same signal lands differently depending on who is in the room. A 79% task success rate means something different to a product manager than it does to a CFO or a legal team. The Workflows skill translates the same finding into eight different business languages so it reaches the right audience in the right terms. Each function has its own frame for what matters. | Function | What it tracks | Where design creates lift | |---|---|---| | Sales | Pipeline growth, conversion rates, quota attainment | Trial friction → smooth onboarding that accelerates revenue | | Marketing | Lead quality, campaign ROI, customer acquisition cost | User signals → sharper messaging and stronger campaign performance | | Product | Feature adoption, retention, product-market fit | Feature testing → early proof of adoption before launch | | Engineering | Velocity, rework costs, defect rates | Usability failures caught early → fewer post-launch fixes | | Strategy | Market share, innovation rate, competitive differentiation | Desirability signals → de-risked bets on new directions | | Operations | Efficiency, support costs, internal adoption speed | Design fixes → operational savings and smoother processes | | Finance | Revenue growth, margin, ROI | Design ROI made visible and defensible | | Legal | Compliance rate, liability cost, risk exposure | Consent and accessibility clarity → reduced regulatory risk | **The Function-First Rule** Teams often present design findings using design language — "users struggled with the flow," "satisfaction was low," "comprehension dropped." That language is accurate but it does not land. The receiving function is not tracking comprehension. They are tracking pipeline, velocity, handle time, or compliance rate. The rule is simple: before sharing any finding with a business function, translate it into their top three metrics. Do not lead with the design metric — lead with the number they already track, then show how the design signal explains it. A finding framed in the function's own language gets into decisions. One framed in design language gets noted and forgotten. --- ## 2. Business Benefit When design findings travel in the right language, they enter decision cycles instead of sitting in reports. Each function starts treating design signals as inputs to their own work — not as updates from a separate team. This helps teams: - get design findings into product roadmaps, sales decks, and finance reviews - build credibility with functions that have not historically worked closely with design - make the same research more valuable by translating it once for multiple audiences - connect design outcomes to the metrics each function is already held accountable for - create a habit of cross-functional signal sharing that gets stronger over time One finding, translated well, can move eight different conversations forward. --- ## 3. Skill Output When used correctly, the skill produces a translated finding for a specific business function. The translation shows: - the function's top metrics - the design signal reframed in the function's vocabulary - the signal chain from Design KPI to Product KPI to Business KPI for that function - the specific lift opportunity design creates for that function The example below shows how this works for a mobile banking dashboard — translated for three different functions. | Function | Translated Finding (Mobile Banking Dashboard) | |---|---| | Product | "Task success on finding transaction history improved from 61% to 79%. Low task success was limiting feature adoption. The fix should increase session return rate and reduce churn in the first 90 days." Jargon used: adoption rate, retention, churn. | | Engineering | "The current transaction history flow has a 39% failure rate in testing. Every failure at this stage becomes a support ticket or a post-launch fix. Resolving it before handoff will reduce defect rate and protect sprint velocity." Jargon used: defect rate, rework, velocity. | | Finance | "Improving first-click success from 61% to 79% on the core retention flow is a leading indicator for 90-day retention improvement. A 5% retention lift in this segment translates to measurable reduction in account closure and an increase in lifetime value per user." Jargon used: retention, LTV, account closure. | | Failure Mode to Watch | Presenting all three translations in one meeting. Each function needs its own conversation. Mixing vocabularies in a single readout makes the finding feel unfocused and none of the audiences take clear ownership. | | Next Step Handoff | → glare-lead-results to track whether the translated signal entered each function's decision cycle and moved the outcome | --- ## 4. Prompt Strategies The prompts below show different ways to use this skill. Each example uses a mobile banking dashboard update. --- ### Prompt 1 — Translation Entry: Reframe a finding for one function "We have a usability finding from our mobile banking dashboard: first-click success on transaction history improved from 61% to 79% after the redesign. We need to present this to our VP of Engineering next week. Using the glare-lead-workflows skill, translate this finding into Engineering's language — using their top metrics, their vocabulary, and the specific lift opportunity design creates for their team." **Why this works:** An engineering leader is not tracking task success. They are tracking defect rates, sprint velocity, and rework cost. This prompt uses the Engineering function template to reframe the same finding into a language that answers the question an engineering leader is already asking: will this reduce rework? **Best for:** - preparing a single-function readout after a research or testing sprint - any situation where a finding needs to reach a team that does not normally engage with design results - building a habit of translating findings before sharing them outside the design team --- ### Prompt 2 — Multi-Function Entry: Prepare the same finding for multiple audiences "We need to share our mobile banking dashboard results with three different audiences next week: our Product Director, our CFO, and our Head of Operations. The core finding is that first-click success on transaction history improved from 61% to 79%, which we believe connects to retention. Using glare-lead-workflows, translate this finding for each of the three functions — using their metrics, vocabulary, and lift opportunity — and tell us what to lead with in each conversation." **Why this works:** The same finding has three different stories depending on who is listening. The product leader wants adoption and retention. The CFO wants margin and churn reduction. Operations wants ticket volume and handle time. This prompt translates once for each audience so every conversation opens with the number the function already tracks. **Best for:** - preparing for a week with multiple stakeholder presentations - making one research cycle produce findings that are useful across the whole business - connecting the same design result to the different priorities of different decision-makers --- ### Prompt 3 — Lift Entry: Find where design creates value for an unfamiliar function "Our Legal team has raised concerns about the consent flow on our mobile banking dashboard. We have not worked closely with Legal before and we are not sure how to frame our design work in terms they care about. Using glare-lead-workflows, explain where design creates lift for a Legal audience, name the metrics they track, and help us frame our consent flow testing as a risk-reduction signal in their language." **Why this works:** Legal teams track compliance rates, liability costs, and regulatory risk — not usability scores. This prompt uses the Legal function template to reframe consent flow testing as evidence of risk reduction, giving the team a way into a conversation with a function that has historically been a blocker rather than a collaborator. **Best for:** - any initiative that involves a function design does not regularly work with - translating design testing into risk, compliance, or cost terms for non-product audiences - building new cross-functional relationships by showing up in the function's language first --- *Glare Framework · glare-lead-workflows · Lead Area* *Handoffs: glare-lead-business-goals · glare-lead-mapping · glare-lead-results · glare-design-review*