Support and implementation guidance
Every product we ship includes documentation. But documentation alone does not always cover the specific integration question you run into at 2pm on a Wednesday when a layout is not behaving the way you expected. This page consolidates the most common support paths, setup questions, and implementation guidance for working with our design systems, documentation themes, and page templates.

The fastest path to answering most questions is the product documentation itself. Each product includes setup instructions, configuration references, and usage examples written for developers who want to get moving without reading through pages of preamble.
If you are working with one of our products and are not sure where the docs live, start with the products overview. Each product card links to its documentation, demo, and any relevant resource guides.
Product documentation
Documentation for each product is structured around the tasks you are most likely doing. Installation comes first. Then configuration. Then component usage, customization, and advanced patterns. We do not bury the practical information behind conceptual introductions.
- Design system docs cover component APIs, token structures, and layout primitives
- Documentation theme docs cover sidebar configuration, search setup, shortcodes, and content structuring
- Page template docs cover section layouts, hero patterns, responsive behavior, and content slot usage
Installation and initial setup
Most of our products are distributed as downloadable packages. The typical setup flow involves extracting the files, installing dependencies, and running a local development server. Each product README covers the specific steps, but the general pattern is consistent across everything we ship.
If you are seeing missing dependency errors during installation, check that your Node.js version matches the minimum requirement listed in the product docs. We test against current LTS releases. Older versions may work but are not guaranteed.
Customizing design tokens
Our design systems ship with a default token set that covers color, spacing, typography, and elevation. To customize tokens, modify the token source files and rebuild. The token architecture is flat by default with optional nesting for teams that prefer hierarchical organization. The design tokens guide covers this in depth.
Do not override tokens by writing CSS that targets generated class names. That approach breaks on updates. Use the token files as the single source of truth and let the build pipeline do its job.
Documentation theme configuration
Sidebar navigation in Ace themes is driven by a configuration file, not by file system structure. This is intentional. File system driven navigation works for small sites but falls apart when you need to control ordering, group pages logically, or handle sections that span multiple content areas.
If your sidebar is not rendering the way you expect, check the navigation config file first. A common issue is nesting depth. The themes support up to three levels of nesting by default. Going deeper requires a configuration flag and usually indicates a content structure that should be reorganized instead.
Page template customization
Page templates use content slots for flexible section composition. Each section is an independent block with its own layout logic, spacing, and responsive behavior. You can reorder sections, remove them entirely, or duplicate them for A/B testing different content flows.
If a section is not aligning the way you expect, check whether you are mixing template sections with custom markup. Template sections expect to be direct children of the page container. Wrapping them in additional divs breaks the spacing and alignment system.
Integrating with existing projects
Our products are designed to work as standalone projects or to integrate into existing codebases. The integration path depends on what you are working with. Design systems integrate at the component and token level. Documentation themes typically run as separate sites or subsites. Page templates can drop into any project that supports their underlying framework.
The most important thing to get right during integration is the CSS scope. Our products use namespaced class names to avoid conflicts. If you are seeing style collisions with your existing styles, check that you are not applying global resets that override our component styles. The documentation for each product includes a section on CSS integration.
Responsive behavior
Every product we ship is responsive by default. Breakpoints follow a mobile first approach with consistent thresholds across all products. If you are adding custom sections alongside our components, match the breakpoints documented in the product you are using. Mixing breakpoint systems creates layout inconsistencies that are painful to debug.
Browser support
We support current versions of Chrome, Firefox, Safari, and Edge. We test against the two most recent major releases of each browser. If you need to support older browsers, check the product documentation for any known compatibility notes and consider running the CSS through an autoprefixer pipeline.
Performance considerations
Our products are built with performance as a constraint, not an afterthought. CSS is minimal and scoped. JavaScript is loaded only where interactive behavior requires it. Image handling follows standard responsive image patterns. If you notice performance issues after integrating one of our products, the cause is more likely in the integration layer than in the product itself. Check for duplicate CSS, unoptimized images, or blocking scripts introduced during integration.
Common issues
Most issues we hear about fall into a few categories. Here are the ones that come up most often, along with the fastest path to resolving them.
Styles not applying correctly
Check the CSS load order. Our stylesheets should load after any reset or normalize stylesheet and before any custom overrides. If you are using a CSS in JS solution alongside our products, specificity conflicts are likely the cause.
Components rendering without expected spacing
Verify that the parent container uses our layout classes. Components rely on the surrounding layout context for spacing. Dropping a component into a container with its own padding or margin overrides will produce unexpected results.
Documentation search not working
Documentation theme search requires a build step to generate the search index. If search is returning no results, rebuild the search index using the command documented in the theme setup guide. Search indexes are not generated during development mode in some configurations.
Template sections overlapping on mobile
This usually happens when custom content inside a section exceeds the expected content bounds. Check that images inside sections have max-width constraints and that custom text content does not overflow its container.
If the documentation and this page do not answer your question, you can reach us directly. We respond to support questions during business hours, typically within one business day.
- Contact us for direct support inquiries
- Resource guides for in depth coverage of design system, documentation, and template topics
- Changelog for recent updates and compatibility notes
When reaching out about a specific issue, include the product name, the version you are using, and a description of the expected versus actual behavior. Screenshots help. Code snippets help more. The more context you provide up front, the faster we can point you in the right direction.
We also maintain resource guides that go deeper into specific topics. If your question is about design system governance, documentation structure, component auditing, or template selection methodology, the resources section likely has a guide that covers it.