> For the complete documentation index, see [llms.txt](https://docs.darcyiq.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.darcyiq.com/settings-and-configuration/design-md.md). # Design Standards Set organization-wide design and branding guidelines that DarcyIQ applies to every conversation, agent, and workflow. **Define your brand once with a Design.md, and Darcy uses it everywhere — no more manual formatting passes.** {% hint style="success" %} **One source of truth for your brand**: Upload your brand guidelines as a Design.md and every document, presentation, or piece of content Darcy generates will follow your standards automatically. {% endhint %} ## Overview A Design.md is a Markdown document that captures your design and branding requirements. DarcyIQ reads it whenever it produces output — chat responses, generated documents, presentations, charts, and agent deliverables — so the look, tone, and structure stay consistent with your brand. Organizations that own more than one brand can keep more than one. Each **brand** is its own Design.md with its own assets, one of them is the **default**, and anyone can switch brands for a single conversation. | Capability | Description | | ------------------------- | ---------------------------------------------------------------------------------------- | | **Organization-wide** | The default brand applies to every user, agent, and workflow in your organization | | **Multiple brands** | Sub-brands and product lines each get their own Design.md instead of sharing one | | **Markdown format** | Plain Markdown — easy to write, easy to review, and easy to keep under change control | | **Applied automatically** | Darcy respects the Design.md across chat, agents, and scheduled runs without prompting | | **Upload or create** | Start with your existing brand guidelines, a ready-made design system, or a blank editor | ## What to Include A good Design.md captures everything Darcy needs to know to produce on-brand output. Common sections include: | Section | Examples | | ---------------------- | ---------------------------------------------------------------- | | **Brand Identity** | Brand name, mission, audience, key value propositions | | **Voice & Tone** | Formal vs. conversational, when to use each, words to avoid | | **Typography** | Heading conventions, casing rules, formatting preferences | | **Color Palette** | Primary, secondary, and accent colors used in charts and visuals | | **Document Structure** | Standard sections for proposals, reports, briefs, etc. | | **Naming Conventions** | Product names, capitalization, trademarks, abbreviations | | **Content Rules** | Disclaimers, legal language, regional variations | | **Visual Guidelines** | Chart styling preferences, image orientation, layout principles | The format is flexible — anything you'd put in a brand-guidelines document can go here. Use headers, lists, and examples liberally so Darcy can follow them precisely. ## Setting Up Your Design.md {% stepper %} {% step %} **Open Brand Management** Navigate to **Settings → User Configuration → Brand Management** and find the **Organization Brand** card. Only administrators and owners can make changes here. {% endstep %} {% step %} **Start a brand** Click **New brand** for a blank editor, or **Design Catalog** to start from one of the ready-made design systems included with Darcy. If you've never saved one, the editor is pre-filled with a draft generated from your existing settings — save it to make it your first brand. {% endstep %} {% step %} **Edit and Refine** Use the built-in Markdown editor to adjust headings, add examples, and tune the language. You can also paste in an existing brand-guidelines file. {% endstep %} {% step %} **Save** Click **Save** to publish it. The default brand takes effect immediately for all users, agents, and scheduled runs. {% endstep %} {% endstepper %} {% hint style="info" %} **Pro Tip**: Convert your existing brand guidelines PDF or doc into Markdown first, then paste it in. Darcy follows clearly structured rules better than long prose. {% endhint %} ## Working With Multiple Brands Your brands appear as cards, each showing its color swatches, with the default marked. Selecting a card opens it in the editor beside its assets. | Action | What it does | | ------------------ | --------------------------------------------------------------------------------------- | | **Set as default** | Makes this the brand Darcy uses when nobody picks one. There is always exactly one | | **Duplicate** | Copies a brand as a starting point — useful for a sub-brand that differs in a few rules | | **Delete** | Removes a brand. You can't delete the last one | There's a cap on how many brands an organization can keep; **New brand** and **Duplicate** are disabled with an explanation once you reach it. ### The Design Catalog Darcy ships with a catalog of ready-made design systems. Browse it from the **Design Catalog** button — adding one makes an **editable copy that you own**, so tuning it later never fights an upstream change. An administrator can turn the catalog off for the organization if only your own brands should be offered. ### Brand Assets Each brand carries its own asset library: logos, fonts, brand-guideline files, and reference imagery. Darcy stages these into its workspace **only when that brand is the one in use**, which is what keeps one brand's logo out of another brand's deck. {% hint style="info" %} **App Appearance is separate.** The logos and favicons that brand the DarcyIQ interface itself live in the **App Appearance** card on the same page — light and dark variants for each. They control what your team sees in the product, not what Darcy generates. {% endhint %} ## Choosing a Brand in Chat The composer has a **palette** control that asks *"Which brand should I use?"* Pick one and it applies to everything Darcy generates in that conversation — leave it alone and the organization default is used. The picker lists your brands first, with the default badged, and then the Design Catalog. A catalog entry chosen here applies to **that chat only**; it isn't added to your organization's brands. ### Design Polish The brand picker also has a **Design polish** switch. When it's on, websites, prototypes, interactive apps, and other generated UI are held to stricter design rules: deliberate layout, typography, spacing, and interaction states, plus a final quality check, instead of the generic look AI-built pages tend to have. * **On by default.** Turn it off for a conversation where you want quick, plain output, and the setting is remembered for that chat. * **Your brand still wins.** The selected brand's colors, fonts, logos, and voice take priority over the polish rules. * **Chat only.** Agents, automations, and API calls that don't set it are unaffected. * **Dashboards and forms stay practical.** For data-heavy UI, only the rules that improve clarity apply, such as consistent color and shape, interaction states, and contrast. ## Where Design.md Applies Once saved, Design.md is loaded automatically across DarcyIQ. You don't need to reference it in your prompts — it's always active. | Surface | How It's Used | | ----------------------- | ------------------------------------------------------------------------- | | **Chat** | Drives tone, formatting, and structure of Darcy's responses and artifacts | | **Agents** | Layered on top of the agent's own role and instructions | | **Workflows** | Applied to outputs generated by automated workflow runs | | **Scheduled Runs** | Respected during background agent runs that produce reports or content | | **Generated Documents** | Documents and presentations inherit your conventions | ## Editing and Versioning Design.md is a living document — update it whenever your brand evolves. * **Edit anytime**: Open the editor in Brand Management to make changes * **Immediate rollout**: Saved changes apply to new conversations and runs as soon as they're saved * **Admin-only**: Only organization administrators and owners can modify the Design.md ## Best Practices ### Writing Clear Guidelines 1. **Use structure**: Break rules into sections with clear headers — Darcy follows structured guidance more reliably than prose 2. **Include examples**: Show what good output looks like ("Use 'partner' not 'vendor' when describing relationships") 3. **Be specific about style**: "Headings in Title Case" beats "Use professional headings" 4. **List forbidden patterns**: Calling out what *not* to do is just as valuable as what to do ### Keeping It Maintainable | Practice | Recommendation | | -------------------------- | ---------------------------------------------------------------------------------------------- | | **Start small** | Begin with the rules that matter most and expand over time | | **Review periodically** | Treat Design.md like any brand asset — review quarterly | | **Version control** | Keep a copy in your team's repo or DAM so you can track changes alongside other brand assets | | **Test with real outputs** | After updates, ask Darcy to draft a representative deliverable to verify the rules are working | ### Pairing with Other Features * **Skills**: Use [Skills](/core-features/skills.md) for task-specific instructions while Design.md governs brand-wide rules * **Blueprints**: Pair Design.md with [Blueprints](/organize/blueprints.md) so generated documents inherit both your template and your brand * **Agents**: Build [Agents](/core-features/agents.md) without re-stating brand rules — Design.md already covers them {% hint style="info" %} **Pro Tip**: If a sub-brand or product line needs a different treatment, give it its own brand rather than burying the exception in one Design.md. Duplicate the brand it's closest to, change what differs, and let people pick it in chat. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.darcyiq.com/settings-and-configuration/design-md.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.