Step 1: Review project output
Review everything you have built. The full inventory:
- Data profiling results from DuckDB
- Data quality assessment (from experience, no template)
- Metric definitions -- plain language and SQL -- for revenue, average transaction value, and category trends
- Three interactive plotly charts with drill-downs, human-readable hover labels, and minimum-data-point warnings
- Exploratory Metabase dashboard for Amina with cross-filters and drill-downs
- Guided Metabase dashboard for store managers with pre-set questions and "needs attention" flags
Verify everything is saved and committed. Notebooks, SQL files, Metabase exports or configuration notes.
Step 2: Write the README
The README is the document another analyst reads when they need to understand what was built and why.
Write a README.md for the project. Include:
1. What was built: interactive dashboards for Soma Books, a three-store bookstore chain in Dar es Salaam
2. Who it's for: two audiences -- Amina (exploratory dashboard) and her store managers (guided view)
3. Key metrics: revenue (total and retail-only), average transaction value, category growth trends -- with the inclusion/exclusion rules
4. How to run: Docker + Metabase for the persistent dashboards, Jupyter for the plotly charts
5. Design rationale: why there are two views and who each one is for
The design rationale section matters most. Another analyst will see two dashboards and wonder why. The README explains: the exploratory view serves someone who knows what questions to ask. The guided view serves someone who needs the questions already answered. Both use the same metric definitions, both show the same numbers, but they present the information at different literacy levels.
Document the metric definitions alongside the dashboards. When a future analyst modifies a query, the documentation tells them what the metric should include, what it should exclude, and why. Governance survives beyond the project only if it is written down.
Step 3: Commit and push
Commit any remaining changes. Push to GitHub.
git add -A
git commit -m "Complete Soma Books interactive dashboards: exploratory and guided views with governed metrics"
git push origin main
Step 4: Final message to Amina
Open the chat with Amina. Send a final summary of what was delivered.
Three things to communicate: (1) the two dashboards are ready -- the exploratory view for her and the guided view for her managers, (2) the metric definitions document what each number means and what is included or excluded, and (3) the author events analysis she requested would be a valuable follow-up project when she has the event attendance data.
Keep it in her terms. Not "dual-audience self-service design" but "your dashboard and a simpler version for your managers." Not "metric governance documentation" but "a document explaining what each number means."
Amina responds professionally. The dashboards are what she needed. Her managers will use the guided view starting next week.
Check: Does your README explain the difference between the exploratory and guided dashboards? Could another analyst understand why there are two views and who each one is for?