I helped evolve an already-shipped diagnostic surface into a clearer resolution workflow, moving from readable messages to safe fixes and accountable suppression.
Diagnostic Viewer already collected technical messages, but the path from explanation to resolution remained fragmented. I shaped message hierarchy, Fix-It requirements, safe failure behavior, and suppression strategy with engineering partners; together, we established a reusable interaction model and support system for diagnostic authors.
Diagnostic Viewer had already shipped when I joined the work. MathWorks had re-engineered it in R2014a to collect messages from multiple simulations and make filtering easier. My work started from that real product state.
Diagnostics were dense, technical, and distributed across the model canvas, viewer, configuration settings, documentation, and command line. A message could describe several causes, suggest several remedies, or propose a change to the model itself.
Dense messages had to be scanned under pressure.
Important actions could not depend on hover or memory.
A fix might change model state or fail partway through.
Suppression needed context, ownership, and a way back.
I researched comparable diagnostic systems, explored message hierarchy and action visibility, authored visual requirements, analyzed Fix-It use cases, helped drive functional requirements, supported usability testing, and contributed to suppression and diagnostics-management strategy.
I worked with developers and diagnostic-authoring teams on the mechanism behind automatic fixes. Engineering partners shaped callbacks, transaction behavior, and implementation. Product teams owned their diagnostics and the shipped product.
I began with message hierarchy, scanning, stages, toolbar behavior, and action visibility. The aim was practical: make the important content easier to find and remove interaction patterns that users could miss.
That work built trust with the development team and created room to address the larger product question: what should happen after a user understands the message?
I evaluated 26 diagnostic scenarios to understand when the product should explain a remedy, offer one automatic fix, expose several alternatives, or avoid automation. The work covered success, failure, dependencies, deletion, and diagnostics with several linked causes.
The interaction needed an authoring contract behind it: a cause, a clear action label, a callback, feedback after execution, and a recovery path when the action failed.
A useful Fix-It sometimes had to modify a model. The decision boundary was explicit: apply the model change in a controlled transaction, roll back partial work if the action failed, and leave saving to the user.
That same principle carried into suppression. Accepting an exception should record context and preserve the ability to review, restore, or govern it later.
The resulting interaction model separated understanding, action, feedback, and governance.
Make severity, cause, and the affected model context easy to scan.
Distinguish explanation, manual guidance, and automatic actions.
Tell the user what the product will change before execution.
Apply a controlled transaction and report success or failure.
Leave persistence to the user and provide recovery when needed.
Let teams suppress, justify, review, and restore accepted diagnostics.
The durable outcome was a reusable interaction model, supported by guidance and review for the teams applying it.
The interaction model covered suggestions, automatic actions, alternatives, success, failure, and recovery.
Guidelines, reviews, documentation, and internal forums helped product teams apply the pattern.
MathWorks documentation still shows suggested fixes, success and failure states, suppression, justification, restore, and Suppression Manager.
Attribution: public documentation shows current product behavior. Dated design and review artifacts establish my contribution, while the current experience also reflects later team work.
It needs clear consequences, recoverable failure, and an explicit boundary around user control.
I would now test the mechanism earlier with lower-fidelity state models. That would expose safety and comprehension questions before visual details made them expensive to change.
Official MathWorks sources establish the product state. Dated private artifacts establish my role and remain unpublished.
The diagrams abstract the internal work; confidential project and participant material is not reproduced.