North Collective is a modular acoustic furniture studio.
Audience: architects and teams improving shared workspaces.
Offer: repairable acoustic screens, modular seating, and tactile natural finishes.
Primary action: request a material sample.
This company is fictional. Create a suitable identity; no established palette or style is prescribed.
Every result uses the same fictional company, design prompt and embedded skill. The capture budget is recorded per batch: historical runs may have a time cap, while a batch marked with no limits has no time or output cutoff. Each result identifies its protocol and execution mode. Timing is descriptive; sequential and concurrent methods should not be ranked together.
Each result is one design attempt, not an overall quality ranking. Only attempts with a generated page are shown here; this gallery does not measure the overall success rate. The label beneath each model shows the service used to generate its page. Effort is the requested setting, and matching names do not mean equal reasoning budgets. Providers retain different native system instructions. Model identity comes from CLI catalogs and recorded responses, not independent server attestation. Comparisons can contain batches with different capture budgets; read the budget shown with each result.
Costs use recorded prices and token counts. API routes show estimated request spending; subscription routes show an API-equivalent estimate when available. Missing prices or token counts stay unavailable. These are not invoices or design scores.
Previews run separately from this site. External fonts, images and libraries need a connection and may affect rendering. Forms cannot submit data. Original HTML is preserved without design repairs.
Read the exact prompt
Create a distinctive, complete one-page website for this fictional company.
Company brief:
North Collective is a modular acoustic furniture studio.
Audience: architects and teams improving shared workspaces.
Offer: repairable acoustic screens, modular seating, and tactile natural finishes.
Primary action: request a material sample.
This company is fictional. Create a suitable identity; no established palette or style is prescribed.
Design skill to apply:
---
name: web-design
description: Design, build, and visually refine websites, landing pages, dashboards, and web app interfaces with a distinctive identity and usable interactions. Use for new frontend design, substantial visual redesign, or focused improvements to layout, typography, color, and motion. Preserve established brand systems. Not for backend-only work or behavior fixes without a design component.
---
# Web Design
Deliver an interface whose appearance helps people understand the product and complete their task. A successful result has a recognizable identity, credible content, working behavior, and a composition that survives real devices and real data.
## Design foundation
Use these principles to make deliberate design decisions:
- Establish the subject, audience, and purpose before selecting a style. Derive visual character from that world. Put something characteristic of the subject in the opening view.
- Make explicit decisions about typography, palette, motion, and background treatment. Use a coherent token system. Inspiration can come from cultural references or a familiar visual environment, but translate it to the brief.
- Choose type deliberately; give each family a role. Build hierarchy with scale, spacing, and weight. A familiar font is acceptable when the brand or reading task calls for it.
- Let one expressive feature lead. Use animation selectively and make interaction feedback understandable. Background effects should contribute meaning or atmosphere; a plain surface may be the right decision.
- Question repeated defaults: interchangeable card grids, decorative gradients, unnecessary labels, or the same type pairing across unrelated projects. No aesthetic is universally forbidden; an explicit user preference wins.
- Sketch a direction, check its fit before building, then critique the rendered result. Use plain, specific interface copy and meaningful action names. Support mobile, keyboard use, and reduced motion.
## Establish the assignment
### Standalone one-page briefs
When given a company brief and asked for one page, make a complete vertical experience: an opening that communicates the offer, enough concrete content to make it believable, and a useful next action. The company may be fictional; treat the supplied facts as the shared brief and invent only supporting copy consistent with them. Do not add fabricated awards, statistics, or endorsements.
Develop personality through composition, type, art direction, and interactions together. A color swap on a generic landing page is insufficient. Avoid making every company a software startup. A repair shop, scientific instrument maker, and independent cinema should suggest different ways to organize and show their work. Do not impose a fixed section count or mandatory hero format.
If the delivery contract requests HTML, CSS, and Tailwind, use all three. Additional browser-compatible frameworks are optional choices, not evidence of quality. Keep the artifact runnable under the specified delivery constraints. Use only libraries and assets accessible to the rendered page; npm imports require an explicitly supported build pipeline. Design image fallbacks instead of making the composition depend on a fragile external URL.
For response-only evaluations, the supplied brief and embedded skill are the complete context. Make decisions independently, do not request clarification, browse for hidden instructions, or claim to have run a browser. Return exactly the requested artifact format; keep planning and critique out of visible page copy and out of the response when code-only output is required. Perform a final static pass over mobile layout, navigation, interactions, missing assets, and HTML completeness before returning.
Inspect the existing page, neighboring routes, project instructions, components, tokens, dependencies, and supplied assets. Determine whether the request is a new identity, an evolution of the existing design, a reference recreation, or a change to one visual dimension.
Respect that scope. A typography adjustment should not become a rebrand. A supplied screenshot calls for fidelity; an inspiration reference calls for interpretation. Keep an established component system unless changing it is part of the request.
Infer missing details from the project and state consequential assumptions briefly. Ask only when a missing answer would materially change the product or design. Do not invent business claims, testimonials, customer logos, or operational data. Mark demo content when a prototype needs examples.
## Turn the brief into a buildable direction
For substantial design work, write a short direction before coding. Keep it proportional to the task; it is a working decision, not an approval ceremony.
- **Job:** Who uses this, what they need first, and the main action or decision.
- **Evidence:** Actual content, assets, or domain details that should shape the page.
- **Composition:** Reading order, relative emphasis, density, and how the layout changes on a narrow screen.
- **System:** Font roles, named color values, spacing rhythm, surface treatment, and interaction behavior. Reuse existing tokens where appropriate.
- **Signature:** The specific visual idea that makes this project recognizable and why it fits.
For an open brief, briefly consider meaningfully different compositions before choosing. Changing accent colors does not constitute a different direction. Choose by the audience's task and available content, then build without waiting for an unrequested sign-off.
Check the direction with a substitution test: if the product name and logo changed, would the same design still fit nearly anything? If so, strengthen its relationship to actual content or behavior. Do not solve this by adding decoration.
## Build the experience
Get the page structure and major proportions right before polishing shadows and transitions. Implement one representative region with its real content to settle the visual system, then extend it consistently.
Use the repository's framework and styling conventions. Keep repeated decisions in tokens and repeated behavior in components. Avoid adding a UI library for one effect or layering corrective CSS over conflicting rules.
Choose structures that fit the information:
- **Marketing:** Make the offering, proof, and next step understandable. Let the actual product or service determine the opening composition and section order.
- **Dashboards:** Prioritize comparison and action. Preserve units, time ranges, sorting, and data provenance. Dense rows or tables may communicate better than separate tiles.
- **Editorial:** Support sustained reading, navigation, and media captions. Check long titles and realistic article lengths.
- **Applications:** Design around the complete task, including validation, progress, recovery, and completion. Keep repeated controls predictable.
Wire visible controls to meaningful behavior within the requested scope. A prototype may use local state, but should not present a simulated operation as a completed external action. Include relevant loading, empty, error, disabled, and success states.
Use real available assets with intentional crops and aspect ratios. If creating imagery would materially improve the work, use an available image workflow. Do not substitute decorative emoji for a coherent icon system or invent image paths. Keep important text and controls as accessible HTML.
Define mobile reading order explicitly. Let content determine breakpoints. Check long labels, large values, wrapped navigation, and expanded panels. Avoid shrinking a desktop layout until it technically fits. Give dense tables a deliberate overflow or alternative reading treatment.
## Inspect and refine
When browser tooling is available, run the interface and inspect screenshots at a narrow phone width and a representative desktop width; add intermediate widths where the composition changes. Exercise the primary task, navigation, keyboard focus, and relevant alternate states. Inspect actual rendering, not just DOM structure.
Review in this order:
1. **Understanding:** Can a new visitor identify the page's purpose and next action?
2. **Composition:** Are the focal point, spacing, alignment, and reading order convincing at each width?
3. **Content resilience:** Do long content, missing media, and empty or failed data preserve the layout?
4. **Interaction:** Are controls functional, feedback visible, and focus behavior usable?
5. **Finish:** Are font loading, image crops, contrast, reduced motion, and fine alignment correct?
Fix the highest-impact observed problems first and inspect affected views again. Avoid cosmetic churn once the design works. Run the repository's checks appropriate to the changed code; passing a build does not establish visual quality. If browser inspection is unavailable, say so and distinguish code checks from visual verification.
Deliver the implemented result or requested design artifact, its preview or file location, and a concise account of what was verified. Call out material unfinished behavior honestly.
Additional requirements:
Choose the aesthetic and page structure that best serve this company.
Delivery contract:
Return exactly one complete HTML document, beginning with <!doctype html> and ending with </html>. No Markdown fences, explanations, or separate files.
Use semantic HTML, CSS, and Tailwind CSS. Load Tailwind with <script src="https://cdn.jsdelivr.net/npm/@tailwindcss/browser@4.3.0"></script>. Inline custom CSS and JavaScript are welcome.
You may choose any additional framework or library that runs in this HTML document through public HTTPS browser builds or ES modules. Do not require npm installation, a server, a bundler, or a second file. Framework choice is yours; a framework is not required.
Make a finished one-page experience with credible company-specific copy, a deliberate visual identity, responsive desktop and mobile layouts, and functioning navigation and primary interaction. Use local demo behavior for forms and explain the demo outcome honestly.
Use accessible HTML, keyboard focus, readable contrast, and reduced-motion handling. External images and fonts are allowed; use valid public HTTPS URLs and meaningful fallbacks. Do not embed another website, contact backend services, or submit user data.
The brief and skill above are your complete context. Work independently without tools or follow-up questions. Do not mention this evaluation, the model, effort, or skill in the visible website. Return the implementation now.