Choose evidence for the reader
A portfolio should help a reviewer understand a question you investigated, the work you performed and the evidence behind the result. Start with one coherent case study rather than an unverified list of tools. State whether the data is synthetic, public or privately supplied, and only publish material you have permission to share.
Make the page easy to scan
Use a short introduction, a project summary and a case-study section with a clear heading. Put the question and conclusion near each other, then explain the method. Add working source links where appropriate. Avoid presenting unfinished templates, empty project cards or decorative dashboard images as completed analytical work.
Connect every result to its input
The self-contained example below includes all three synthetic input records, row calculations and product totals. A reader can verify 100 plus 50 plus 50 equals 200 without obtaining a hidden file. For a larger project, provide a permitted sample or clear retrieval instructions, a data dictionary and the steps needed to reproduce the result.
Explain an analytical decision
Describe how you handled duplicate identifiers, missing values and units. Separate a measured result from an interpretation. In the example, Notebook revenue exceeds Pen revenue in an invented three-order sample; this does not prove a real market preference or profit advantage. Mention what information would be needed to investigate those broader questions.
Use accessible charts and tables
Do not make a screenshot the only way to understand a result. Provide a text explanation of important findings and an accessible table when exact values matter. For a complex chart image, provide a suitable short alternative and a fuller equivalent description nearby or through an appropriate link. Give tables meaningful captions and identify header cells.
Review the complete browser experience
Save the example as portfolio.html and open it locally. Check the project navigation link, heading order, table readability and keyboard access. Test narrow screens and browser zoom. If you later add a repository or dashboard link, verify that a reader without your account can access the intended content and that it does not expose private records.
Practice a second version
Replace the invented records with a different permitted sample and recalculate every result. Keep units explicit and include one data-quality check. Ask another learner to reproduce the total from the page. If the explanation cannot account for a number, revise the analysis before polishing the design.
Know what publishing changes
A local HTML file is a practice artifact. Hosting it publishes content to an audience whose access rules you must understand. Static hosts can serve HTML/CSS/JavaScript, but they do not automatically turn a local analysis into a private application. Review all files and screenshots before publishing. Do not add fictional employers, client impact, certificates or placement claims.
Complete local portfolio.html example
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Data Analyst Portfolio: Synthetic Orders Study</title>
<style>
body { font: 1rem/1.6 system-ui, sans-serif; margin: 0; padding: 1rem; color: #183047; }
main { max-width: 52rem; margin: auto; }
table { width: 100%; border-collapse: collapse; }
th, td { text-align: left; padding: .4rem; border: 1px solid #adc0cf; }
a { color: #124e94; }
</style>
</head>
<body>
<main>
<h1>My Data Analysis Practice</h1>
<p>Classroom portfolio example using synthetic records. No real client outcome is claimed.</p>
<nav aria-label="Project navigation"><a href="#orders-study">Orders case study</a></nav>
<article id="orders-study">
<h2>Which product generated more revenue?</h2>
<p>Question: compare revenue for two products in a three-order synthetic sample.</p>
<table>
<caption>Complete synthetic input. Prices are arbitrary INR values.</caption>
<thead><tr><th scope="col">Order</th><th scope="col">Product</th><th scope="col">Quantity</th><th scope="col">Unit price</th></tr></thead>
<tbody>
<tr><td>1</td><td>Notebook</td><td>2</td><td>50</td></tr>
<tr><td>2</td><td>Pen</td><td>5</td><td>10</td></tr>
<tr><td>3</td><td>Notebook</td><td>1</td><td>50</td></tr>
</tbody>
</table>
<h3>Method</h3>
<p>Check distinct order IDs and positive quantities. Calculate quantity times unit price for each order, then sum by product. Row values are 100, 50 and 50 INR.</p>
<table>
<caption>Revenue by product in this sample only</caption>
<thead><tr><th scope="col">Product</th><th scope="col">Revenue (INR)</th></tr></thead>
<tbody><tr><th scope="row">Notebook</th><td>150</td></tr><tr><th scope="row">Pen</th><td>50</td></tr></tbody>
</table>
<p>Total sample revenue: <strong id="sample-revenue">200 INR</strong>.</p>
<h3>Interpretation and limitations</h3>
<p>Notebooks contribute more revenue in this sample. Three invented records cannot establish real customer demand, profit or a market trend. Tax, returns and costs are not modelled.</p>
<h3>Next check</h3>
<p>Insert a duplicate order ID and decide how the analysis should report it before recalculating totals.</p>
</article>
</main>
</body>
</html>
Expected result
Input row revenue: 100, 50 and 50 INR. Notebook: 150 INR. Pen: 50 INR. Total: 200 INR. This is synthetic classroom data, not a real business result.
Further reading
Check your progress
Keep your working files, test cases and notes together. Explain one design decision, demonstrate a failure case and list what you would improve next. These concrete outputs make it easier to identify the next skill to practice.