SaltStack Job Inputs
SaltStack
The Job Inputs feature allows IT admins to add form fields and variables to SaltStack jobs to reduce job duplications and require specific form fields when running the job.
Role: Lead Designer
Time frame: 3 months
The Goal
Design a feature that allows admins to require fields or variables to be filled out before running a job.
Challenges
Code Mode vs Form Fields
Very tight deadlines.
No time allowed for early discovery research.
Pressure to rush designs.
Cut in Scope
No existing users since this was a new product.
Needed to get funding to recruit external participants for research.
Design Process
Requirements
Created with Product Manager
Planning workshops
Design
Wireframes
High fidelity mocks
Validation
Internal validation
Usability testing
Delivery
Handoff to engineering
Answering questions
Quality testing
Requirements
Lead planning workshops with Product Management and Engineering.
This included:
List requirements
Identify risks and dependencies
Align cross-functional stakeholders
Design
This page shows the Jobs page. Jobs are commands to be run with specific variables and arguments every time. Previously, users needed to add arguments as strings of code.
This shows the “YAML mode” option for the Jobs page. Since this feature is primarily built for IT admins, there are split preferences on UI form fields and just using a “code mode” and we needed to meet both options.
This shows the process for adding a job input, to specify specific arguments and form fields to be filled out when running the job.
This screen shows the end result of setting up the job inputs in the Jobs page. This is what users will see when running the job.
Validation
For initial, early designs, I got feedback internally from the professional services team as well as technical account managers. Once I made initial adjustments, I reached out to a handful of customers to do a combination of feedback and usability testing.
Research goals:
Understand users’ expectations for how they’d be able to add job arguments that users can fill in when running the job.
Find out which parts of the design are less clear, less intuitive, and block a user’s workflow.
Find out whether the form labels we’ve used are clear.
Top Insights:
The word “Hidden” for arguments was unclear and needed to change.
Responses were mixed on whether users are more likely to use the form fields or “YAML mode”
Users did not really understand positional arguments, and most users didn’t need them anyway.
Delivery
Lastly, I attended regular meetings with the engineering team to answer questions and design error states as needed. After the feature release, I led a retrospective with the engineering team to discuss what went well and what didn’t so that we can improve for the next time.
