From portfolio to studio website: a new purpose needs a new information architecture

This article records the information architecture and collaboration direction at the time of the redesign. Current commissions cover graphic design, UI/UX, and frontend development, quoted by confirmed scope; see the services page.

When a website’s main job changes from showing past work to helping people understand what is being built, how it is built, and whether there is a way to work together, navigation centered on a portfolio is no longer enough. Adding a few cards does not turn a portfolio into a studio website. First, each page needs a clear answer to whose problem it solves and what that problem is.

This article uses the site’s pages, routes, and content contracts to explain the information architecture change. My main judgment is that a change in purpose should start with page responsibilities and the order of entry points, before visual design and components. The work stays, but it no longer has to explain everything.

From one portfolio entrance to several reading paths

The original portfolio mainly answered one question: what work has been done? The site now also needs to explain what it is doing, which implementation methods it uses, which product is being developed, where a collaboration can begin, and where to find the author’s background and complete body of work.

The routes divide those responsibilities as follows. The table retains the original Chinese site’s paths to explain its architecture; English routes use the /en prefix, and Japanese routes use /ja.

Route	Main question it answers	Page responsibility
/	What is this website trying to do now?	Studio positioning, notes entry point, one product, collaboration direction, and about/contact access
/notes	What methods and records can I read?	Published article list, category information, and an empty state when there are no articles
/notes/[slug]	What is the full account of a particular topic?	An article, its summary, date, tags, body, and further reading
/products/daily-order	What product is currently being developed?	日序’s positioning, status, intended features, and product entry point
/services	Where can a conversation about working together begin?	Collaboration direction, problems open for discussion, and contact access
/about	Who is doing the work, and what experience have they gained?	Actual background, working approach, experience, and links to implementation work
/about/work	What websites, systems, and visual work have been completed?	The work collection, with a switch between websites/systems and content/visual work

This division does not turn every noun into a page. It gives each question a primary entry point. Visitors can browse past work at /about/work, while the product has its own introduction. Neither page needs to explain the studio’s entire position.

The homepage no longer sends everyone straight to the portfolio

The homepage no longer starts by filling the screen with work cards. A positioning statement and a short explanation introduce what the site does. Notes come next, followed by the single product, the collaboration direction, and access to background and contact information.

With this order, readers can first understand what is available here, then choose to read about methods, look at the product being refined, learn how a collaboration might work, or return to the full background. The homepage directs people to different paths rather than acting as a miniature portfolio wall.

The homepage’s notes section shows at most the three latest published articles in the selected language and links to the full list. If there are no published articles, it displays a readable empty state instead of duplicating an article to fill the layout. This small rule sets a real boundary: the information architecture cannot rely on fake content to look complete.

The product section makes the same trade-off. Only one product has a confirmed name and entry point, so navigation goes directly to its detail page. There is no /products overview created just to list a single item.

Notes document methods; they are not extended work cards

A work card can quickly explain what something is and where to see it. A note has a different job. It needs to explain decisions, methods, limitations, and the scope of verification so readers can understand how a result came about, rather than only seeing the final screen.

For that reason, /notes and /notes/[slug] are separate content entry points. The list includes only published articles whose publication time has arrived. Each article page handles the body, table of contents, tags, dates, and further reading. Drafts and unfinished translations do not become published article links, keeping content that is still being prepared distinct from content ready for public reading.

This distinction also keeps the work page from becoming an all-purpose explanation page. It retains the scope of work actually completed. Notes handle the longer explanations of architectural decisions, content workflows, and verification boundaries. Both kinds of page can discuss implementation, but readers arrive with different expectations about depth.

Past work remains, but it is no longer the only answer

Notes, the product, collaboration, and background now occupy the main navigation. Work is no longer the only top-level entry point. It has not been removed: /about still links to implementation work and the portfolio, and /about/work retains the full collection. The old /work URL also remains readable for compatibility and identifies the new route as canonical.

These are two different responsibilities:

• Main navigation determines what readers should understand first.
• Compatibility routes keep existing links useful by preserving access to the original content.

Mixing them often produces navigation that appears to include everything but offers no clear reading order. Keeping an old URL does not require keeping the old information architecture on the homepage or in the main navigation.

The work collection now has three switchable sections: websites and systems, content and visual work, and a separately labeled AIGC character-visual section. The first two describe work that was actually done; AIGC is explicitly presented as AI-generated character imagery rather than a new product case study or a complete AI project. A new purpose for the website does not give every past project a new background or make them all part of the same story.

Products and collaboration need boundaries, not empty pages

The label “studio website” can make a site seem incomplete without a product overview, service packages, case studies, and a full contact workflow. The available content does not support all of those, so the architecture deliberately leaves some gaps.

日序 is the only clearly defined product entry point, and its page explicitly says that it is still being refined. The site can introduce a real product implementation, but that does not establish a second product, a complete product line, or a finalized feature scope.

Likewise, /services does not package collaboration into fixed offerings. It describes a direction still taking shape: clarifying ideas, turning processes into tools, and building a first version with AI. It offers a starting point for discussion. It neither promises that every project will follow the same process nor claims to have mature, packaged services.

Leaving these gaps visible may make the site feel less complete, but it stays closer to what can currently be demonstrated publicly. Information architecture starts by acknowledging which content exists, rather than reserving pages for everything expected to exist someday.

Multilingual URLs are part of the information architecture

The site keeps its Traditional Chinese homepage at /, with English at /en and Japanese at /ja. Fixed pages have corresponding URLs in each language. Language selection, the page’s lang attribute, metadata, and links can therefore use the same URL source to determine the right locale.

Notes follow a stricter rule: an article URL is created only for a language version that actually exists and is complete. At the stage documented in the Chinese original, the untranslated English and Japanese notes lists used honest empty states. Completed translations now appear in their respective lists, while missing translations still receive no invented routes. A Chinese article alone does not generate a fake translation page or send readers to an unrelated homepage.

This is a rule about content entry points, not just translation. Switching languages should tell readers which languages contain this particular content. When a translation does not exist, an empty state is clearer than a page labeled as translated that is not actually the same article.

What this architecture addresses, and what it does not prove

The routes, page components, content data, and static-output checks documented in the original support these observations:

• The home, notes, product, collaboration, about, and work pages each have a recognizable responsibility.
• /about/work is the primary work route, while the old /work remains a readable compatibility entry point.
• Multilingual fixed pages use corresponding locale routes; article pages and the sitemap do not pretend that missing note translations exist.
• Published pages contain actual HTML. Article pages are not empty shells whose content appears only after the browser executes JavaScript.

This evidence supports the claim that the information architecture has been implemented and checked at an engineering level. It does not support the following conclusions:

• There is no user research or analytics evidence that this order is necessarily easier to understand than the old site.
• There is no evidence of SEO rankings, traffic, conversions, or collaboration outcomes, so the architecture cannot be credited with business results.
• Full responsive behavior, animation timing, and reading comfort still need visual acceptance by users. A passing build cannot replace that review.
• Product and collaboration copy remain limited to the current public scope. Page illustrations do not establish unconfirmed features or services.

What I will check before the next site reorganization

1. Write down the site’s main task before listing pages to add.
2. List the questions readers repeatedly ask and assign each a primary entry point.
3. Let the homepage direct readers to different paths instead of compressing all content into work cards.
4. Add product, category, or case-study pages only when their content, functionality, and public scope are established.
5. When old URLs need to stay, handle compatibility separately from main navigation. Historical routes should not determine the new reading order.
6. Only then translate page responsibilities into components, styles, and animation, checking output, interaction, and subjective reading experience separately.

For this site, moving from portfolio to studio website means more than adding a notes link or making the homepage a larger wall of work. The change is to give positioning, methods, the product, collaboration, background, and work distinct responsibilities, while leaving room for content that does not yet exist. That is how a new page adds to the information architecture rather than merely filling the layout.

Scope of this record

This article describes the pages, routes, content queries, and studio-site development specification implemented in the repository at the stage covered by the Chinese original, with the translation-list status clarified above. It explains page responsibilities and public boundaries in terms readers can use. It does not present mockups, planned features, unfinished translations, visual acceptance, or search outcomes as completed product facts.