Variant Manager V2

By Sreelakshmi S B

Agenda

01

02

03

04

Impact

Introduction

The Process

Reflections

Introduction

SIMULINK

Simulink is a block diagram environment for Model-Based design and simulation.

​

SIMULINK

Each component of the car (tire, chassis etc.) can be modelled separately.

​

Simulink Variants

• System components might need multiple design variations to meet different sets of requirements.
• Users may need to switch frequently between these design choices.
• Simulink variant capabilities allow users to represent all design alternatives in a single model.

Simulink Variants

Variant Configurations

Different modes of a system

E.g. different configurations of a car

Simulink Variants

Variant Controls

The variables that control the makeup of the system. They vary across different configurations.

E.g. number of cylinders can be 4 or 6

EngineType can be “Diesel” or “Gasoline”.

Simulink Variants

Variant ConstraintsControls

Checks that limit the configurations of a system. These are made up of control variables

​

E.g. number of cylinders cannot be 4 if the engine is gasoline.

Working With Variants

Consider a car

​

Working With Variants

The car is made up of several parts

​

Working With Variants

Together these parts(components) make up the car (system)

​

Working With Variants

The entire car system can be modelled in SIMULINK

​

Working With Variants

The components themselves can have configurations, controlled by their own set of control variables

​

Diameter, Width of wheel

No. of cylinders, engine type

Variant Manager

A central tool that allows users to manage variants in a model - i.e. manage the car system

​

Variant Controls

Variant Configurations

The Project

Variant Manager 1.0 was a tool that was embedded in SIMULINK.

A new and improved version of the Variant Manager (Variant Manager 2.0) was to be built and shipped separately - as a support package.

​

I worked with a cross-functional team to design and ship the new support package.

Overview

Context

Duration

My Role

Tools

CDA-UX at MathWorks

​

6 months

UX Researcher

Figma, Miro, G Suite

Excel, PowerBI

Process

Research

Design

Testing

Redesign

Testing Round 2

Launch

Primary and secondary Research

Design Sprint #1,

Wireframing,

Prototyping

Usability Testing #1

App Design Reviews #1 and #2,

Design Sprint #2, Wireframing, Prototyping

Usability Testing #2

Motivation

Revenue Increase

Shipping VM separately would be an additional source of revenue

Tool Complexity

Several new functionalities had been added to the tool over the years. The tool had become too complex to be contained within SIMULINK.

Java Transition

The team was transitioning away from Java and changes were being made to the codebase.

Stage #1 : Research

Understanding

The Tool

​

• Hands on exercises
• With example models
• With large-scale customer models
• Documentation
• Talking to stakeholders (cross-functional team members)
• Attending team meetings

​

Discovery

​

Research using primary and secondary sources

• ERS Reports (Event Reporting System)
• Interactions between customers and Customer Facing Engineers (CFEs)
• Support cases on Salesforce
• Reported bugs and enhancements
• Interviews with Customer Facing engineers
• Interviews with other Stakeholders

​

Curating Requirements

​

Based on the research, a set of requirements were compiled for VM. The high-level requirements are given below.

​

• Component Development
• Model Assembly/System development
• Variant Analysis
• Analyze different variant configurations
• Variant Reduction
• Reduce a variant system to just a subset of configurations
• Auto-generation of configurations
• Automatically generate all possible configurations for a model
• In-tool guidance

User Personas

​

3 personas were created

User Personas

​

Component Developer

Component Development

Software Integration Engineer

Variant Analysis and Reduction

System Architect

Component Assembly

Mapping User Flows

User Flows

​

Mapped user flows for the 3 user personas, in Miro

• 4 workflows in total
• Component Development
• Assembly
• Analysis
• Reduction
• Stages broken into steps

Stage #2 : Design

Design Sprint

• Goal : convergence on requirements, ideas
• Focus : New features, critical workflows
• 4 days
• 11 Participants (CFEs, UX Team, Developers, Technical Writers, Advanced Support Group)

​

Design Sprint

Default Layout

Variant Controls and Configurations

In tool guidance

Reduction and Analysis

Day 1

Day 2

Day 3

Day 4

Wireframing

Initial wireframes were created based on the ideas generated from the design sprint.

​

​

Main Layout

Reduce

Analyze

Prototyping

These wireframes were converted into prototypes in Figma and finally coded prototypes.

Rationale : The team had code from the Variant Manager V1 which they could reuse to create coded prototypes quickly.

This was done with the intent of conducting usability tests to gather feedback for the designs

​

​

Stage #3 : Testing

Usability Testing

Test were run on the prototypes.

• Method : Remote Moderated Usability Test
• Think-aloud
• Goal : Test the current designs, isolate issues in the 4 workflows
• Participants : 4 + 1 pilot
• Duration : 1 hour per session
• 3 tasks to cover the 4 workflows

​

Usability Testing

Data Collected

​

Qualitative : User Behavior, User Feedback

​

Quantitative : Task metrics (task completion time, number of steps, number of errors, error recovery rate, number of doc visits etc. )

​

Attitudinal data (Post task ratings, Post study ratings)

​

​

Usability Testing

Objectives

​

The test aimed to test the following parts of the Variant Manager workflow, in particular

1. Using variant manager at the component level
2. Using variant manager at the system level
3. Analyzing configurations
4. Reducing the model

​

Conducting the Tests

Analysis

I analyzed the quantitative and qualitative data collected, post each session and conducted a final analysis once all sessions were completed. The focus was on qualitative data.

​

Some of the issues that came up from the test are indicated below

​

• Cognitive Overload
• Difficulties with understanding and framing constraints
• Issues with finding and using the component browser for the assembly workflow
• Confusing terminology - users could not understand what some of the terms meant
• Users could not understand the save workflows within the tool

​

​

Stage #4 : Redesign

Design Modifications

Based on the results of the usability test, we made modifications to the design. The new designs were handed over to the development team for implementation.

​

Changes to the design included :

​

• Adding help for constraints

​

• Modifications to the layout

​

• Modifications to the component browser

​

• Modified terms and Icons, specifically in the toolstrip

​

​

​

App Design Review

The new designs were prototyped and shared with the app design review team

​

Goal : To check if VM V2 behavior meets existing standards w.r.t

• MATLAB/SIMULINK Apps
• CDA tools in SIMULINK

​

Reviewers : Panel of 5 ; UX Design and Research heads in the CDA Space

​

Feedback

Some of the violations that came up in the review are

• Clarity of workflows, next steps not always clear to the user
• Launching Variant Reducer and Analyzer
• Toolstrip Organization standards
• Working Area Standards
• Icons, naming conventions

​

​

​

​

​

Design Sprint #2

A second design sprint was held at this stage.

• Goal : generate new designs to address the app design review feedback
• Focus : High-level workflows, violations
• 3 days
• Participants : 4 (UX team, Development Leads)

​

Design Sprint

Assembly Workflow

Component Development workflow

Layout, Icons, Naming, Entry Points

Reduction and Analysis

Day 1

Day 2

Day 3

Day 4

Prototyping

New wireframes, followed by prototypes were created based on the designs that came out of the design sprint.

​

Modifications included :

​

• More full-fledged help
• Changes to the default layout
• Toolstrip changes
• Change placement of features to improve discoverability
• Changes to names and icons
• Progressive disclosure - less information shown on screen
• Contextual changes to move to secondary workflows
• Simplifying constraints and adding examples
• Reducer and analyzer launch from the main screen

​

​

​

​

App Design Review #2

These new designs were taken to the App Design Review Team for a second design Review.

​

The feedback was largely positive this time around, with minor corrections in

• Division of real estate in the toolstrip
• Display of feedback within VM

​

Based on the review, modifications were made to the coded prototype, once again

​

​

​

​

​

Layout after Design Modifications

Stage #4 : Testing Round 2

Usability Testing # 2

Another round of usability tests were run on the new prototypes, this time with customers

• Method : Remote Moderated Usability Test
• Think-aloud
• Same tasks as Round 1
• Goal : Find usability issues with the 4 core workflows, get customer feedback
• Participants : 5 Customers
• Duration : 1 hour per session
• Pilot with 2 CFEs

​

​

Usability Testing

Data Collected

​

Qualitative : User Behavior, User Feedback

​

Quantitative : Task metrics (task completion time, number of steps, number of errors, error recovery rate, number of doc visits etc. )

​

Attitudinal data(Post task ratings, Post study ratings)

​

​

Usability Testing

Objectives

​

The test aimed to test the following parts of the Variant Manager workflow, in particular

• Using variant manager at the component level
• Using variant manager at the system level
• Analyzing configurations
• Reducing the model

​

Note on Recruiting Participants

Participants were recruited using a set of 4 screener questions

​

• Questions were drafted in consultation with the cross-functional team
• These were sent out to current and potential new users for VM
• Goal: get customers with varying levels of expertise in Variant systems and different workflows within VM

​

​

Analysis

I conducted another round of analysis on the quantitative and qualitative data collected.

​

Overall, the quantitative data indicated better metrics - higher success rates, less completion times on average

​

A few new issues that came up from the test are indicated below

​

• Consistency with terms across the tool
• Some terms were still confusing to some users
• Users expected Auto-complete and dropdowns while filling control variables, configs etc.
• Heavy reliance on Help and documentation
• Setup options overwhelming, for reduction workflow

​

Further changes were made to VM based on these results.

​

Impact

Variant Manager 2.0

Variant Manager 2.0 was shipped as a support package in SIMULINK R2022b

​

• The tool would initially be free, future releases would be paid

​

​

​

​

​

​

Variant Manager 2.0

Variant Manager V1

​

from SIMULINK 22a

New Features

Variant Reducer

​

from SIMULINK Design Verifier 22a

Variant Analyzer

​

from SIMULINK Design Verifier 22a

Variant Manager 22b

(Redesign)

Get In-tool usage guidance to learn the tool faster

Manage different types of

variant entities

• More features
• Improved Workflow

Improved UI layout and workflow for Defining and Validating Constraints

Improved component configuration specification

Variant reduction and Analysis

Note : The development team led the design of this feature, due to time/ resources constraints within UX

​

​

Automatically generate configurations

Backend changes

• improved efficiency
• Modular architecture
• Scalable
• Improved performance with larger models (10-60x speed opening large models)

​

Reflections

Plans for the Future

​

Not all changes were implemented, not all requirements got equal focus

​

• More focus on reduction and analysis workflows
• Auto generation of configurations
• Wizard-style in-tool usage guidance
• More intuitive ways to specify control variables, configurations and constraints

​

Monitoring usage of the support package through Data-Driven UX practices.

​

Further design iterations

​

​

​

Improvements

Timeline

• The UX Team joined the development team after the team had started implementing some ideas
• It was difficult to convince the team to take a different design direction

​

Design Sprint #1

• Lesser Participants
• Goals should have been more focussed
• Could have removed the need for a second round

​

App Design Review

• Initial Designs should have been constrained by existing App Design standards (could have been enforced during/after the design sprint)
• Review could have been conducted at an earlier stage

Thank You

• CREDITS: This presentation template was created by Slidesgo, including icons by Flaticon, and infographics & images by Freepik