220 lines
11 KiB
Markdown
220 lines
11 KiB
Markdown
# Design Context
|
|
|
|
## Product
|
|
|
|
WebDev Pipeline is a SaaS acquisition and audit workspace for web designers, small agencies, and local marketing service providers. It helps customers find local business leads, evaluate their web presence, prepare specific mini-audits, and manage respectful outreach with human approval.
|
|
|
|
The product is not primarily an internal tool for Matthias Meister Webdesign. Matthias is the seed user and domain expert, but design decisions must serve external customers who will pay for a reliable, professional workflow they can trust with their own prospects.
|
|
|
|
## Target Audience
|
|
|
|
### Primary SaaS Users
|
|
|
|
Independent web designers, small web studios, small agencies, and local marketing providers in Germany or DACH. They sell websites, redesigns, local SEO, maintenance, or digital consulting to local businesses. They need a repeatable acquisition workflow that feels professional rather than spammy.
|
|
|
|
They often work alone or in small teams, so the product must reduce operational load: lead discovery, qualification, audit evidence, outreach drafting, follow-up tracking, and handoff status should be clear without requiring CRM-heavy process management.
|
|
|
|
### Team Buyers And Operators
|
|
|
|
Small agency owners, account leads, sales assistants, and freelancers delegating research/outreach preparation. They care about quality control, brand safety, clear approval gates, and whether the tool makes their agency look thoughtful rather than automated.
|
|
|
|
### Recipient Audience
|
|
|
|
The downstream recipients are local businesses. They are not dashboard users, but the SaaS must protect their dignity and trust. Public audit pages and emails created through the product must feel specific, respectful, and helpful. No public scores, scare tactics, or generic AI language.
|
|
|
|
## Core Use Cases
|
|
|
|
- Configure local campaigns by niche, postal code, radius, cadence, and daily/weekly limits.
|
|
- Discover fewer but higher-quality local business leads.
|
|
- Keep leads without email visible as "Kontakt fehlt" or similar action states instead of dropping them.
|
|
- Prioritize website potential: no website, outdated site, poor mobile experience, weak contact guidance, accessibility issues, local SEO opportunity.
|
|
- Capture evidence: screenshots, PageSpeed signals, relevant pages, text excerpts, checked links, and skill outputs.
|
|
- Turn evidence into reviewable public audit pages for prospects.
|
|
- Review and edit generated audit copy, email drafts, subjects, phone scripts, and follow-up drafts.
|
|
- Require explicit human approval before publishing or sending anything.
|
|
- Track replies, follow-ups, offers, wins, losses, blocked leads, duplicates, and do-not-contact states.
|
|
- Give small teams enough operational visibility without becoming a full CRM.
|
|
|
|
## Brand Personality
|
|
|
|
Concrete words: trustworthy, exacting, field-tested.
|
|
|
|
The interface should feel like a professional agency workbench: dense, capable, calm, and evidence-led. It should reassure customers that the product will help them acquire clients without damaging their reputation.
|
|
|
|
It should communicate: "This system helps your agency notice real opportunities, build specific proof, and contact people carefully."
|
|
|
|
Tone qualities:
|
|
|
|
- Professional, direct, and restrained.
|
|
- Useful before clever.
|
|
- Confident without hype.
|
|
- Operational but not cold.
|
|
- Respectful toward both the SaaS customer and the business being contacted.
|
|
- Quality-control oriented: review, approve, publish, send.
|
|
|
|
Avoid:
|
|
|
|
- Internal-only language tied to Matthias as the sole operator.
|
|
- Growth-hacker energy.
|
|
- Neon AI dashboards.
|
|
- Overfriendly startup copy.
|
|
- CRM bloat.
|
|
- Generic "AI-powered" emphasis.
|
|
- Threatening scores, shame language, or urgency theater.
|
|
- Decorative metrics that do not help the next decision.
|
|
|
|
## Design Direction
|
|
|
|
### Working Concept
|
|
|
|
"Agency Evidence Desk": a compact SaaS workspace where local-business opportunities become evidence-backed, human-approved outreach.
|
|
|
|
The product should visually combine:
|
|
|
|
- A consulting dossier: findings, evidence, public copy, approval history.
|
|
- An agency production desk: queues, roles, handoffs, status, limits.
|
|
- A calm control room: campaign health, blockers, next actions, and send safety are obvious.
|
|
|
|
The memorable thing should be the feeling of an agency-grade proof workflow, not another generic lead-gen dashboard.
|
|
|
|
### Theme
|
|
|
|
Light-first for everyday professional office work. It should not be sterile white. Use tinted surfaces that feel like organized dossier paper, with crisp contrast for repeated scanning.
|
|
|
|
Dark mode can exist for long review sessions, but it should remain serious and restrained. Avoid glowing "AI cockpit" styling.
|
|
|
|
### Layout Principles
|
|
|
|
- Prioritize "what needs review or approval now" over vanity KPIs.
|
|
- Use dense but calm SaaS dashboards; avoid landing-page composition inside the product.
|
|
- Prefer work queues, split panes, evidence stacks, approval rails, timelines, and status ledgers over equal card grids.
|
|
- Make workflow hierarchy visible through structure first, color second.
|
|
- Keep repeated records compact and scannable.
|
|
- Surface account/team safety states: limits, blocked leads, approval status, send readiness.
|
|
- On mobile, preserve critical review and approval actions; adapt the workflow rather than hiding it.
|
|
|
|
### Component Principles
|
|
|
|
- Cards are for records, queue items, modals, and framed tools only.
|
|
- Avoid card-inside-card compositions.
|
|
- Avoid generic icon-heading-text card grids.
|
|
- Filters should be action-oriented, not database-oriented.
|
|
- Badges should encode workflow state, risk, ownership, or approval status.
|
|
- Primary actions should be rare and state-specific.
|
|
- Publishing and sending actions must look consequential, not casual.
|
|
- Use icons for familiar tools and statuses; pair icon plus text when the consequence matters.
|
|
|
|
## Visual Language
|
|
|
|
### Palette Direction
|
|
|
|
Use OKLCH. The base should be a muted, professional operational palette:
|
|
|
|
- Deep green/teal for approved, safe-to-proceed, and primary operator action.
|
|
- Ochre or paper-yellow for manual review, attention, and pending approval.
|
|
- Muted blue for evidence, source material, screenshots, audit artifacts, and analytics.
|
|
- Restrained red only for failed, blocked, destructive, compliance-sensitive, or do-not-contact states.
|
|
- Tinted neutrals toward the brand hue; avoid plain grayscale.
|
|
|
|
The UI must not read as one-note green or default gray. It needs distinguishable semantic families for lead, audit, evidence, review, outreach, blocked, running, and manual-required states.
|
|
|
|
### Typography Direction
|
|
|
|
Brand words: trustworthy, exacting, field-tested.
|
|
|
|
Reflex fonts rejected for this project: Inter, IBM Plex, Space Grotesk, DM Sans, Instrument Sans, Newsreader, Fraunces, Playfair.
|
|
|
|
For future font exploration, prefer fonts that feel like professional labels, consulting dossiers, municipal forms, and precise tool interfaces rather than generic SaaS. Candidates to evaluate before implementation:
|
|
|
|
- Atkinson Hyperlegible Next for readable dense body UI.
|
|
- Commissioner for firm, constructed headings.
|
|
- Archivo or Familjen Grotesk for compact operational labels.
|
|
|
|
Do not switch fonts casually if it adds build or network risk. If using `next/font/google`, verify locally because font downloads can affect builds.
|
|
|
|
### Motion
|
|
|
|
Motion should confirm workflow state changes, not entertain. Use quick, precise transitions for selection, queue movement, publish confirmation, send confirmation, and progressive disclosure. Avoid bouncy motion and decorative reveal sequences.
|
|
|
|
## UX Priorities
|
|
|
|
### Dashboard
|
|
|
|
The dashboard should answer: "What needs attention across my acquisition workflow?" before "How many things exist?"
|
|
|
|
Preferred first screen:
|
|
|
|
- Review and approval queue.
|
|
- Campaign health and blocked runs.
|
|
- Contact missing / audit ready / review open / follow-up due buckets.
|
|
- Account or team-level safety signals.
|
|
- Metrics as supporting context, not hero content.
|
|
|
|
### Campaigns
|
|
|
|
Campaign UI should feel like controlled lead sourcing, not scraping. Make limits, cadence, recent run outcome, and next scheduled run highly visible. Manual start should be clear, but not framed as an uncontrolled blast action.
|
|
|
|
### Leads
|
|
|
|
Lead UI should be organized around next action:
|
|
|
|
- Kontakt recherchieren.
|
|
- Audit starten.
|
|
- Daten klären.
|
|
- Sperren / nicht kontaktieren.
|
|
- Zurückstellen.
|
|
|
|
Rows/cards should show why the action is needed and what evidence supports it, not just static company fields.
|
|
|
|
### Audits
|
|
|
|
Audit UI should foreground:
|
|
|
|
- Critical finding.
|
|
- Evidence available.
|
|
- Checked pages.
|
|
- Screenshot status.
|
|
- Public readiness.
|
|
- Review owner/status.
|
|
- Failure requiring manual intervention.
|
|
|
|
Avoid exposing raw PageSpeed scores externally. Internal technical signals are allowed only when they help the SaaS user decide what to say or do.
|
|
|
|
### Outreach
|
|
|
|
Outreach is the highest-trust workflow. The UI must make separation obvious:
|
|
|
|
- Draft generated.
|
|
- Draft reviewed.
|
|
- Audit published.
|
|
- Email approved.
|
|
- Final send confirmed.
|
|
|
|
Never make send feel automatic or casual. The product should protect the customer from reputational mistakes.
|
|
|
|
### Analytics
|
|
|
|
Analytics should diagnose the acquisition workflow, not create a generic metric wall. Prioritize conversion from discovered lead to contactable lead, audit-ready lead, approved outreach, sent email, reply, conversation, offer, and won client.
|
|
|
|
### Public Audit Pages
|
|
|
|
Fixed light design, quiet and respectful. No public scores, no pressure language, no overdramatic urgency. It should read like a specific observation from a competent web professional who actually looked at the site.
|
|
|
|
Public audit pages should make the SaaS customer look credible. The page should support a trust-building sales conversation, not feel like an automated report.
|
|
|
|
## Accessibility And Constraints
|
|
|
|
- Next.js App Router, Tailwind CSS, shadcn/ui, Convex, Better Auth.
|
|
- Preserve existing client/server boundaries.
|
|
- Do not change Convex hook order or mutation semantics during visual work.
|
|
- Maintain responsive behavior across mobile, tablet, and desktop.
|
|
- Avoid fragile visual hacks that conflict with tests around navigation, prefetch, or protected routes.
|
|
- Public audit pages must remain noindex and calm.
|
|
- This is SaaS-facing product UI. Avoid internal-only assumptions, single-user copy, and anything that would not scale to customer accounts or small teams.
|
|
|
|
## Current Design Gap
|
|
|
|
The current UI still reads too much like default shadcn: neutral cards, neutral muted labels, equal-weight badges, and generic dashboard spacing. The next craft pass should make larger structural changes: queue-first dashboard, split review workspace, action-oriented filters, evidence-first audit cards, semantic status surfaces, and SaaS-grade account/team framing.
|
|
|
|
The goal is not "prettier shadcn." The goal is a recognizable agency acquisition product that makes customers feel in control of evidence, approvals, outreach safety, and pipeline quality.
|