👂 First listened to user feedback

Before beginning design, I collaborated with the PM to analyze feedback related to the alarms feature of SystemLink Server, a server-based predecessor of SystemLink Enterprise. The feedback showed that users were overwhelmed with too many alarms, and many requested enhanced functionality for managing this volume of information.

👀 Then looked at user behavior

We then analyzed user behavior and learned that users were often setting alarms in order to be notified of system events so that they could manually trigger another system event. No wonder that critical alarms were getting lost in the noise of this work-around!

💭 Formed a hypothesis

If users have the option to automate tasks, then they will set less alarms, reducing the resultant alarm "noise".

🧪 Tested the hypothesis

I partnered with our UXR on a moderated, talk-aloud tree test that provided enough of a stimulus for users to explore and react to while also being quick to launch.

The key findings were:

• A preference for automations: users preferred to automate tasks vs setting an alarm when the ultimate goal was the resulting task
  
  

• Differing mental models: when creating a routine, some users were inclined to think first of the triggering event while others first thought of the desired automated task
  
  

• Seeing is believing: users relied on the visible options of triggers and events when creating their desired routine
  
  

🖌️ Used findings to inform function & design

The findings provided guidance for the ultimate function and design of the Routines feature.

Here's how:

• A preference for automations: in collaboration with the PM and product team, we identified a set of triggers and resulting events that would be included in the final version of the Routines feature. Keeping in mind our goal of reducing unnecessary alarm states, we limited the triggers that could be paired with an alarm.
  
  

• Differing mental models: The design needed to allow users to create routines starting with either the trigger or event, not force them into a singular workflow.
  
  

• Seeing is believing: The design should allow users to easily browse available trigger-event pairings and provide feedback and easy recovery when a desired pairing is not available.
  
  

🧪 Tested a clickable prototype

I created a clickable prototype in Figma that I tested with users at the SystemLink expo booth during NI's annual NI Connect conference. The tests validated the design, and users were not only able to easily discover the types of pairings they could and could not pair when creating a routine, but were also notably excited about the prototyped feature and design.

📦 Delivered options

The ultimate, north-star version of the feature included design system components that were in "incubating"status and functionality that would take the development team time to create. I collaborated with the PM and dev team to provide an option that could be developed asap, an option illustrating what could be possible once the design system evolved a bit, and a north-star option with the final designs and functionality.