Hassaan Javed
Start with the page inventory and goal
List every page, reusable template, modal, form, and special state included in the build. Mark which pages are launch-critical and which can follow later. This prevents a polished homepage from hiding an incomplete project scope.
For each page, identify the primary action and the content owner. A developer can then make sensible decisions about component reuse, CMS structure, analytics, and validation.
- Approved page and template list
- Primary action for each page
- Final or clearly labeled draft copy
- Named owner for missing content and approvals
Define responsive behavior, not only breakpoints
Desktop and mobile frames are useful, but the important detail is what happens between them. Note when grids collapse, navigation changes, images crop, long headings wrap, and decorative elements disappear.
Include realistic long and short content in repeated components. A card that works with one tidy sentence may fail when connected to Webflow CMS content.
- Desktop, tablet, and mobile intent
- Image crop and focal-point guidance
- Navigation and menu states
- Long-copy and empty-content examples
Turn repeated design decisions into a system
Use shared text styles, color variables, spacing rules, and components for repeated patterns. Name them by purpose rather than appearance so the Webflow implementation stays understandable when the design evolves.
Variants should represent real states such as compact, featured, dark, or with-image. Avoid creating separate components for tiny visual differences that could be handled by a clear property or modifier.
- Typography hierarchy and font files
- Color and spacing tokens
- Buttons, fields, cards, and navigation components
- Hover, focus, active, disabled, and error states
Separate CMS content from page decoration
Mark content that editors will update after launch. Group fields into logical collections and identify relationships such as authors, categories, services, projects, and locations.
Provide examples for optional fields and empty states. This helps the developer build conditional visibility and prevents blank wrappers, broken spacing, or duplicated collections.
- Proposed CMS collections and relationships
- Required and optional fields
- Slug and URL expectations
- Empty-state and conditional-content behavior
Document motion, integrations, and acceptance checks
For every interaction, describe the trigger, movement, duration, and reduced-motion fallback. A short prototype is more useful than a note that says animate this section.
Before development starts, list forms, analytics events, CRM destinations, cookie requirements, redirects, and third-party scripts. Finish with agreed browser, device, accessibility, and content checks for approval.
- Interaction prototypes and reduced-motion behavior
- Forms, analytics, CRM, and automation requirements
- Redirects and existing SEO requirements
- Browser, responsive, accessibility, and launch checklist