HumanValue Global Career Intelligence | Researched 8 November 2026
Before publishing another data-analysis dashboard, explain what each field means, how its values are coded and which records your calculation includes. A data dictionary makes those decisions visible. For African analysts presenting work to international employers, it can demonstrate a skill that a chart alone cannot: helping another person interpret and reuse the data without guessing.
This guide shows how to build a small, credible dictionary alongside a fictional dataset. It is a documentation exercise, not a claim that you have completed a real client analysis. Use it to strengthen the explanation behind your work, then compare your evidence with the actual technical requirements of the role you want.
1. Start with the question a reviewer will ask
A reviewer looking at “average response time” may ask: response by whom, measured from which event, in what unit, across which cases? If those answers are absent, two analysts can produce different figures from the same file and both believe they followed the heading. Clear documentation helps reveal the disagreement before a decision is based on the chart.
A dictionary describes fields and their interpretation. It complements rather than replaces a project README, source note and calculation explanation. A README might explain the project’s purpose and permission to use the data; a dictionary explains a column such as first_reply_minutes. A metric note explains how that column enters a particular measure.
2. Choose data you can legitimately share
Use an explicitly fictional dataset or public data whose access and reuse conditions you have checked. A file being downloadable does not automatically settle every reuse question. Retain the source, version and relevant terms for a public-data project. Do not publish an employer’s customer or staff records to demonstrate analysis skills.
For the example here, create an invented support-request dataset with no personal identifiers. State that all cases are fictional. Keep one row per request and describe that unit of observation. Do not mix requests, messages and customers in the same row structure without explaining the relationship.
3. Document meaning as well as format
The California Open Data Publisher’s Handbook lists field names, labels, types, definitions and valid values as dictionary elements. Its supported type choices relate to its own publishing platform. Your project may use different technical types, but readers still need an unambiguous explanation of the values.
| Field | Meaning and format | Interpretation rule |
|---|---|---|
request_id |
Invented request reference stored as text | One reference per row; preserve leading characters |
opened_at |
Timestamp when the fictional request was recorded | All example timestamps use UTC; state the convention explicitly |
first_reply_minutes |
Elapsed minutes from opening to the first recorded staff reply | Non-negative number; blank means no reply recorded in this exercise |
status |
Controlled text: open, waiting or closed | These labels are defined for this fictional project only |
closed_at |
Timestamp of recorded closure | Blank while no closure is recorded; it is not a zero-duration case |
A type alone is not a definition. “Integer” does not explain whether a value counts people, days or transactions. A date column also needs to identify the event. “Date” is too vague if opening, delivery and completion could all be relevant.
4. Distinguish zero, missing and not applicable
In the fictional dataset, a reply time of zero means the recorded elapsed time is zero under the exercise’s measurement rule. A blank means that a first reply is not recorded. These are different statements. Replacing every blank with zero would change the meaning of the data and could make a performance measure misleading.
Write down the coding rule before calculating. If the source uses several missing-value codes, retain their definitions and explain any transformation. Do not assume that a value such as 99, an empty string or “N/A” always has the same meaning across datasets. If you do not know, flag the question instead of silently treating it as a number.
Fictional arithmetic example: Two replied cases have first-reply times of 10 and 20 minutes. Their mean is 15 minutes. A third case has no reply recorded. Treating that blank as zero would produce 10 minutes across three rows, a different calculation with a different and unsupported interpretation. Report the unresolved case separately and state the denominator used.
This illustration is arithmetic, not a recommendation for a universal customer-service KPI. A real organisation needs an agreed metric definition, reporting window and handling of cases that remain unresolved. The analyst’s job includes making those choices explicit.
5. Make international interpretation easier
When colleagues work across countries, avoid ambiguous date strings, unexplained local abbreviations and currency columns without currency identifiers. A value shown as 01/02 can be read differently depending on convention. Use an explicit format and explain the time-zone treatment where timestamps matter.
If a project includes monetary amounts, define the currency, unit and whether any conversion was performed. Do not combine currencies because the column is called “amount”. If categories are translated, retain a mapping so a reviewer can follow the original and display labels. These choices help a distributed team understand the analysis without relying on shared local assumptions.
The US Geological Survey’s data-dictionary resource provides another official reference for documenting data elements. Use reference material to improve the clarity of your own project, not to imply that a public agency has reviewed or endorsed your portfolio.
6. Add checks that test the documented rules
For the fictional support file, check whether request references are unique, status values match the stated vocabulary and recorded reply times are non-negative. Where a closure is recorded, examine whether its timestamp precedes opening. State what was checked and what failed. Do not report “clean data” when only one rule was tested.
Keep a change log for corrections made in the exercise. Show the issue, the decision, the reason and whether the source value was preserved. If a rule changes, version the dictionary with the dataset. A perfect-looking dictionary for an older file can be less useful than a clearly labelled current document with open questions.
7. Build the portfolio around an explainable result
Package the fictional data, dictionary, transformation notes and one modest analysis. Explain the question, the calculation and the limits before showing the chart. Ask a peer to calculate the same measure using your documentation; differences can reveal an unclear field or denominator. Record the feedback and what you revised.
For spreadsheet foundations, review HumanValue Workplace Excel Essentials against your specific needs. The course uses Tanzanian workplace examples; it is not an international data-science credential. For another technical communication skill, see how to explain a tested API quickstart.
8. Questions analysts often ask
Is a dictionary only useful for large datasets?
No. Even a small file can contain an ambiguous date, code or unit. Document the fields whose meaning a reviewer would otherwise have to infer.
Can a dashboard tooltip replace the dictionary?
A tooltip may help users read one visual. A separate dictionary can explain the underlying fields, valid values and rules needed by someone reusing the file. Keep them consistent.
Does this demonstrate every data-analyst skill?
No. It demonstrates documentation and a defined part of analytical reasoning. An employer may separately require SQL, statistical methods, domain knowledge, programming or other skills.
9. Present the evidence honestly
Describe your work as a fictional documentation-and-analysis project, identify the tools you actually used and explain one interpretation problem you prevented. The CV & Application Pack Lab can support clearer presentation of genuine evidence. When exploring international career information, match your sample to the vacancy and keep claims proportionate to what the project proves.
