Build a focused portfolio with verifiable case studies, usable contact paths, accessible presentation and a tested production release.
Define who will read the portfolio and what they should be able to assess or do: understand your role, inspect relevant work, try a demonstration or contact you. Select projects that provide evidence for that purpose. Draft a page outline with a clear introduction, case studies, background and contact path.
For each project, explain the problem, constraints, your specific contribution, key decisions and the resulting evidence. Distinguish team outcomes from your own work and label prototypes or illustrative results. If a writing target helps, enter your chosen word budget and observed drafting pace; the tool does not supply an SEO-preferred length.
Use semantic headings, descriptive links and meaningful image alternatives. Check text and backing colors, keyboard focus, zoom and layout at narrow widths. Give media dimensions, compress assets while inspecting quality, and provide text context for demonstrations. Test the contact path and make download labels identify their file type.
Build with the project’s configured command and serve the resulting output. Follow project links, direct URLs, browser back/forward and contact actions. Check loading, empty/error states and keyboard navigation on desktop and phone layouts. Use browser network and performance tools to inspect real resources; a total asset estimate cannot identify the slow request.
Choose hosting that supports the app’s actual rendering and server needs. Verify the domain, HTTPS, meaningful page titles, descriptions and canonical URLs. Review measured responses and cache settings; the header parser can inspect one pasted redacted response block. Publish through your normal release process and verify the public contact and project paths.
Save a release note with the deployed version, checked routes and known limitations. Review broken links and outdated claims when work changes. If you collect analytics, define the relevant events and handle privacy requirements before collection. Compare actual visits and completed contact actions over a stated period without assuming a universal conversion target.
Draft and download case-study outlines and release checks.
Plan remaining drafting work using your own editorial word target.
Compare chosen text and backing colors.
Inspect one pasted production response for declared headers.
Loading your checklist…
Google’s starter guide emphasizes helpful, understandable content and descriptive presentation. It does not prescribe a magic word-count target.
Use WCAG’s rendered text/background requirements along with keyboard and layout checks; a color-pair result is only one part of accessibility.
Keep these task-specific records with the tested version and review date.
| Record | Include | Verify |
|---|---|---|
| Contribution | Problem, constraints, your work and collaborators | Claims match the evidence |
| Demo | Version, route, setup and fallback | Works without the development environment |
| Contact | Intended action and destination | Complete the actual contact path |
Link to permitted evidence or explain what is confidential instead of inventing a performance figure.
A direct project link should work without first opening the homepage.