Model Advisor is a tool that allows modelers to run rules against a Simulink model. It's a little like "lint" for your code. It can find syntax errors, industry compliance errors, and potential code generation and simulation issues. It's used heavily in the automotive and aerospace fields to check compliance with your Simulink model against industry standards.
Taking a page from NNg's Error Prevention heuristic, I established the principle that "it is best to prevent errors, but if you can't it is best to show them in context" (close to when and where they happen). Simulink's Edit Time Checking informs users of errors or potential problems while users are editing their model, well before they invested the time to compile it.
Compiling a Simulink model can take minutes or hours. Alerting a user to an error before compilation could yield huge time savings. Edit time, like a spell checker, ran in a separate thread so as not to impede performance while interacting with the app.
Research and Planning
I gathered data from customer-reported bugs related to compliance and error checking. The team also built a relationship with the Automotive Advisory Board, a group of industry advisors responsible for authoring our best practices and standards.
One big constraint imposed by stakeholders was that this type of checking should not get in users' way or impede their productivity. This feature would be very visible on the Simulink canvas. We also didn't want to infringe on or conflict with other visual features and decorations on the Simulink canvas. Many feature owners had a stake in the outcome of this project. I helped establish a 12-person committee of feature owners who served as important stakeholders and domain experts. In bi-weekly review sessions, they provided feedback and guidance with design decisions.
We researched similar products including notifications, spell checkers, lint, type-ahead and code assistance tools.
Two key findings were
Different levels of severity needed to be represented, a low level that allowed users to continue working and a high level that stopped users from continuing because the error was severe and needed to be addressed immediately.
Users did not only want to identify issues, but they wanted to be able to take action to resolve them in the same context
The feature, therefore, needed to provide just enough affordance to assist, but not interrupt the user's flow which meant that it could not have modal workflows, animation, or high contrast, It also needed to provide users details of an issue and offer suggestions to fix it.
Design Process
I facilitated sessions to generate ideas for visual treatments on block diagrams by printing several hard copies of various-shaped Simulink building blocks on large 11x14 paper. I encouraged participants who were engineers, tech writers and stakeholders, to use markers and colored pens to generate as many indicators on blocks in a short time frame. This resulted in a multitude of ideas that could be later explored.
Prototyping
During our explorations, we doubled down on design principles:
Don’t slow down the user
Alert to issues in a timely way and in context
Provide enough information to fix the issue.
I produced some small prototypes illustrating interactions. Prototypes were written in jQuery and explored transitions, popups, fading badges, and indicators.
Conclusion
Creating interactive prototypes in HTML and JavaScript, and testing those prototypes with users was a level of control I enjoyed. I was able to explore many different designs in running code. Working in this manner gave me confidence that the designs I suggested could be implemented. The control to tweak the interactions was valuable in my role as an interaction designer (for instance, the amount of time to transition or fade in after a hover-over). This level of prototyping would have been very difficult to do in a tool such as Figma.
The time to market grows exponetially as the number of stakeholders increases 😀