Skill detail
website-design-proposal-strategy
Supports website-design proposal strategy, scope, and costing rather than design execution.
Inspect before use
Automated review checks relevance, not safety or endorsement. Read the source instructions before using this skill.
SKILL.md
The saved excerpt is a snapshot from review. The external source remains the complete and most current version.
--- 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. <!-- dual-compat-start --> ## 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 1. Define the website's role in the assignment: marketing, lead generation, service delivery, information access, ecommerce, investor confidence, stakeholder communication, or public accountability. 2. Select the proposal posture: premium authority site, growth/lead-generation site, institutional information site, ecommerce system, campaign landing page, or web application interface. 3. Draft the philosophy: strategy before design, content before decoration, search and accessibility by default, performance/security as quality gates, and measurable launch outcomes. 4. Build the methodology from reviewable artefacts: discovery brief, content/SEO map, UX architecture, design system, prototype, build, QA, launch, training, and support. 5. Explain the stack in client-value language: speed, ownership, maintainability, security, integrations, content workflow, scalability, and total cost of ownership. 6. Explain design decisions through client goals, user needs, evidence, trade-offs, and approval points, especially where stakeholders may prefer different layouts or technologies. 7. Treat forms, search, navigation, errors, confirmation messages, and content workflows as business-critical service moments, not minor interface details. 8. 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. 9. Define post-launch support, maintenance, analytics review, security updates, content updates, and optimisation so they are not implied freebies. 10. 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 thRead the full source on GitHub (opens external page)