Pain and trust in decision support
UX Research Internship
Cloud Platform Business Unit, VMware Inc.
Summer 2015
Methods
Service design, interview, observation, focus group, experience map
Challenge
Offer established server administrators solutions that automate some of their decision-making, and convince them that these automations are trust-worthy while retaining their sense of control, security, and owenership.
Background
VMware's Central User Experience group is tasked with defining, designing and validating the user experience for a range of VMware products. In the summer of 2015, I interned for Kathryn Murrell's team, which was responsible for the Software Defined Data Center (SDDC), including vSphere Suite, vRealize Suite, vCloud Air, Site Recovery Manager, and VSAN.
A key issue encountered in the early stages of design was how advanced users of VMware's datacenter management products would perceive or accept solutions proposed, recommended, or enacted by these automated systems. Before server administrators could be convinced to try them out, we needed to understand their concerns and considerations. To help with this process, I created a model for user trust that could be used to situate discussions and seed designer understanding of this issue.
Research
I conducted several interviews, sat in on a number of design meetings for an as yet unannounced product, and observed a blind focus group session with over a dozen high-level system administrators who discussed desirable features of virtual server management software and their challenges with it.
The Pain-Trust model
I used an experience map-like visualization to illustrate the stages of the trust relationship between a server administrator and an automated agent. Like an experience map, my model had a graphical representation of all stages of a process that includes user touchpoints, thoughts, feelings and action.
Unlike a traditional experience map, in which the X axis represents the chronology of a journey from pre- to post-execution, my X axis represented the relationship between a user and the system along a continuum of trust: from a cool, cautious interaction through a slow warming to a sense of reliance on the system and justified trust in its actions:
- Monitor: The system passively monitors the server and offers information only when queried. The administrator queries and interprets the data.
- Notify: The system is trusted to interpret patterns and issues timely alerts. Only the administrator takes corrective action.
- Gather: The system proposes a range of solutions, including newly available cloud services. The administrator selects one.
- Decide: The system selects a solution and the administrator confirms it. Trust is strengthened by a match between the administrator's solution and the one recommended by the system.
- Act: The system implements its best solution and notifies the administrator. Undo and a full refund are available if needed.
- Automate: The system manages the server, while the administrator can monitor, audit, and override any decisions it makes.
The model proposed that all software solutions exist somewhere along this continuum between Pain (effort, responsibility, autonomy) and Trust (automation, decision support). With users such as server administrators, who have typically been reticent to lose control over their servers, the relationship must start with a low level of commitment, and the product must build trust slowly over time, understanding that there is an optimal balance of trust and autonomy for every user and service.
Quotes in red represent challenges the user is struggling with at each stage of the relationship, while quotes in green indicate the desired outcome in case of a sound intervention on the system's part. The headings above the chart indicate the actions taken by the system at every stage, while the verbs in the Trust section describe the system's role in fostering the trust relationship with the user. Product-specific details have been omitted from the map.
The model proved robust and illustrative. Each SDDC product could be situated in one of its columns, and the difference between their current level of trust and the one they desired to achieve was clearly represented. This type of experience map is a tool for aligning the findings, goals and expectations of researchers, designers and programmers on an interdisciplinary UX team.