I began working at Quest Software in 2019 as a senior user experience design in a full-time work-from-home role (8 months before COVID-19 turned us all into work-from-home devotees).  
Spotlight Cloud
I started out working on a product called Spotlight Cloud - a database performance monitoring (DPM) solution based on a very successful enterprise-scale installed solution that had made the leap to cloud. 
Case Study:
Introducing a new feature (Notifications) to our cloud DPM product, Spotlight Cloud.

We had several unknowns to address:
Where in the UI to most effectively organize and display notifications
Where to add the entry point(s) to that display area
Where/when across the UI to reinforce notification alerts
Where to add entry point(s) to management and configuration of notifications.
Distinguishing between (already introduced) marketing notifications and the new connection-centric notifications.

This project involved early concept design and feedback iterations, building a moderator guide, recruiting for the study, conducting the moderated testing sessions, analyzing session videos and notes, organizing findings and providing the research-backed recommendations.
Research Summary:
What we did:
Conducted a 25-40 minute interviews with current/past Spotlight users as well as DBA-type contacts from Quest Labs db comprised of several questions. We covered high level thinking around color usage and iconography to convey urgency and differentiation of DS disconnect messaging, as well as urgent vs informational type notification behavior and display preferences.
We provided participants with A/B/other interactive mockups and static images to examine before asking them to indicate which approach best fits their perception of appropriate styling (color, iconography), layout, and location as relates specifically to DS Disconnect messaging, as well as urgent/non-urgent notifications in general.  We also elicited their open feedback on communication methods outside the web application, and regarding Spotlight Cloud as a whole and notifications in general.
Why we did it:
To ensure we release the Urgent Notification and DS Disconnect features inline with users' expectations and preferences around how they view THEIR connections vs. Quest connections.
To verify whether Magenta is an appropriate choice to differentiate DS-connection notifications from customer connection-related alarms and heat map tiles.
What we found:
That our users want and expect to easily distinguish between different types of connections (theirs, ours) and between connection issue severity (any connection), and that color was their preferred method of doing so. Participants also wished to be shown the most urgent notification iconography at any given time, falling back to informational (blue) in the absence of urgent notifications.
What we recommended based on the research:
Introducing / keeping a new color (vivid magenta) to distinguish DS connections (ie. quest software connections) vs user connections, and to differentiate urgent notifications from non-urgent information notifications. 
Adding an additional format for timestamps on DS disconnect notices: time elapsed since data visibility loss.

Prioritizing SMS text messages as the first-released method of alerting users to DS disconnect events, as it had the most support by far among the provided method options.
WHERE notifications should manifest
WHERE notifications should manifest
colors and shapes
colors and shapes
marketing notifications
marketing notifications
connection notifications
connection notifications
Connection Management panel options
Connection Management panel options
connection list and snackbar style, placement, color
connection list and snackbar style, placement, color
Badge element on Notifications header entry point
Badge element on Notifications header entry point
Case Study:
Evaluate our workflow for configuring email notifications.

We wanted to test a proposed workflow and discover:
Will the users find the feature in the UI?
Does the number of interactions required fit their need for efficiency?
Are we providing the right feedback throughout the flow?
How are they and their organization using notifications today?

This project involved a matured concept design, initial prototype and revised protoypes for testing, a moderator guide, recruiting for the study, conducting the moderated testing sessions, analyzing session videos and notes, affinity diagrams, ROI plotting and providing the research-backed recommendations.
Research Process Summary:
What we did:
Our clarified research goals led to participant and question selection.

Usability testing notes were culled into observations per participant, then clustered into groups in affinity diagrams to surface themes.
Themes were distilled into specific recommendations, which were then prioritized through role-based perspectives (design & product, architecture initially, to be followed by development, support, test, and sales.)
Top 5 recommendations were mapped on a grid with axes of Difficulty and Impact to help visualize the best balance between the two when determining sprint sequencing
UX Story: Feature fit for user's mental model on upcoming Reports functionality
We needed to be sure that when we launched our embedded reports feature that it met with success by accommodating our users' mental model of what reports should do for them in the context of DPM.  
In addition to some informal questions asked at the end of some moderated testing sessions with our end users on other topics, we conducted a survey specifically around this topic.   This research allowed us to confirm what was expected as table stakes and to prioritize each aspect of functionality based on USER NEED as well as the complexity and cost to develop, test, release and maintain.
One Identity
As time went on and leadership attitudes towards usability testing changed, I moved to a different product from a company Quest had acquired: OneIdentity.   Now I'm working with a fellow UX designer to translate a well-loved and much used thick client to a web-based application, while introducing new features and mixing up some elements to produce new SaSS offerings.

The product is called Safeguard for Privileged Passwords, a Privileged Access Management industry tool that pairs with its sibling, Safeguard for Privileged Sessions.

Task Management
Tasks in Safeguard are created by the user's actions, and ideally are clearly called out when triggered, as they progress, when they've completed or been interrupted, and otherwise get out of the user's way.   The thick client has had them, but the web client is where we can truly optimize them.
Types of tasks vary greatly, and depending on the type of user they may do more of one type than another. For instance, one user might routinely check and change the passwords for the accounts, assets or end users under their care.  Organizing tasks by type might help one user, but laying them out by date/time might better fit someone else.    If users are working in batches of tasks, being able to clear ALL the successful or completed tasks in a single click may prove vita. These videos show some exploration of these topics.
User Management
[Users] are both a focus of design and development as "primary users" in Safeguard, ie. those that use the product to administer assets, accounts, partitions, etc.  AND users are also the 'end users', ie the ones that request passwords or sessions in the sense of PAM (privileged access management.).   
User management in Safeguard refers to our primary users managing the user identities of the end users, either one by one, in batch operations, or in the guise of user groups - where a single action can cascade across the enter group of users.
Making user management easier, more efficient and more intuitive is a prime focus for us at OneIdentity. These videos show some thinking in motion.
Back to Top