AgriTech / Web App / End-to-End Product Design
Shrimpl is an platform with the mission to make shrimp farming smarter and more sustainable. It helps farmers turn complex data into clear, actionable insights to improve productivity and reduce risk.
Project overview
Overview
Shrimpl is an operating system designed to help shrimp farms manage their entire farming cycle, from planning and daily operations to analytics and reporting.
Although I was initially tasked with redesigning the dashboard experience, research revealed a much larger opportunity. The dashboard was only the final destination of a much longer operational workflow. Before meaningful insights could exist, farms first needed a structured way to plan their operations, guide daily work, and consistently capture data.
This realization expanded the project from a dashboard redesign into three connected products:
Farming Plan
Farming Operation
Farm Dashboard
This case study focuses on Farming Plan, the foundation that standardizes an entire farming cycle before it begins.
What I actually did in the project
I collaborated closely with the product manager and engineering team to redefine how farming plans were created and managed.
My responsibilities included defining product requirements, mapping operational workflows, designing information architecture, creating the interaction model, building reusable UI patterns, and validating the experience through continuous discussions with stakeholders.
Although this project built upon research conducted during my design challenge before joining the company, that initial work mainly served as a reference. After joining, the assumptions were revisited and refined based on business discussions, technical constraints, and deeper understanding of shrimp farming operations.
The Challenges
Data Had No Foundation
The original vision was to redesign the farm dashboard. However, the biggest obstacle wasn't visualization.
Many farms simply didn't generate enough structured data to support meaningful analytics. Farmers recorded information differently across farms, while many operational activities were never captured digitally at all. As a result, dashboards frequently displayed empty charts or incomplete reports, giving the impression that nothing was happening even when farms were operating normally.
Without reliable operational data, improving the dashboard alone would have produced a better interface, but not better insights.
Knowledge Was Difficult to Scale
Another challenge came from the industry's dependence on farm technicians.
New farmers rarely managed a farming cycle independently. Instead, they relied heavily on technicians provided by shrimp feed companies to recommend stocking strategies, feeding schedules, disease prevention, water quality management, and daily activities.
This expertise existed almost entirely in people's experience rather than inside the product itself, making it difficult for farmers to learn, operate confidently, or maintain consistent practices without external support.
Every Farm Worked Differently
Planning was largely manual. Each technician followed their own methods when preparing a farming cycle, including activity schedules, stocking plans, feeding strategies, operational milestones, and data recording requirements.
Without a standardized planning process, farms executed the same farming cycle differently. Workers received inconsistent instructions, data quality varied between farms, and comparing performance across cycles became increasingly difficult.
We realized meaningful analytics could only exist if every farming cycle started from a structured operational plan.
Inconsistent Data Collection
Farmers recorded data inconsistently, limiting the value of farm insights.
Knowledge Relied on Technicians
New farmers depended on technicians because essential farming knowledge was difficult to access.
No Standardized Farming Plan
Without a structured farming plan, operations varied across farms and data became unreliable.
Research Summary
Instead of evaluating the dashboard independently, we stepped back and examined the entire farming workflow.
The research combined findings from my earlier design challenge, interviews with internal stakeholders, product walkthroughs, and continuous discussions with domain experts after joining the company. While the initial challenge helped establish personas, user journeys, and early assumptions, those findings were treated as references rather than final conclusions and were refined throughout the project.
One observation quickly became clear:
The dashboard represented only the final stage of a much larger operational system.
Understanding the Challenge
Although the project began as a dashboard redesign, the research quickly revealed that the problem extended far beyond visualization. The dashboard was only the final destination of a much larger operational workflow, and its quality depended entirely on the consistency of the data collected throughout the farming cycle.
To understand where the existing experience was breaking down, I revisited the previous UX research conducted before joining the company, including personas, user journeys, interviews, and usability findings. I summarized these insights into a single "How Might We" statement that became the foundation of the project.
How might we design a flexible, low-effort farm management experience that works for users with different roles, habits, and digital skills, while encouraging regular and meaningful data collection through clear guidance, automation, and relevant insights?
Rather than focusing on dashboards, this question shifted the project toward understanding how operational data is generated on real shrimp farms.
Understanding Farm Data
This analysis revealed two fundamental questions that guided the rest of the project.
Data Source - Where farm data comes from
To answer the first question, I worked closely with the CTO to analyze the platform's existing data model. Rather than treating each data point as an isolated field, I mapped every relationship between the data to understand where it originates, how it is generated, and how it contributes to downstream calculations and dashboards.
The analysis showed that farm data comes from three primary sources:
Pond Metadata – Static information such as pond area, location, species, and currency, much of which can be imported automatically from Deep Aqua and other connected systems.
User Input Data – Operational records manually entered by farm workers or farm owners, including feeding, shrimp weight, water quality, stocking, harvesting, and other daily farming activities.
Derived / Calculated Data – Metrics automatically generated by combining metadata and user inputs, such as stocking density, biomass, survival rate, mortality rate, FCR, and other operational KPIs.
Rather than asking users to manually calculate these values, the system continuously derives them as more operational data becomes available.
Data Break Down
To validate this model, I then traced the relationships between individual data points provided by the CTO. This helped identify which values were manually collected, which could be automated, and which were calculated from multiple inputs. Understanding these dependencies became essential because a single data point could influence multiple downstream metrics and dashboard insights.
For example, pond area imported from satellite imagery combines with stocking quantity entered by users to calculate stocking density, which later contributes to population estimates, survival rate, biomass, mortality, and production KPIs. This relationship exists throughout the entire farming cycle and became the foundation for designing both data collection and reporting.
Data Relationship Diagram
Data Frequency – How often data is generated
The second question focused on when farm data becomes available.
Not all information follows the same collection frequency. Operational records such as feeding, water quality monitoring, and shrimp health are recorded daily, while shrimp sampling, financial records, inventory updates, and harvesting occur weekly or only during specific farming phases. External sources such as satellite imagery and market prices follow their own update schedules and may occasionally be delayed due to technical limitations.
By analyzing the collection frequency of each data point, I was able to identify when users should be asked to provide information, when data could be updated automatically, and when values should simply be calculated from existing records. This prevented unnecessary manual input while ensuring that the dashboard remained accurate and meaningful.
Understanding both where data comes from and how frequently it is generated became the foundation for designing the Farming Plan, operational workflows, and ultimately the Digital Twin that powers the dashboard.
Breaking Down the Existing Platform
Understanding the data model explained how information was generated, but it didn't explain how the platform supported day-to-day farm operations.
To answer that, I reverse engineered the existing platform by analyzing each module through four questions.
What problem is this solving?
What information is required?
Where does that information come from?
Can any of this process be simplified or automated?
This investigation revealed six major operational areas within the platform. Although these capabilities already existed, they functioned as separate modules with limited connection between planning, execution, and monitoring.
Summary
The Summary dashboard evolved beyond a collection of charts into three connected views: Data Progress, Team Progress, and Farm Progress.
Together, they answered three operational questions.
Is the farm data complete?
Is the team completing the required work?
Is the farm progressing according to plan?
This analysis also introduced early concepts around collaboration, task ownership, milestones, and operational progress tracking.
Dashboard Summary
Operational
The Operational module became the largest area of investigation.
Working closely with shrimp farming specialists, I broke down the entire shrimp farming process into farming phases and the activities within each phase to understand not only what users recorded, but why those activities existed.
This research became the foundation for structuring activities, schedules, and planning workflows inside the Farming Plan, while ensuring they aligned naturally with the existing operational dashboard.
Dashboard Summary
Finance
Finance was more than historical reporting.
Production forecasts influenced revenue estimation, inventory usage affected operational costs, and market prices helped determine harvest timing.
This revealed a much stronger relationship between financial planning and day-to-day farm operations than the existing platform suggested.
Dashboard Summary
Risk Monitoring
Risk Monitoring shifted from documenting incidents to identifying early warning signs.
Water quality, operational observations, environmental conditions, and historical records all contributed to understanding potential risks before they became critical.
Dashboard Summary
Inventory
Inventory management extended beyond stock tracking.
Feed consumption, projected farming activities, safety stock, and reorder planning all became part of the operational workflow rather than standalone inventory tasks.
Dashboard Summary
Understanding Real Farming Operations
While analyzing the Operations module, I worked closely with shrimp farming specialists to understand how technicians actually manage a production cycle in the field.
Together, we broke down the complete shrimp farming process from stocking to harvest, documenting every operational activity, monitoring requirement, and management decision throughout the cycle. Rather than thinking in terms of isolated tasks, farmers naturally organize their work into distinct farming phases, each with different priorities, activities, and data collection requirements.
For example, the early larval stage focuses heavily on feeding schedules, water treatment, and survival management, while later phases gradually shift toward growth monitoring, routine farm operations, and harvest preparation.
Shrimp farming workflow showing farming phases and activities within each phase.
Breaking the farming process into phases became a critical reference for the rest of the project. It established the structure for planning activities, scheduling operational tasks, organizing monitoring requirements, and eventually designing the Farming Plan itself.
Equally important, this phased workflow aligned with how the existing Operations dashboard recorded farm activities, ensuring that future planning workflows could transition naturally into day-to-day farm operations without disrupting existing processes.
Key Insight
By combining the findings from the data model, the existing platform, and real farming operations, one pattern became increasingly clear.
Every dashboard visualization ultimately depended on operational activities performed throughout the farming cycle.
The dashboard was never the product. It was simply visualizing the current state of the farm.
This realization introduced the concept of the Digital Twin, where every planning decision, operational activity, inventory update, financial transaction, and monitoring record continuously contributes to a living digital representation of the physical farm.
Instead of designing better dashboards, the project shifted toward designing the operational system responsible for creating and maintaining that Digital Twin.
Shrimp farming workflow showing farming phases and activities within each phase.
Product Strategy
The Digital Twin fundamentally changed the product architecture. Instead of centering the experience around dashboards, I reorganized the platform around the complete farming lifecycle.
The experience was divided into three connected products.
Farming Plan, where technicians prepare farming strategies before production begins.
Farming Operation, where workers execute daily activities while continuously recording operational data.
Farm Dashboard, where managers monitor production through analytics, forecasts, and business insights generated by the Digital Twin.
Rather than existing as separate tools, each stage continuously feeds the next. Farming Plans become Farming Operations. Farming Operations continuously update the Digital Twin. The Digital Twin powers the Dashboard.
Functional Sitemap
Once the product direction was established, I translated the operational workflow into product capabilities.
Every planning responsibility identified during research became a functional module inside the Farming Plan. Instead of organizing the product around technical requirements, the structure reflected how technicians naturally prepare a farming cycle.
The initial sitemap included areas such as general information, stocking strategy, staffing, operational activities, inventory planning, financial planning, milestones, and key performance metrics.
Although this sitemap evolved throughout the project, it established the first complete picture of everything the product needed to support before any interface design began.
Farming Plan - Simplify Sitemap
Farming Plan - Detail Sitemap
Design foundation
With the product architecture established, the next challenge was translating a complex operational workflow into an interface that remained intuitive for users while supporting the scale and flexibility required by commercial shrimp farming.
Rather than moving directly into high-fidelity designs, I explored multiple layouts, interaction models, and workflows through low-fidelity wireframes. Every major decision was reviewed with product managers, engineers, and shrimp farming specialists to balance usability, scalability, and technical feasibility.
Building on an Existing Design System
Given the project's timeline, creating a design system from scratch was not a priority.
Instead, the interface was built using MUI Design System. Existing components provided consistency across the platform while allowing the team to focus on solving workflow and interaction challenges instead of rebuilding fundamental UI elements.
This approach accelerated implementation and ensured the new experience aligned with the rest of the product ecosystem.
MUI Design System
Rethinking the Product Layout
One unexpected challenge emerged as the Farming Plan began taking shape.
The existing product layout wasn't designed to support a workflow of this scale. Multiple layers of navigation, cards, side panels, and nested sections resulted in repeated horizontal and vertical layouts that competed for attention, making the interface feel visually cluttered and difficult to navigate.
Instead of solving this only for the Farming Plan, we stepped back and redesigned the overall product framework.
The new layout introduced a clearer hierarchy by separating navigation into two levels:
Vertical navigation for the platform's primary products and modules.
Horizontal navigation for the workflow within each product.
This structure reduced visual repetition, established a clearer information hierarchy, and created a reusable layout that could be adopted across Farming Plan, Farming Operation, editing workflows, and future products.
More importantly, reusing the same layout significantly reduced development effort by avoiding the need to build different navigation patterns for every feature.
Comparison between the original product layout and the redesigned application framework.
Designing the Farming Plan Framework
Using the functional sitemap and user flow as a foundation, I mapped every planning step into low-fidelity wireframes before exploring different interaction models.
Several approaches were evaluated, including long-form layouts, step-by-step workflows, and tab-based workspaces. Each concept was reviewed through multiple design critiques to understand its strengths, weaknesses, and long-term scalability.
Farming Plan Setup
Farming Plan Preview
Edit Farming Plan
After several iterations, we selected a tab-based workspace because it allowed users to move freely between planning sections without losing context. More importantly, the same interaction model could be reused across other workflows, including editing existing Farming Plans and the future Farming Operation module, reducing the need for separate layouts and minimizing development effort.
Farming Plan Latest Layout Version
Another important decision was not locking users into a sequential workflow.
Although the Farming Plan has a logical order, real planning is rarely completed by one person. Staffing, inventory, finance, and operational planning are often prepared by different teams at the same time.
Keeping every planning section independently accessible allowed multiple people to contribute simultaneously while maintaining a single shared plan.
Looking back, this also validated one of the project's biggest product decisions: shifting Shrimpl from a farm-centric platform to an organization-centric workspace. Instead of planning belonging to one farm manager, the Farming Plan became a collaborative workspace shared across the organization, reducing duplicated work and making planning significantly more flexible.
Simplifying Complex Planning Workflows
The most challenging parts of the product were Activities and Data Planning, as both needed to simplify highly complex operational workflows without overwhelming users.
Although both modules shared the same goal, they presented very different design challenges. The Activities module focused on organizing operational workflows throughout the farming cycle, while the Data Planning module focused on structuring the information collected from those activities.
Activities Module
The Activities module became one of the most iterative parts of the project. It needed to organize farming phases, recurring activities, staff assignments, schedules, and operational tasks within a single workspace while remaining intuitive for users with different levels of digital literacy.
I began with quick paper sketches to explore different ways of organizing the workflow before committing to any interface direction. These early concepts helped define how farming phases, activities, and schedules could be grouped while identifying potential usability issues early in the design process.
Early paper sketches exploring different activity layouts and interaction concepts.
After narrowing down several promising ideas, I conducted visual research across scheduling, project management, calendar, and timeline-based products. Rather than looking for visual inspiration alone, I analyzed how each product handled hierarchy, dense information, long-running tasks, and interaction patterns.
The research revealed different strengths for tables, calendars, Gantt charts, timelines, and hybrid layouts, providing valuable references before translating those ideas into the Farming Plan.
Visual research comparing scheduling, timeline, calendar, and project management interfaces.
Using those insights, I created multiple low-fidelity wireframes to evaluate how each approach would perform with actual farming scenarios. Each iteration refined the information hierarchy, interaction patterns, and overall readability through continuous discussions with product managers, engineers, and shrimp farming specialists.
The final timeline-based layout was selected because it best reflected how farming activities naturally progress throughout the production cycle while remaining flexible enough to support different farming strategies and future operational requirements.
Low-fidelity wireframes showing the evolution of the Activities module toward the final timeline layout.
Data Module
Unlike the Activities module, the challenge wasn't designing a new interaction pattern. The timeline and scheduling structure were already established. The real complexity came from organizing more than 120 operational data points into a system that farmers could actually understand.
One of the earliest concepts grouped data points by category using dedicated colors and icons. Each data group had its own visual identity, with individual data points inheriting different shades within the same group. While this made the structure easier to understand internally, design reviews revealed an important usability concern. Many shrimp farmers have some degree of color vision deficiency, and relying heavily on colors and icons made the interface more difficult to scan, especially when displayed across a dense timeline.
Color-coded data groups
Early concepts using color-coded data groups and categorized timelines.
After several rounds of exploration, we shifted the focus away from how the data was categorized and toward what users were actually trying to record.
Instead of asking users to schedule individual data points immediately, the workflow first guided them to select the type of information they wanted to collect. Scheduling and configuration became a second step, reducing the amount of information users needed to process at one time.
Although this introduced an additional step to the setup process, it significantly simplified the overall experience and made the workflow easier for farmers to understand.
Organizing Data Collection by Purpose
Configuring Data Collection Timeline
The Data Planning module went through numerous design reviews with product managers, engineers, and shrimp farming specialists. While the final solution wasn't considered perfect, it represented the best balance between usability, technical constraints, and delivery timelines.
Rather than delaying the entire Farming Plan, the team agreed on a solution that could be released alongside the rest of the product while leaving room for future refinement as more farming data and user feedback became available.
Both modules required continuous iteration with farming specialists and engineers before reaching a structure that felt intuitive while remaining technically feasible.
Balancing Product Logic and Technical Constraints
Many design decisions extended beyond interface design.
The Farming Plan connects staffing, inventory, finance, stocking strategies, and operational schedules into a single workflow, meaning changes in one module often affected several others. Financial projections depended on inventory costs and staffing plans, while operational activities influenced resource planning throughout the farming cycle.
The project also uncovered future requirements, such as supporting polyculture farming, where multiple shrimp species are managed within the same production cycle. While this reflected real farming practices, supporting different activities, monitoring requirements, and calculations for each species exceeded the scope of the first release.
Instead, the first version focused on a single-species workflow while establishing an architecture that could support future expansion without requiring a complete redesign.
Final Design
Following several rounds of iteration, the final solution was organized into two connected experiences. The Farming Plan Library enables users to discover and reuse farming knowledge shared across the platform, while the Farming Plan provides a structured workspace for creating and managing farming strategies before they are executed on a farm.
Together, these experiences transform fragmented operational knowledge into reusable planning assets while establishing a consistent foundation for downstream farming operations.
Farming Plan Overview
The Farming Plan Library serves as the entry point for planning. Instead of creating every farming plan from scratch, users can explore farming strategies contributed by other technicians and organizations, allowing them to learn from real operational practices before starting their own plan.
The library also encourages knowledge sharing across the platform. Successful farming strategies become reusable assets that can be duplicated, adapted, and continuously improved rather than remaining isolated within individual farms.
Farming Plan Library
Browsing and Discovering Plans
The Farming Plan Library is designed to help users quickly discover relevant farming plans through search, filtering, and categorization. Instead of overwhelming users with detailed configurations, each plan provides enough information to understand its purpose before exploring it further.
Plan Details
Beyond manual search, the library is also integrated with Deep Aqua, a global mapping platform that covers more than 80% of shrimp farming ponds worldwide. When users explore a farming area through Deep Aqua, the system automatically recommends farming plans based on the farm's location, farming region, and pond scale. This helps users discover operational strategies that are more relevant to their local farming conditions, reducing the effort required to find a suitable starting point.
Deep Aqua integrate with Farming Plan Library
Reviewing a Farming Plan
Once a suitable plan has been identified, users can review its complete configuration before applying it to their own farm. Each plan captures real farming practices, allowing users to understand how experienced farmers organize production timelines, stocking strategies, operational activities, resource planning, and key performance metrics.
Rather than serving as a static template, each farming plan becomes a reference that users can adopt directly or adapt to fit their own operational needs.
Creating a Farming Plan
For users who want to build their own operational strategy, the Farming Plan provides a structured planning workspace. Instead of collecting every configuration in a single interface, the planning process is divided into modules that reflect how technicians naturally prepare a farming cycle.
Each module captures a different aspect of the operation while remaining connected as part of a single farming strategy.
Farm Setup
Planning begins by defining the farming cycle itself. Users provide the basic information that identifies the plan, including its name, farming location, production duration, and general description. This information establishes the context for every decision made throughout the planning process.
Farm Setup
Ponds Planning
Once the plan has been created, users define the physical farming environment by registering the ponds included in the operation. Since every activity, stocking decision, and data collection task is associated with a pond, this becomes the structural foundation of the entire farming plan.
Ponds Planning
Stock & Harvest Planning
With the farming area established, users configure the production strategy for each pond. This includes stocking density, survival rate, expected harvest size, and projected biomass.
To support planning decisions, the system also provides recommended stocking density ranges based on different farming methods and farming species, helping users compare their strategy against common industry practices before finalizing the plan.
Stock & Harvest Planning
Staff Planning
Successful farming depends on clearly assigned responsibilities.
The Staff module allows users to define the workforce involved in the farming cycle before operational activities are created. By establishing team members first, later planning modules can directly assign responsibilities without repeatedly redefining personnel.
Staff Planning
Activities Planning
Activities transform a farming strategy into an executable operational plan.
During our research, we learned that shrimp farmers rarely manage an entire farming cycle as one continuous process. Instead, they naturally divide it into operational phases, each representing a different stage of shrimp growth with its own objectives and management practices. Although the terminology varies between farms and regions, organizing work into phases is a common approach used to simplify planning and daily operations.
For example, the early larval stage requires intensive management, including frequent feeding, water treatment, and close health monitoring to minimize mortality. As the shrimp mature, daily operations become more stable, shifting towards routine feeding and periodic health checks. Designing the activity timeline around these phases allows users to organize tasks according to real farming practices while providing a clear overview of the entire production cycle.
Each activity can then be assigned to specific ponds, staff members, and scheduled dates, creating an operational plan that can later be executed through the Farming Operation module.
Activities Planning - Adding new activities
Plan Details - No phases added
Plan Details - Phases added
Data Planning
Designing the Data Planning module was one of the most challenging parts of the project.
Unlike the other planning modules, this feature had to accommodate more than +120 existing data points that were already being used across the platform. Before redesigning the interface, we first studied how these data points were organized in the legacy system and how farmers actually used them during daily operations.
Our research revealed that the existing structure was primarily organized by technical data point names, making it difficult for users to understand what information should be collected throughout a farming cycle. Instead of preserving this system, we reorganized the data around operational goals that farmers naturally think about, such as Water Quality Monitoring, Health Monitoring, Growth Performance, Expense & Revenue Tracking, and Inventory Management.
This shift transformed the experience from browsing a long technical checklist into planning meaningful monitoring activities that align with real farming operations.
Data Planning - Grouping Data Point
Data Planning - Scheduling Data Point
Inventory Planning
Once operational activities and monitoring requirements have been established, the system generates a consolidated inventory plan containing the materials required throughout the farming cycle.
Instead of manually maintaining separate purchasing lists, users can review and adjust the expected quantities of feed, chemicals, additives, and other farming supplies before operations begin, improving resource preparation and reducing planning effort.
Inventory Planning
Financial Planning
The final planning step estimates the financial outcome of the farming cycle.
Based on the operational strategy, inventory requirements, and expected harvest, the Finance module calculates operational costs, projected revenue, and estimated profit. Bringing financial planning into the same workflow allows users to evaluate the economic impact of their strategy without relying on external spreadsheets.
Finance Planning
Preview & Publish
Before publishing, users can review the farming plan as a complete operational blueprint.
The preview consolidates the entire strategy—including farm information, activities, monitoring requirements, inventory, and financial projections—into a single view for validation. Once published, the farming plan becomes a reusable strategy that can be shared through the Farming Plan Library or applied directly to Farming Operation.
Preview & Publish
Retrospective
This project grew far beyond its original goal. What started as a dashboard redesign evolved into designing an end-to-end farm management ecosystem, connecting planning, operations, and analytics through a shared operational workflow.
The most valuable takeaway was learning to design from the system rather than the interface. By understanding how farmers work, how data flows, and how different teams collaborate, the solution became much more than a collection of screens.
While I'm proud of the overall product direction, there are still areas I would continue refining. The Activities and Data Planning modules can be further simplified, and future iterations should support more complex scenarios such as polyculture farming while improving accessibility for a wider range of users.
Think in systems
Strong products start with understanding workflows.
Design is a team effort
The best ideas came from cross-functional collaboration.
Progress over perfection
Great products evolve through continuous iteration.
