Structuring a deep-tech website: the Morse Micro project

A technical website needs to explain what the company makes while giving knowledgeable visitors a direct route to the detail. Someone evaluating a component may need documentation immediately. Someone discovering the technology may need an application, an explanation and evidence that it works. A single generic sales journey serves neither particularly well.

That was the information-architecture challenge in Refract’s work for Morse Micro, a semiconductor company. The published project account covers strategy, audience mapping, user flows, the sitemap, design system and Webflow implementation. The useful lesson is how those decisions connected: the audience work changed what belonged on the site and how people could move through it.

1. Give each audience a task

The project began with a workshop and stakeholder sessions across the business. The team considered engineers, partners, commercial leaders, investors and prospective hires, among other visitors. Those audiences were not just labels for different marketing messages; they needed access to different kinds of information.

Engineers needed specifications, documentation and product comparisons. Commercial visitors needed to understand applications. Investors and partners needed a clear picture of the company and its ecosystem. The architecture had to make those paths available without splitting the business into disconnected websites.

For a similar project, turn each audience into a concrete task before designing the navigation. “Find the evaluation kit for this product” is a more useful test than “appeal to engineers”. A task has a starting point, a destination and information someone needs along the way.

2. Connect the product to the evidence

The Morse Micro process describes connecting products with modules, evaluation kits, resources, partners and applications. Visitors could begin with a product, an application or a technical question and follow the relevant relationships.

This is where a sitemap becomes more than a menu. A product page can explain the component, then link to the resources required to evaluate it. An application page can explain a use case and lead into the relevant products and proof. A resource can help someone move back to the product it documents.

• Product: what it is, where it fits and the technical detail needed to evaluate it.
• Application: the problem, the role of the technology and relevant evidence.
• Resource: the document or tool, its context and the next useful destination.
• Company: the people, partnerships and information that support confidence in the business.

These are planning prompts derived from the project’s structure. The specific content types should come from your product and buyers. Creating pages for categories you cannot meaningfully explain only adds maintenance.

3. Do not force every page into one template

Morse Micro’s product ecosystem needed both reusable CMS structures and more specialised technical content. The account describes chip pages with detailed tables and diagrams, alongside broader product, application, support and company templates.

A single flexible page builder can appear to solve every requirement, but it also leaves every editor deciding the hierarchy again. At the other extreme, a rigid template can make important information difficult to express. The useful design decision is which content should be consistent and which needs a dedicated structure.

Use real content to test that boundary. Put a detailed specification, a short application story and an unusually long resource title into the wireframes. Decide how related items are selected and what happens when a field is absent. Those decisions shape both the reader’s experience and the publishing workload.

4. Let navigation reveal the business

The project’s top-level structure settled around Products, Applications, Support and Company. Its navigation made product breadth visible and supported movement between chips, modules, evaluation kits and resources. Search provided another route for people who already knew what they wanted.

That combination matters. Browsing helps someone understand an unfamiliar portfolio; search helps someone retrieve a known item. Good navigation does not require every visitor to learn the company’s internal organisation before finding the information they need.

To review your own site, start from a deep page as well as the homepage. Can a visitor who arrives through search identify the product, understand why the page matters and reach the next piece of evidence? Search visitors do not necessarily see the introduction you designed at the top of the site.

5. Make the structure maintainable

Refract implemented the Morse Micro site in Webflow with reusable templates, CMS structures and components. The published process also describes a shared design system and cross-linking between products and resources. The architecture had to survive new content after the initial design work.

For another technical business, the useful handover questions are practical: who owns each content type, who checks technical accuracy, how are related resources kept current and which changes need engineering support? Agree those responsibilities while designing the site, when the content model is still easy to change.

This case study documents the website work. It does not provide a measured increase in rankings, leads or revenue. Those outcomes need a separate baseline and measurement period. What the project does show is a method for turning a complex product ecosystem into clearer paths that a buyer, an engineer and an editor can use.