CASE STUDY 05
Digitizing
Asset
Management
A double digitization challenge - redesigning how Nutrien manages assets and the people behind them, with AI accelerating every stage from synthesis to ideation, and engineering embedded as a design partner from day one.
DATA VISUALIZATION . AI ASSISTED IDEATION & SYNTHESIS
CLIENT
Nutrien
SYSTEM
Digital Transformation . Asset Management
MY ROLE
METHODS
Senior UX Designer
Ethnographic Research · Field Studies · Persona Development · Empathy Mapping
CORE CHALLENGE
MANUAL
DIGITAL . DATA VISIBILITY . USER MANAGEMENT
OVERVIEW
Heavy data.
No way to
it clearly.
This project focused on digitizing Nutrien's asset maintenance, utilization, and optimization processes - workflows that were entirely manual, carried out through data-heavy physical documents maintained and updated by staff across multiple locations.
The absence of any digital data-visualization layer was placing enormous cognitive load on Regional Finance Managers - the people responsible for reviewing this data and making profitability decisions based on it. Beyond asset management, there was an equally critical gap: no system for managing the users responsible for purchasing or leasing those assets in the first place.
This was a double digitization challenge - the data needed a digital home, and so did the people managing it
Entirely manual process
Asset maintenance, utilization tracking, and optimization decisions were all carried out through physical documents with no digital record, no version control, and no visibility across locations.
Unsustainable cognitive load
Regional Finance Managers were required to review and interpret dense, unstructured data documents to make high-stakes profitability decisions without any visualization or summarization layer to support them.
No user management system
There was no mechanism to manage the ownership, permissions, or accountability of users responsible for purchasing or leasing assets - a foundational gap that created risk and inefficiency across the organization.
"The data existed. The decisions were being made. But the system made both harder than they needed to be and the people carrying that weight had no way to say so."
PRODUCT DISCOVERY
Before designing
understand the ecosystem.
I began by mapping every stakeholder connected to this product - not just the end users, but the people who would commission it, maintain it, and be held accountable for its outcomes. From there, I ran a co-creation workshop to build a shared product ecosystem map, ensuring that no one's reality was being assumed away before the design work began.
STEP 01
Stakeholder Mapping
Identified and mapped every stakeholder with a relationship to this product - from Regional Finance Managers to asset owners to procurement leads - before a single conversation was scheduled.
STEP 02
Product ecosystem co-creation workshop
Facilitated a workshop with stakeholders to collaboratively map the product ecosystem surfacing assumptions, aligning on scope, and building shared ownership over the problem definition before moving into research.
STEP 03
Artifact review & assumption mapping
Before meeting users, I reviewed all existing artifacts to chart what was already known and, crucially, what remained unknown. This pre-research clarity sharpened every question I brought into the field.
STEP 04
Field research - ethnographic observation
Met users in their actual work environments to observe their processes in context. Not what they said they did - what they actually did, and where the real friction lived.
PRODUCT ECOSYSTEM MAPPING
RESEARCH PREPARATION
What I knew.
What I needed to find out.
One practice I consistently apply before entering any user research is mapping the boundary between known and unknown - using existing artifacts to establish a baseline, so every research session is spent closing real gaps rather than confirming assumptions I could have resolved at my desk.
KNOWN - FROM ARTIFACT REVIEW
The current process was entirely manual and document-driven
UNKNOWN - NEEDED FROM FIELD RESEARCH
Where in the workflow did cognitive load peak — and why?
Regional Finance Managers were the primary decision-makers
What workarounds had users already built to compensate for system gaps?
Asset ownership and leasing were key workflows in scope
There was no existing user management layer in the system
How did different roles experience the same data differently?
What would users trust a digital system to do and what would they not?
USER RESEARCH PREP WORK
ETHNOGRAPHIC RESEARCH
Into the field.
Into the real workflow.
The most important research decision on this project was going to identify where the work actually happened. Sitting across from a user in a meeting room tells you what they think and do. Observing them at their actual workstation reveals the gap between the two.
WHY FIELD RESEARCH OVER INTERVIEWS ALONE
Ethnographic observation puts the researcher in the user's context where the workarounds are visible, the environment shapes the behavior, and users can show rather than tell. It's where the voice of the user is heard at its most unfiltered.
Context reveals what interviews miss
Visiting users in their actual work locations surfaced environmental factors - interruptions, shared screens, physical document flows - that no interview question would have uncovered.
Workarounds as design signals
Every improvised workaround a user had developed was a direct signal of where the system had failed them and a starting point for what the new design needed to solve.
Voice of the user at its core
Field research allowed users to narrate their own experience in real time not reconstruct it from memory - producing insights grounded in actual behavior, not recalled behavior.
FIELD RESEARCH WORK
RESEARCH METHODS
Three tools.
One user-centred foundation.
Field research fed directly into a set of synthesis tools designed to translate raw observation into actionable design direction and to give the full cross-functional team a shared understanding of who they were building for.
PERSONA DEVELOPMENT
JOURNEY MAPPING
EMPATHY MAPPING
Ethnographic research gave the persona work a depth that workshops alone couldn't achieve. Each persona captured not just role and responsibilities, but the cognitive pressures, environmental realities, and trust thresholds that would shape how users engaged with a new digital system.
Journey maps traced the full asset management workflow from initial procurement through ongoing maintenance decisions, identifying bottlenecks, handoff failures, and moments where the manual process created compounding downstream problems.
Empathy maps gave the team structured access to users' feelings, frustrations, and motivations, not as abstract data points, but as a shared reference for design decisions. When a feature was proposed, the empathy map was the check: does this reflect how our users actually think and feel?
AI IN THIS PROJECT - SYNTHESIS
From field notes to design direction in half the time.
After completing ethnographic field sessions, I was sitting on a significant volume of raw observation notes, process recordings, and stakeholder interview transcripts. Traditionally, this synthesis phase - clustering observations, surfacing behavioural themes, identifying opportunity areas, would consume the better part of a week before any design thinking could begin.
I fed the raw notes into AI tools to do the first pass of thematic clustering: grouping recurring language, flagging contradictions between what users said and what I observed them doing, and identifying which pain points were role-specific versus systemic. The output wasn't insight , that still required my interpretation and contextual judgment. But it compressed the time between data and direction dramatically, freeing up cognitive bandwidth to spend on the harder questions the data was pointing toward.
Crucially, I used AI to surface the gaps, the questions the data raised but didn't answer, which directly sharpened the known/unknown framework I brought into subsequent research rounds.
AI IN DESIGN IDEATION
Exploring further,
faster.
The data visualization layer was the most consequential design challenge in this project. Regional Finance Managers needed to make high-stakes profitability decisions from complex, multi-variable asset data and the wrong visual approach wouldn't just be confusing, it would actively lead to worse decisions. Getting the direction right before committing to wireframes mattered enormously.
Rather than opening Figma and anchoring on the first concept that felt comfortable, I used AI as an ideation partner feeding in the specific user constraints surfaced from field research and asking it to generate a wide range of possible visualization approaches.
AI IN THIS PROJECT - IDEATION
Designing with constraints, not around them.
The prompt wasn't generic. I gave the AI the specific context: users making time-pressured decisions, varied data literacy across roles, high cognitive load already present before they open the dashboard, and a need to surface anomalies without overwhelming the baseline view. The resulting directions ranged from conventional (tabular summaries with status flags) to approaches I wouldn't have reached on my own - progressive disclosure models that surfaced different data depths depending on the user's role.
I didn't use those outputs directly. I used them as a pressure-test on my own assumptions, running each direction against the empathy map to ask: would this reduce cognitive load for someone already carrying too much, or add to it? That question filtered the viable directions quickly and gave me a sharper brief to bring into engineering conversations.
The final visualization approach wasn't AI-generated. It was AI-informed, human-judged, and engineering-validated.
TOOLS USED: CHATGPT . GEMINI
ENGINEERING COLLABORATION
Design and engineering
in the same room.
One of the deliberate choices I made early in this project was to bring engineering in before the designs were finished not after. In a digitization project where the data structure, API limitations, and backend constraints would directly shape what was possible in the UI, designing in a vacuum wasn't just inefficient. It was a risk I wasn't willing to take.
EARLY ALIGNMENT
Sharing research findings with engineering before ideation
I ran a working session with the engineering lead to walk through key findings from field research - particularly the cognitive load pain points and the workarounds users had built. Engineers who understand why a design decision was made are far more likely to find creative ways to support it within technical constraints.
CONSTRAINT MAPPING
Understanding data structure before committing to layouts
Before finalizing any visualization concepts, I ran the leading concepts by engineering to map each one against the actual data structure available. This surfaced constraints early and in two cases redirected the design in ways that produced a better outcome than the original concept, not just a technically feasible one.
ITERATIVE REVIEWS
Regular design-engineering check-ins during wireframing
Rather than a single handoff review, I scheduled short, focused check-ins with engineering at each significant wireframe milestone. This meant that by the time designs reached hi-fidelity, they had already been stress-tested against backend realities and the engineering team felt genuine ownership over the solutions, not just recipients of a spec.
USER MANAGEMENT ARCHITECTURE
Co-designing the permissions model
The user management system - one of the two core digitization gaps required particularly close design-engineering collaboration. The permissions model had to accommodate complex organizational hierarchies. I worked with engineering to map the data model first, then designed the UI around what the system could actually support, avoiding the common failure of designing a permissions interface that looks right but breaks on implementation.
" The best design decisions on this project didn't happen in Figma. They happened in conversations with engineering where constraints became creative constraints, and both sides left with better answers than either had going in."
HI-FIDELITY DESIGNS
The most important thing a designer can do in a digitization project is resist the urge to digitize the existing process. Use AI to move faster through the data. Work with engineering to understand what's actually possible. Then design the system that should exist - not the one that does.