A mockup can guide a design, but it is not a product specification

The implementation details and project status described here refer to the studio redesign recorded in the original article on October 2, 2026. Current commissions cover graphic design, UI/UX, and frontend development, quoted by confirmed scope; see the services page.

A mockup can quickly convey a page’s mood, information hierarchy, and likely reading order. The reference images for the studio redesign did just that: they brought possible structures for the homepage, mobile homepage, notes list, article page, product introduction, and collaboration directions together as visual layouts.

But the titles, dates, cards, product interfaces, and service items that appear in those images do not automatically become real content or features. These were AI-generated direction sketches, not measured design documents, product screenshots, published articles, or evidence of working features. My main judgment is this: use mockups to agree on visual direction, not to replace the implementation contracts for content data, product features, and interaction behavior.

A mockup first answers how a page should look

Mockups are useful for working through visual questions, such as:

• Which section belongs in the first viewport, and which sections lead to further reading?
• Which should draw attention first among the headings, explanations, buttons, cards, and images?
• Should content that sits side by side on desktop become a vertical reading sequence on mobile?
• Do notes, products, collaboration, and about content read as distinct sections?
• What mood should the page maintain, and where does it need breathing room?

This information is useful because the people implementing the page can discuss whether to pursue that direction without fixing every CSS value at the outset.

A mockup cannot, on its own, answer a different set of questions:

• Do the article titles in the image actually exist, and can those dates be published?
• Which URL should a button lead to, or is it only a visual placeholder?
• Have the fields shown in the product interface been implemented, and can the listed services actually be delivered?
• Is an interface image a real product screenshot, a static illustration, or simply a way to communicate composition?
• How will the page behave with keyboard input, JavaScript disabled, a narrow screen, enlarged text, or a loading failure?

Mix these two sets of questions together, and the image quietly starts making product decisions. Something that looks dated gets treated as published; something that looks like a feature gets treated as complete; something that looks like a contact form gets treated as a form that can actually be submitted.

One image often contains four kinds of information

When I read a mockup, I first separate the visible content into four layers rather than copying every detail into the code.

Information visible in the image	What it can help us discuss	What is still needed for implementation
Sections and arrangement	Page hierarchy, reading order, and how content is grouped on desktop and mobile	The actual DOM order, RWD rules, and whether the sections really exist
Sample text	Content length, heading hierarchy, and card density	Final copy, sources, language versions, and publication status
Interface imagery	Visual focus and the proportions between the product and the website	Real assets or explicitly labeled illustrations, alt text, dimensions, and error states
Implied functionality	Possible entry points and interactions	Routes, element semantics, data sources, states, keyboard behavior, and behavior without JavaScript

For example, a notes-list mockup can contain many seemingly complete cards and category labels. It can help us discuss whether cards need topic tags, summaries, and reading links. It cannot prove that those articles have been written, let alone justify adding fake articles to fill the grid.

Likewise, a dashboard in a product mockup can indicate that the product section needs a larger visual focal point. A few account fields cannot establish a complete data model, and every small icon in the illustration should not be treated as a promised feature.

Turn visual direction into an implementation contract

A more reliable approach is to ask what each visual element we want to keep is responsible for in the product.

Visual element	Implementation question in the recorded pages	Available evidence
Homepage note cards	Which articles should be read, how should they be ordered, and what happens when none exist?	HomePage.astro uses getPublishedNotes(lang) and takes up to three articles; it shows an empty state when no articles are eligible for publication
Notes list and categories	Are categories part of a real content contract, and where should a click lead?	NotesPage.astro builds its list from publishable articles; categories, featured entries, pagination, and article links follow the data and routes in that implementation
Article table of contents	Does it stay in sync with the body, and how should it work on mobile?	ArticleLayout.astro builds the table of contents from the headings actually rendered; mobile also has a Drawer and a fallback for use without JavaScript
Product interface	Is it an actual screenshot, a programmatically generated illustration, or an asset that has not yet been obtained?	ZeniDashboardPreview is a static interface preview rendered by a component; it communicates composition but does not prove a particular real data state
Collaboration-direction rows	Which collaboration scopes can be described publicly, and which are still exploratory?	servicesCopy lists collaboration directions and starting points for discussion, and explicitly states that AI adoption consulting remains a future direction
Side-by-side sections on mobile	What happens to content order, wrapping, overflow, and interaction as the screen narrows?	The same main DOM structure, RWD rules based on fitting the content, and actual narrow-screen and keyboard checks

This step changes the task from copying an image to confirming each section’s responsibility. Some elements become formal data. Others become CSS or local script behavior. Some should simply be removed because the generated image added them only to make the layout look complete.

An interface illustration is not a product screenshot

This redesign involved at least three things that can easily be lumped together as “screens.”

Direction sketches

A direction sketch helps us discuss the overall mood, section proportions, and information hierarchy. It does not guarantee that the text, icons, dates, images, or features will match the final version. The redesign specification explicitly labels the reference images as AI-generated direction sketches; details added by the model are not implementation requirements.

Programmatically generated interface illustrations

A website can use Astro components and CSS to generate a static interface illustration rather than depend on a generated image. For example, ServicePreview.astro on the collaboration page in the recorded implementation generates simplified panels, text lines, and cards for different directions, labeled “Interface illustration.” This section is a decorative aria-hidden preview, not an interactive service system.

The ZeniDashboardPreview used on the homepage and product page is also a display assembled in code. It can communicate the product section’s visual proportions and content direction, but it should not be described as a screenshot of a real account at a particular moment.

Real screenshots

A real screenshot should come from an existing page or product state, and the content that can be made public needs a separate check. At a minimum, it should be possible to explain which version, route, or state was captured and whether the data in the image has been de-identified. If the image is only a static illustration, label it “Interface illustration” rather than using the word screenshot to give it credibility it does not have.

This distinction also affects how images are handled in engineering. Images intended for publication need appropriate alt text, dimensions, lazy loading, and a loading-failure state. Purely decorative illustrations should not cause assistive technology to interpret them as a set of interactive data.

When they conflict, real contracts take priority over the image’s mood

The redesign specification at the time sets the following order of priority: the latest explicit feedback comes before content and behavior contracts; those contracts come before approved original images and copy; the mockup’s mood comes last. This does not dismiss visual design. It prevents an image from acquiring decision-making authority without discussion.

The implementation described in the original article provides several concrete examples:

• Note cards are not duplicated to match the number shown in the image. The homepage reads only articles eligible for publication in that language and shows an empty state when none exist. The list page also derives featured entries, the regular list, and pagination only from actual articles. Sample cards in a mockup cannot replace this data condition.
• Categories are not expanded for visual completeness. An image can show several category chips, but the content schema and data in the recorded implementation support only confirmed categories. Without sufficient content and routing behavior, adding a category means mistaking decoration for a product feature.
• A product preview is not automatically a feature list. The product page at the time includes the positioning, status, and description of 日序, along with two documented directions. More detailed interface elements in the mockup cannot directly expand the product’s scope.
• Collaboration directions do not automatically mean mature services. The collaboration page has three directions: interface and content design, websites and Web systems, and AI application exploration. Its copy also retains the limitation that “AI adoption consulting remains a future direction.” A visually complete service row does not mean every item already has a fixed package or a guaranteed delivery process.
• The article table of contents is not copied by hand from the image. It should be generated from the actual headings in the article body, and further reading should come from published articles. Table-of-contents text and cards drawn in a mockup are only layout examples.

When an image conflicts with the code or content rules, the response should not be to force the code to look more like the image. First ask whether the difference reflects unfinished work, an unresolved decision, or an image that was only ever a direction sketch. Different answers call for different responses.

Fill out a mockup checklist before implementation

Not every reference image needs to become a pixel-by-pixel acceptance checklist. But each section that will be implemented can at least have six answers recorded first:

• Visual intent: what should the reader notice first in this section?
• Implementation contract: is the section responsible for content, navigation, interaction, or decoration?
• Real source: where do the text, images, states, and links come from?
• Missing content: how should it appear when articles, images, translations, or product data are unavailable?
• Exclusions: which details in the image are not promised, will not be made public, or are not being implemented yet?
• Verification evidence: which specific point needs to be checked through HTML, data, keyboard use, a narrow screen, or a manual visual review?

The original checklist is retained below in Traditional Chinese:

視覺意圖：這個區塊想讓讀者先看到什麼？
實作契約：它在頁面裡負責內容、導航、操作還是裝飾？
真實來源：文字、圖片、狀態與連結從哪裡來？
缺少時：沒有文章、圖片、翻譯或產品資料時要怎麼呈現？
不包含：圖中哪些細節不承諾、不公開或暫時不做？
驗證證據：要用 HTML、資料、鍵盤、窄螢幕或人工視覺確認哪一件事？

This checklist is not quite the same as ordinary requirements gathering. It addresses misunderstandings that mockups are especially likely to create: treating sample text as final content, an illustrated interface as a screenshot, or a service name on the screen as a product commitment. Separate those identities first, and it becomes clearer what is worth implementing and what should remain a discussion.

What this approach can and cannot establish

The Astro implementation and documents described here support several specific judgments. The homepage, notes list, article pages, product page, and collaboration page each have actual components and content sources. Published notes enter public pages through publication queries. Interface previews in the product and collaboration sections can be generated in code. Article tables of contents can remain tied to the actual headings.

That evidence does not support the following conclusions:

• The mockup is already a precisely measured design document.
• The published pages already match the images pixel for pixel.
• Every product feature, service scope, article, and date shown in the images already exists.
• The RWD, reading comfort, animation timing, or visual mood in that implementation has passed manual acceptance checks on every device.
• These pages have already produced search, traffic, collaboration, or business results.

Engineering checks can verify parts of the output, data, and behavior. The final visual direction and public content still need approval from the person with authority to decide. A mockup is most useful not when it makes every decision in advance, but when it exposes the decisions that need to be made earlier.

Scope of this record

This article examines the differences between the studio redesign reference images and the Astro pages recorded at the time. It focuses on the boundaries between visual direction, implementation contracts, interface illustrations, real screenshots, and fabricated content. It is not a complete visual-design tutorial, and it does not present unmeasured RWD, user research, product features, or service outcomes as confirmed facts.