It’s Called a Mix for a Reason

As a musician turned audio engineer (turned power systems engineer), it can be tempting to think in individual tracks. You turn up the guitar, add some low-end to the kick, brighten up the vocals. But that mentality breaks down once you take the track out of solo. Every single change you make affects the mix as a whole. Boosting the low-end makes the track feel fuller, but you just buried the vocals. A bit of compression can tighten things up–or make it feel lifeless. Eventually you realize that you’re not adjusting the guitar, or the drums, or the vocals, but the entire mix itself.

Power systems work the same way. In transmission planning, you’re never simply ‘rebuilding a line’ or ‘adding a generator’; you’re altering the power flow for an entire region. Shifting generations or loads in one area will see flows redistribute everywhere. Adjusting the reactive support and voltage won’t just affect that bus, but numerous others downstream.

The issue for both worlds is thinking locally when the reality is always global.

You’re Hearing What You Modeled

In a mix, one of the fastest ways to improve a mix is to think subtractively. Instead of boosting everything you recorded, just clean what you didn’t. Remove the mud, cut unnecessary frequencies, and get rid of what isn’t serving the mix. Just get rid of the noise and pollution so that your instruments can do their job. A clean mix isn’t about adding more, it’s about making space.

We face this same problem in power system modeling, just with different terminology. Whether you have bad data, inconsistent assumptions, or stale models–it’s all just noise. And it shows up everywhere. Flows that don’t make sense, voltages that look off, and worst of all, study results that technically solve but don’t reflect the reality of your system. The real work isn’t in just running the study, it’s cleaning the inputs. You can have the latest and greatest node-breaker model on your side of the Mississippi but it won’t mean anything if your model is stale. Bad data leads to bad flows, bad studies, and bad operations–all under the guise of a clean, converged result. In music, bad monitors make your mix sound fine—until you play it somewhere else. Power system models are no different: you want to find out if a project doesn’t work in your study, not your RTO’s.

There’s No Perfect Answer–Only Tradeoffs

There is no one way to write or mix a song. An instrumental-heavy track will take the focus and leave less space for the vocals while a brighter mix might sound exciting but could become fatiguing. There’s no perfect mix where everything is both punchy and clear, warm yet loud. It’s a constant balance and prioritization of our own goals.

Power systems are no different. There will never be a perfect operating point in our electrical system. We’re forced into a balance between reliability, cost, losses, and constraints, and every improvement throws the stress elsewhere. We can relieve a constraint but inadvertently bind another zone, or improve voltage but also increase our losses. And in doing this, we can end up optimizing in circles; stepping one foot forward and the other back until we’re stuck doing the splits. We need to understand that our goal is not to build the perfect mix or system, it’s to get better at consciously choosing our tradeoffs.

In both worlds, we need to recognize which tradeoffs matter in our context, accept small imperfections in our low-impact areas, and focus our effort where it actually matters. In a mix, an instrument might not sound perfect in isolation but holds the track together in the grander song. In your electrical system, your losses might not be minimized, but the system is reliable and within limits. Either way, we’re not looking for the ultimate solution, we’re deciding which imperfections we’re willing to keep.

The Mixdown

This has been a fun analogy but really, I think it’s more than that. The ability to think in systems is a skill that transfers, and developing one domain only helps you get better in the others. It’s easy to think of skills like music as simply creative and the world of power systems as entirely analytical when in reality there’s such a large overlap between any two fields, creative or not. And by putting them together, we’re able to see connections and create new ideas in ways we might never have if we’d simply stayed in a single lane. Whether you’re a musician, engineer, chef, gardener, or one of the countless others, we’re all working to find a balance–to take a complex, interconnected system and shape it into something desirable. So what else can we find in our lives that aren’t actually worlds apart? I’ll definitely be keeping an eye out.

The post Mixing a Song Is a Lot Like Building a Power Flow Case appeared first on Simple Thread.

Utilities are rebuilding and expanding lines. Developers are siting new generation, storage, and large loads closer to existing infrastructure. Transportation, pipeline, telecommunications, and industrial assets often share or cross the same rights-of-way. In that environment, one question becomes increasingly important:

What happens to nearby conductive objects when they sit inside the electric and magnetic fields created by energized power lines?

That is the core question behind electromagnetic and electrostatic induction studies.

These studies are not just academic exercises. They help identify whether nearby fences, pipelines, vehicles, structures, rail systems, communication lines, or substation equipment could experience induced voltages or currents during normal operating conditions. In some cases, those induced effects can create safety concerns for field personnel, the public, livestock, or nearby infrastructure.

As the grid changes, understanding these effects is becoming an essential part of responsible power system planning and design.

Induction Is a Normal Operating Condition, Not Just a Fault Concern

When people think about electrical safety studies, they often think first about faults: touch potential, step potential, short-circuit events, and grounding performance under abnormal conditions.

Those studies are critical. But induction studies look at a different type of risk.

Electromagnetic and electrostatic induction can occur under steady-state, normal operating conditions. Energized conductors produce electric and magnetic fields that extend into the surrounding space. When nearby conductive objects are exposed to those fields, voltages and currents can be induced depending on the object’s geometry, grounding condition, material, and proximity to the source.

That distinction matters.

Induced Voltage and Current Report; A Review of Public Hazards Associated with High-Voltage Transmission Lines. Oregon Department of Energy — Feb. 2013

A fence, pipeline, vehicle, or structural component does not need to be part of a fault event to become energized. It may experience induced voltage simply because it is located near an operating transmission line or other energized conductor.

The magnitude may be lower than a fault-related hazard, but the exposure can be persistent. That is what makes induction studies important for safety, design, and mitigation planning.

Two Different Mechanisms: Magnetic and Electric Field Coupling

Induction studies generally consider two related but distinct mechanisms.

The first is electromagnetic induction, which is driven by magnetic fields. When current flows through an overhead conductor, it creates a magnetic field around the conductor. If that magnetic field intersects a nearby metallic object, it can induce a voltage along the object. If the object is grounded, current can flow through it.

A practical example is a grounded fence running near a transmission line. Depending on the line current, fence length, grounding arrangement, and separation distance, the fence may carry induced current that could create a shock hazard when touched.

The second is electrostatic induction, which is driven by electric fields. Electric fields are created by voltage differences between energized conductors and nearby objects. Conductive objects that are isolated from ground, such as certain vehicles, equipment, or metallic structures, can experience induced voltage through capacitive coupling.

If a person touches that isolated object, a discharge current may flow through the body. This can be perceptible, uncomfortable, or hazardous depending on the conditions.

Both mechanisms are important, and both need to be modeled carefully.

Why These Studies Are Becoming More Important

The need for induction analysis is growing because the grid is becoming more physically and electrically complex.

More transmission upgrades are being planned to support load growth, renewable integration, data center development, electrification, and broader reliability needs. At the same time, existing corridors are often being reused or expanded rather than replaced with entirely new rights-of-way.

That creates more opportunities for close proximity between energized conductors and other conductive infrastructure.

For utilities and energy organizations, this raises practical questions:

• Are nearby metallic objects exposed to unacceptable induced voltages or currents?
• Are electric and magnetic field levels within applicable exposure limits?
• Could induced voltages accelerate corrosion on nearby infrastructure?
• Could communication systems experience interference?
• Are grounding, bonding, shielding, or procedural controls needed?
• Do field crews need specific work practices or personal protective equipment?

These are not questions that can be answered confidently with rough assumptions alone. The geometry, grounding, soil characteristics, conductor loading, and physical layout all matter.

That is why detailed modeling is so important.

What Good Modeling Has to Capture

A defensible induction study requires more than a simplified representation of a line and a nearby object.

The model needs to reflect the physical system with enough detail to produce meaningful results. That includes conductor type, diameter, resistance, spacing, circuit configuration, clearances, sag, shield wire grounding, phase energization, maximum loading conditions, soil resistivity, and nearby conductive objects.

It also requires careful attention to the geometry of the system. Conductive objects may be above ground, buried, isolated, grounded at one end, grounded at multiple points, or connected in complex ways. Small modeling assumptions can change the results.

For electromagnetic and electrostatic induction studies, tools such as SES/HIFREQ within CDEGS are commonly used because they allow engineers to build detailed three-dimensional models and solve the field interactions directly. That level of modeling helps account for effects such as multi-layer ground, soil return paths, leakage, and complex coupling between energized conductors and nearby objects.

This matters because induction problems are inherently spatial. The distance between objects, their orientation, their length, and their grounding configuration all affect the final result.

Standards and Limits Provide the Safety Framework

Engineering judgment is important, but induction studies also need to be tied to recognized standards and guidance.

IEEE C95.6 provides exposure limits for electric and magnetic fields in the 0–3 kHz range, including limits at power frequency. These limits help define acceptable exposure for the public and for controlled environments where trained personnel, work practices, and PPE may apply.

Additional industry guidance, including EPRI references, is often used when evaluating discharge current from isolated objects such as vehicles. For example, guidance commonly considers whether discharge current through a person touching a large isolated object remains within acceptable limits.
The goal is not just to calculate field values. The goal is to determine whether the system is safe, whether exposure is acceptable, and whether mitigation is needed.

Mitigation Is Part of the Study, Not an Afterthought

A useful induction study should not stop at identifying a problem.

If induced voltages, currents, or field levels exceed acceptable thresholds, the next step is to evaluate practical mitigation options. These may include grounding, bonding, shielding, changes to physical layout, revised work practices, or procedural controls for field crews.

The right mitigation depends on the object, the source of coupling, the operating conditions, and the site constraints. In some cases, a grounding change may be enough. In others, the solution may require a more detailed evaluation of object geometry, clearances, or construction practices.

This is where modeling becomes especially valuable. Engineers can compare scenarios, test sensitivities, and evaluate whether a proposed mitigation approach actually reduces risk before changes are made in the field.

The Bigger Picture: Better Models Lead to Better Decisions

Power system studies are becoming more demanding across the industry.

Planning teams are being asked to evaluate more scenarios, incorporate more uncertainty, and make decisions faster. At the same time, the physical grid is becoming more interconnected with transportation, communications, industrial, and energy infrastructure.

Induction studies are a good example of why detailed modeling still matters.

They require a strong understanding of power systems, electromagnetic field behavior, engineering standards, and practical field conditions. They also benefit from better workflows, better data handling, and repeatable study methods.

As the grid continues to evolve, these studies will play an important role in helping utilities and developers understand risk, protect people, and make defensible engineering decisions.

Need Support With Power System Modeling?

Simple Thread is expanding our power systems modeling services to help utilities, developers, and energy organizations study complex grid behavior with more clarity and confidence.

Our team supports detailed modeling and analysis across transmission and distribution systems, including electromagnetic and electrostatic induction studies, transients analysis, interconnection support, hosting capacity, and other advanced power system studies.

If your team is trying to evaluate a complex study, improve an existing workflow, or turn manual study processes into something more repeatable and scalable, we’d be happy to talk.

Get in touch with Simple Thread to learn how our power systems modeling team can support your next study.

The post Why Induction Studies Matter More as the Grid Gets More Crowded appeared first on Simple Thread.

Since 2016, grid disturbances have triggered more than 15,000 MW of unexpected generation loss from inverter-based resources. These weren’t equipment failures or extreme weather events. They were generators that were online, connected, and behaving exactly as their software told them to, on a grid whose planning models had no idea.

October 1, 2026 is when that starts to change.

When Physics Stopped Being Enough

For most of the grid’s history, generation reliability was a physics problem. Synchronous generators, spinning turbines locked to the electromagnetic frequency of the interconnection, respond to disturbances the way a spinning top responds to a push. They resist. They stay connected. The response is inherent, predictable, and doesn’t require anyone to configure it correctly.

Inverter-based resources don’t work that way. They respond to grid conditions through software. The inverter reads the voltage and frequency at its terminals, runs those values through control algorithms, and decides in milliseconds whether to stay connected, ramp down, or trip offline. That decision is programmable. And it’s been programmed, across thousands of facilities over the past decade, primarily to protect the equipment.

“An inverter configured to protect itself will trip offline during a disturbance. A grid that built its stability models around generators that stay connected doesn’t know the difference until the fault happens.”

In June 2022, a routine fault on a 345 kV transmission line in West Texas triggered an unexpected loss of approximately 1,711 MW of solar generation across the ERCOT system. Normal fault. Normal clearing time. ERCOT frequency dropped to 59.7 Hz. The solar facilities that tripped weren’t malfunctioning. Their inverters saw the fault, calculated that staying connected posed a risk to the equipment, and disconnected. Exactly as programmed. Nothing in the interconnection study had predicted it because nothing in the interconnection study had accurately modeled what those inverters would actually do.

That event was one data point in a much larger pattern. Since 2016, NERC has documented major disturbances totaling more than 15,000 MW of unexpected IBR losses, 10,000 MW of which occurred in just the four years between 2020 and 2024. In every case, the behavior that caused the loss wasn’t captured in the planning models. The models said the generators would stay connected. The generators didn’t.

Why the Models Are Wrong

The gap between modeled behavior and actual behavior isn’t primarily a design problem. It’s a data management problem.

IBR facilities are modeled at interconnection, when the inverter manufacturer provides a set of parameters that get baked into the planning studies. Those parameters reflect the equipment as configured on the day of interconnection. What they don’t reflect is every firmware update, protection setting adjustment, or plant controller reconfiguration that happens afterward. And there have been many. Inverter manufacturers push updates. Operators adjust settings to optimize performance or extend equipment life. Plant controllers get reconfigured as operating conditions change. None of it automatically propagates to the transmission planner’s model.

The result is a fleet of generators whose actual behavior under fault conditions is systematically different from what the grid’s planning models assume. NERC’s Level 3 Alert, issued in May 2025, was direct about what it found: previous technical recommendations had been largely unimplemented by generator owners, and data submission rates remained unacceptably low. Many entities couldn’t provide basic technical information about their own equipment. Does this sound familiar to anyone?

“The models were built at interconnection and never updated. The inverters were updated constantly. After a decade of that divergence, what the grid thinks it’s running and what it’s actually running are not the same thing.“

What October 1 Requires

Three standards close that gap, on a compliance schedule that is already running.

PRC-028-1 requires IBR facilities to install disturbance monitoring equipment capable of recording voltage, frequency, and real and reactive power during grid events, with UTC time synchronization and mandatory data submission to NERC within 90 days of qualifying events. This is the foundation. Without it, the operational compliance requirements of the other two standards can’t be demonstrated.

PRC-029-1 establishes mandatory ride-through requirements. IBRs must remain connected and continue delivering real and reactive power through defined voltage and frequency disturbance profiles. The standard distinguishes between design compliance, verifying that inverter settings and protection schemes are configured correctly, and operational compliance, demonstrating through actual disturbance data that the facility performs as designed. Design compliance is required by October 1. Operational compliance follows once PRC-028 monitoring is installed and generating records.

PRC-030-1 governs what happens after a disturbance. When a facility experiences an unexpected loss of 20 MW or more, or 10 percent of gross nameplate capacity within four seconds, the generator owner must detect it, analyze the event and identify root causes within 90 days, and develop a corrective action plan within 60 days of completing the analysis. This is continuous, ongoing compliance. There’s no one-time certification. Every qualifying event opens a new clock.

The dependency chain matters. Design compliance under PRC-029 requires reviewing and potentially updating inverter settings and protection schemes, which often requires an outage window to implement. Scheduling outage windows in summer means coordinating with transmission operators who are managing the highest load days of the year. Many generator owners haven’t started that process. Summer is six weeks away.

The Data Infrastructure Behind Compliance

To detect a qualifying event, a facility needs monitoring equipment generating timestamped, synchronized records. To analyze the event within 90 days, the generator owner needs validated models that accurately reflect current inverter settings, not the settings from the original interconnection study. To develop a defensible corrective action plan, they need to understand whether the issue is hardware, firmware, settings, or something in the plant controller that has drifted from the original design.

Most of that data doesn’t exist in a clean, queryable form. Event records live in historian systems with inconsistent tagging. Inverter settings documentation, if it exists at all, lives in commissioning binders that haven’t been touched since the facility energized. The firmware version running on the inverters may or may not match what was submitted to the modeling team. We’ve seen this pattern before. The shadow tool problem isn’t limited to interconnection queues and study workflows. It runs all the way through the operating fleet.

The generator owners who will absorb PRC-028, PRC-029, and PRC-030 without a compliance crisis are the ones who already have continuous disturbance monitoring, model validation processes that track inverter changes, and clear documentation of what their fleet is actually doing under fault conditions. The ones who will struggle are the ones trying to reconstruct that picture from scratch with October on the horizon.

How many generator owners reading this have a clear, current picture of what their IBR fleet’s actual inverter settings are versus what’s sitting in their planning models? Our guess is that number is smaller than anyone is comfortable admitting. If you’re working through this, we’d like to hear what you’re running into. Drop it in the comments.

Thanks for reading. Subscribe to The Current and follow Simple Thread on LinkedIn for fresh analysis, project highlights, and event updates, delivered straight from the front lines of utility software.

The post The Grid Still Can’t Predict How Its Own Generators Behave appeared first on Simple Thread.

As a personal case study, I wanted to tie in an experience I had over Christmas. My sister had received a number of smart home devices as presents, including a few sets of 3-way light switches intended for the stairs. When installing these, we took the logical route: we initially installed them by keeping track of the connected wires on the old switches, hooking the new smart switches up to those exact same wires. We expected it to just work. Nothing fancy, nothing complicated.

Now, a little background on 3-way switches. Omitting neutral and ground for the sake of simplicity, a 3-way switch essentially has a “common” terminal and two “traveler” terminals. All the switch does is choose which traveler is connected to the common. In order to light our lightbulb, we need to close our circuit, connecting the line on one end of our 3-way switches to the line on the other side.

The way they work is very similar to railroad switches. Let’s start with our circuit, a simple oval loop of train track. In our analogy, let’s make our light bulb a train station, and our power source a second train station. The light bulb station removes cargo from the train, and the power source station adds a new shipment. Let’s put these on one side of our oval train track.

On the other side, we add our switches. We take the rail that leads from the power source station and add a switch that acts as a fork in the rail: it decides whether the train will travel down a parallel red rail, or a black rail. At the end of these parallel rails, we place our second switch, which decides whether to connect the red rail or the black rail back into the single track leading to the light bulb.

Before the power source station will send a train with cargo toward the light bulb station, it makes certain there is a clear path to get there. This means that if the first switch sends it onto the red rail, and the second switch accepts the red rail, it sends the train. If they both use the black rail, it sends the train. But if the first switch sends it on the red rail, and the second switch accepts the black, the train would derail, and so the power source station refuses to send the train. Regardless of what is selected by switch one (red or black), switch two can always affect whether the train will be accepted back or not. This is why flipping either switch on a 3-way circuit can toggle the light on or off, entirely independent of the other switch.

That is how 3-way switches are intended to work, and how anyone familiar with them might expect them to be connected. But when we went to test the light, we noticed some odd behavior. If we toggled one switch to turn the light off, the other switch could not turn the light back on. This worked both ways.

The reason this behavior might go unnoticed for years is that if one old, “dumb” switch is left in the position that allows the light on, and just goes unused, the other switch behaves exactly like a normal light switch. No one is the wiser. With a smart switch, though, it kind of just chooses one to toggle, expecting standard behavior. Instead, it behaved rather erratically and would sometimes alert about a disconnected switch. In any case, we sought to identify the source of the issue.

The behavior turned out to be the result of some confused wiring on the top switch. Rather than delve into the actual wiring, let’s return to our railroad example. This time, imagine the connections of the black rail and the source feed rails are reversed. The rail from our power source bypasses the first switch entirely and connects directly to the second switch, right where the black rail used to go, merging with the red rail. Now, the black rail connects to the output of the second switch, acting as a return track that brings the train backward to the input of the first switch. At that first switch, the track splits: one path leads to the rail for the light, but the other path connects to the opposite end of the red rail. Because of this, the red rail isn’t a parallel track anymore, it forms an isolated loop between the two switches. By expecting the standard parallel configuration, we were largely blind to the actual mess of what was actually in the wall.

Once we figured it out, we started noticing crossed wires in other places. Later, we found a 3-way switch being used in place of a normal switch for a simple porch light. At my older brother’s house, he encountered a setup where both switches had to be flipped “on” for the light to come on because one traveler wire was simply never connected.

In the realm of home wiring, these mismatched expectations usually stem from simple misuse. But in the professional world, this same disconnect happens frequently, sometimes because of errors, but often because of differing priorities and objectives.

In our efforts to integrate GIS and network models for the power grid, we see how different data sources have different objectives with their data. GIS data from the HIFLD (Homeland Infrastructure Foundation-Level Data) focuses heavily on how lines connect different substations. Open source and community-contributed maps, on the other hand, may focus more on where there is infrastructure (where the power lines and substations physically sit), but don’t have a particular focus on representing how it is connected. As such, some features may be grouped together based more on location than the actual relational properties of the infrastructure.

In tasks like these, it is important to recognize that the expectation of how something should be used, represented, or configured, may not line up with how someone else expected it to be used, represented, or configured. In our light switch case, that happens to be because of misuse, but in real-world cases, it can often come down to a difference in priorities or perspectives that lead to multiple valid interpretations of an objective that fail to match up. Ultimately, whether you are wiring a three-way switch or modeling a power grid, the most important tool you have is the ability to step back, let go of the pattern you expected to see, and evaluate the reality of what is actually there.

The post Crossed Wires: When Expectations Obscure Reality appeared first on Simple Thread.

Two days later, you’re staring at your screen, wondering why you didn’t just become a mechanic like your family suggested. Just me?

The trap was set long before you joined the project. The original designers and developers are gone, off working at different companies. If you’re lucky, there are a few others around who can offer some anecdotal mythology about how things came to be.

So now what?

We all approach this situation differently. Here’s how I’ve learned to navigate it.

Start with “Why?”

The first question I ask is: Why did they do it this way?

If I can answer that, I can usually solve most of the problems I encounter. Instead of focusing on how I would have built it, I try to accept that the code exists as it does because, at the time, it worked given the constraints, resources, and requirements.

So what were those constraints? What pressures shaped these decisions?

And why does this always seem to happen on a Friday afternoon?

Using Tech Debt as Clues

Codebases aren’t sterile—they accumulate debris over time. And like an archaeological dig, that debris can tell a story.

Some useful questions to ask:

• Why hasn’t this code been refactored?
• Why are we using outdated libraries or frameworks?
• Why weren’t variable or method names updated as their purpose evolved?
• Are the comments still accurate?

Technical debt exists for many reasons—and not all of them are bad. Understanding why that debt was accepted helps frame everything else.

Was it:

• A time or budget constraint?
• A technical limitation?
• A skill gap?
• Or simply not considered debt at the time?

Answering those questions often explains why you’re currently daydreaming about playing video games instead of actually playing them.

Analyzing the Time Period

Context matters.

Like an archaeologist, you can’t just examine the artifacts—you need to understand the era they came from. For maintainers, that means digging into the commit history, old tickets, past designs, and even git blame (oh… it’s them again).

Consider the following:

• What did the code look like when that comment was written?
• What requirement changes drove later modifications?
• How often has this requirement changed?

Our industry moves fast. Libraries and frameworks come and go. Some solutions may not have existed when this code was written; others may no longer exist today.

These factors matter when you’re trying to understand why a particular approach was taken.

More importantly, this process often reveals the concerns previous developers were trying to address—and those concerns are what you need to carry forward.

Understanding the Person

Spend enough time in a codebase and you start to recognize individual developers by their style—their naming conventions, structure, even their spacing.

Understanding who wrote the code and where they were in their career can add valuable context.

Was this a junior developer solving the problem the best way they knew how? Or a senior developer balancing trade-offs between performance, deadlines, and maintainability?

I try to approach this with empathy. Assume good intentions from those who came before you.

That doesn’t mean every decision was the right one. Sometimes, a genuinely bad call was made and now it’s yours to fix.

Putting It All Together

So how does this help?

For one, it stops the doom spiral. Instead of reacting emotionally, you start investigating methodically.

With better context, you can make better decisions:

• Maybe it’s time to pay down some technical debt.
• Maybe it’s time to modernize libraries or frameworks.
• Or maybe it’s best to leave things alone—for now.

Either way, you’re no longer operating on instinct or frustration. You’re making informed decisions.

The post Learning to love other people’s code. appeared first on Simple Thread.

As a joint initiative between the Department of Energy (DOE) and the Electric Power Research Institute (EPRI), NASPI 2026 showcased vital solutions for grid modernization. Featuring a distinguished keynote address by Craig Creamean, Vice President of Transmission Operations at Exelon Corporation, and many technical presentations, the event provided a comprehensive look at the future of power system dynamics, grid monitoring, and data analytics.

Here is a deep dive into the key themes, tools, methodologies, and expert presentations from NASPI 2026.

1. The Impact of Data Centers and Inverter-Based Resources (IBRs)

A major focal point across multiple sessions was the dramatic shift in grid dynamics driven by the rapid integration of IBRs and the massive power demands of data centers.

• Data Center Dynamics: AI training workloads induce oscillations across broad frequency ranges which pose reliability risks. Kaustav Chatterjee from PNNL presented a critical technical report on “Measurement Systems for Monitoring Data Center Oscillations” where PMU limitations with high frequencies were discussed.
• IBR Performance Response and Analytics Monitoring: Bikal Pudasaini discussed dynamic performance analysis of an inverter-based PV plant and the challenges inverter settings posed on expected behavior. Priya Mana from PNNL shared updates from the white paper expected to be published next month.

2. Success Stories in Real-Time Operations

With grid complexities increasing, the need for synchronized measurements and actionable advanced analytics is paramount. Several utility success stories highlighted how the industry is already deploying these monitoring solutions.

• Islanding Support in Brazil: ONS presented their use of OpenWAMS and ~1,000 PMUs to manage islanding resynchronization. Because islands can drift faster than SCADA refresh cycles, PMU data provides the granular measurements necessary to safely reconnect islands.
• Cloud-Based Oscillation Monitoring: Xiaochuan Luo from ISO-NE and Yang Chen from PJM demonstrated ESAMS (Eastern Interconnection Situational Awareness and Monitoring System), a tool that analyzes streamed PMU data to detect wide-area oscillations, identify source of oscillation and automatically deliver notifications to reliability coordinators.
• Model Calibration: Fernando Fachini of Dominion Energy shared a framework for generator unit model parameter calibration using synchrophasor data. By using the Morris Algorithm for sensitivity analysis and Bayesian Optimization for tuning, they ensure models accurately reflect field behavior.

3. Next-Generation Tools

Several software platforms aimed at translating complex synchrophasor data into actionable insights for operators.

• Force Oscillation Location: Lin Zhu from EPRI presented its Forced Oscillation Localization Tool (FOLT), which aims to estimate source locations and source types for wide-band frequency oscillations ranging from less than 0.1Hz up to 15Hz.
• OPTIMA Initiative:  Matthew Rhodes from SRP discussed the DOE initiative, which is developing tools for real-time health risk assessments, anomaly detection, and grid strength monitoring in IBR-dominated grids. A collaborative effort with ASU, PNNL, Denovo Energy Solutions, GE Vernova to develop a wide range of tools
  • Grid Operator Analytics and Assessment Tools for Inverter-Based Resources Dominated Grid (GOAAT-IBR): Interactive dashboard visualizing system health in real time: grid inertia, IBR related sub-sync oscillations, and grid strength. Disturbance event correlation and curated datasets for post event analysis
  • Dynamic Assessment of System Health for Inverter-based Resource (IBR)- dominant Power Systems (DASH-IBR)
  • Wave Apps Platform: Wide area monitoring based on point on wave (POW) data containing a wide range of analytical tools: Oscillation correlation Analysis, Oscillation Source Localization, Nuisance Trip Detection, Grid Strength Monitoring

• V²Cal Tool: Pavel Etingov from PNNL presented the “Verify & Validate + Calibrate Tool for Automated Model Parameters Tuning” during the Engineering Analysis Task Team meeting. A tool for automated model validation and parameter tuning to help utilities meet NERC MOD-026-02.

4. Breaking Data Silos: The Call for Sharing

Emmanuel Oleka from Dominion Energy delivered a powerful argument for cross-boundary data sharing. While many utilities have invested in PMUs, the data often remains siloed due to cybersecurity (NERC CIP) and institutional concerns.

• The Risk of Silos: Without data sharing across tie-lines, operators face delayed recognition of grid-wide problems and misdiagnosis of events.
• A Practical Playbook: Oleka called for NASPI to develop a practical “playbook” for neighbor-to-neighbor sharing, potentially using ISOs as data brokers to standardize governance and technical procedures.
• Data as Infrastructure: Eric Andersen of PNNL echoed this, stressing that utilities must view data as critical operational infrastructure and address the risks of not sharing, such as atrophied skillsets and missed technological advances.

Conclusion and Industry Support

At the vendor show, we were thrilled to share the latest on Aion Pulse—the evolution of the Generator Scorecard tool licensed from PNNL. The feedback from industry peers was instrumental in shaping our roadmap.

NASPI 2026 proved that while the grid is facing unprecedented volatility from AI data centers and renewable energy integration, the analytical tools required to maintain stability are rapidly evolving. Whether it is moving from PMUs to continuous POW analytics, automating model validation and parameter tuning, or fighting for better utility-to-utility data sharing, the industry is taking decisive steps to secure the grid of the future.

The post What We Learned at NASPI appeared first on Simple Thread.

“Coming together is a beginning;
keeping together is progress;
working together is success.”

—Henry Ford
Image source: The School of Athens by Raphael (1511)

Intro

Last year, I wrote a blog post called, Speaking in CIM: The 26 Year Old Language of the Power Grid.

That post was mostly an overview, with a bit of history mixed in. If you’ve found yourself here and have never heard of the CIM, you should probably go back and read that first.

Anyway, I had a lot of fun last year researching and writing that post. And after it was published, I was pleasantly surprised by the feedback I received. I have had many great conversations with bright individuals thanks to that post.

One thing led to another, and in the Fall of 2025 I actually had the privilege and the honor of attending an in-person conference hosted by the CIM Users Group.

The CIM Users Group (a sub-group under the UCA International Users Group organization) hosts in-person events throughout the year, and I was lucky enough to find this Fall meeting happening at Siemens’ office in Wendell, NC, just 3 hours away from my hometown in Richmond, VA.

The conference was full of wonderful, like-minded individuals who were passionate about open-source standards for the electric utility industry.

After the CIM User Group meeting had come to pass, I decided that one of the best things I could do for the Common Information Model was to continue to write about it.

So I’m going to continue this series of CIM blog posts by diving into different sub-topics.

This post will focus on the people and organizations who write, build, and maintain the CIM.

UCAIug and the CIM Users Group

The first organization that you must know when it comes to any and all things CIM (Common Information Model) is one that I’ve already mentioned in the intro: the CIM Users Group.

The CIM Users Group, often abbreviated as CIMug, can be thought of as the core maintainer and stewards of the CIM standards.

I’ll also call out that “CIM standards” is sort of a squishy phrase. Sometimes when someone says “CIM” they’re referring to one, particular standard, and other times, they’re referring to a group of many standards. And then other times they’re referring to a very particular UML data model, which is actually an artifact that is used to generate downstream standards (more on that later).

You’ll probably find me switching back and forth, but I’ll try to be as clear as possible. When I say “CIM”, I’m probably referring this set of standards that (as of March 25, 2026) CIMug has listed on their about page:

IEC 61970 – For power system modeling and energy utility data exchange including EMS, topology, wires, SCADA, etc.

IEC 61968 – For power system modeling related to DMS, assets, work, GIS, metering and application messaging.

IEC 62325 – Modeling for energy markets with support for both North American and European markets (others under consideration).

Companion Standards – The CIM standards include a variety of extensions supporting many use cases including system planning, dynamic simulation, and smart grid messaging to premises systems

Ok, now back to CIMug.

CIMug is a sub-group of the UCA International Users Group (often abbreviated as UCAIug). UCAIug, a not-for-profit-corporation, has two other user groups that are not at all related to the CIM standards—the 61850 Users Group and the OpenFMB Users Group.

CIMug itself is made up of employees of UCAIug, as well as its members, which pay yearly dues.

What does CIMug do?

Earlier, I said that CIMug can be thought of as the core maintainer and steward of the CIM standards.

One important way that they steward the CIM standard is through education.

One very practical way that we can see this stewardship in action is in the CIM User Group meetings.

In most (or maybe all?) of the CIM User Group meetings, a significant portion of the scheduled content is instructional. For example, in the 3-day conference I attended, the entire first day was set aside for what they call “CIM University”. This is a full, 9 a.m. to 5 p.m. day of CIM knowledge, straight to the brain. People come to these meetings to learn about CIM from all over the world. Engineers, executives, leadership, management, product owners, from ISOs, RTOs, co-ops, small businesses, and big firms.

Alongside education, another very important responsibility of CIMug is developing, maintaining, and all of the other work that goes into “the UML”.

Now, I’m afraid I’m going to have to make another technical aside and explain what “the UML” means and how that relates to “CIM standards”.

But to explain what “the UML” means, we’re going to have to look at our next organization.

What is the IEC?

This section is going to be a bit dense, but please bear with me. I promise it’s important.

The International Electrotechnical Commission (IEC) is one of the three, big international standards bodies.

The big three being:

1. IEC – electrotechnical standards
2. ITU – telecommunications and radio standards
3. ISO – almost everything else (quality, materials, processes, management systems, etc.)

When I was initially learning about the CIM, the most confusing thing to me was this specific relationship between the IEC and CIMug.

On CIMug’s about page, they reference IEC TC 57 in this blurb—

The CIM Users Group is focused on helping its members obtain the benefits of adapting IEC TC 57 modeling standards for all utility operations on a global basis…

TC, here, stands for Technical Committee. So, similar to how CIMug is a subgroup of UCAIug, IEC TC 57 is a group within the massive organization that is the IEC. This technical committee is specifically responsible for the published standards that we often think of as “the Common Information Model”.

If you go to the IEC TC 57’s website, they have this as a marketing blurb:

We develop and maintain International Standards for power systems control equipment and systems including EMS (Energy Management Systems), SCADA (Supervisory Control And Data Acquisition), distribution automation, teleprotection, and associated information exchange for real-time and non-real-time information, used in the planning, operation and maintenance of power systems.

Now let’s unpack the somewhat codependent relationship of CIMug to IEC TC 57.

First, it’s important to highlight that the standards published by the IEC TC 57 are not free, nor open-source. These standards are copyrighted and sold by the IEC.

The notable standards published by IEC TC 57 are:

• IEC 61970 – For power system modeling and energy utility data exchange including EMS, topology, wires, SCADA, etc.
• IEC 61968 – For power system modeling related to DMS, assets, work, GIS, metering and application messaging.
• IEC 62325 – Modeling for energy markets with support for both North American and European markets (others under consideration).

These three standards, as with all IEC standards, are defined, very formally, in a Microsoft Word document (and often viewed as a PDF).

The IEC depends on the CIM User Group to maintain the CIM, and submit revisions, when necessary, in order to adapt to the ever-evolving challenges that face the power grid.

This means that the CIM User Group is responsible for revising the standards, and then formally submitting revisions to the IEC for review. These submissions must follow the formally specified format (as Microsoft Word document) expected by the IEC, and a lengthy review process follows.

And what does CIMug get for all of their hard work? Well, they are rewarded with the CIM being formally accepted as an IEC standard. It’s a big deal, and a hard thing to do, to get a standard accepted by the IEC. In some ways, it made the CIM less of a dream for some electrically grid interoperability enthusiasts, and it became more of a reality. The CIM becoming a real IEC standard was a real, tangible step towards grid interoperability.

ENTSO-E and CIM in the European Union

In the history of the CIM, one of the most important, landmark events was the CIM becoming codified as IEC standards.

Downstream of these IEC standards, the next most important event(s) in the success and adoption of the CIM was the mandatory adoption in the European Union.

Here’s a brief timeline:

• 2009, ENTSO-E was established with the express goal of improving cross-border system operation, develop interoperability, and preparing technical groundwork for future EU rules

• 2010-2011, ENTSO-E started publishing CIM profiles, purely on a voluntary / preparatory basis
• 2013, CGMES (Common Information Model for Grid Models Exchange), published by ENTSO-E
• ~2015, new grid network codes began to be approved by European energy regulators which mandated grid data exchange in the format specified by ENTSO-E, which was CGMES—a CIM based format!

So, 10 years after CIM was created, transmission operators were required by the EU to provide grid models in a CIM-based format.

And now we’re 10 years into those mandates, and the CIM is alive and well in Europe.

This widespread adoption in Europe meant that the CIM would be put through many trials and tribulations, as many different utilities were quickly adopting the new standard into their systems. Many software vendors popped up and provided CIM-based tools, or provided consulting services to grid operators who suddenly had to provide CIM models to their regulatory authorities.

The result was a much healthier, much more well-known standard.

What is “the UML”

Now that we’ve made it clear what IEC standards are, and that they are not free, and are not open source, we can go back to exploring what parts of the CIM are free and are open-source.

This is where we get to explore what CIM users mean when they refer to, “the UML”.

“The UML” refers to the ontological data model that CIMug maintains. Funny enough, it’s not true UML (Unified Modeling Language) format, but rather a very special variant of UML. But that’s a topic for another post.

It’s an “ontological model” model, meaning that it doesn’t contain any proper data itself, but rather it’s a formal specification of how to represent objects, concepts, and other entities, and their relationships to one another. In the case of the CIM, the “objects, concepts, and other entities” that we’re modeling are all related to the power grid and its data.

For example, a very, very small subset of the ontological model (as UML) looks a bit like this—

(Credit to PNNL, A Power Application Developer’s Guide to the Common Information Model)

This ontological model is painstakingly maintained by CIM user group members (and specifically by members of the model maintenance team). These maintainers use very specialized tools, like Enterprise Architect, to maintain and extend this model.

This UML model is ultimately taken, processed, and then turned into the formal definition of the IEC standards.

It can be thought of as an upstream artifact that is used to generate the downstream IEC standards.

But, most importantly, this artifact (the UML model) is free and open-source.

So while the official CIM standards published by the IEC are closed-source and proprietary, the ontological model, itself, is free and open source.

Unfortunately, I can’t give you a link and say, “here you go, go explore the CIM ontological model”, because, currently, the best way to view it is to use Enterprise Architect, which costs at least $245 for a license. But if you do have EA, you can go to the CIMug Artifacts site, download a .eap file, and start exploring!

Conclusion

Understanding the big players and the dynamics between these organizations was hugely important to me as I tried to enter the CIM world. Between the intro post to CIM, and this post exploring the orgs, hopefully the Common Information Model is slowly being demystified.

In the next post, we’ll be exploring these questions:

• “Is CIM For Planning or Operations?”

• “Is CIM For Transmission or Distribution”

The post Exploring the CIM Through the Organizations That Make It Happen appeared first on Simple Thread.

The tower itself is not the dimly lit room depicted in movies… that’s TRACON (Terminal Radar Approach Control). We eventually made it down to the TRACON room. That part felt like the movies. Up in the tower cab itself, it just looked like a normal day at the office. Several workstations with large monitors, on-duty controllers in shorts and t-shirts with headsets on, talking to inbound and outbound airplanes. No drama, no flash. Just people working.

The union rep giving us the tour walked us through the different screens. One showed every airplane in the PHX airspace inbound to the north or south runway. He changed a filter from just PHX traffic to the whole globe, and you could see how busy the air truly is.

flightaware.com flight tracker is very similar to the display in the tower with inbound plans highlighted one color, and outbound another.

There was another system he pointed out as one of the newest pieces of software they use: TFDM, the Terminal Flight Data Manager. It replaced a previously paper-based system that included everything a controller needs. Flight number, aircraft type, planned speed, requested altitude, equipment, departure time, transponder code, the complete flight plan. When he mentioned it was essentially brand new, I was surprised, because it looks like something built for Windows 95.

Screenshot of the TFDM system’s Electronic Flight Data (EFD) exchange and Electronic Flight Strips (EFS) in the tower to replace printed flight strips.

Standing in that tower, I didn’t see bad design, or old design. I saw software shaped by the people who actually use it, optimizing for what works right rather than what looks right. Just the information you need, where you need it.

My friend, the retired controller, put it perfectly: “The issue is that it doesn’t have to be that complex. Simple information has to pass from controller to controller. I’m sure you understand that it’s minimal bandwidth, so to speak.”

He’s right. A flight strip, whether paper or digital, carries a small, defined set of data from one person to the next. The job of the interface is to make that handoff clean and reliable. That’s it.

EFS strip from the last plane my retired air traffic controller friend talked to.

And that clarity made me think about how much of the software world operates in the opposite direction. The to-do list app market alone is a graveyard of over-engineered solutions to a problem that pen and paper solved a long time ago. Kanban boards, AI prioritization, integrations with everything, gamification. The simple act of writing something down and crossing it off has been optimized and re-optimized by people who seem more interested in the system than the task. Standing in that tower, looking at software built to pass a small set of information from one person to the next, all of that flair starts to look like what it is: complexity in service of itself.

The Hard Part Isn’t the Software

TFDM isn’t the end of a modernization effort, it’s the beginning. At its core, the rollout isn’t about replacing paper, specifically. It’s about automating and integrating processes that controllers and traffic managers currently do manually or with separate, disconnected tools. Adopting a new system that centralizes all of those things is a massive cultural shift for a workforce of over 10,000 controllers managing more than 44,000 flights a day.

Those paper strips aren’t just basic data visualization… they’re part of how controllers think. The physical position of a strip on the board carries meaning, but the manual process of prepping, stuffing, sorting, and then analyzing those strips pulls attention away from the actual job. That’s the case for digitizing, and it’s a strong one. The goal is to remove friction, not redesign the experience. When you digitize that, you’re not just changing the medium, you’re changing the cognitive and social contract the team built around that medium. Getting that right matters more than making it pretty.

The instinct in software is to map the manual process, build the digital equivalent, train the users, and measure adoption. It starts to feel like treating a culture problem like an onboarding problem. The load-bearing parts of old systems are often invisible until you remove them.

In any environment, first impressions with a new system matter. If the replacement stumbles early, it confirms every doubt the team already had. In a setting where reliability isn’t optional, those doubts are hard to walk back. I don’t think trust is something you can ship in v1.

The Case for Boring Software

I keep coming back to the same question: are we solving the problem, or are we creating a new one? The digital version doesn’t have to be a one-to-one mirror of the paper version, but it shouldn’t stray so far from the system that works today that the user has to relearn the job they already know how to do.

The tools in that tower don’t look like they were made in 2026. They look like they were made thirty or forty years ago, and I think there’s a reason for that. There’s no necessity for bleeding-edge design here. The initial design decisions are honed in on what matters: does this help the controller do their job safely and reliably?

I don’t actually know if the software air traffic controllers interact with is their favorite, or if it’s buggy, or if they think it’s great. I got the feeling that it’s good enough. In a profession where the stakes don’t leave room for anything less, that deserves more respect than we usually give it. The boring-looking software in that tower cab isn’t a failure of imagination. To me, it’s evidence that the people who built it respected the work.

The Reason Doesn’t Have to Be Technical

Remember the TRACON room, the dark one with all the radar screens that felt like the movies? It turns out those rooms don’t actually need to be dark anymore. The older radar displays weren’t backlit, so controllers needed the dim environment to read them. The newer STARS system they use now has backlit screens and TVs everywhere. The technical requirement for the darkness is gone, but decades of working that way doesn’t just flip like a switch. The rooms are still dark. Nobody mandated it. Nobody requested it. It’s just how the job feels right. The absence of a reason to change was reason enough to stay.

Good design isn’t knowing whether to leave the lights on or off. It’s knowing to ask the question first.

The post What an Air Traffic Control Tower Taught Me About Software Design appeared first on Simple Thread.

It usually strikes during a project kickoff. A product manager or influential stakeholder asks a fundamental question about user behavior. Everyone in the room nods thoughtfully. “We should run a study to figure that out,” someone says. So, your team spins up a new research plan, recruits participants, spends weeks conducting interviews or tests, and synthesizes the findings.

Then, a few months later, you stumble across a dusty slide deck in a shared drive from a year ago. The exact same question was asked. The exact same answers were found. You just spent weeks, and a significant chunk of your budget, re-learning something your team already knew.

Research amnesia is incredibly expensive. It wastes time, burns through resources, and most dangerously, causes severe stakeholder fatigue. When leadership and product teams see the same questions being investigated year after year, trust in the UX research process starts to erode. What’s worse is when end users don’t feel heard. Trust in the product fades and animosity for the brand takes its place.

Research shouldn’t be a disposable commodity that resets with every project; it should be an accumulating, searchable, shared brain.

Right now, our team is in the middle of an experiment to cure research amnesia once and for all. We are actively building a UX research repository that actually scales, using a combination of Atomic UX Research, the Zettelkasten method, and Obsidian.

We are still in the early stages of this journey, refining our process as we go. But because this setup has already fundamentally changed how we handle user data, we wanted to share our framework in progress.

Adapting Atomic UX Research for the Real World

Our approach is heavily inspired by Daniel Pidcock’s concept of Atomic UX Research, the idea of breaking knowledge down into its constituent, reusable parts. However, we have adjusted Daniel’s traditional formula (Experiments ➞ Facts ➞ Insights ➞ Recommendations) to work for our needs.

Here is how we’ve adapted the “atoms” of our research:

• Research Studies (Not just “Experiments”): We broadened the scope. Whether we are doing evaluative usability testing or generative/exploratory interviews, any form of data collection is categorized as a “Study.”
• Research Questions (Instead of “Insights”): This is the biggest shift. Instead of storing abstract insights, we use specific Research Questions as the connective tissue of our repository. They act as the anchors for what we are actually trying to learn.
• Facts: The raw, unbiased observations, behaviors, and direct user quotes we gather during a study. Facts make no assumptions.
• Recommendations: The actionable next steps for the product or design team, born directly from the facts that answered our research questions.

By breaking research down this way, a “Fact” discovered in a Q1 generative study can be reused to answer a new “Research Question” in a Q4 evaluative study.

Enter Zettelkasten: The Philosophy of Connection

To manage these atoms, we turned to the Zettelkasten (or “slip-box”) method.

Traditionally used by academics and writers, Zettelkasten relies on creating atomic, decentralized notes that prioritize connections over rigid folder hierarchies. In a standard system, you might put a research report into a folder named “Q2 Research Project.” In a Zettelkasten system, you write down a single user behavior and link it to the broader concepts it touches.

The parallel here is perfect. A Zettelkasten “atomic note” is the exact same thing as one of our UX “Facts.” By treating research this way, we shift from creating top-down, isolated documents to building a bottom-up web of continuous knowledge.

Why Obsidian is the Perfect Engine

To build this web, we needed the right tool. We were already using Obsidian for our note taking and knowledge management needs. Turns out that it was also the perfect tool for our UX research brain, over traditional wikis or cloud drives, for three main reasons:

1. Bi-directional Linking: By simply typing [[ ]], we can instantly connect a new Fact directly to a broader Research Question. If I link Note A to Note B, Note B automatically knows Note A is pointing to it. And, I can create queries to pull lists of related notes, super valuable for synthesizing Facts to answer Research Questions.
2. The Graph View: Obsidian visualizes your notes as a literal web. We can look at the graph and visually see multiple Facts from different Research Studies clustering around a single Research Question over time, giving us immediate confidence in the data.
3. Future-Proofing: Obsidian uses local, plain-text Markdown files. We own our data. Our research repository isn’t locked into a proprietary, cloud-based database that might change its pricing or shut down tomorrow. We can also securely store it on premises, which is critical for our highly regulated clients.

As a side note, it turns out there is a large contingent of people who are using Obsidian to take Smart Notes following the Zettlekasten approach. To learn more, check out:

• Sonke Ahrens’s book How to Take Smart Notes: One Simple Technique to Boost Writing, Learning and Thinking – for Students, Academics and Nonfiction Book Writers, and
• Odysseas video, Obsidian: The King of Learning Tools (FULL GUIDE + SETUP), on YouTube for configuring Obsidian for Zettlekasten.

Both were instrumentally inspirational as I was pulling these connections together in my mind.

Our Workflow in Practice

Because we can’t share specific client data, let’s look at a hypothetical scenario to demonstrate the mechanics of our Obsidian vault. Imagine we are researching the onboarding experience for a fictional power systems analysis app.

Here are the 7 steps of our current workflow:

1. Set up the Research Study as a central note: We create a hub for the initiative. (e.g., Generative Research: App Onboarding).
2. Define the Research Questions: We create individual, standalone notes for the core questions we want to answer (e.g., RQ: What are the primary pain points for first-time users?). We link these Question notes back to the central Study note.
3. Select the Methodology: Inside the Study note, we decide on and document the best approach to answer those specific questions (e.g., 1:1 user interviews, diary studies).
4. Conduct and Document: As the study happens, we drop our raw session notes and interview transcripts directly into Obsidian as their own notes (e.g., Session: Interview with User A – March 4).
5. Extract the Facts: This is the critical “atomic” step. We comb through the session notes and extract pure, unbiased observations and quotes, turning each into its own standalone “Fact” note (e.g., Fact: User A stated that they regularly abandon apps when asked to create an account before seeing fees).
6. Link Facts to Questions: We connect the dots. Using Obsidian’s bi-directional linking, we attach these individual Fact notes to the relevant Research Question notes. Over time, the Question notes naturally compile their own evidence-based answers.
7. Compile Findings & Recommendations: We return to the central Study note. Instead of writing a massive report, we synthesize the answered questions into actionable recommendations right there in the hub.

No 50-page PDFs. Just clear, linked, evidence-backed next steps.

What’s Next: An Ongoing Journey

As mentioned, this repository is very much a living, breathing experiment for our team. We are still figuring out the best linking conventions and bringing new team members into the Obsidian/Zettlekasten/Atomic Research mindset.

However, the early observations are incredibly promising. Logging research this way feels infinitely more valuable than building slide decks. We are already seeing how an observation from one study can spontaneously answer a question in another, completely unrelated project.

We will be sharing a follow-up post in the future once we have more mileage with this system. We plan to share the long-term results, the friction points we will inevitably encounter, and how this web of knowledge scales as we add hundreds of new facts to the vault.

Stay tuned.

The post Building a UX Research Brain: Atomic Research, Zettelkasten, and Obsidian appeared first on Simple Thread.

In Marty Cagan’s book Inspired, he describes the frustrating experience of laboring long to develop product features that went ignored by consumers. The problem that he identifies is that executives would dictate product requirements long in advance without having gone through the product discovery process to determine the product’s value to the user, resulting in technically impressive software that nobody wanted. For UX designers, product usability and learnability can produce a similar dilemma, though further down the funnel. In cases where user experience is insufficiently or improperly considered, the frequent result is cumbersome products which are difficult to learn and therefore go unused. Here the problem is often that although the valuable software “does the thing” according to spec, the experience of the product continually subverts the users’ expectations, making it an utter frustration to use.

In contrast to this, I’m sure that we’ve all had at least one tool that no longer gets noticed when we use it. Instead, that tool feels like an extension of our own body. Before reaching that point of confident comfort though, we had to learn the tool and get the initial practiced hang of it. In software design (as with any tool) this learning period can be longer or shorter depending on how the tool is designed. Therefore, an ever-present concern of UX designers is how do we help the user learn the tool quickly?

How do we learn?

To answer that question, it helps to get clear on our epistemology, or our understanding of how we learn and know things. By considering this, we can get greater clarity on how UX designers can ensure that the value of their product actually reaches the end user. Firstly, humans don’t navigate tools or the world primarily by logic or reason, but rather the majority of our living and doing is upheld by our unconsciously-lived, reflexive and bodily experience. Philosopher Esther Lightcap Meek describes the mechanism by which human knowing takes place as “Subsidiary-Focal Integration,” a process wherein the knower tacitly relies on clues in the world (subsidiaries) to achieve a coming together (focal integration) of those clues. Knowing is that “aha!” moment when the clues come together to become a coherent pattern of meaning, at which point the knower is no longer attending to the clues but only on the integrated whole.

This is a bit technical, but Meek insists that this process is normal in all ordinary knowing and thus bears greatly on our understanding of UX design. According to Meek, we look through the clues to attend to the focus, and this is how we would come to know how to use a tool. To make this clearer, consider riding a bike! At first a child will wobblingly try to pay attention to moving the pedals and balancing and steering and not falling, all the while switching their focus rapidly between these different clues. Yet once they’ve practiced enough, they no longer focus on these clues at all, but rather their focus is shifted to the joy of riding and trying wherever they want as fast as they can. At that point they can even do tricks! Yet if the bike were to do something funny, like their chain caught suddenly, their focus would shift right back to the clues so that it could be reintegrated into the whole.

The ways we know and learn digital tools are no different. As a user interacts with a digital tool, they are building up reflexive confidence in what they are doing as they attend to their goal. At first, they may switch between the buttons, to the navigation, to the data on the page, and back again, but eventually they begin to look through these UI elements to their end goal. If this is how we learn things, then the epistemological question that designers must ask is “which clues do I include and how do I help the user familiarize themselves with them such that they begin to look through them?” It seems to me that Design patterns are part of the answer and are fundamental to building and maintaining the user’s integrated usage of the tool.

Design Patterns are like forest paths

Nielsen Norman Group defines design patterns as “Repeatable solutions for common design problems” and I’d argue that this definition encompasses a broad scope. A design problem is any need that would necessitate augmentation of the tool, and solution can be any element represented in the tool in response to those problems. In the case of digital design, this can be repeated signifiers or objects for communicating affordance or function (like buttons or icons). It could be repeated layout conventions or repeated process or workflow handling. The list goes on and can encompass any decision that’s reflected in the tool, really. The point is that repetition builds familiarity and establishes convention, thus compounding expectation of meaning as that pattern is used more. As a side note, these conventions don’t have to stay local to the medium of digital technology— we see design patterns repeated in road design, architecture, advertising, etc. Design patterns are ubiquitous in our world and should be sourced from the whole of our experience in the world to make the tool make richer sense.

As tools mediate our intent, their usage follows the same process of subsidiary-focal integration that we see in all knowing. Our intent forms a vector starting in the willful agent (the user), it comes to the tool (the UI) and proceeds through it, ending at the outcome. The tool is the means by which the outcome is accomplished, but as we said, the tool has to be inhabited or navigated effectively by the user for that to be the case. In our journey from intent to outcome, we can liken onboarding a new tool to arriving at the edge of a thick forest— the outcome that we seek is through that forest, and we have to get to the other side. A tool that’s designed in defiance or disregard of all conventions is like the Old Forest in J.R.R. Tolkien’s classic, The Lord of the Rings; the trees move and there’s no hope of getting to the other side. There are even websites whose whole purpose as a joke is to confound the user as much as possible through the use of “anti-patterns;” controls so cumbersome and opaque to understand that the frustration is funny. We’ve all probably experienced something like this even in expensive enterprise-grade software, but the service-nature of design should motivate us to avoid these failures and make products that are hospitable to human use.

If the tool itself is the forest that we must traverse, then we can liken design patterns to foot paths in two senses. On the one hand, no matter how thick the woods, eventually a path necessarily will be formed through persistent usage. The path may be crazy and roundabout, but if it’s been trod enough it will be clear and usable eventually. Humans were designed with the uncanny ability to learn and adapt, and given enough time and need, we often learn to cope with tremendous amounts of ambiguity or dysfunction within a tool to use it effectively. In this case, the “pattern” isn’t so much designed as incidental. The other way that design patterns are like foot paths, is as in the case when someone cuts a well tended, clear, obvious, and direct way through. Design and human crafting is so ubiquitous that this is the sort of thing we’re used to and is what we look for if we find ourselves lost in the woods. If we see a clearly maintained path we know not only that civilization is near but also that we can get to it by way of the path. Designing in a convention-fitting manner is like cutting a clear and direct path for the user, and as long as people continue to use it, and the conventions (the path) are “maintained,” the path will remain traversable. Furthermore, the more that people use it, the more the significance of the pattern is compounded! That significance is at one level of magnitude when a pattern is used consistently in a single tool, but it’s another level entirely when the pattern is used commonly across the whole of the internet! In this case, our foot path becomes more like a four lane highway.

How then shall we design?

Thinking back to Esther Lightcap Meek’s pattern of knowing mentioned earlier, let’s consider now what design patterns are actually doing here. When a tool uses a common design pattern, the user is being presented with a familiar clue, one which has become laden with significance through previous encounters. Because this clue has prior meaning, the user can inhabit it more confidently in new contexts, and they can subconsciously gear their expectations toward the outcome they’ve experienced before. To use another analogy, if someone knows how to drive a car well, then it won’t be so hard to drive a bus or a semi-truck given the similar design patterns across the vehicles (steering with the wheel, gas and braking through the pedals, etc.). Design patterns give us familiar handles with which to engage new things.

Two words which serve us designers as guideposts to accelerate user learning are convention and consistency. Firstly, wise designers would do well to lean heavily on common design patterns, as those conventions form the basis of approachability for a new tool. When a designer leverages existing design patterns, they have provided a scaffold of familiarity for the user to rely upon even if the tool is new. In this case, the paths through the forest are clear and direct, so the time it takes to learn the tool is minimized. Convention isn’t much help without consistency though. If a tool relies heavily on strong, conventional design patterns, then deviations from that pattern will be a great shock to the user. It’d be like having a bike whose chain drops at random intervals— if it’s generally a good bike then it will certainly be a surprise, and will immediately draw your attention away from your focus from riding. From there on, you may have the lingering concern that it may happen again sooner or later. Without consistent implementation of patterns within our products, the user grows uncertain, and doubts whether or not they’ll be able to proceed confidently. Although the initial learnability of the product may be high, inconsistent design can thwart the maintenance of that integrated focus, and unfortunately that can begin to affect consumer trust in that product.

An effective design system is a great way to establish strong convention and consistency within software development. A design system generally consists of both a component library which contains all of the common UI components used in the system, and a set of standards and guidelines on how to design with the components. A design system is like a set of Legos with broad enough instructions to be able to build anything. The discipline of using only the global components available in the library ensures a base layer of consistency at least internal to the app, while the guidelines ensure consistent standards of implementation even with multiple designers working simultaneously. The best design systems, in addition to this, draw heavily on common design patterns and conventions from other applications and build those conventions into the components themselves. So at that point, the system is maximizing universal conventions while maintaining the highest degree of internal consistency— at least from a component level.

A design system is just one powerful tool that designers have in their toolbox, but with attention to these two C’s designers should be able to design products that quickly become effortlessly helpful.

The post Patterns of Knowing in Product Design appeared first on Simple Thread.