Integrating AI into product design and strategy
Every agency says it uses AI. This guide shows product leaders where AI should show up in design workflows, AI product UX and design infrastructure, and what evidence to ask for at each level.
A product leader putting together an agency shortlist in 2026 will hear the same line from every candidate: “we use AI.” The phrase covers anything from a designer pasting notes into a chatbot to agents that draft screens from a documented design system. On its own, it says nothing about who checks the output or what the client keeps.
A more useful test is where AI enters the work and what it leaves behind that someone can inspect. Agencies that use AI in their process, rather than only talking about it, can show evidence at three levels: the design team’s own workflow, the AI features inside the product, and the infrastructure that keeps both consistent. This guide walks through each level for product leaders deciding what to buy. Humbleteam publishes it and offers work at all three levels, so treat its examples as one reference point and ask every candidate for the same evidence.
Adopting AI tools and workflows in design teams
Adoption rarely starts evenly. Figma’s 2026 AI report, drawn from 8,403 survey responses, found that 41% of respondents say AI meaningfully changes how their teams work together, up from 7% two years earlier. The report describes four adoption patterns, from grassroots experiments to top-down mandates, and points to the friction that appears when teams lack a shared playbook.
An agency that helps a team adopt AI should start from tasks, not tools. Studios that publish their methods tend to be specific. A reading companion to Design Week’s series on studio AI use summarizes 18 studios by “the exact tools they reach for, what they use them for.” ChatGPT comes up most often, named by 8 of the 18. Ask agencies for the same level of detail about their own work.
The table below is an illustrative checklist, not an industry standard. It maps stages of product design and strategy work to the evidence that real use leaves behind.
| Stage | Where AI helps | Evidence to ask for |
|---|---|---|
| Research synthesis | Clustering interview notes, drafting discussion guides | Source notes beside each finding, and the researcher’s corrections |
| Product strategy | Stress-testing hypotheses, comparing directions | The options considered, the criteria, and who made the call |
| Prototyping | Drafting flows and variants from a brief | The brief, the rejected drafts, and the reasons |
| Design system | Generating states and variants from approved components | The rules the tools read, and a check that flags off-system output |
| Handoff and QA | Specs, resizing, design QA | The human review step before anything reaches engineers |
The design system is where adoption becomes repeatable. Large public systems now document AI patterns next to their other components. IBM’s Carbon for AI adds an AI label, explainability guidance and dedicated color tokens for marking AI-generated content. AWS’s Cloudscape breaks generative AI interactions into parts such as the entry point, user input, the in-progress state and the output.
A team bringing AI into its process needs two kinds of entry in its system: rules for how AI features look and behave in the product, and rules its own tools can read when they draft work. Humbleteam’s published Cluely example on its AI infrastructure page shows the second kind in use. Agents handle the routine build from the design system, the designer does the final pass, and a human signs off before anything merges.
Designing UX for AI-powered products
Designing a copilot or a chat interface is a different job from using AI inside the design team. An agency can do one well and not the other, so ask for evidence of each separately.
The problems are familiar. A chat box gives people no hint of what to ask. Generated answers take time, can be wrong, and can sound sure of themselves when they are. Microsoft’s HAX Toolkit organizes 18 guidelines for human-AI interaction around four moments: the first interaction, during interaction, when the AI system is wrong, and over time. A useful design review walks through the same four moments for the product in question.
Agentic features add a question of control. Before an agent acts on a user’s behalf, the interaction model should state what it may do alone, what needs confirmation, how progress is shown, and how an action is undone or passed to a person. Writing those rules down before visual design starts keeps the agent useful without burying the user in prompts and approvals. The comparison of agencies that design AI agent flows goes deeper into confirmation, undo and human handoff.
The Cluely case shows how this plays out in one product. For a real-time meeting assistant, Humbleteam treated attention as the central design constraint: suggestions stay at the edge of the screen, and the assistant never joins the call as a participant. Its other AI product work includes UX/UI for Synthesia’s text-to-video platform and a redesign that gave VOS users access to new AI tools for analyzing their mental health data, both listed on its page for AI companies. The services listed there are prototyping, product UX, websites and landing pages, mobile UX/UI and branding.
A request such as “we want AI agents in our design process” belongs to the next section. Setting up agents for designers is infrastructure work. Designing agents for customers is product UX.
Building AI infrastructure for design
“AI infrastructure” usually refers to compute, models and data platforms. For a design team, the useful infrastructure is narrower: a documented design system that tools can read, design tokens kept in code, agreed review gates, and access that stays in the team’s own accounts. General infrastructure runs the models, while design infrastructure decides what they may produce and who approves it.
Building it starts with data about the current work, not a tool list. Humbleteam’s AI infrastructure service describes three steps: look at how the team works across tasks, backlog, design system and handoff; produce a plan for which agents to set up; then implement them and train the team to run them. The same page says the agents live in the client’s workspace on the client’s billing, with model training on client data switched off.
The link to product strategy comes from choosing which tasks to automate. A team planning more experiments needs variants drafted from its design system. A team in the middle of a rebrand needs every screen state regenerated consistently. A team with a growing handoff backlog needs specs and QA. Each choice should trace back to a roadmap goal, and its results should be counted in accepted work, including the review time that work took.
To test whether an agency can build this, give it a bounded task and follow it from brief to approved result. The guide to evaluating an AI design agency’s workflow infrastructure lists the evidence to request, and the AI workflow training pilot explains how to check that your team can run the setup without the agency.
Before the first agency call
- List the 3 design tasks that eat up the largest share of hours, and the person who reviews each one.
- Ask every agency for one example per level: a workflow, an AI feature and the infrastructure behind it.
- Check whether your design system covers AI patterns: labels, waiting and error states, and confirmation rules.
- Agree where agents will run, whose accounts hold the files and who maintains the setup.
- Run one bounded task and measure the accepted output, including review and corrections.
