Start with the role, not the software list
A data analyst, BI developer, and analytics engineer can all use SQL, Power BI, Python, or Tableau. The useful distinction is the problem you want your portfolio to prove you can handle. Define a target role, the questions it is expected to answer, the systems it touches, and the level of technical depth the reader should find.
| Positioning focus | Portfolio evidence to emphasize |
|---|---|
| Data analyst | Business question, source data, cleaning choices, analysis, dashboard decisions, assumptions, and recommendations. |
| BI developer | Semantic model, star or snowflake choices, DAX measures, Power Query or ETL, governance, performance, and deployment context. |
| Analytics engineer | Data modeling, transformation workflow, testing, documentation, data contracts, downstream usability, and versioned implementation. |
Choose projects with a question and a constraint
A dashboard screenshot rarely shows why the work mattered. Start every project with a decision someone needed to make, the data available, and the constraints that shaped the solution. A smaller project with an honest explanation is more useful than a large collection of visuals with no context.
- State the business or operational question before naming the tool.
- Explain where the data came from and what was missing, unreliable, or intentionally excluded.
- Describe cleaning, transformations, modeling, measures, calculations, and validation decisions.
- Show the output at a readable scale, then offer a technical deep dive for readers who need it.
- Separate measured outcomes from proposed use; do not imply an outcome you did not observe.
Show technical depth without making the page unreadable
Use a layered structure. Begin with the business context and the result the work was intended to support. Then offer details about acquisition, SQL, Python, Excel automation, Power Query, Tableau, Power BI, DAX, semantic models, and dashboard interaction. Readers should be able to stop at the level that serves them.
- For data models, identify fact and dimension concepts, grain, important relationships, and why a structure fits the reporting question.
- For measures and calculations, explain the business definition, filter assumptions, edge cases, and how you checked the output.
- For visual design, explain the primary audience, comparison task, accessible labeling, interaction choices, and information hierarchy.
- For performance, document the constraints you observed and the changes you made; do not claim a benchmark you did not measure.
Make data quality, assumptions, and limitations visible
Trust comes from showing what the work does not prove as well as what it does. Explain data freshness, missing values, definitions, exclusions, synthetic elements, unverified inputs, and assumptions. If a metric is scaled, normalized, or composite, say so plainly. This helps a reader judge the work without mistaking a polished interface for a complete answer.
A fictional worked example
Business question: how should a support-operations team examine resolution patterns by category and channel while keeping the metric definition and incomplete records visible? The intended audience is a fictional support-operations lead. The intended decision is where to investigate definitions, workflow, or staffing questions next, not whether a person or team has met a performance target. This belongs in an analyst portfolio because it connects a decision to source data, quality work, modeling, measure design, dashboard structure, and limitations.
| Table | Important example fields | Role in the analysis |
|---|---|---|
| Tickets | Ticket ID, opened date, resolution timestamp, final status, agent key, category key, channel key | One record per synthetic support ticket before documented quality handling. |
| Agents | Agent key, team label, active-date range | Provides non-identifying synthetic grouping attributes; no person names are used. |
| Dates | Date key, date, week, month, quarter | Supports consistent time filtering and trend comparisons. |
| Categories | Category key, standardized category | Keeps inconsistent source labels out of report groupings. |
| Channels | Channel key, channel label | Supports a controlled channel breakdown and makes incomplete values visible. |
- Dim Date
- Dim Agent
- Dim Category
- Dim Channel
The grain of Fact Tickets is one eligible synthetic ticket per row. Dimensions are separated so dates, agents, categories, and channels can filter the same measures consistently. This structure supports trend and breakdown questions, but it is illustrative rather than a universal modeling requirement.
Resolution Rate =
DIVIDE(
[Resolved Tickets],
[Total Tickets]
)Resolved Tickets is the numerator: eligible tickets meeting the documented final-resolution rule in the current filter context. Total Tickets is the denominator: all eligible ticket records in that same context. Reopened tickets need an explicit rule, and blank or incomplete status and timestamp records should be flagged rather than silently counted. The business definition must be documented because the calculation is only as valid as those choices.
| Layer | Purpose | Design and accessibility notes |
|---|---|---|
| Primary KPI | Show Resolution Rate with its written definition and exception context. | Do not rely on color alone; label the value and definition directly. |
| Trend | Show the rate and eligible ticket volume over time. | Use readable axes, direct labels where practical, and sufficient contrast. |
| Breakdown | Compare category and channel patterns without turning the view into a ranking claim. | Keep category names legible and provide a table alternative when useful. |
| Operational detail | Expose fictional exception records for investigation. | Use descriptive column headers, keyboard-reachable controls, and a constrained mobile layout. |
| Filters and interactions | Filter date, category, and channel while preserving definition context. | Give controls visible labels, predictable focus order, and clear reset behavior. |
| Mobile and readability | Prioritize the KPI, definition, trend, and key exceptions on narrow screens. | Stack content, allow tables to scroll within their container, and avoid clipped labels. |
- Overview
- Business context
- Data and quality
- Model
- Measures
- Visual design
- Findings
- Assumptions and limitations
- Technical appendix
Continue planning the evidence
Career portfolio websites for data analysts — Plan analyst evidence around questions, quality, models, measures, and decisions.Career portfolio websites for BI developers — Go deeper on semantic models, DAX, governance, and delivery.How to show confidential work — Choose permission, redaction, synthetic data, and access controls responsibly.Career portfolio demonstration work — Review a clearly disclosed fictional demonstration with no downloadable files.Choose the right evidence format
| Format | Useful when | Check before publishing |
|---|---|---|
| Screenshots | The visual hierarchy or outcome can be understood without interaction. | Sanitize names, values, metadata, notifications, and hidden browser UI. |
| Interactive demo | Interaction changes how the reader understands the analysis or dashboard. | Use fictional or approved data, maintain it, and make controls accessible. |
| GitHub repository | The code, SQL, documentation, or data pipeline is the useful evidence. | Review commit history, secrets, licenses, sample data, and setup instructions. |
| Downloadable artifact | A reader genuinely needs to inspect a file offline. | Remove confidential data and document versions; do not publish a file merely because it exists. |
A practical project-page structure
- Role or project label and one-sentence value proposition.
- Business question, audience, and decision context.
- Data sources, quality checks, transformations, and modeling choices.
- Measures, calculations, analysis method, and important assumptions.
- Dashboard or deliverable explanation with accessible visuals.
- Limitations, privacy approach, and what the project does not claim.
- Links to deeper technical material only when it is safe and useful to publish.
Maintain the portfolio as your work changes. Retire weak projects, update screenshots when an interface changes, and make the opening page easier to scan than the deepest technical section. A portfolio is not a storage room for every artifact; it is a guided record of the evidence most relevant to your next role.
Sources
- Understand star schema and the importance for Power BI
Microsoft Learn · Accessed August 5, 2026. Used to support the discussion of facts, dimensions, model relationships, and the connection between model design, usability, and performance.
- DAX overview
Microsoft Learn · Accessed August 5, 2026. Used as a primary reference for describing DAX as part of a Power BI portfolio's technical evidence.