Three AIs, One Design System
How I turned scattered AI use into governed product workflows for illustration, copywriting, and prototyping across Branch International's product team.
Branch's product team works across India, Kenya, and Nigeria, supporting areas such as onboarding, KYC, loans, repayments, rewards, account management, customer support, risk, and operations.
AI was already entering the team's workflow. In a product-team poll I ran, everyone responded, and the results showed that AI was already being used for copywriting: 65% used ChatGPT, 20% used Claude, and others used Gemini.
The issue was not adoption. The issue was reliability. Generic tools could produce fast outputs, but those outputs often lacked Branch's product reality, market nuance, brand voice, component context, and design-system logic.
Branch did not need AI experiments. It needed governed AI workflows for product work.
Input came through 1:1s, Slack DMs, product reviews, presentations, FigJam voting, and direct testing.
Across 530 screens, with 1,778 copy changes implemented.
Directional reduction in evaluation time based on general PM feedback.
Across Branch, PMs, designers, and researchers were already using ChatGPT, Claude, and Gemini to rewrite copy, explore flows, and create early ideas. But every person brought their own prompt, context, and quality bar.
Generic AI tools did not know which products existed in each market. They did not understand how copy should change between a button, screen title, error message, banner, toast, or form description. They also did not know how Branch's product should sound.
The opportunity was to move from loose personal productivity to governed workflows that made AI more useful, consistent, and safe for real product work.
Research Inputs
I used lightweight research methods because the work was internal and moving quickly. The goal was to understand real AI use, not theoretical interest.
| Method | Who was involved | What I wanted to learn |
|---|---|---|
| 1:1 conversations | PMs, researchers, designers | How teams were already using AI and where outputs failed |
| Slack DMs | PMs, researchers, designers | Specific pain points from day-to-day copy and workflow use |
| Copywriting poll | Full product team | Which AI tools people used for rewriting copy |
| Product-wide reviews | PMs, designers, researchers, stakeholders | Whether the proposed systems matched real team needs |
| FigJam voting | Product team | Which illustration direction felt most aligned with Branch |
| Direct tool testing | PMs, designers, developers | Whether the workflows were useful in real work |
Adoption was already happening. The problem was that every person was bringing their own prompt, context, and quality bar.
What I Discovered
The research changed the brief. The team did not need to be convinced to use AI. It needed governance, context, and clearer review points.
| Finding | What it meant | Design response |
|---|---|---|
| AI adoption already existed | The team did not need convincing to try AI | Focus on governance, not novelty |
| Outputs lacked product truth | AI could reference unavailable products or wrong service states | Add product and market rules |
| Market language differed | The same copy could feel natural in one country and wrong in another | Add market-specific terminology |
| Brand voice was inconsistent | Outputs sounded polished but not like Branch | Encode brand voice rules |
| Component context was missing | CTAs, titles, descriptions, errors, empty states, and toasts needed different treatment | Add component-level copy rules |
| Prototypes felt generic | Claude could prototype, but not in Branch UX patterns | Map prompts to Neem components and Branch screen patterns |
| Illustration styles were fragmented | Screens used mixed visual languages | Align the team on one reusable illustration system |
The Strategic Decision
At first, the obvious answer looked like better prompts. But the deeper issue was governance. People already had access to AI tools. What they did not have was a shared system that understood Branch's products, markets, design language, and quality bar.
I treated each workflow like an internal product: define the user and use case, understand failure points, encode product rules, create reusable workflows, test with real team members, turn repeated feedback into system constraints, and keep humans in control of final approval.
Initiative 01 - Illustration GPT
Creating one visual language for Branch product illustrations.
Problem
The issue was not just speed. It was visual consistency. Branch's existing illustration set had grown across different needs and contributors. Some screens used 3D-style assets, others used line illustrations, and some used softer Notion-like visuals. Individually, some assets worked. Together, they did not feel like one product system.
The first challenge was not generating images. It was helping the team align on what Branch illustration style should become.
What I designed
I created an Illustration GPT that could generate Branch-aligned product illustrations using structured rules for colour balance, material treatment, lighting, perspective, product relevance, reusable composition, output quality, and market adaptability.
The goal was not to create random AI illustrations. The goal was to create a repeatable illustration system that could support product surfaces across India, Kenya, and Nigeria.
Team alignment and iteration
To converge on a style, I ran three public review sessions where I presented multiple illustration directions to the product team. I also ran a FigJam vote so designers, PMs, researchers, and stakeholders could compare options and express preferences.
Repeated feedback became a system rule. Isolated preferences were noted but not over-weighted. This helped move the team from subjective opinions to shared visual principles.
Six Major Versions of Illustration System Refinement
The illustration system evolved through repeated review, testing, and constraint tuning. The main work was finding the right level of strictness: enough to create consistency, but flexible enough to support different product moments.
| Version | What changed | Why it changed |
|---|---|---|
| v1 | Established the first Branch illustration rules, materials, and manifest | Create a consistent baseline |
| v2 | Refined early style rules and material handling | Improve alignment with Branch preferred visual direction |
| v3 | Added stronger instructions and more detailed rules | Reduce inconsistent outputs across prompts |
| v4 | Improved system structure and usage guidance | Make generation more repeatable |
| v5 | Expanded rule sophistication and prompt control | Improve quality, consistency, and production readiness |
| v6 | Tightened final system prompt, rules, materials, and manifest | Stabilise output for team use and rollout |
In practice, the iterations focused on colour balance, material realism, visual weight, lighting, background treatment, perspective, and how much freedom the GPT should have when interpreting a brief.
All illustration sets are ready. About 60% are live in the app, with the remaining rollout dependent on engineering bandwidth. The system reduced design review back-and-forth because new work started from clearer style rules and stronger shared alignment. This gave designers a shared visual baseline instead of restarting style debates for each new illustration.
Initiative 02 - Copywriting AI
Turning individual prompting into a market-aware copy workflow.
Problem
People were already using AI to write and rewrite product copy. The issue was that generic AI did not understand Branch deeply enough. It could produce clean English, but it often missed product truth, market nuance, brand voice, or component context.
A suggestion could reference a product that did not exist in a market, use terminology that felt unfamiliar to customers in that country, write a CTA like a paragraph, or ignore casing rules, character limits, and component-specific behaviour.
What I designed
I built a copywriting system using versioned JSON rule files and operating guides across brand voice, market terminology, product rules, component rules, heuristics, lint rules, material maps, and workflow guidance.
The system helped the team write, rewrite, and audit product copy against Branch's product reality.
Seven Iterations of Guardrail Tuning
The Copywriting AI evolved through seven versions. Each version adjusted how strict or flexible the system should be across brand voice, component rules, market language, linting, and product context. The work was less about adding features and more about tuning the rules until the system could produce useful copy without becoming rigid or generic.
| Version | What changed | Why it changed |
|---|---|---|
| v1 | Created the first rule system across brand, markets, components, heuristics, and material mapping | Establish a baseline for structured copy generation |
| v2 | Expanded market and component coverage | Early outputs still missed product and market context |
| v3 | Strengthened brand and lint logic | Improve consistency in tone, casing, and formatting |
| v4 | Refined heuristics and constraints | Make outputs more reliable across ambiguous product moments |
| v5 | Rebalanced rules to reduce over-correction | Some guardrails needed to be relaxed so copy could still feel natural |
| v6 | Added operating guide and stronger workflow structure | Make the system easier to use and repeat across teams |
| v7 | Tightened final rule logic across brand, market, lint, and component files | Stabilise the system after testing and feedback |
Across versions, the work moved from "rewrite this copy" to "rewrite, audit, and validate this copy against Branch's product reality."
Before and After: Turning Generic Copy Into Product-Ready Microcopy
To test the system, I audited real product surfaces and compared existing copy against Branch's market, brand, component, and UX writing rules. The goal was not to make copy sound nicer. It was to make each string clearer, more contextual, and more appropriate for the product moment.
| Product area | Component | Before | After | What improved |
|---|---|---|---|---|
| Onboarding | Screen title | Verify your mobile number | Enter your mobile number | Clearer task framing |
| Onboarding | Input label | Phone Number | Mobile number | Better India-market terminology |
| Onboarding | Input label | Email ID | Email address | More universal and easier to understand |
| OTP | Error message | Unfortunately, the provided code does not match. Please try again. | Incorrect OTP. Please try again. | Shorter, clearer, less formal |
| KYC | CTA | Proceed | Continue | More natural progression cue |
| Repayment | Section title | Repayment History | Payment history | Simpler and easier to scan |
Copy AI impact
The copywriting workflow supported 530 reviewed screens, 4,390 audited components, and 1,778 implemented changes across onboarding, KYC, loan, account, repayment, rewards, and support flows.
Copywriting became more reliable through Branch-specific product, market, component, brand, and lint rules. The workflow reduced design-review back-and-forth because first drafts started closer to Branch's product reality. This helped reduce review friction because copy started closer to Branch's product, market, and component standards.
Initiative 03 - Neem DS Prototyper
Helping PMs evaluate PRDs through interactive prototypes.
Problem
PMs could already use Claude to create rough prototypes, but the outputs did not understand Branch's UX patterns. Claude could generate a screen, but it did not know how Branch structured flows, how Neem components were used, what screen patterns were acceptable, or how product ideas typically moved through the app experience.
That made the prototypes useful as rough sketches, but weak as alignment tools. The opportunity was to make prototyping faster without making it generic.
What I designed
I created a prototyping workflow that helped PMs move from PRD or product idea to an interactive prototype using Branch's design-system logic. The workflow connected PRD input, Claude Skill interpretation, Figma MCP context, Neem component mapping, token-compliant React prototypes, stakeholder review, and PRD refinement before high-fidelity design.
The Neem DS Prototyper reduced PRD evaluation time by about 30%, based on general feedback from PMs. The tool was tested directly by PMs, designers, and developers. The biggest shift was not only speed: stakeholders could respond to interactive prototypes earlier, before work moved into high-fidelity design. This made PRD feedback more concrete because stakeholders could react to an interaction, not just a written description.
Testing and Feedback Loops
I tested the workflows with the people who would actually use them: designers, PMs, UX researchers, and developers. Feedback came through 1:1 conversations, Slack DMs, product-wide presentations, show-and-tell sessions, FigJam voting, and direct tool testing.
Each tool had a different feedback loop. Illustration GPT focused on visual alignment with designers and the wider product team. Copywriting AI was tested broadly because designers, PMs, and UX researchers all wrote copy. Neem DS Prototyper was tested by PMs, designers, and developers to check whether prototypes were useful for PRD evaluation and stakeholder feedback.
The feedback helped separate novelty from usefulness. If a tool only produced impressive outputs, it was not enough. It had to reduce real workflow friction.
What Changed Across the Product Team
The work helped Branch move from scattered AI experimentation to governed AI-assisted product work.
| Area | Before | After |
|---|---|---|
| AI usage | Individual use of ChatGPT, Claude, and Gemini | Shared AI workflows with Branch-specific rules |
| Copywriting | Manual rewrites and repeated review cycles | Market-aware copy generation and audit workflow |
| Illustration | Mixed styles across product surfaces | Unified illustration direction with reusable generation rules |
| Prototyping | PRDs reviewed mostly as written documents | Interactive prototypes used for earlier stakeholder feedback |
| Review | Subjective feedback and repeated corrections | Clearer guardrails, quality checks, and approval points |
| Team enablement | AI value depended on individual prompting skill | PMs, designers, and researchers had reusable systems |
“He is an AI-native builder with a designer's eye and a PM's brain.”
What I Learned
- AI quality depends on context, not just model capability: The same AI tool can produce weak or useful output depending on the rules, examples, constraints, and product knowledge it receives.
- Guardrails need tuning: Too few guardrails produced generic outputs. Too many made the system rigid. The work was finding the right balance between consistency and flexibility.
- Internal AI tools need product thinking: A useful workflow needs clear users, repeated problems, feedback loops, usage patterns, constraints, and success criteria.
- Human review still matters: The goal was not to remove human judgement. It was to help teams start closer to the right answer, reduce repeated corrections, and spend more time on higher-quality decisions.
The real contribution was not just creating three AI tools. It was designing product-team infrastructure that made AI more useful, more consistent, and more aligned with Branch's product reality.