One product does not need a catalog page just to fill a layout

The site structure and product status described here refer to the original record of October 6, 2026. Paths such as /products and /products/daily-order below are the original Traditional Chinese route examples; the English and Japanese navigation links lead to their own localized product introduction pages.

A website has one product, yet its navigation first sends visitors to a product catalog. That page contains one card, and only after clicking it do they reach the full introduction. If the intermediate page merely repeats the product name and summary, what different information does it provide?

In the implementation recorded here, this site’s product entry links directly to the 日序 introduction, without a separate /products catalog. The reason is not that a catalog page would be difficult to build. There are no multiple products to choose between, nor another set of product information that needs to be brought together in one place.

I first ask what the catalog should help the reader accomplish, then decide whether to add that layer. With only one product, introducing it directly can often answer the question at hand.

An extra entry point should answer an extra question

A catalog can help visitors compare uses, identify the audiences for different products, or quickly find an item whose name they already know. If those tasks exist, the intermediate page has a responsibility of its own.

But if there is only one card and it leads to the only detail page, the reader has no choice to make. Unless the catalog offers other content, it may simply rearrange the beginning of the detail page.

This does not mean a single product can never have a catalog. For example, a collection page may be useful if the same product already has different editions, applicable plans, or clearly separated entry paths. These are possible design scenarios, not a claim that 日序 already has those editions or plans.

Those needs had not arisen for this site at the time of the record, so both the main navigation and the homepage product section link to /products/daily-order. Navigation helps visitors find the product, and the introduction page explains it. There is no extra page inserted just to display a card.

Do not mix portfolio work, features, and products to fill columns

A design may reserve three columns even when there is only one product. Recent portfolio work, shared components, or experiments without a defined public scope are the easiest things to add to the remaining spaces.

But they are different kinds of information. This site’s portfolio page retains websites, systems, and visual work that have been made, while the product entry introduces 日序 in the recorded implementation. Relabeling portfolio work as “products” does not automatically turn it into an application service being offered.

Likewise, the financial overview, reports, goals, and schedule on the 日序 introduction page describe different aspects of the same product. They are not four independent products. Turning them into four product cards may fill the grid, but it changes what that card category means.

I would keep the existing distinctions: portfolio work describes what has been made; features describe how a product is used; a product introduction explains the situations it aims to address and the entry points available at the time. When there are too few items, change the layout rather than the facts.

The detail page should introduce the one product fully

Building one fewer page does not mean omitting the information along with it. At the time of the record, the 日序 introduction includes the product name and positioning, workflow, feature directions, interface illustrations, and a link to the Demo.

These sit on a single reading path. Readers can first understand its purpose, then examine its different aspects, and finally decide whether to leave this site to view the Demo.

The interface illustrations have their own limits. The page states that the images explain the intended workflow and do not contain real financial or schedule data. The existence of those images cannot, by itself, prove that every product feature is complete. Nor are they evidence of user data or product results.

When writing a product introduction, I therefore separate the explanations presented on this site from the features actually verified in the application. This article assesses the website’s structure through its introduction page and entry-point implementation. It does not substitute display material for end-to-end verification of the application.

A URL can leave room to grow without creating the page first

The product detail page in this record is at /products/daily-order, a URL that already identifies it as a named product. That does not require /products to have a page at the same time.

The two decisions can remain separate: paths can keep clear names, while public entry points are created only for pages that have content and a purpose. The site’s fixed English and Japanese product pages also have corresponding URLs, and each language’s main navigation points to its own introduction page.

If a genuine second product becomes available to introduce in the future, the content of a collection page can be decided then. The existing 日序 detail page need not lose its address just because a catalog has been added. Nor should the catalog turn every entry point into a sequence that prevents direct access.

This is a direction for future expansion, not a claim that the site already has a second product or has completed that routing change.

Even with a second product, first ask whether comparison is needed

An increase in product count is a reason to revisit the purpose of a catalog, not sufficient reason to create one automatically.

I would first organize each product’s publicly describable name, audience, purpose, and entry point, then ask whether readers actually need to choose between them. If the two entry points serve entirely different situations, the homepage or navigation may already be enough to direct people. If the uses are similar and easy to confuse, a catalog has more reason to provide an explicit comparison.

It is also necessary to distinguish “being prototyped” from “available to use” rather than placing both in indistinguishable cards. A product still in preparation can have its progress or public scope explained, but a “Use now” link should not take people somewhere without the matching functionality.

I use one concrete question to decide whether a catalog is needed: if this page were removed, which necessary information or choice would readers lose? If there is none, let them go straight to the product for now.

Scope of this record

This article draws on this site’s main navigation, homepage product entry, 日序 introduction page, language paths, and content decisions for the studio website. It describes how the website introduced a single product at the time of the record. It is not a report on 日序’s feature completeness, user research, click-through rates, or conversion results, and it does not turn portfolio work or planned tools into a product line that does not exist. For the division of responsibilities across the site, see From portfolio to studio website: when the purpose changes, the information architecture must change too.