Turn the brand message into a clear website

The website you are reading is the subject of this case. We did not take a template and swap the words. We used the interface system AiTOM built itself to turn our brand message into a clear bilingual site. The reason is direct: if we argue for designing the way of working first and letting AI help second, we should show it on our own site, including what it can do and what we are still adjusting.

Where we started

The starting point was a brand message already settled: positioning as "AI Transformation & Brand Growth", the brand line "從洞察出發，每一步都算數。" (start from insight, make every step count) and blue as the primary colour. The question was how to turn that into a site readers can actually understand and navigate, in two languages, with content that keeps growing, without redoing the layout for every new page.

We also did not want the site to be a one-off piece. Content has to be safely editable by many people and by AI, checkable after each edit and revertible when something goes wrong. In other words, we wanted a system that can run over the long term, not one good-looking page.

What we did

We split the site into clear layers, each doing one thing:

• Design tokens: shared specifications for colour, type size and spacing, keeping the whole site consistent.
• Components: basic units such as buttons, cards and navigation, built on the tokens.
• Section modules: page sections assembled from components, such as the hero or a case list.
• Layouts: how sections are arranged.
• Page data models: what content a page needs, which separates content from layout.
• The composer: assembles layouts and sections into complete pages from the data models.

For content we use CMS JSON posts, compiled into pages. The site is bilingual, Chinese and English, and currently has 43 in-depth capability articles in both languages, each with sources. Because content and layout are separate, editing text does not touch layouts, and adjusting a layout does not accidentally change an article.

Throughout, the director only states needs; AI proposes a structure; and the owner reviews through screenshots, on both desktop width and 375px mobile width. Before every release an automated browser QA run is executed. A person performs the deploy, then it is live-verified and logged.

What went wrong and what we changed

The first problem was AI-written content that was fluent but unsourced. For the in-depth articles we added source and evidence rules: each article carries sources, and it is finished only when the text matches its evidence.

The second was the risk of regenerating everything. When a site is compiled from data, regenerating all pages is convenient but can silently rewrite pages unrelated to the current work. We now scope each change and check the differences before release, confirming that only the expected pages moved.

The third was a trade-off on visuals. We once built a visual effect that the director, after seeing it, decided not to use. Because history is fully kept, it was reverted cleanly and nothing else was affected. That is why we insist on never overwriting and always being able to revert.

What changed

The most concrete result comes from QA. The latest release has 270 pages, passes 810 automated checks and has 0 broken links. These are figures from an actual run, and they show the site is not checked page by page by eye: every release has a repeatable set of checks.

In working terms, adding content became simple: write a JSON post, compile, check, have a person deploy, then verify and log. The brand message also has a fixed outlet, so different pages say the same thing.

We do not claim the site is perfect. It is still being adjusted. What matters is that adjusting is safe: the scope is explicit, differences can be inspected and mistakes can be reverted.

What you can reuse

• Settle the brand message before designing pages. Once the message is clear, the layout has something to stand on.
• Layer the site: tokens, components, sections, layouts, data models, composer, each with one job.
• Separate content from layout: manage content as data and compile it into pages.
• Run automated QA before every release, and look at screenshots at desktop and phone width.
• Have a person perform the deploy, then verify and log it live.
• Scope each change, keep versions and revert when needed.

A website is not a piece finished once. It is a system you can keep growing with confidence.