| name | website-design-proposal-strategy |
| description | Use when a proposal includes a website, ecommerce site, portal, landing page, content hub, or web frontend and must align UX, content, SEO, technology, delivery, launch, costing, and support. |
| metadata | {"portable":true,"compatible_with":["claude-code","codex"]} |
Website Design Proposal Strategy
Acknowledgement: Shared by Peter Bamuhigire, techguypeter.com, +256 784 464178.
Use When
- Drafting or reviewing proposals for website design, website redesign, SEO-ready sites, ecommerce sites, landing pages, content hubs, portals, or web application frontends.
- A non-website proposal includes a website or digital presence component that must be explained credibly.
- The proposal must communicate the firm's website development philosophy, stack choices, premium quality gates, and commercial value.
- The financial proposal must cost website discovery, UX, content, SEO, development, QA, launch, handover, and support.
Do Not Use When
- The assignment has no website, web content, SEO, digital presence, or web technology component.
- The client only needs a one-line mention of "website" with no scope, budget, or delivery implication.
Required Inputs
- ToR/RFP scope, target audience, website objectives, content needs, languages, integrations, hosting constraints, and required standards.
- Existing website URL, analytics, brand assets, content inventory, SEO baseline, and stakeholder approval path where available.
- Commercial assumptions: timeline, support period, content responsibility, hosting/licence rules, and whether the work is premium/high-trust.
Domain Method
- Define the website's role in the assignment: marketing, lead generation, service delivery, information access, ecommerce, investor confidence, stakeholder communication, or public accountability.
- Select the proposal posture: premium authority site, growth/lead-generation site, institutional information site, ecommerce system, campaign landing page, or web application interface.
- Draft the philosophy: strategy before design, content before decoration, search and accessibility by default, performance/security as quality gates, and measurable launch outcomes.
- Build the methodology from reviewable artefacts: discovery brief, content/SEO map, UX architecture, design system, prototype, build, QA, launch, training, and support.
- Explain the stack in client-value language: speed, ownership, maintainability, security, integrations, content workflow, scalability, and total cost of ownership.
- Explain design decisions through client goals, user needs, evidence, trade-offs, and approval points, especially where stakeholders may prefer different layouts or technologies.
- Treat forms, search, navigation, errors, confirmation messages, and content workflows as business-critical service moments, not minor interface details.
- Cost the scope from delivery drivers, not page count alone: senior discovery, UX, content, SEO, development, integrations, QA, project management, launch, documentation, training, and support.
- Define post-launch support, maintenance, analytics review, security updates, content updates, and optimisation so they are not implied freebies.
- Run the website design proposal gate before finalising methodology, executive summary, work plan, and financial proposal.
Quality Standards
- The proposal explains why the website matters commercially, not only what pages will be built.
- The approach is specific enough that an evaluator can see deliverables, sequence, controls, and acceptance criteria.
- Content, SEO, UX, accessibility, performance, security, analytics, and handover are first-class workstreams.
- Stack recommendations are justified by client needs rather than fashion or developer preference.
- Pricing protects premium delivery quality and does not hide material work inside a vague lump sum.
- The proposal shows how the website supports the wider service journey, conversion path, support model, or institutional mandate.
- The support model is specific enough to manage expectations after launch.
Domain Risks
- "We will design a modern website" with no content, SEO, UX, analytics, or launch logic.
- Costing by page count only.
- Promising custom systems, CMS, ecommerce, multilingual delivery, or integrations without corresponding discovery, QA, support, and risk budgets.
- Treating hosting, domain, copywriting, photography, licences, content migration, SEO, maintenance, or training as implied freebies.
- Using technical jargon where the evaluator needs business value.
Existing Deliverables
- Website proposal win theme.
- Technical approach and methodology text.
- Stack philosophy and architecture rationale.
- Design rationale, evaluator story, and user-journey language.
- Deliverables and acceptance criteria.
- Financial proposal costing notes and assumptions.
- Maintenance, support, and optimisation assumptions.
- Website design proposal quality review.
Do Not Use When
- Do not use this skill when a neighbouring specialist named in the description owns the primary decision; route there first and use this skill only as a supporting layer.
- Do not use it to invent buyer facts, evidence, legal positions, statutory rules, delivery capacity, or current external claims.
Inputs
| Artefact | Source/provider | Required? | Missing-input behaviour |
|---|
| website brief, audiences, content, SEO evidence, integrations, governance, budget, and launch constraints | Buyer, ToR, approved project record, accountable owner, or verified evidence source | Yes | Stop the affected decision, name the missing source, and return only a qualified outline or assumption register. |
Outputs
| Artefact | Consumer | Acceptance condition |
|---|
| website proposal strategy, scope, and quality gates | Buyer, evaluator, and website delivery team | Claims trace to supplied evidence; assumptions, owners, exclusions, decisions, and observable acceptance tests are explicit. |
Evidence Produced
| Evidence | Consumer | Acceptance condition |
|---|
| Decision and source trace for the output | Reviewer and release owner | Each load-bearing choice identifies its source, rationale, accountable owner, and any unassessed check. |
Capability Contract
Default to read-only for analysis, critique, discovery, and review. Minimum capability is access to the supplied artefacts and permission to inspect or calculate relevant evidence. Edit only the requested working copy. Do not publish, send, spend, change production systems, certify compliance, make a statutory claim, or approve a commercial concession without explicit authority.
Degraded Mode
If required files, interviews, finance doctrine, search evidence, calculation tools, network access, or specialist review are unavailable, return the narrowest useful qualified result. Mark unavailable checks as not assessed, separate facts from assumptions, and state what is needed to resume. An unassessed gate is never a pass.
Decision Rules
| Choice | Action | Failure/risk avoided |
|---|
| Select website scope and delivery route | Align audience jobs, content readiness, search evidence, technology, integrations, and operating ownership. | A visually ambitious proposal with no content or launch feasibility. |
| Evidence conflicts or authority is absent | Stop the affected recommendation, record the conflict, and seek the named owner’s decision. | Invented facts or unauthorised commitments. |
| Evidence and approval are complete | Proceed within scope and retain the decision trace. | Irreproducible approval or scope drift. |
Workflow
- Confirm the consumer, decision, neighbouring-skill route, authority, and required inputs; stop if the primary route or accountable owner is unknown.
- Inspect supplied evidence and record facts, assumptions, conflicts, and unavailable checks; stop on a load-bearing contradiction.
- Apply the domain method and decision rules, preserving the repository’s proposal voice and specialist constraints.
- Draft the contracted output with observable acceptance conditions and an evidence trace.
- Review alignment with scope, work plan, team, pricing, risk, and dependent proposal sections; recover by revising the affected choice and rerunning the check.
- Run the critical-analysis and anti-slop gates; block release on unsupported claims, failed safety or finance gates, or an F slop grade.
Quality Standards
- Every load-bearing claim is verified or explicitly qualified, and the output distinguishes fact, assumption, recommendation, and commitment.
- Scope, method, work plan, staffing, pricing, risks, dependencies, and acceptance conditions remain mutually consistent.
- The output preserves domain constraints, names accountable owners, covers failure paths, and blocks unsupported or unauthorised promises.
- British English and the repository’s East African professional tone are used unless the buyer requires another standard.
- The critical-analysis and anti-slop gates pass before release, with no unassessed check represented as passed.
Anti-Patterns
- Inventing a buyer fact or proof point. Fix: cite the supplied source or mark the statement as an assumption requiring confirmation.
- Treating an unavailable check as passed. Fix: mark it not assessed and name the evidence needed to resume.
- Copying a neighbouring skill’s method without routing. Fix: use the specialist for the primary decision and retain only the supporting layer here.
- Writing acceptance as “satisfactory” or “appropriate”. Fix: state an observable measure, evidence record, and decision owner.
- Adding premium or technical claims without delivery capacity. Fix: reconcile the claim with named people, time, budget, dependencies, and authority.
Worked Example
A membership portal needs public content, payments, and restricted resources. Separate website and application scope, name content owners, verify integration assumptions, and define launch acceptance and support.
References
- website-design-proposal-gate - proposal-ready philosophy, methodology, stack, deliverables, costing drivers, and red flags.
- 06-methodology - proposal methodology section owner.
- 10-financial-proposal - financial proposal and costing owner.
- premium-client-proposal-strategy - use for premium, executive, enterprise, affluent, or high-ticket website proposals.
- service-design-proposal-strategy - use when the website is part of a wider customer, citizen, or staff service journey.
- proposal-storytelling-and-evaluator-journey - design rationale, evaluator journey, and case-story support.
- customer-service-and-maintenance-proposals - post-launch support, SLA, maintenance, and escalation language.
- premium-pricing-and-value-defense - premium website pricing and value defence.
- technical-strategy-credibility-checklist - architecture, maintainability, operations, SaaS, and roadmap checks.
