Lesson 34 / Capstone
Portfolio Polish
Refine a final web project for presentation with stronger hierarchy, consistency, accessibility, responsiveness, performance, storytelling, and live-demo confidence.
Course Role
Studio Support
Best during work sessions, critique, debugging, project planning, or final polish.
Teacher Notes / In-Class Use
Demo Live
- Model the core workflow from the lesson using a small class example.
- Connect the example back to the first goal: Evaluate a final project like a portfolio piece
Try In Class
- Run a 20-minute polish sprint and fix only must-fix or should-fix issues.
- Have students make one visible change, save, refresh, and explain what changed.
Submit Or Check
- Ask students to show the work in the browser, not only in the editor.
- Have students commit their progress with a clear message when the checkpoint is stable.
Watch For
- Students copying code without checking file paths, spelling, or capitalization.
- Visual changes that work locally but break when the project is published.
Learning Goals
- Evaluate a final project like a portfolio piece
- Prioritize fixes by impact before adding new features
- Improve visual consistency, content clarity, accessibility, responsiveness, performance, and interaction quality
- Prepare a project story, final critique notes, and a reliable live demo
Polish Is Editing
Polish does not mean adding more decoration. It means removing friction, strengthening hierarchy, tightening spacing, fixing inconsistencies, and making the project easier to understand.
At the end of a project, the best move is usually not a brand-new feature. The best move is making the core experience clearer, more reliable, and easier to present.
Final Polish Mindset
- Protect the working version of the project before making risky changes.
- Fix broken or confusing parts before adding decorative extras.
- Improve what viewers will notice first: page purpose, hierarchy, navigation, and mobile layout.
- Choose clarity over complexity when time is limited.
- Make the project easier to explain, not just busier to look at.
Prioritize The Fixes
Not every issue has the same urgency. Use priority levels so the final hours go toward the work that matters most.
| Priority | Examples | Action |
|---|---|---|
| Must fix | Broken links, missing images, unreadable text, mobile layout breaking, form labels missing, live URL not working. | Fix before submission. |
| Should fix | Inconsistent spacing, unclear headings, vague buttons, weak image crops, uneven card styles. | Fix after must-fix issues are stable. |
| Nice to fix | Extra animation, decorative details, additional sections, optional visual flourishes. | Only do if the core project is already solid. |
Portfolio Review Passes
| Pass | Question |
|---|---|
| Content | Does each page clearly explain what it is and why it matters? |
| Hierarchy | Can a viewer scan the page and understand the most important content first? |
| Consistency | Do buttons, cards, spacing, type, colors, and image treatments follow a system? |
| Responsive | Does the design work at mobile, tablet, and desktop widths? |
| Accessibility | Can the project be used with keyboard, readable contrast, and clear labels? |
| Performance | Are images optimized and unnecessary assets removed? |
| Interaction | Do buttons, links, forms, and navigation have clear states and feedback? |
| Presentation | Can you explain the project goal, audience, process, and final decisions? |
Visual Consistency Pass
A project feels more finished when repeated elements behave like they belong to the same system.
- Buttons use consistent colors, padding, border radius, and hover or focus styles.
- Cards share a consistent layout, spacing, image ratio, and border treatment.
- Headings follow a clear type scale instead of random sizes.
- Spacing between sections feels intentional and repeatable.
- Images use consistent cropping, alignment, and quality.
- Colors support hierarchy instead of competing everywhere at once.
- Edges and alignment line up cleanly across nearby elements.
Content Clarity Pass
Good polish is not only visual. The words on the page should make the project easier to understand.
- Replace placeholder copy with real project content.
- Rewrite vague headings so they describe the section clearly.
- Make calls to action specific, such as View the Menu or Explore Projects.
- Make the page purpose obvious within the first screen.
- Remove repeated text that does not add new information.
- Check spelling, capitalization, and punctuation in visible UI text.
Project Story Formula
A portfolio piece should help someone understand the problem, your decisions, and the result. Even a short class project can include a clear project story.
I built [type of site] for [audience] so they can [goal].
I focused on [design or development choices].
One challenge was [challenge], and I improved it by [solution]. Project Summary Example
<article class="project-summary">
<h1>Neighborhood Food Guide</h1>
<p>
I built a responsive listing site for students who want to compare local
restaurants by price, distance, and study-friendly features. I focused on
clear navigation, reusable cards, mobile layout, and optimized images.
</p>
</article> Before And After Critique Prompts
A strong critique does not only show what changed. It explains why the change made the project better.
- What was confusing, inconsistent, or unfinished before the polish pass?
- What did you change?
- Why does the change help the audience?
- What tradeoff did you make because of time?
- What would you improve next if the project continued?
Presentation Structure
Use a simple structure so the presentation stays focused and does not turn into clicking around randomly.
| Part | What To Say Or Show |
|---|---|
| Goal | What the project is and why it exists. |
| Audience | Who the site is for. |
| Key pages or features | Show the most important page, flow, or interaction. |
| Design decisions | Explain layout, color, typography, navigation, or component choices. |
| Challenge | Mention one problem you solved or improved. |
| Live demo | Click through the stable parts of the published site. |
| Next step | Name one improvement you would make with more time. |
Live Demo Checklist
- Open the live URL before presenting.
- Close unrelated tabs and windows.
- Click through the navigation path you plan to show.
- Test the key interaction before presentation time.
- Check the mobile layout if responsive design is part of the project goal.
- Avoid spending presentation time explaining broken areas unless the critique asks about them.
- Have backup screenshots ready if internet, hosting, or projection fails.
Portfolio Project Card Guidance
If the project will become part of a portfolio later, capture the important information while the work is still fresh.
- Project title
- Your role
- Tools and technologies used
- Short project summary
- Screenshot or mockup image
- Live site link
- Repository link, if appropriate
- What you learned or improved
Quality Bar
| Level | What It Means |
|---|---|
| Unfinished | Core pages, links, images, or layout are broken or unclear. |
| Class-ready | The project meets the assignment, works live, and has been checked for responsive, accessibility, and content issues. |
| Portfolio-ready | The project has a clear story, polished visuals, strong screenshots, tested live links, and a concise explanation of decisions. |
Final Technical Pass
- Open the live URL and click through important pages.
- Test the layout at mobile, tablet, and desktop widths.
- Check keyboard focus, headings, contrast, labels, and alt text.
- Optimize images and remove unused assets.
- Confirm links, forms, and interactions behave as expected.
- Check metadata, title, favicon, and any social preview tags used by the project.
- Run one final performance or Network panel check for unusually large files.
Common Last-Minute Mistakes
| Mistake | Better Move |
|---|---|
| Adding a new complex feature at the end | Polish the core experience first. |
| Only checking desktop | Run a mobile pass before submission. |
| Ignoring content quality | Rewrite vague headings and placeholder copy. |
| Changing many styles at once | Make small improvements and test after each one. |
| Over-animating the final version | Use motion only when it clarifies feedback or flow. |
| Submitting without testing the live URL | Open the published site and click through it. |
Final Polish Checklist
- Remove unused sections, dead links, and placeholder content.
- Make spacing and button styles consistent across pages.
- Check headings, contrast, focus, and keyboard navigation.
- Optimize images and confirm the live site loads correctly.
- Write a short project description that explains the purpose and audience.
- Prepare two or three sentences for critique or presentation.
- Choose one must-fix issue and one should-fix issue to resolve before submission.
Checkpoint
Before moving on, make sure these feel true.
- I can evaluate a project for clarity, hierarchy, consistency, responsiveness, accessibility, and performance.
- I can improve a project without adding unnecessary complexity.
- I can explain the project goal, audience, process, and result.
Practice
- Run a 20-minute polish sprint and fix only must-fix or should-fix issues.
- Choose three improvements that make your final project clearer, not just busier.
- Rewrite the project summary using the project story formula.
- Prepare a two-minute presentation using the goal, audience, key feature, decision, challenge, and next-step structure.
- Run one accessibility, one responsive, and one performance pass on the live URL.
- Create or update one portfolio project card with title, role, tools, summary, screenshot, live link, and what you learned.