Disclaimer: This case study is based on an internal project. Some details, terminology, and visuals have been adapted or blurred to protect sensitive information and confidentiality. The goal is to highlight my approach to design, problem-solving, and outcomes.
Challenge
Reporting for a highly potent greenhouse gas was manual, error-prone, and scattered across disconnected spreadsheets trackers and asset management systems. This created data silos, inconsistent formats, and no real-time visibility, making it difficult for teams to find, trust, and act on emissions data.
Approach
Followed a user-centred, iterative design approach to design a role-based centralised monitoring dashboard shaped by user research. Created structured views around key use cases, applied contextual and human-centred data visualisation. Tested interactive prototypes with real data for rapid feedback and refinement.
Results
Adopted across teams as part of daily operations and regular performance reviews.
Cut reporting cycles significantly.
Increased data accuracy and reliability, improving trust in reported figures.
Enabled faster, evidence-based decision-making by surfacing trends and high-priority issues.
Led concept development and end-to-end UI/UX design, from research synthesis to polished development-ready prototypes.
Collaborated with researchers, engineers, product managers, and stakeholders throughout discovery to handoff, ensuring feasibility, accuracy, and alignment with project goals.
Delivered fully annotated design assets including Figma files, interaction specifications, and video walkthroughs.
DATA VISUALISATION
DASHBOARD DESIGN
SYSTEMS THINKING
SUSTAINABILITY
WORKFLOW OPTIMISATION
ENTERPRISE WEB APPLICATION
"User reported that the dashboard become the single trusted source for the latest emission data.”
— Operational Staff
"User valued the ability to quickly identify high-priority issues and monitor progress toward resolving them."
— Operational Staff
The SF6 dashboard is a centralised and comprehensive dashboard within the internal asset management platform for visualising, monitoring and managing the Sulphur Hexafluoride (SF6) gas data. This data is crucial for environmental reporting, asset risk visibility and operational decision-making.
Duration
Core Users
Team
Tools
Area of Business
< Jump to >
The SF6 (a gas 24,300 times more potent than CO₂) reporting process was fragmented, manual, and error-prone, heavily reliant on spreadsheets trackers disconnected from the asset management system. These trackers were difficult to navigate, prone to human error, and lacked real-time updates. This made it difficult for operations teams, environmental teams, and leadership to access timely and reliable insights into usage and emissions.
Key challenges included:
Data silos, inconsistent formats, and a lack of real-time visibility.
Difficulty integrating with legacy systems.
Limited user awareness of where to find or how to interpret data.
Contributor – Actively participated in user interviews, journey mapping, and co-creation sessions alongside a senior researcher and designer.
To ground the design in real user needs, we began with discovery sessions involving leadership, operations staff, analysts and environmental specialists. We mapped the existing reporting workflow to identify friction points, such as data fragmentation, manual processes, and challenges in interpreting complex datasets.
Key research outputs: Through the journey mapping exercise of four key personas: Leadership, Operations staff, Analyst, and Environmental specialists. We identified three primary use cases:
At a glance view: for instant, high-level insights.
Detailed view: for in-depth exploration and filtering.
Reporting view: to support structured data reporting.
Led concept development, UI design, prototyping and user testing. Collaborated with the researcher, stakeholders, product managers and developers.
After uncovering distinct user needs through discovery, I translated these insights into an intuitive dashboard and conducted usability testing to observe interactions and gather feedback to improve the dashboard design and experience iteratively.
Design Decision 01
Familiarity first: Reducing the learning curve
Decision
Intentionally designed the initial dashboard interface to mirror the layout and structure of familiar spreadsheet based trackers. This included replicating common terms, table formats, and layout hierarchies that users were already accustomed to.
Why this decision was made
Many users were long-time spreadsheet users with deeply ingrained habits. Introducing a drastically new layout would have increased resistance and slowed adoption. By starting with something familiar, we reduced friction, built early trust, and created a smooth transition into a more structured digital tool.
Impact
Smooth user onboarding without formal training.
Reduced resistance to the new system.
Set a foundation for evolving the UI over future iterations.
Design Decision 02
Use case aligned structure: Design for intent
Decision
Transitioned from fragmented spreadsheet trackers to a centralised, role-based, interactive dashboard. Structured into three clear sections, each mapped to a specific user need:
At a glance view: for instant, high-level insights.
Detailed view: for in-depth exploration and filtering.
Reporting view: to support structured data reporting.
Why this decision was made
Users had diverse goals, depending on their roles. A one-size-fits-all layout would have led to clutter, confusion, or underuse. By aligning the information architecture with distinct use cases, we helped each persona access what they needed more quickly and with greater clarity.
Impact
Improved task efficiency across personas and reduced cognitive load.
Increased confidence in navigating the dashboard.
The structure scaled well as new features were introduced post-launch.
Design Decision 03
Scorecard and reporting
Decision
Designed the scorecard modal to reflect the same structure and allowed each key metric to be copied with one click, eliminating the need for manual data entry into regulatory spreadsheet.
Why this decision was made
Data needs to be submitted using a predefined format. By aligning the reporting layout with the required structure and reducing manual data entry, we improved both speed and accuracy.
Impact
Reduced reporting time significantly, especially for recurring operational and performance reviews.
Increased confidence in data accuracy.
Eliminated rework caused by formatting issues or manual errors.
Design Decision 04
Visualisation with purpose: Making numbers meaningful
Decision
Alongside the raw emission data card. Emission numbers were presented and visualised as contextual cards to make data relatable and easier to interpret. Examples included real-world equivalents such as energy use or travel distances. Later iterations incorporated estimated costs and potential compliance impacts to highlight the operational and financial stakes.
Why this decision was made
Raw environmental metrics can feel abstract and hard to interpret. Senior stakeholders and non-technical users needed to quickly understand the real-world implications. Framing the data in relatable terms made the impact more tangible and encouraged timely action.
Impact
Executives could instantly grasp the scale and significance of emissions at glance.
Contextual cards became one of the most referenced features in stakeholder reviews.
Design Decision 05
Data storytelling and visualisation: Driving insight, not just display
Decision
Applied data visualisation best practices to design charts and continuously gathered user feedback to refine them. Examined which metrics were best suited for different types of data. To enhance decision-making, actionable context, such as benchmarks, comparisons, and percentage changes, is included in charts (including bar, line, and trend charts) and data cards. Embedded inline tooltips that revealed calculation logic, assumptions and linked to source documentation (e.g., environmental policies, technical standards).
Why this decision was made
Displaying numbers wasn’t enough users needed to understand what they meant and what to do next. Senior stakeholders, in particular, needed to scan for anomalies or trends without wading through raw tables. Analysts wanted supporting detail, but not at the cost of simplicity.
By focusing on storytelling, not just visuals, we gave each user role exactly what they needed to act with confidence.
Impact
Users could interpret trends and anomalies faster.
Iterative chart testing via the charting library accelerated usability feedback and refinement.
Helped shift the role of the dashboard from a passive data viewer to an active decision-support tool.
Design Decision 06
Detailed view: Control through interaction
Decision
Designed detailed analytical views for operations teams and analysts who needed to deep-dive into metrics. The dashboard supported:
Customisable table views with filter, sort, and search by asset attributes
Colour-coded thresholds to quickly flag metrics exceeding set limits.
A priority issues section highlighting the most significant anomalies, with direct links to related records in the asset management system.
Customisation & personalisation: Users could adapt table views, sort, and filter by asset, time period, and metric.
This enabled users to investigate patterns, prioritise maintenance, and drill down into specific problem areas with ease.
Why this decision was made
Unlike senior stakeholder who needed quick summaries, operational teams and analysts required control and depth. Their workflows involved comparing multiple variables, identifying anomalies, and tying insights back to operational actions. Giving them the ability to customise and filter data ensured the dashboard served not just as a viewer, but as a decision-making tool.
Impact
Significantly improved efficiency of investigative workflows for operational teams.
Enabled users to spot and act on issues faster, particularly with the priority issues feature.
Reduced context-switching by embedding relevant record links links directly into the interface.
Led the final design handoff, including documentation, edge case management, and prototype delivery.
Early and frequent collaboration with the engineering and product teams ensures proactive alignment and feasibility checks.
Key actions:
Shared early design and prototypes for technical validation and team feedback.
Delivered a fully annotated Figma file with edge cases, interaction notes, and fallback states.
Included short video walkthroughs to reduce handoff friction and accelerate development.
Transformed a fragmented, manual reporting process into a unified digital dashboard that’s now embedded in daily operations, regular performance reviews, and strategic decision-making.
🔍
Improved data visibility & insights
Provided real-time visibility into exposure and trends across all assets, including critical infrastructures sites. The dashboard becomes a strategic tool, not just a reporting tool, enabling users to spot anomalies, prioritise maintenance and track environmental performance.
🚀
Operational efficiency & automation
Reduction in reporting time required to generate regular reports and eliminating manual spreadsheet consolidation.
🤝
Data confidence & trust
Reduction in interpretation errors and administrative overhead and freed up time for analysis over data management.
“User reported that the dashboard become the single trusted source for the latest emission data.”
— Operational Staff
“User valued the ability to quickly identify high-priority issues and monitor progress toward resolving them."
— Operational Staff
01
Zooming out helps design better
One of the biggest takeaways for me was the value of systems thinking. Initially, it was tempting to focus solely on the UI or screen-level issues, but this project prompted me to take a step back. The real problem wasn’t just about SF6 reporting issues. It was about disconnected systems, siloed teams and outdated workflows. Understanding how everything fits together helped me design something far more relevant and impactful.
“Great UX doesn’t just solve a screen-level problem—it untangles system-level complexity.”
02
Prototypes speak louder than words
Creating clickable prototypes helped me communicate intent clearly across product, engineering, and non-design stakeholders, especially when dealing with abstract data and complex workflows.
“If a picture is worth 1,000 words, a prototype is worth 1,000 meetings.” – Tom & David Kelley
That quote hit home during this project.
03
Working with real data early makes a huge difference
We didn’t wait to perfect the charts before conducting the test. I plugged in real or near-real data early and iterated quickly directly in the chart library. That helped us figure out what wasn’t working fast, whether it was the wrong chart type, unclear labelling, interaction patterns and visual hierarchy. Tweaks, such as adding benchmarks or trend indicators, had a disproportionately positive effect on comprehension.
04
People need more than numbers, they need context
I learned that simply showing accurate data isn’t enough; users need to trust what they see. Tooltips, data sources, and calculations helped the user feel confident in using the dashboard as a source of truth. Without context, numbers are just noise.
05
Cross-functional collaboration must be ongoing
We brought engineers in from the start, not just during handoff, and that made a huge difference. They flagged technical constraints early (like asset management tools sync limitations) before they became blockers, and we adapted together. It turned what could’ve been late-stage blockers into collaborative problem-solving.
06
Designing for adoption is as important as designing for functionality
Success depends not only on the features we built, but on whether people actually use them. Early versions of the dashboard were intentionally designed to follow familiar layouts (like spreadsheet) to minimise friction, integrated it into existing workflows (such as regular operational calls), and gradually introduced advanced features.