Guide Purpose
Use this process to reduce rushed guesswork, clarify ownership, improve content readiness, and create a better experience for clients, designers, developers, writers, and strategy partners.
Web Design Workflow Process Guide
This guide defines a repeatable workflow for web design projects so strategy, content, design, development, ownership, and approvals stay aligned from intake through launch.
1. Overview
The goal of this process is to create a consistent, repeatable workflow for web design projects across Marketing, DX, content owners, developers, writers, strategy partners, and leadership stakeholders.
This process is not intended to slow projects down. It is intended to prevent unclear requests, missing content, rushed timelines, incomplete design direction, avoidable rework, and weak user experiences.
| Area | Primary Purpose | Main Benefit | Process Role |
|---|---|---|---|
| Alignment | Bring the right people into the project early | Fewer surprises and clearer expectations | Shared starting point |
| Content Readiness | Confirm what content exists and what still needs to be created | Design is based on real needs instead of assumptions | Design foundation |
| Ownership | Identify who owns decisions, content, approvals, and maintenance | Less confusion during and after launch | Accountability layer |
| Design Quality | Connect visual design to audience, content, and purpose | Better user experience and stronger outcomes | Strategic execution |
2. Core Principle
A website or page should not begin with “make a homepage.” A homepage is usually a connector. It highlights, organizes, and guides users into the deeper content, services, tools, stories, or tasks that live throughout the site.
Before homepage design begins, the team should understand what the site is for, who the primary users are, what actions users need to take, what content exists, what content is missing, and who owns the site after launch.
| Question | Why It Matters | Risk If Missing |
|---|---|---|
| What is the site for? | Defines the purpose and success criteria | The design becomes decorative instead of strategic |
| Who is the audience? | Shapes content, language, layout, and calls to action | The page may serve internal assumptions instead of user needs |
| What content supports the homepage? | Determines what the homepage should promote and connect to | The homepage becomes a guessing game |
| Who owns content and approvals? | Keeps the project moving with clear responsibility | Decisions stall or change late in the process |
3. Project Intake
Every web project should begin with a documented request, even if the idea starts through a hallway conversation, leadership request, meeting, or informal chat.
| Field | Required | Purpose | Notes |
|---|---|---|---|
| Project Name | Yes | Identifies the project clearly | Use a consistent name across chats, tickets, docs, and files |
| Requesting Department | Yes | Identifies who is asking for the work | Should include the primary department or group |
| Project Owner | Yes | Defines who is responsible for the project moving forward | This may not always be the same as the requester |
| Decision Maker | Yes | Clarifies who can approve direction | Prevents late-stage reversals and unclear authority |
| Content Owner | Yes | Identifies who provides and maintains content | Required before design can be finalized |
| Requested Launch Date | Yes | Defines timeline expectations | Include the reason for the date if it is urgent |
| Primary Audience | Yes | Guides content, structure, and design decisions | List secondary audiences separately |
| Project Goal | Yes | Defines what the work is trying to accomplish | Should be outcome-focused, not just page-focused |
| Known Constraints | Recommended | Identifies timing, content, technical, or approval issues | Document risks early |
| Existing Pages or Systems | Recommended | Shows what the new work connects to | Include URLs, tools, data sources, or related sites |
4. Intake Gate
Before design starts, the team should know who owns the project, who provides content, who approves direction, what the request is, and why the work matters.
| Requirement | Status Needed | Reason |
|---|---|---|
| Documented Request | Required | Creates a shared record of the ask |
| Owner Identified | Required | Prevents the project from becoming ownerless |
| Decision Maker Identified | Required | Clarifies who can approve direction |
| Content Owner Identified | Required | Prevents design and development from inventing content |
| Timeline Reason Documented | Required for rush work | Helps the team understand urgency and risk |
5. Discovery and Alignment
Discovery brings the right people together before work starts moving in different directions. The purpose is to align on scope, audience, content needs, functionality, ownership, timeline, dependencies, and approvals.
| Group | Role | When Needed | Primary Contribution |
|---|---|---|---|
| Requesting Department | Project context and goals | Always | Defines need, audience, and ownership |
| Strategy | Project alignment | Recommended | Clarifies goals, audience, success measures, and process |
| Content/Writing | Content quality and clarity | When content is new, complex, or public-facing | Reviews voice, clarity, accuracy, SEO, and structure |
| Design | User experience and visual structure | Always for design work | Translates content and strategy into accessible layout |
| Development | Technical feasibility and build planning | When build work is needed | Identifies technical needs, constraints, and implementation path |
| DX | Platform, data, systems, or technical ownership | When the project connects to DX systems or workflows | Coordinates technical direction and system alignment |
| Analytics/SEO | Measurement and findability | Recommended for major projects | Defines tracking, search needs, and success indicators |
6. Content Map and Site Map
Content should lead structure. Before visual design begins, the team should create at least a working content map and site map.
| Content Field | Required | Purpose | Owner |
|---|---|---|---|
| Page Title | Yes | Identifies the page and its purpose | Content owner |
| Page Purpose | Yes | Explains why the page exists | Project owner |
| Audience | Yes | Defines who the page is for | Project owner and strategy |
| Key Message | Yes | Clarifies the main idea users should understand | Content owner and writer |
| Required Sections | Yes | Defines the page structure | Content owner, strategy, and design |
| Calls to Action | Yes | Defines what users should do next | Project owner and strategy |
| Data, Stats, or Links | As Needed | Supports accuracy and user tasks | Content owner |
| Content Status | Yes | Shows what is ready, missing, or pending | Content owner |
| Approval Owner | Yes | Defines who approves content | Project owner |
| Maintenance Owner | Yes | Defines who keeps content current after launch | Requesting department |
| Site Area | Required | Purpose | Notes |
|---|---|---|---|
| Homepage | Yes | Connects users to the deeper site content | Should not be designed in isolation |
| Main Navigation | Yes | Shows the primary content structure | Should reflect user priorities, not internal politics |
| Supporting Pages | Yes | Defines what the homepage links to | Needed before homepage design is finalized |
| Priority Pathways | Recommended | Shows the most important user journeys | Helps guide content hierarchy |
| External Systems or Tools | As Needed | Identifies technical dependencies | Include dashboards, forms, portals, or data tools |
| Missing or Unknown Pages | Yes | Documents gaps before they become blockers | Assign owners and dates where possible |
7. Content Review
Before design or development moves too far, content should be reviewed by the appropriate writing or content team. Placeholder content can support early wireframes, but it should not replace content planning.
| Review Area | Required | What to Check | Why It Matters |
|---|---|---|---|
| Clarity | Yes | Is the content easy to understand? | Users should not have to interpret internal language |
| Accuracy | Yes | Are facts, numbers, names, and links correct? | Prevents trust and maintenance issues |
| Audience Fit | Yes | Does the content match the needs of the intended users? | Improves usefulness and task completion |
| Brand Voice | Recommended | Does the content sound appropriate for the institution? | Improves consistency across pages |
| Calls to Action | Yes | Are the next steps clear? | Helps users move forward |
| SEO Basics | Recommended | Are page titles, headings, and key terms clear? | Improves findability |
| Accessibility | Yes | Is the content structured clearly for all users? | Supports inclusive access and standards |
| Maintenance | Yes | Who updates the content after launch? | Prevents stale or abandoned pages |
8. Design Strategy and Wireframe
Design should start with structure before polish. The wireframe phase should show how the content works, how users move through the page, and where the project still has gaps.
| Wireframe Area | Required | Purpose | Review Focus |
|---|---|---|---|
| Content Hierarchy | Yes | Shows what information is most important | Does the page lead with the right message? |
| Page Sections | Yes | Defines the structure of the page | Are sections clear, useful, and complete? |
| User Pathways | Yes | Shows where users go next | Are the next steps obvious? |
| Navigation Needs | As Needed | Shows how the page connects to the site | Does the structure match the site map? |
| Reusable Components | Recommended | Identifies design system patterns | Can existing components solve the need? |
| Content Gaps | Yes | Documents missing or incomplete content | Who owns the missing items? |
9. Visual Design
Once structure is approved, the designer creates the visual design using approved brand standards, design system components, accessibility requirements, and existing templates where possible.
| Design Area | Required | Purpose | Notes |
|---|---|---|---|
| Page Layout | Yes | Defines how content is arranged | Should support the approved wireframe |
| Content Hierarchy | Yes | Uses visual weight to guide users | Headings, spacing, and modules should support scanning |
| Component Recommendations | Yes | Identifies reusable patterns | Use existing design system options where possible |
| Responsive Considerations | Yes | Plans mobile, tablet, and desktop behavior | Do not treat desktop as the only design state |
| Image or Media Direction | As Needed | Clarifies visual content needs | Include ratio, crop, and quality notes |
| Button and Link Strategy | Yes | Clarifies primary and secondary actions | CTAs should be purposeful and consistent |
| Accessibility Notes | Yes | Documents accessibility considerations | Include contrast, heading order, focus, and interaction notes |
| Development Notes | Recommended | Helps the build move smoothly | Include behavior, states, and reusable component notes |
10. Development Handoff
Development should begin when the design, content, and scope are stable enough to build without major guessing. Development should not be expected to resolve missing content, unclear ownership, or stakeholder disagreements that should have been handled earlier.
| Handoff Item | Required | Purpose | Notes |
|---|---|---|---|
| Approved Design | Yes | Provides the build direction | Include mobile or responsive notes where needed |
| Content Source | Yes | Shows final or working content | Content gaps should be clearly marked |
| Page Map or Component Notes | Recommended | Connects design to implementation | Identify reusable modules and special cases |
| Required Interactions | As Needed | Defines behavior | Include accordions, sliders, tabs, filters, modals, or forms |
| Accessibility Notes | Yes | Supports inclusive implementation | Include keyboard, focus, labels, headings, and contrast notes |
| Responsive Behavior | Yes | Defines how the layout adapts | Include important stacking or order changes |
| Image and Media Needs | As Needed | Clarifies assets required for launch | Include file names, ratios, alt text, or captions |
| Analytics or Tracking Needs | Recommended | Supports measurement | Include events, goals, dashboards, or reporting needs |
| Known Risks | Yes | Documents unresolved issues | Prevents hidden assumptions from becoming launch problems |
11. Review, QA, and Launch
Before launch, the project should go through a final review that confirms content, links, accessibility, responsive layout, approvals, analytics, and ownership.
| Review Area | Required | What to Confirm | Reviewer |
|---|---|---|---|
| Content Accuracy | Yes | Text, facts, names, stats, and dates are correct | Content owner |
| Links and CTAs | Yes | All links work and route users correctly | Project team |
| Mobile Layout | Yes | Page works on smaller screens | Design and development |
| Accessibility Basics | Yes | Headings, contrast, labels, keyboard access, and focus states are checked | Design and development |
| SEO Basics | Recommended | Page title, headings, metadata, and key terms are appropriate | Content or SEO support |
| Analytics Setup | Recommended | Tracking is in place where needed | Analytics support |
| Ownership Confirmation | Yes | Maintenance owner is confirmed | Project owner |
| Final Approval | Yes | Decision maker approves launch | Decision maker |
12. Rush Project Process
Some projects will always be urgent. A rush process should exist, but “rush” should not mean “skip all process.” It should mean the team documents the tradeoffs clearly and agrees on what can realistically be completed.
| Requirement | Required | Purpose | Risk If Missing |
|---|---|---|---|
| Reason for Urgency | Yes | Explains why the work needs to move quickly | Everything becomes urgent by default |
| Rush Approval | Yes | Confirms leadership or stakeholder support | Teams absorb unmanaged timeline pressure |
| Project Owner | Yes | Identifies who keeps the project moving | No one owns decisions or blockers |
| Content Owner | Yes | Identifies who provides missing content | Design and development become content guesswork |
| Known Missing Items | Yes | Documents what is incomplete | Gaps become hidden blockers |
| Accepted Risks | Yes | Clarifies what quality, scope, or timing tradeoffs are being made | The team is blamed for decisions it did not make |
| Post-Launch Cleanup Plan | Recommended | Defines how temporary work will be improved later | Temporary work becomes permanent |
A rush homepage with no site map, no content, and no ownership should be treated as a concept or temporary phase, not a completed strategic website.
13. Design Readiness Checklist
Use this checklist before moving a project into design.
| Check | Required | Review Notes |
|---|---|---|
| Documented request exists | Yes | Request should be captured in the approved intake process |
| Project owner is identified | Yes | Someone must own the project from request through launch |
| Decision maker is identified | Yes | Approvals should not be unclear or scattered |
| Content owner is identified | Yes | Design cannot finalize around missing or ownerless content |
| Audience is defined | Yes | Audience drives structure, tone, and priorities |
| Project goal is clear | Yes | The page should solve a defined need |
| Content map exists | Yes | At minimum, the team needs working content structure |
| Site map or page structure exists | Yes | The homepage should connect to known pages or pathways |
| Required pages are known | Recommended | Missing pages should be documented with owners |
| Homepage purpose is clear | Yes | The homepage should support the larger site, not replace planning |
| Calls to action are identified | Yes | Users should have clear next steps |
| Timeline is realistic | Yes | Rush timelines should document tradeoffs |
| Review process is defined | Yes | Prevents unclear feedback loops |
| Approval path is defined | Yes | Prevents late-stage reversals |
| Known risks are documented | Yes | Protects the team and improves transparency |
14. Homepage Design Requirements
Before requesting a homepage design, the team should provide the information needed to understand what the homepage is supporting and where users need to go next.
| Input | Required | Purpose | Notes |
|---|---|---|---|
| Site Purpose | Yes | Explains why the site exists | Should be more specific than “we need a homepage” |
| Primary Audience | Yes | Defines who the page serves first | List internal and external audiences separately |
| Key User Tasks | Yes | Shows what users need to do | Examples: find data, request help, explore reports, contact the team |
| Site Map or Proposed Navigation | Yes | Shows what the homepage connects to | Can be working draft if clearly labeled |
| Supporting Pages | Yes | Identifies destination content | Missing pages should be marked |
| Content Priorities | Yes | Guides hierarchy | Helps avoid visual design based only on preference |
| Required Homepage Sections | Recommended | Identifies known modules | Examples: hero, quick links, highlights, dashboards, contact, FAQ |
| Calls to Action | Yes | Defines user next steps | Primary and secondary CTAs should be identified |
| Reference Sites | Optional | Provides visual or structural inspiration | References do not replace content strategy |
| Content Ownership | Yes | Defines who provides and maintains content | Ownership should continue after launch |
| Approval Owner | Yes | Defines who approves direction | Needed before design can be finalized |
15. Roles and Responsibilities
Clear roles help prevent design, development, content, and strategy work from blending into unmanaged guesswork.
| Role | Primary Responsibility | Key Deliverables | Common Risk If Missing |
|---|---|---|---|
| Requesting Department | Defines the need, provides context, and maintains content after launch | Request, content, approvals, maintenance plan | The site launches without long-term ownership |
| Strategy | Clarifies goals, audience, structure, intake, and success measures | Alignment notes, intake guidance, success criteria | The project becomes task-based instead of purpose-based |
| Content/Writing | Reviews or develops content for clarity, accuracy, and usefulness | Reviewed copy, content recommendations, content gaps | The design is built around incomplete or unclear content |
| Design | Translates approved strategy and content into an accessible branded experience | Wireframe, visual design, responsive notes, design handoff | Design is forced to solve missing strategy or content |
| Development | Builds the approved design within technical and platform requirements | Built page/site, interaction behavior, QA support | Development is asked to interpret unresolved design or content decisions |
| Leadership | Supports the process and helps remove blockers | Priority clarity, decision support, timeline support | Urgency bypasses the process and creates rework |
16. Key Process Rule
No team should be asked to move quickly because another part of the process did not happen.
If content, structure, ownership, or approvals are missing, the project can still move forward, but the risk should be documented and shared clearly.
- The goal is not to block work.
- The goal is to make work smoother and more predictable.
- The process should protect the client experience as much as it protects internal teams.
- Design should support real content, clear purpose, and known user needs.
- Rush work should document tradeoffs instead of hiding them.
- Ownership should continue after launch.
17. Recommended Next Step
Start using a standard intake and content planning document for each major page type or template. Each time a new template or page type is created, the team should also create a guide and intake process for that page type.
| Reusable Item | Purpose | Benefit |
|---|---|---|
| Page Type Guide | Explains what the page type is for | Creates consistent expectations |
| Content Intake Form | Collects required content before design | Reduces missing information |
| Required Content Fields | Defines what content is needed | Improves readiness and quality |
| Recommended Content Lengths | Guides layout-friendly writing | Improves visual consistency |
| Ownership Expectations | Defines who maintains the page after launch | Prevents stale content |
| Design and Development Notes | Documents layout, behavior, and technical needs | Speeds up future projects |
| Analytics or Success Measures | Defines how the page will be evaluated | Moves decisions from opinions to evidence |
18. Summary
A strong web design process creates better alignment before design begins, gives developers clearer direction, helps writers and content owners prepare usable content, and gives clients a more predictable experience.
- Start with a documented request.
- Identify project, content, approval, and maintenance owners.
- Define audience, purpose, and user goals before design.
- Create a content map and site map before final homepage design.
- Use wireframes to confirm structure before visual polish.
- Document rush-project risks instead of skipping process.
- Use each project to improve future templates, intake forms, and guides.
It seems that you have reduce motion enabled!