# Haeeum Publication Template — Master Build Prompt You are designing and building a reusable editorial publication template for **Haeeum's SEO Publishing service**. Read this entire specification before beginning. The objective is not to design a website for a particular client. The objective is to build a **neutral, reusable publication template** that Haeeum can later apply to many different businesses. --- # 1. What Haeeum Is Building Haeeum offers businesses an SEO Publishing service. Instead of requiring a client to build a blog inside their existing website or CMS, Haeeum can host and manage a dedicated publication on a client-owned subdomain: `blog.clientwebsite.com` The client's existing website remains untouched. Haeeum manages the publication independently, including: - technical infrastructure - publication design - article structure - SEO foundations - keyword strategy - content generation - human editing and review - publishing - ongoing optimisation The publication exists to consistently create useful, high-quality pages that can earn search visibility and direct relevant visitors toward the client's main website. These are not mass-produced AI content farms. The objective is to combine the efficiency of a structured publishing system with the quality, usefulness and presentation expected from a professionally managed publication. --- # 2. What You Are Designing You are building **one reusable Haeeum publication template**. Think: **Publication framework**. Not: **Client website**. It should be possible for Haeeum to take this exact template and later apply it to a law firm, an architect, a bakery, an ecommerce company, a construction company, a furniture company, a consultant, a local service business, a technology company, or a professional services firm without redesigning its fundamental structure. The base template establishes: grid, typography, spacing, navigation, publication index, article layouts, image behaviour, metadata treatment, editorial components, responsive behaviour, related content, CTA behaviour, footer, SEO structure. Client branding is a separate layer applied later. --- # 3. The Core Architecture Every Haeeum publication template must use the same underlying content architecture. **CONTENT → TEMPLATE → PUBLICATION** Content should not know which template is rendering it. A single article should be capable of appearing through Template A today and Template B tomorrow without the article being rewritten. This principle is non-negotiable. The content schema belongs to Haeeum. The visual interpretation belongs to the template. --- # 4. Shared Markdown Article Schema Articles should use standard Markdown wherever possible. Each article should begin with structured frontmatter: ```md --- title: "A Practical Guide to Choosing the Right Option" description: "A clear introduction to the subject and the decisions worth considering." slug: "practical-guide" author: "Example Company" publish_date: "2026-08-12" updated_date: category: "Guides" tags: - Example - Guide reading_time: "6 min" hero_image: "/images/article-hero.webp" hero_image_alt: "Descriptive alternative text for the article image" hero_image_caption: meta_title: "A Practical Guide | Example Company" meta_description: "A concise description written for search results." canonical_url: og_image: --- ``` The template must not require content authors to understand its visual layout. --- # 5. Standard Article Content The template must gracefully support normal Markdown: H1, H2, H3, paragraphs, bold, italic, links, unordered lists, ordered lists, blockquotes. It must also support: inline images, image alt text, image captions, long paragraphs, short paragraphs, multiple consecutive headings, long lists, articles with many sections, articles with few sections, articles with many images, articles with almost no images. Do not design only for perfectly curated demo content. The system needs to survive real publishing. --- # 6. Extended Editorial Components Standard Markdown should handle the majority of content. Where richer presentation genuinely improves an article, Haeeum may support a small shared library of editorial components: ```text ``` Keep this library restrained. Do not create custom components merely to make implementation easier. Do not invent template-specific content structures. Every shared component must remain portable between Haeeum templates. --- # 7. Typography **Figtree is the only typeface permitted.** Do not use secondary fonts. Do not use serif fonts, script fonts, handwritten fonts, cursive fonts, or decorative display fonts. This applies to headings, article text, navigation, metadata, captions, quotes, buttons, labels, footer, and every other textual element. If the design needs more character, create it using Figtree through scale, weight, line height, letter spacing, case, alignment, line length, placement, contrast, and whitespace. Do not use a decorative typeface as a shortcut to making something feel editorial. Different templates can interpret Figtree dramatically differently while still sharing the same typeface. --- # 8. Avoid The Recognisable AI Website Aesthetic Do not fall back on design devices commonly overused in AI-generated websites. Avoid: - decorative italic serif headings - serif + sans-serif combinations - cursive accent typography - excessive rounded cards - endless pill-shaped labels - unnecessary badges - glassmorphism - decorative gradients without purpose - arbitrary floating shapes - excessive border radius - excessive shadows - generic SaaS layouts - feature-card grids - dashboard aesthetics - giant glowing buttons - visual decoration that does not contribute to hierarchy Personality should come from **art direction**, not decoration. Restraint is preferable to manufactured personality. --- # 9. Visual Reference A visual reference is provided alongside this prompt. Use that reference as **art direction**, not as a layout to reproduce. Identify what makes it successful: proportions, whitespace, grid, hierarchy, typography, image scale, image placement, metadata, dividers, alignment, asymmetry, density, navigation, article rhythm, mobile composition, editorial restraint. Preserve the **principles** that make the reference successful. Do not reproduce its brand, logo, exact layout, copy, imagery, colour palette, exact grid, or distinctive proprietary elements. --- # 10. Direction For This Template The strongest principles to explore are: exceptional use of whitespace, strong typographic hierarchy, restrained interface design, editorial rather than card-based content presentation, small metadata, deliberate image proportions, thin structural rules where appropriate, confident use of scale, minimal visual decoration, clear hierarchy, publication-like pacing. The template should feel: quiet, editorial, considered, modern, structured, confident. It should not feel: corporate, trendy, SaaS-like, over-designed, AI-generated. --- # 11. Neutral Template Content Do not create this around any existing Haeeum client. Do not allow any client's branding, products, colours, industry, imagery, tone, or personality to influence the underlying template. Use deliberately neutral content during development. Generic publication labels are appropriate: Publication, Journal, Insights, Guides, Article. The purpose of the prototype is to evaluate the template, not the fictional business occupying it. --- # 12. Imagery During Template Development Do not rely on beautiful photography to make the design appear successful. A grey placeholder with a clear image area is preferable during early layout development to a collection of highly art-directed photographs. This lets us evaluate proportions, spacing, grid, hierarchy, image behaviour, and layout without photography doing the design's job. --- # 13. Publication Index Design a proper publication homepage/index. Do not default to a generic **Hero + featured article + three-card grid + newsletter CTA** unless the reference genuinely demands it. Think more like an editorial archive. The index should clearly communicate: publication identity, what the publication covers, article hierarchy, publication dates, categories where useful, article titles, descriptions where appropriate, imagery, navigation. Explore ways of presenting articles without relying on conventional cards. Horizontal editorial entries, changing grid positions, typography-led indexes and structured lists are all valid approaches. The index should remain useful with 5 articles, 20 articles, or 100+ articles. It is a publishing system, not a landing page frozen in time. --- # 14. The Article Page Is The Most Important Page Do not spend most of the design effort on the publication homepage and then create a generic article page. **The article is the product.** A reader should be able to move through a 1,500–3,000 word article without the experience becoming visually monotonous. Consider: title composition, introduction, metadata placement, hero imagery, reading width, heading transitions, changes in content width, full-width imagery, inline imagery, pull quotes, captions, lists, links, statistics, callouts, whitespace, section transitions, related articles, commercial CTAs, article conclusion. Do not simply put everything inside one centred 700px column. At the same time, never sacrifice readability for novelty. --- # 15. Commercial Links And CTAs These publications ultimately exist to create business outcomes. Articles will often link back to important pages on the client's main website. The template needs an elegant way to handle: contextual text links, related service/product links, occasional article CTAs, end-of-article CTAs. These should feel integrated into the publication. Do not turn an editorial article into a landing page. Avoid giant sales banners interrupting the reading experience. --- # 16. SEO Structure Visual experimentation must never compromise SEO fundamentals. Every article must support: one logical H1, logical H2/H3 hierarchy, semantic HTML, crawlable text, real anchor links, descriptive image alt attributes, canonical URLs, meta titles, meta descriptions, Open Graph metadata, structured data/schema, author information, publication dates, updated dates where relevant, clean URLs. Visual hierarchy does not need to exactly mirror HTML hierarchy. A visually unusual composition can still have extremely clean underlying markup. --- # 17. Performance These publications should be extremely fast. Do not introduce unnecessary JavaScript or dependencies merely for visual effects. Prioritise: lightweight frontend architecture, responsive images, appropriate image formats, lazy loading where appropriate, minimal layout shift, sensible font loading, clean semantic HTML, minimal client-side JavaScript, excellent Core Web Vitals. Animation should be restrained and purposeful. This is an editorial publication, not an interaction demo. --- # 18. Accessibility The template must support: semantic HTML, keyboard navigation, visible focus states, sufficient contrast, meaningful link text, image alt attributes, logical DOM order, responsive text sizing, comfortable reading line lengths, sensible touch targets. Do not sacrifice accessibility for visual experimentation. --- # 19. Responsive Design Desktop and mobile should share the same design language but do not need to share the exact same composition. Do not simply collapse desktop columns into a vertical stack and call that responsive design. Treat mobile as an editorial composition in its own right. Consider how titles change scale, whitespace changes, metadata moves, images behave, navigation simplifies, article width changes, pull quotes behave, captions behave, related articles appear. The mobile article experience is particularly important because a large proportion of readers will encounter these publications through search on their phones. --- # 20. Client Customisation Layer The template should eventually accept a controlled client identity layer: ```text publication_name client_logo primary_colour accent_colour text_colour background_colour client_website_url navigation_links default_cta footer_information ``` Do not expose hundreds of visual settings. The purpose of a template is to provide a strong design decision, not a website builder. Haeeum should be able to apply a client's identity without destroying the template. Typography remains Figtree regardless of client. --- # 21. Design Test Throughout development, repeatedly ask: > If all of the example copy and imagery disappeared tomorrow and were replaced with another client's content, would this still be a strong design? Also ask: > Would this still look good with a boring image? > Would this still work with a 12-word article title? > Would this still work with a 70-word article title? > Would this survive a 3,000-word article? > Would this survive 100 articles in the index? > Could a law firm and a bakery both plausibly use this? The template needs to survive real content. --- # 22. Build Requirements At minimum create: **Publication Index** — header/navigation, publication introduction, multiple article entries, varied title lengths, varied descriptions, varied image proportions where appropriate, publication metadata, footer. **Article Page** — navigation, category, article title, description/introduction, author, publish date, reading time, hero image, body paragraphs, H2, H3, text links, unordered list, ordered list, blockquote or pull quote, inline image, image caption, full-width image, CTA, related articles, footer. Create enough article content to meaningfully test long-form behaviour. Do not build an article containing three paragraphs and declare the template complete. --- # 23. Code Architecture Keep the frontend modular and maintainable. Separate **content** from **presentation**. The article content should eventually be capable of coming directly from Markdown/frontmatter. Do not hard-code article content into individual layout components in a way that makes future content ingestion difficult. Do not create template-specific article schemas. Keep visual components reusable where doing so improves maintainability, but do not allow componentisation to dictate the design. This is an editorial design first. --- # 24. What Not To Build Yet Do not build: an admin dashboard, client authentication, an article editor, an AI generation interface, analytics dashboards, a CMS, billing, account management, template selection interfaces. Right now we are building the **publication frontend template**. --- # 25. Working Style Do not spend significant time explaining what you are about to build. Do not repeatedly summarise this specification back. Do not produce a lengthy implementation plan unless a genuine architectural decision requires discussion. Build. When visual feedback is provided, implement it. If something looks weak, rethink it rather than polishing a weak direction. If the reference and a generic web-design convention conflict, favour the design principles established by the reference while protecting usability, accessibility and SEO. Do not add features merely because they are easy to add. Restraint matters. --- # 26. Definition Of Success The finished template should not make someone think: "That's a nice SEO blog template." It should make them think: "I'd be happy for this to be my company's publication." It should have the visual quality of a deliberately designed editorial publication while retaining the technical consistency required for Haeeum to operate it as a scalable publishing system. The underlying architecture should be boring, predictable and reusable. The frontend should not be.