Three systems-thinking tools I keep using

The Ten Methodologies

1. Functional Analysis: Understanding the Real Job

Core Concept: Move beyond surface-level feature requests to understand the underlying purpose a product serves.

Framework:

• Primary functions: The core problem being solved
• Secondary functions: Supporting capabilities that enhance the primary function
• Auxiliary functions: Features that differentiate the experience

Project connection from my course notes:

In my TerraSync project (developed with Anurag), we initially thought users wanted "easy data export" from our geospatial system. Through functional analysis, we discovered:

• Primary function: Enable field teams to share location data with office staff who don't use our mapping interface
• Secondary function: Maintain spatial context when data moves between systems
• Auxiliary function: Create audit trails for data provenance

This led us to build a context-preserving export system rather than a simple CSV download.

Key Principle: The transformation from functional to experiential happens when we layer human needs onto functional requirements. A feature is better described by the job it does in someone's workflow than by its literal action.

Course Example: The course used Apple Pay to show how functional analysis can reframe "digitizing credit cards" as reducing checkout anxiety, building trust through biometric security, and making payment more predictable.

2. Process Diagramming: Mapping User Journeys as Systems

Core Concept: Visualize user experiences as workflows that reveal decision points, handoffs, wait states, and feedback loops.

Key Diagramming Approaches:

Service Blueprints separate experiences into layers:

• Physical evidence (what users see)
• User actions (what users do)
• Frontstage actions (visible system responses)
• Backstage actions (invisible system processes)
• Support processes (infrastructure enabling the experience)

Swimlane Diagrams show parallel processes across actors:

• User activities
• System processes
• Third-party integrations
• Support team interventions

Project connection from my course notes:

In my computer vision segmentation project (fine-tuning SAM for camouflaged object detection), I used process diagramming to understand the training pipeline:

• User actions (in the interface I sketched around the pipeline): Upload images, set parameters
• System processes: Pre-compute embeddings, run training epochs
• Backstage: Model checkpointing, validation metrics calculation
• Wait states: Where a user would need a progress indicator during the 7-epoch training

In the later project log, precomputing the 6,080 ViT-H embeddings took about six hours on the cluster, which is exactly the kind of wait state that deserves feedback. A progress indicator was a design response I considered; these notes do not include a user study measuring its effect.

Course Learning: Process diagrams excel at revealing gaps between user perception and system reality. Wait states and handoffs are where experiences break down.

3. Interaction Tables: Structuring Complexity

Core Concept: Systematically document how different parts of a system communicate, especially edge cases and error states.

Interaction Table Structure:

Value in Practice:

• Identifying gaps in system behavior
• Edge case documentation
• Cross-functional alignment (designers, engineers, QA share language)

Connection to my earlier work:

In my hospital brand work, which centered on the hospital's social media presence, interaction tables helped document:

• Audience interactions with the hospital's social media channels
• Edge cases: accessibility requirements and language preferences

The table was a way to organize touchpoints and their constraints.

Interaction Diagrams:

• State diagrams: How components transition between states (Idle → Loading → Loaded → Error)
• Sequence diagrams: Order of interactions across system components

Course Example: The course used Notion's collaborative editing as a case where detailed interaction diagrams help handle concurrent edits, conflict resolution, and real-time sync.

4. Distributed Product Systems: Designing for Ecosystems

Core Concept: Modern products exist across multiple devices, contexts, and stakeholders. Design for distribution, not isolation.

Key Principles:

1. State Consistency

• Data synchronizes consistently across devices
• Offline edits reconcile when reconnected
• Conflicts resolve transparently

2. Context Adaptation

• Mobile has its own context and needs, so it deserves more than a shrunk-down desktop layout
• Voice interactions follow different mental models than visual interfaces
• Each platform optimizes for its strengths

3. Graceful Degradation

• Core functionality remains available when connections fail
• Offline capabilities enable continued work
• Actions queue for later synchronization

4. Progressive Disclosure

• Show complexity only when needed
• Power users access advanced features
• New users see simplified, focused workflows

Project connection from my course notes:

For my DCmap project (interactive 3D Washington D.C. explorer), I mapped these adaptations:

• Desktop: Full 3D navigation with keyboard/mouse controls, detailed landmark info
• Mobile: Touch-optimized navigation, location-based discovery, simplified UI
• Offline: Pre-cached landmark data, queued bookmark actions
• Performance: Progressive loading of 3D assets based on viewport

Each adaptation serves the same core function (exploring D.C.) while fitting a different context. The shipped project is desktop-first, and offline caching, location-based discovery and viewport-based asset loading are not part of the current implementation.

Course Example: The course used Spotify as an example of a product that maintains playback state across devices, supports offline downloads, and adapts the complexity of its interface to each platform.

5. System Visualization: Making Complexity Comprehensible

Core Concept: Different stakeholders need different diagram types, so the aim is to choose the visualization that suits each conversation.

Diagram Types:

Architecture Diagrams (structural organization):

• Component diagrams: What pieces make up the system?
• Dependency diagrams: What relies on what?
• Integration maps: How do external services connect?

Behavior Diagrams (dynamic interactions):

• Flow diagrams: How does data or control flow?
• Timeline diagrams: What happens when, in what order?
• State machines: How do components change over time?

Conceptual Models (mental models):

• Information architecture: How is content organized?
• User mental models: How do users think about the system?
• Domain models: What concepts exist and how do they relate?

Choosing the Right Visualization:

• Stakeholder alignment: High-level flows with minimal technical detail
• Engineering handoff: Detailed sequence and architecture diagrams
• User research: Conceptual models matching user language
• Problem-solving: Whatever diagram type reveals the issue most clearly

Connection to my earlier work:

At SimplySoft, I used different diagrams for different audiences:

• Client presentations: High-level user journey flows
• Development team: Component architecture and API sequence diagrams
• QA team: State transition diagrams showing all possible UI states
• Documentation: Conceptual models using domain terminology

Course Example: The course described Airbnb's expansion into "Experiences" as a case where ecosystem diagrams showed that an architecture built for spaces would need substantial changes to support activities.

6. Experience-System Mapping: Bridging Technical and Emotional

Core Concept: Great experiences happen when technical systems and human emotions are consciously connected.

Mapping Approach:

Overlay technical layers with experiential layers:

User sees confirmation message
    ↓
[Emotional: Relief, trust building]
    ↑
System sends multi-channel notifications
    ↓
[Technical: API trigger → notification service]
    ↑
Data persisted to database
    ↓
[Backstage: Analytics event, audit log]

Key Questions:

• What should users see? Not every system process needs UI representation
• When do users need feedback? Real-time for critical actions, batched for background processes
• How do we communicate system state? Status indicators, progress bars, ambient cues

Project connection from my course notes:

The Special-SAM experiments ran as batch jobs and notebooks without a user-facing interface, so this is a sketch rather than a shipped product. For a training interface I sketched around that pipeline, experience-system mapping suggested how feedback could work:

• User would see: Training progress with epoch count and a loss curve
• Emotional response: Confidence that training is progressing, and a sense of whether it is converging
• System reality: A seven-epoch training record with loss calculated each batch (the later project log puts the augmented training set at 6,080 samples)
• Design decision: Show epoch-level progress prominently and keep batch-level loss in expandable detail

The aim was to give enough feedback to show the job was running without burying people in technical detail.

Course Example: The course used Uber's "driver is on the way" screen, where an animated car on the map turns periodic location updates into visible progress, as an example of connecting backend behavior to a user's confidence.

7. Network Effects and Feedback Loops

Core Concept: Network products gain value as more people use them. Design requires understanding positive and negative feedback loops.

Feedback Loop Types:

Positive (Virtuous) Loops:

• More users → More content → Better experience → More users
• More data → Better recommendations → Higher engagement → More data

Negative (Balancing) Loops:

• More users → Network congestion → Worse performance → Fewer users
• More content → Lower quality → Reduced trust → Less engagement

Design Process:

1. Identify loop components: What creates value? What attracts users? What sustains engagement? What causes degradation?
2. Map reinforcement patterns: Which loops strengthen? Which have diminishing returns? Where are tipping points?
3. Design interventions: How to accelerate positive loops? Dampen negative loops? Provide feedback about network participation?

Cold Start Problem:

Network products face chicken-and-egg: not valuable until users join, but users won't join until valuable.

Solutions:

• Segment the network: Dense pockets (geography, interest, affiliation)
• Standalone value: Benefits before network effects kick in
• Asymmetric design: Focus on supply side (creators, sellers) to ensure availability for demand

Project connection from my course notes:

Thinking about TerraSync's potential growth:

• Positive loop: More field teams → More location data → Better map coverage → Attracts more teams
• Negative loop: More data → Storage costs → Performance degradation → Reduced responsiveness
• Intervention: Implement data aggregation at scale, progressive loading strategies

Course Example: LinkedIn provided standalone value (online resume) while building toward network effects (job opportunities, connections). Every profile made search more valuable, attracting more profiles.

8. Functional Optimization: Improving What Already Exists

Core Concept: Systematic improvement of existing functionality to reveal innovation trends.

Optimization Process:

1. Baseline Measurement

• Current performance (speed, accuracy, satisfaction)
• Constraints (technical, cost, time)
• User priorities

2. Functional Decomposition

• Break product into discrete functions
• Measure each function's contribution to overall experience
• Identify bottlenecks and inefficiencies

3. Systematic Improvement

• Elimination: What can we remove without losing value?
• Combination: What can we merge to reduce complexity?
• Resequencing: What if we changed the order of operations?
• Simplification: What can we make easier?

Identifying Innovation Trends:

Optimization reveals patterns pointing toward innovation:

• Disappearing interfaces: Fewer steps → automation → ambient computing
• Increasing personalization: Better data → better models → contextual experiences
• Multimodal interaction: Beyond keyboard/touch → voice, gesture, spatial

Project connection from my course notes:

In my SAM fine-tuning project for camouflaged object detection:

• Baseline: 47.52% mIoU (base model)

• Decomposition: Image encoding (frozen), mask decoder (trainable), prompt processing

• Optimization:

  • Loss: Combined BCE and Dice (0.5 each) for pixel-level and region-level accuracy, where the earlier wood and carpet runs had used Dice only
  • Added: Multi-prompt training (point + bounding box)

• Result: 66.35% mIoU (+18.83 points)

These notes record what changed between the base model and the specialized one, but the runs changed several things at once, so they do not show which change produced the 18.83-point gain.

Course Example: The course traced Amazon's path from browsing to one-click ordering, Subscribe & Save, Alexa ordering and the Dash Button as a series of steps that reduced purchase friction. Amazon discontinued the Dash Button in 2019, which is a useful reminder that removing friction does not guarantee a product survives.

9. Stock and Flow Modeling: Understanding System Dynamics

Core Concept: Model how products behave over time using stocks (accumulated resources) and flows (rates of change).

Framework:

Stocks (what accumulates):

• User accounts
• Content in platform
• Features in backlog
• Technical debt
• User trust and satisfaction

Flows (rates of change):

• New user acquisition (inflow)
• User churn (outflow)
• Content creation rate
• Feature development velocity
• Bug introduction and resolution

Building Models:

1. Identify key stocks: What accumulates in your system?
2. Map flows: What increases/decreases each stock? What affects flow rates?
3. Identify feedback loops: How do stocks influence flows? Where are delays? What are balancing vs. reinforcing loops?

From Model to Simulation:

Simulate scenarios to predict outcomes:

• "What if we double acquisition but don't improve onboarding?" → Users grow, active users flat
• "What if we add features faster than resolving bugs?" → Technical debt explodes
• "What if we improve retention 5%?" → Compounding long-term user growth

Project connection from my course notes:

Thinking about my computer vision project training dynamics:

• Stock: Model accuracy (mIoU), training data quality, learned patterns
• Inflows: New training samples, data augmentation, multi-prompt variety
• Outflows: Overfitting, catastrophic forgetting
• Feedback loop: Better accuracy → confidence to train longer → risk of overfitting → need for validation

This analogy helped me think about training and evaluation. It did not establish that seven epochs was an optimal stopping point.

Course Example: The course described Medium as weighing content creation (a flow) and available quality content (a stock) against reader engagement, and used it to argue for building a stock of quality writing by inviting writers before opening publishing to everyone.

10. TRIZ: Functional Conflict Resolution

Core Concept: Product design is full of contradictions. TRIZ (Theory of Inventive Problem Solving) provides systematic principles for working through these conflicts.

Common Design Contradictions:

• More features vs. simplicity
• Fast performance vs. rich visuals
• Personalization vs. privacy
• Accessibility vs. cutting-edge technology

Core TRIZ Principles for Product Design:

1. Segmentation

• Divide system into independent parts
• Make sections modular
• Example: Basic vs. Advanced modes for novice vs. expert users

2. Extraction

• Extract conflicting property or functionality
• Remove problematic part
• Example: Move heavy processing to background threads, show progressive results

3. Parameter Changes

• Change state (solid → liquid → gas)
• Change temporal properties
• Example: Permanent records → Ephemeral (Stories format) for privacy

4. Asymmetry

• Replace symmetrical forms with asymmetrical
• Use different approaches for different cases
• Example: Design asymmetrically for mobile vs. desktop strengths, not forced consistency

5. Merging

• Combine identical or similar objects
• Combine operations in time/space
• Example: Merge multiple notifications into intelligent digests

6. Universality

• Make objects perform multiple functions
• Eliminate need for other parts
• Example: Universal tools (like Notion blocks) replace multiple specialized features

7. Nesting

• Place objects inside each other
• Example: Nest tools in contextual menus, overlays, progressive sheets

Systematic Application:

1. Define contradiction precisely (What improves? What worsens?)
2. Abstract the problem (remove domain-specific language)
3. Apply TRIZ principles (generate multiple solutions)
4. Adapt back to context (how does abstract solution apply?)

Project connection from my course notes:

In DCmap project, I faced contradictions:

Conflict: Rich 3D graphics vs. mobile performance

• TRIZ Principle: Segmentation + Parameter Changes
• Solution: A possible response is to reduce rendering cost by device capability while retaining essential information. This is a design option, not a verified description of DCmap's current implementation.

Conflict: Detailed landmark info vs. limited screen space

• TRIZ Principle: Nesting
• Solution: Nested information in expandable panels, progressive disclosure based on user interaction depth

Course Example: The course presented Tesla Autopilot as a conflict between driver alertness and automated convenience, and described possible responses as a parameter change (monitoring attention rather than hands on the wheel), segmentation (treating highway and city driving separately), and merging (combining steering assistance with attention warnings).