Business Analysis Case Study
EcoTrack – Household Carbon Footprint App
A sustainability concept that translated carbon reduction goals into measurable features, clearer flows, and a simpler product structure for Victorian households.
Problem Definition
Requirements Analysis
User Flow
Prototype Screens
Problem
Households needed a simpler way to understand everyday carbon impact.
Sustainability information is often broad or hard to interpret.
Outcome
EcoTrack translated an abstract sustainability problem into a product structure with clearer features, flows, and prototype evidence.
What I did
- Defined the problem and product scope from a BA and user perspective.
- Mapped the user flow and identified the core interactions the app needed.
- Translated sustainability objectives into measurable digital features.
- Supported wireframes and prototype screens to test how the product could work.
Approach
I treated the case study as a translation problem.
- Defined the user problem before deciding on screens.
- Structured features around footprint visibility, comparison, and action.
- Used user flow thinking to keep the concept focused and coherent.
Artefacts
Problem statement
Helped define what the app was solving and what should stay out of scope for the first version.
Requirements table and feature map
Organised the app around a calculator, neighbourhood comparison, and sustainable device awareness rather than broad environmental messaging.
User flow and journey logic
Used to connect the concept to everyday behaviour and product flow.
Prototype screens
Showed how the carbon features could be presented in a clear mobile interface.
Alternative interface treatment
Supported discussion around consistency, readability, and product direction.
Recommendation
The recommended solution was a focused app that combined footprint visibility, neighbourhood comparison, and practical sustainability prompts.
What I learned
- Abstract problems need stronger definition before any solution work starts.
- Simple flows matter when the product is trying to change behaviour.
- Requirements work is most useful when it leads to measurable and testable features.