sabisan/ROUND_3.md

Round 3 Plan: Solo Architecture Studio Redesign

Context

The current application is a compact server-rendered Go site with SQLite storage, Tailwind-loaded templates, HTMX navigation, image uploads, a password-protected admin area, project/gallery CRUD, a single editable site_content row, and a simple contact request inbox.

The public interface currently has:

• Home page with hero, intro statement, and featured projects.
• Projects index.
• Project detail pages with image overlays.
• About page that also contains the only public contact form.
• No dedicated Services page.
• No dedicated Contact page.

For a small single-person architecture practice, the redesign should not become a full agency website or heavy CMS. The site needs to build trust quickly, show a clear design position, make project work easy to inspect, and collect useful enquiries without making the owner maintain many pages.

What From The Recommendation Fits

• Home page: relevant and already mostly present, but it needs stronger positioning, a clearer call to action, and a better preview of services/process.
• About / Studio page: highly relevant. For a solo practice, this should be one of the strongest trust-building pages because clients are hiring the person, not a large firm.
• Services page: relevant, but should be concise. A long list like architecture, interiors, renovation, consultation, space planning, furniture, project management, and 3D visualization may feel inflated for a one-person studio unless each item is genuinely offered.
• Contact page: relevant. The current form is buried on About, and the form does not pre-qualify leads.

What To Avoid

• Do not create a large multi-page agency structure with too many thin pages.
• Do not add a complex awards/publications system unless the owner has real content to maintain.
• Do not overstate capabilities with every possible design service.
• Do not add map/social integrations until the real contact content exists.
• Do not build a full page builder. The admin should remain simple and opinionated.

Proposed Public Site Structure

1. Home

Purpose: communicate the studio position quickly and send visitors to projects or enquiry.

Recommended sections:

• Full-viewport image-led hero, using a real project image when available.
• Positioning line such as "Residential architecture and interiors in London" rather than generic portfolio wording.
• One primary CTA: "Start an enquiry".
• One secondary CTA: "View projects".
• Short studio statement, 2-3 sentences.
• Featured projects, limited to 3-4.
• Compact services preview, 3 service groups maximum.
• Brief process preview, 3 steps maximum.
• Short about preview with portrait and link to Studio.

Current implementation impact:

• Keep the existing Home route.
• Rework home.html layout and copy fields.
• Continue using featured projects from the existing project model.
• Add admin-editable CTA text/link and positioning fields.

2. Studio

Purpose: make the solo practitioner credible, specific, and approachable.

This should replace or rename the current About page to "Studio". The route can remain /about for compatibility, but the navigation label should become Studio.

Recommended sections:

• Portrait or working photo.
• Name, role, and location.
• Short personal narrative.
• Design philosophy.
• Approach/process.
• Credentials, registrations, selected experience, or publications as a simple text block.
• Contact CTA.

Current implementation impact:

• Keep the existing about content fields but expand them.
• Add fields for philosophy, approach, credentials, and availability/service area.
• Remove the main contact form from this page or reduce it to a CTA linking to Contact.

3. Services

Purpose: help visitors self-qualify without making the practice look larger than it is.

Recommended services for a solo architecture company:

• Residential architecture.
• Renovation and extensions.
• Interior architecture and spatial planning.
• Early-stage consultation.

Optional only if accurate:

• Planning support.
• 3D visualization.
• Furniture and finish selection.
• Project coordination.

Recommended sections:

• Service overview.
• 3-4 editable service cards.
• "How projects work" process section.
• Typical timeline ranges.
• Geographic availability.
• Small FAQ.
• CTA to Contact.

Current implementation impact:

• Add GET /services.
• Add a services.html template.
• Add admin support for editable services and FAQs.
• For the first implementation, services can be stored as structured rows rather than hard-coded copy.

4. Contact

Purpose: create a proper conversion point and collect enough information to assess fit.

Recommended sections:

• Contact form.
• Email, phone, location.
• Short expectation statement, for example response time or preferred project types.
• Optional social links.
• Optional map later, not required now.

Inquiry questionnaire fields:

• Name.
• Email.
• Phone, optional.
• Project type.
• Location.
• Budget range.
• Timeline.
• Message.

Current implementation impact:

• Add GET /contact.
• Keep POST /contact, but expand the stored fields.
• Update admin contact inbox to show the structured enquiry details.
• Add validation for required fields and length limits.

Proposed Navigation

Use five top-level links:

• Projects
• Studio
• Services
• Contact

Home remains the logo link. This keeps navigation focused and avoids a marketing-heavy structure.

Backend And Data Plan

Site Content

The existing site_content row is good for global editable content, but it needs more fields:

• site_name
• positioning
• hero_cta_label
• hero_cta_url
• secondary_cta_label
• secondary_cta_url
• studio_philosophy
• studio_approach
• studio_credentials
• service_area
• response_note

These can be added through a migration while preserving current data.

Services

Add a services table:

• id
• title
• summary
• details
• position
• active

This keeps the Services page editable without turning it into a page builder.

FAQs

Add a faqs table:

• id
• question
• answer
• position
• active

Use FAQs mainly on Services and optionally Contact.

Contact Requests

Expand contact_requests:

• phone
• project_type
• project_location
• budget_range
• timeline
• status
• notes

status can start simple: new, reviewed, archived. notes is private admin-only text.

Projects

The current project model is usable. Consider adding only:

• summary for cards and homepage previews.
• scope for project detail metadata.
• status or completion_stage if the studio wants to show built/in progress/concept.
• position for manual ordering.

Manual ordering matters more than created-at ordering for a portfolio.

Admin Plan

Keep the tabbed admin from Round 2 and add two tabs:

• Main
• Projects
• Studio
• Services
• Contact

Recommended ownership:

• Main: home hero, positioning, intro, CTA labels/links, hero image.
• Projects: project CRUD, gallery uploads, featured flag, ordering.
• Studio: portrait, name, role, bio, philosophy, approach, credentials.
• Services: service rows, process copy, FAQ rows.
• Contact: public contact details, enquiry inbox, enquiry status, private notes.

The admin should stay form-based. Avoid rich text editing in this round unless there is a clear content requirement.

Interface Direction

The current visual direction is image-led, quiet, and minimalist. That fits architecture, but the redesign should make the site feel more intentional and less like a generic template.

Recommended direction:

• Use generous image layouts for project pages.
• Keep typography restrained but improve hierarchy.
• Make the homepage less sparse by adding actionable service/process content.
• Use project facts and captions to make work inspectable.
• Keep color neutral, but avoid a flat all-neutral interface by using material-inspired accents such as stone, clay, brass, or muted green in small amounts.
• Do not use decorative cards as the main layout. Use full-width sections, grids, and strong image composition.

Implementation Phases

Phase 1: Public IA And Contact

• Add /contact page.
• Move the enquiry form there.
• Expand contact request fields.
• Add navigation item.
• Update admin contact inbox.

This creates immediate business value and fixes the weakest current conversion path.

Phase 2: Studio And Home Rework

• Rename About navigation to Studio.
• Expand Studio content fields.
• Rework homepage sections and CTAs.
• Add home services/process preview using simple editable fields or seeded service rows.

This improves trust and positioning without a large backend expansion.

Phase 3: Services

• Add /services.
• Add services and FAQs tables.
• Add admin Services tab.
• Add process/timeline/geography content.

This helps visitors self-qualify and reduces repetitive pre-sales explanations.

Phase 4: Project Depth

• Add project summary/scope/status/manual ordering.
• Improve project detail pages with clearer metadata and richer captions.
• Add admin ordering controls.

This is valuable after the lead path and positioning are stronger.

Testing Plan

• Add route tests for /, /projects, /projects/{slug}, /about, /services, and /contact.
• Add form tests for expanded contact validation and persistence.
• Add migration tests for new columns/tables.
• Add admin tests for new tabs and update actions.
• Manually verify HTMX navigation still works with direct URL fallback.
• Manually verify mobile layouts for Home, Studio, Services, Contact, and Project detail.

Open Questions

• Should the public label be "Studio" while keeping /about, or should the route become /studio with /about redirecting?
• Which services are genuinely offered by the practitioner today?
• Does the studio want to show a phone number publicly, or keep initial contact email/form-only?
• Are there real awards, registrations, or publications to show, or should credentials remain a simple text block?
• Should contact requests trigger email notification, or is the admin inbox enough for now?

Recommended Next Step

Start with Phase 1. A dedicated Contact page with a structured enquiry form is the highest-value backend and interface improvement, and it gives the later Home, Studio, and Services pages a clear conversion destination.