Prompt and Logic Design for SaaS: Why UX Designers Need to Own It?

When a SaaS product team ships an AI feature, there is a moment, usually during a sprint review, when someone asks: “who owns the prompt?” The answer is almost always “engineering.” The prompt is a technical artefact. It lives in the codebase. It is written in plain text but deployed like code. It controls the model. Naturally, it belongs to the people who control the model. This is the wrong answer. The prompt is the most consequential UX decision in an AI feature. It determines what the AI sounds like, what it will and will not do, how it handles ambiguous input, what format its output takes, and how it behaves at the edge cases that matter most to user trust. These are not engineering decisions. They are product and UX decisions that happen to be implemented in a text file. At Inity Agency, prompt and logic design is a UX responsibility in every AI feature engagement, here is why, and what it actually involves.

What a Prompt Actually Is in a SaaS Context

In a SaaS product with an AI feature, there are typically two types of prompts:

The system prompt – a set of instructions provided to the model before any user interaction. It defines what the AI is, what it can and cannot do, how it should respond, and what constraints it operates under. The user never sees the system prompt, but every response the AI generates is shaped by it.

The user prompt – the input the user provides at interaction time. In a chat interface, this is what the user types. In a non-conversational AI feature (a “Summarise this document” button, an automatic classification system), the user prompt is constructed by the product: the document text, the data, the context, assembled by the backend before being sent to the model.

In most SaaS products, the system prompt is the critical design surface. It is where the product team defines the AI’s behaviour. Getting it right is the difference between an AI feature that feels like a natural extension of the product and one that feels generic, off-brand, or unreliable.

What a Well-Designed System Prompt Contains

1. Role Definition

The system prompt begins by telling the model what it is and what context it is operating in. This is not “you are a helpful AI assistant” — that is the default behaviour of every general-purpose model. A product-specific role definition tells the model:

• What product is it part of (“You are the AI assistant embedded in [Product Name], a compliance management platform for care home operators”)
• Who the users are (“Your users are care home managers and compliance officers responsible for tracking regulatory deadlines across multiple care settings”)
• What its primary job is (“Your primary job is to help users understand their compliance status, identify upcoming deadlines, and generate audit-ready reports from their compliance records”)

Role definition grounds the model in the product’s specific context. Without it, the model will produce generic, technically accurate responses that may be contextually useless.

2. Task Scope

Task scope defines what the AI should and should not do, the boundaries of its responsibility. This is a product decision with UX implications: if users ask the AI to do something outside its scope, how should it respond? What should it redirect them to?

Task scope in a system prompt explicitly states:

• What the AI is designed to help with (in plain terms, with examples)
• What it should decline to help with and why (“If users ask for legal advice, explain that you cannot provide that and recommend they consult their legal team or regulator”)
• How it should handle ambiguous requests that could be in or out of scope

Scope definition prevents the AI from becoming a general-purpose chatbot embedded in a specialist product — one of the most consistent causes of AI feature trust erosion.

3. Output Format Specification

The format of the AI’s output is not determined by the model, it is determined by the prompt. And the format is a UX decision: what format will users find most useful for this specific context?

A compliance manager asking “what are my upcoming deadlines?” needs a structured list, sorted by urgency, with dates clearly visible. Not three paragraphs of prose. The system prompt must specify this:

“When presenting compliance deadlines, always use a structured list format with the deadline name, date, property name, and urgency level (Critical/High/Medium/Low) on separate lines. Sort by date ascending. Do not provide prose descriptions unless the user asks for more detail on a specific deadline.”

Output format specification covers: format (list, table, prose, structured JSON for rendering), length (maximum word count, level of detail), section structure (headings, subheadings, bullet points), tone (formal, conversational, clinical), and what to include vs exclude.

4. Constraint Rules

Constraints are the rules that prevent the AI from doing things the product should not do. They are a combination of legal risk management, brand protection, and user safety decisions.

Common constraint categories:

• Data constraints – “Only reference information from the user’s own compliance records. Do not make assumptions about compliance status from general regulatory knowledge.”
• Accuracy constraints – “If you are not certain of a compliance deadline date, say so explicitly. Do not generate a date unless it comes from the user’s records.”
• Scope constraints – “Do not provide legal advice, interpret regulatory requirements, or make determinations about compliance status that are not directly supported by the user’s records.”
• Safety constraints – “If a user describes a situation that suggests immediate risk to resident safety, prioritise signposting to the appropriate authority over continuing the compliance conversation.”

Constraints are written by the UX team in collaboration with legal, compliance, and product. They require an understanding of what the product should never say or do, in the context of the user’s expectations and the product’s liability exposure.

5. Few-Shot Examples

Few-shot examples are examples of ideal inputs and outputs embedded directly in the system prompt. They are one of the highest-leverage prompt design techniques because they show the model exactly what good looks like, more precisely than any instruction.

A few-shot example for a compliance AI might look like:

Example input: “When is my next gas safety certificate due?”

Ideal output: “Your gas safety certificate for Oakfield House is due on 15 March 2026 — in 34 days. This is marked as High priority. To view the certificate history or add a new certificate, go to Oakfield House > Compliance > Gas Safety.”

Writing few-shot examples is a UX design task, it requires knowing the user’s language, the product’s navigation, the appropriate level of detail, and the right tone for the context. Three to five well-designed examples produce a dramatically more consistent and product-appropriate AI output than instructions alone.

6. Edge Case Handling

Edge cases in prompt design are the scenarios that fall outside the expected happy path: ambiguous queries, out-of-scope requests, inputs that contain sensitive information, and queries that the AI cannot answer reliably.

Each edge case needs an explicit handling instruction in the system prompt. Without it, the model will improvise, and improvised edge case handling is what produces the AI outputs that make product teams look bad.

“If the user asks about a property or deadline that does not appear in their records, say so clearly and ask whether they would like to add a new record. Do not speculate about what the deadline might be based on regulatory knowledge.”

Prompt Logic: When the Prompt Changes Based on Context

A static system prompt that never changes is appropriate for simple AI features. Most product AI features need prompt logic — decision rules that govern how the prompt varies based on context.

Common prompt logic patterns in SaaS:

Role-based prompting: Different user roles receive different system prompts. A manager prompt enables generating reports and viewing team-level data. An operator prompt scopes the AI to their specific assigned properties. The logic that selects which prompt to use based on the authenticated user’s role is a product logic decision, implemented in the backend.

Context injection: Data relevant to the user’s current context is dynamically injected into the prompt. “The user is currently viewing the compliance dashboard for Oakfield House. Their upcoming deadlines in the next 30 days are: [dynamically retrieved list].” This context injection is what makes the AI feel like it knows the user’s situation rather than operating on generic knowledge.

Query routing: Some queries should be handled by different models or different prompt configurations. A simple factual query (“when is my next deadline?”) is handled by a retrieval prompt. A complex analysis query (“which of my properties has the highest compliance risk?”) might be routed to an analytical prompt with different format and depth instructions.

Designing these logic rules is a product decision with significant UX implications; it directly determines how context-aware and personalised the AI’s responses feel.

Testing Prompts Like Usability Testing

The process of evaluating and improving a product prompt is essentially identical to usability testing:

1. Recruit five to ten users (or simulate representative users) with realistic task scenarios
2. Present each task scenario to the AI and observe the output
3. Evaluate each output against the criteria: Is it accurate? Is it the right format? Does it match the product’s tone? Does it handle the edge case correctly?
4. Identify the patterns of failure, the prompt instructions that are unclear, missing, or producing consistently wrong behaviour
5. Revise the prompt and re-test

The iteration cycle is fast, prompt changes take minutes to implement and can be tested immediately. This makes prompt testing the highest-leverage low-cost UX research in an AI feature development process. Three rounds of prompt testing, starting before development completes, consistently produce AI features that are significantly more usable than those that ship without prompt iteration.

How Inity Handles Prompt and Logic Design

At Inity, prompt and logic design is a parallel track to AI interaction flow design; both happen during the Feature Design phase of an AI development engagement, before implementation begins.

The UX lead owns the system prompt draft, the few-shot examples, and the edge case handling instructions. The engineering lead owns the prompt logic, context injection, query routing, and role-based selection. Both review and iterate on each other’s work. The first draft prompt is tested against representative user scenarios before development begins.

Conclusion

The prompt is the most consequential and least understood UX surface in a SaaS AI feature. It is written in plain text, which makes it seem like a writing task. It is deployed in the codebase, which makes it seem like an engineering task. It is neither. It is a product design task that requires understanding the user’s context, the product’s use case, the edge cases users will encounter, and the tone and format that will make the output useful. The teams that understand this and assign prompt ownership to the people who understand users, not just models, consistently ship AI features that feel intentionally designed rather than generically capable.

→ Building AI features and not sure who should own the prompt? Inity’s AI development service includes prompt and logic design as a core deliverable, owned by the product design team. Book a call.