A proposed UX strategy for a data security product. This document lays out UX design ideas, research ideas, and supporting activity content.

1. UX Strategy
CA Data Content Discovery FY19
Leslie A. McFarlin, Sr. UX Architect
EDP Value Stream
1

2. Table of Contents
Introduction Slide 3
Support Shifting to Automation Slide 6
Strengthen Information Presentation Slide 26
Create a Product Narrative Slide 33
Advance Ongoing Usability Efforts Slide 37
2

3. Introduction
This document outlines a UX strategy for Data Content Discovery (DCD) for the
2019 fiscal year.
UX strategy arises out of feedback from product stakeholders, customers, and
recommendations from assigned UX resources.
Each fiscal year, UX strategy will be revisited and revised to ensure support for
changing business goals and customer needs.
3

4. Introduction
FY19’s UX Strategy contains 4 objectives.
1. Support shifting to automation.
2. Strengthen information presentation.
3. Create a product narrative.
4. Advance ongoing usability efforts.
Where appropriate, wireframes will depict examples of solutions.
** Wireframes illustrate the concept, not the final design direction, and may not use the exact icons, fonts, and colors from the product.
4

5. Introduction
Based upon the items in this UX strategy document, two long-term goals for
DCD have been defined:
5
Positively Motivate DCD Usage Help Users Build Trust in DCD
By demonstrating to users that DCD
can help them achieve key tasks in
their data security plan, they will…
...willingly use DCD as intended.
...explore its fit for the future.
By consistently providing valuable
support to users as they perform tasks,
and by providing accurate and valuable
data as the output of those tasks, users
will…
...explore other ways to apply DCD.
...advocate for DCD use.
...collaborate on future feature work.
MOTIVATION → USE → TRUST

6. Support Shifting to Automation
6

7. Initiative Overview
Based upon customer feedback, DCD is shifting from manual activities to
automated activities.
Automation forces a shift in user engagement in terms of what users do,
when they do it, and how.
UX work must support the user through these changes to mitigate the
psychological trade offs automation introduces into workflows.
7

8. Where Does Automation Occur?
8
Autodiscovery Autoscan
● Acts as a user-directed spotlight on
mainframe data.
● Provides an overview of the mainframe data
landscape.
● Populates the data set repository that fuels
Autoscan.
● Policy-governed scanning that executes
based upon a combination of time and
importance.
● Policies may generate one or multiple scans,
though users may still manually create scans.
● FUTURE: Users may provide input on
individual match results to DCD.

9. Automation and User Engagement
Automation reduces cognitive load by performing two types of tasks:
1. Highly repetitive tasks.
a. High user engagement, low cognitive effort- users have to perform every aspect of a
task, but their performance declines over time due to boredom causing a loss of vigilance.
2. Cognitively complex tasks.
a. High user engagement, high cognitive effort- creates mental fatigue because of
sustained mental engagement.
9

10. Automation and User Psychology
Regardless of the automation implementation, users can exhibit any of the
following:
10
Automation Bias
Believing that a user should
not question the output of an
automated system as it can
do the job better than they
can.
Automation Complacency
Ignoring output of an
automated system because it
has a track record of
accuracy.
Automation Irony
Inability to return to evaluate
an automated system’s output
because automation has
enabled a user to engage in
other activities.

11. Automation Bias in DCD
Automation bias will become most evident when requiring input from users.
Users exhibiting automation bias defer to the judgments of the algorithm,
discounting their own knowledge and judgment.
A second form of automation bias exists: Refusing to use automated features
because of the perception that the automation is limited.
This could also appear, but results from either a failure of the product to
produce useful output, or from a mix of other cognitive biases acting on
the situation.
11

12. Mitigating Automation Bias
Automation bias arises from a misunderstanding of automation within a
product, specifically what are its limitations.
Two debiasing methods can be applied to counteract automation bias:
Education, informing users on the strengths and limitations of
automation in DCD.
Nudges, defaulting to a recommended response with supporting
information for the default.
12

13. Debiasing through Education
Educating users on the intended use of automation within DCD will erode the
foundation for automation bias.
Narratives to demonstrate use cases can serve as educational tools.
UX and Information Engineering have a cross-functional group developing best practices
for narrative strategies.
In-application content and help documentation can also educate users.
UX and Information Engineering are already working toward a content strategy for
delivering supplemental information.
13

14. Debiasing through Nudges
Nudges direct users to an ideal response, but still allow them to choose
something different.
Successful nudges pair an ideal response with supporting information.
Engineering, UX, and Information Engineering need to work together to determine:
Lists of possible responses
When to default to a particular response
How to access supporting information
How to communicate supporting information (depth of explanation, tone)
14

15. Nudge Example: Recommended Defaults
15
Recommended defaults
based on match levels for
agreement and actions
Access to
reasons for
recommendations

16. Nudge Example: Supporting Information
16
Visual cues for which row
the user is viewing.
Presents the match level
with the reasons why.
Presents the
recommendations and
the reasons for them.
Note that the reasons
indicate the product
owner can influence the
recommendations via the
scan policy.

17. Automation Complacency in DCD
Automation complacency will also appear once DCD requires input from users
on match results.
Automation complacency usually has a pattern:
Users are engaged with the feature.
Use lessens over time once some internal criteria for behavior is met.
Use picks up again once something unexpected occurs.
17

18. Reducing Automation Complacency
Automation complacency results from automation consistently producing
acceptable results.
Complacency indicates overreliance, misuse due to users’ inattention.
Education can discourage overreliance, but it is not enough because it does
not encourage behavioral change from the user.
Mechanisms for prompting engagement and shaping actions need to be
designed into DCD.
18

19. Prompting & Shaping Example
19
Soft prompt example:
Hard prompt example:
Indicates the scope of information
needing evaluation.
Provides users a way to go
directly to the items needing
feedback.
Messaging clearly indicating the importance of obtaining
feedback.

20. Automation Irony in DCD
Autoscan will be the primary cause of automation irony in DCD:
Autoscan eliminates the need for users to set up individual data scan,
instead requiring a one-time policy creation in order to execute 1 or more
scans.
Automation irony arises from a predictable internal process:
As users learn to trust an automated feature, they will disengage from it,
and focus their attention elsewhere. Returning to the feature becomes
difficult over time due to the change in focus.
20

21. Addressing Automation Irony
Automation irony arises because the automation was designed correctly for
its intended purpose.
Automation irony is a symptom of a busy work environment.
Reducing automation irony follows the same design principles for reducing
automation complacency (prompting and shaping).
Environmental factors are harder for UX to directly impact, making it
harder to design solutions for automation irony.
21

22. Addressing Automation Irony
To increase the odds of successfully combating automation irony, DCD can
add extra functionality:
Email alerts triggered by a time threshold for items needing user input.
Reporting on required user inputs (response counts per sensitive data
type, rate of response).
Any additional features for reducing automation irony should help manage
the user input workflow.
22

23. Prompting & Shaping for Automation Irony
23
Language resembles the hard prompt example:
● “requiring”, to convey the necessity of feedback.
● “critical to maintaining accuracy”, to indicate usefulness
of the feedback.
Banner cannot be closed, and will remain sticky
at the top of all pages until the user clicks the
‘View Items’ link.

24. Email Alerts Example
24
Email alerts can be set according to a time threshold in a
location such as System Settings, or even within individual scan
policies.
Multiple email contacts for providing input
can be set along with the time frame for
email alerts.
**This example assumes email addresses for
users (Autoscan Policy Creator, DCD
Administrator) are held somewhere in the UI. This
is one option for an email alert feature, but not the
only one.

25. Reports Example
25

26. Strengthen Information Presentation
26

27. Initiative Overview
Content strategy is needed to address multiple content issues in DCD.
Feedback from user testing and insights from a heuristic evaluation have
identified 3 major opportunities:
1. Improving the quality of information within DCD, specifically the
information architecture and terminology used.
2. Adding supplemental information to the UI, such as tutorials and
contextual help.
3. Evaluating the tone of in-application communication.
27

28. Improving Information Quality
As DCD adopts more automation, information content within DCD needs to
change in the following ways:
1. Terminology must shift from indicating manual activities, to signaling
automated activities.
2. Messaging should prioritize plain language over technical language.
3. Information architecture should prioritize major functionality that
supports the intent of the product over secondary functionality.
28

29. Improving Information Quality
Multiple initiatives are needed to address the issue of information quality in
DCD:
Content analysis to address feedback on terminology and messaging
from the recent usability testing and heuristic evaluation.
Card sorting, for creating a useful and usable information architecture
(navigation structure, classifier categorization).
29

30. Adding Supplemental Information
Automating features leads to less user engagement, which means users have
less opportunity to learn how the product functions.
Less knowledge about function makes it easier for users to make errors,
and harder for them to recover from errors.
Supplemental information within DCD serves two purposes:
1. Stop errors before they happen.
2. Enable error recovery.
30

31. Adding Supplemental Information
Tutorials and contextual help need to be monitored periodically via user
testing for depth and fidelity.
Depth refers to level of detail- overcomplication provides too much
detail, while oversimplification does not provide enough. Both leave
users unable to build an accurate mental model of the product.
Fidelity refers to accuracy of detail- low fidelity creates
inaccurate mental models, which ultimately lead to lower user satisfaction
and underutilization when the product does not function as expected.
31

32. Tone of Communication
Tone of in-application messaging conveys attitude, and it influences how
people think about products and use them.
Automated products must pay special attention to tone in the following
circumstances:
Learning and recovery- users respond better to content with an
encouraging tone when they are learning or resolving errors.
Prompting user interaction- where user input is required for the output
of automated tasks, persuasive language can motivate users.
32

33. Create a Product Narrative
33

34. Initiative Overview
Product narratives serve multiple functions for DCD:
1. Demonstrate product capabilities to new and existing clients.
2. Educate users on how to use the product. [Related to reducing
automation bias.]
3. Provide an internal rallying point for product development.
4. Support the development and maintenance of personas.
UX is currently working with Information Engineering resources to determine
best practices for creating narratives.
**An example of successful narrative creation is from DCD’s “flashy demo”.
34

35. Implementing a Narrative Strategy
35
Phase I
Gather Stakeholder Perspectives
Phase II
Write & Refine
Phase III
Finalize & Release
Identify and interview internal
stakeholders for their insights on
what they are trying to solve, and
for whom.
Stretch goal: Identify and interview
customers for the issues they need
solved, what they expect from the
product, and who would be using
the product for those issues.
Based upon feedback, identify the
key issues and draft narratives for
each.
Validate narratives internally.
Validate narratives externally.
Adjust narratives based upon the
feedback from validation sessions.
Begin using the narratives
internally among the product
teams, and externally with
customers.

36. Current Progress: Phase I
Narrative strategy is a newer concept at CA, and the intent is to use DCD for
setting the standard on implementation.
In-progress items for Phase I include:
● Finalizing interview questions.
● Obtaining additional interview resources across multiple time zones.
● Finalizing available interview time slots.
● Stretch goal: Identifying customers who could potentially give feedback.
**Please come see Leslie for detailed documentation on narrative strategy at CA.
36

37. Advance Ongoing Usability Efforts
37

38. Initiative Overview
Customer feedback and internal reviews have led to the creation of many
stories for usability improvements that cover content and interaction design.
For details on feedback, see the usability testing report and heuristic
evaluation report.
Product Management, UX, and Engineering must work together to match
business objectives with prioritized UX findings to address usability items in
the backlog.
UX will recommend a schedule of activity to monitor product usability.
38

39. Usability Evaluation Program
As DCD customer adoption improves, more opportunity for customer
validations will present themselves, making this an opportune time to propose
a UX research program comprised of:
● Formative and summative usability testing.
● Inspection methods, such as heuristic evaluations and cognitive
walkthroughs.
● Inclusion of metrics (industry-standard metrics) and development of
custom metrics to baseline the product experience and users’ attitudes
and perceptions.
39

40. Formative and Summative Usability Testing
Usability testing reveals issues that might otherwise go undetected before
users begin interacting with features.
Formative Usability Testing evaluates smaller chunks of a product and
may not include metrics.
Summative Usability Testing considers the larger product and is more
formal, involving metrics and requiring a more detailed analysis.
Both leverage participant screening, task analyses, and retrospective
questioning.
40

41. Inspection Methods
Before conducting usability tests, inspection methods can be conducted to
identify any obvious usability issues and resolve them.
Inspection methods involve usability experts and/or product team members
walking through a product and evaluating it against dimensions of usability.
Cognitive walkthroughs pair usability experts and product team
members in a walkthrough of individual features.
Heuristic evaluations require a minimum of 2 usability experts to
evaluate a product against usability principles.
41

42. Inclusion of Metrics
Metrics provide an easy way to summarize subjective perceptions and
objective measures of usability.
Several industry standard metrics exist that may apply to evaluating
perceptions of usability.
UX will work with product management to decide which metrics meet
DCD’s needs.
Custom metrics will be created to assess users’ attitudes and perceptions of
EDP products.
42

43. Inclusion of Metrics: Custom Metrics
To begin with, a Semantic Differential Scale (SDS), will be created based upon
how product management hopes for EDP products to be perceived by users.
Product management will receive a request to participate in a multi-part
research activity to inform SDS creation.
SDS can assist with improving motivation for DCD usage, as well as acceptance
of DCD within our customers’ work environments.
** To learn about the SDS, visit this site: https://www.fieldboom.com/semantic-differential-scale.
43

44. Improving Design
DCD currently follows the outdated EDL design style, which includes a mix of
interaction design patterns and visual design recommendations.
Within CA’s design community, an effort is underway to standardize
interaction design patterns, but the visual design standards have proven
more challenging.
Visual design experts within the EDP value stream are working on a style guide
to provide a vision for the look and feel of EDP products going forward.
For style guide inquiries, please reach out to Mauricio Silva.
44

45. Appendices
Supporting Content to Main Sections
Future Workflows
User Motivation
Technological Trust
45

46. Future Workflows
Feedback from DCD Product Owners highlighted 2 major workflows related to
the automation support objective:
Reporting, the summary and analysis of policy-related findings.
Remediation, the pathways to remain compliant with data security
regulations.
To maximize usefulness, reporting workflows should link to remediation
workflows.
46

47. Reporting
As a long-term goal, DCD reporting will transition away from summarizing
scan matches to presenting opportunities to improve sensitive data security.
Example wireframes for a regulation-based (PCI-DSS) report created in
2017 can be found here.
Existing wireframes can be evaluated for fit, and then reworked as necessary
before being validated with customers.
** A clickable prototype based on the wireframes linked above was created by a former team member, but the location of that file is
unknown.
47

48. Remediation
Remediation in DCD could allow deletion, archiving, securing, and encrypting
based upon scan results.
At the moment, understanding how the data can be acted upon via DCD
presents a challenge for determining the user flows for each activity.
To begin designing and validating a solution, UX will need the following for
each activity:
Permissions Potential system errors Any limitations by data source
Any external programs needed to complete remediation flows.
48

49. User Motivation
For product use dictated by the work environments, motivation tends to be
driven by external forces (extrinsic motivation).
Externally-motivated actions fall into two categories:
Compliance activities, performed to avoid punitive measures.
Willing activities, performed because of perceived benefits.
For DCD, we should focus on building willingness to use, as it offers users the
greatest benefits.
49

50. User Motivation: Compliance vs. Willingness
Compliance actions can result in underutilization as users do just enough to
avoid punishment for inaction.
For DCD users, underutilization risks failure to comply with data security
regulations and data breaches.
Willingness actions lead to intended use, and exploration of how to use
beyond what was intended.
Marks user acceptance and recognition of the technology’s benefits.
50

51. Technological Trust
Users develop technological trust through demonstrated benefits of use.
Use requires motivation to start, and motivation to persist.
Via continued use, users progress from rules-based trust to knowledge-based
trust.
Rules-based trust focuses on risk-benefit ratios: If benefits outweigh risks,
usage will continue. If not, usage ends.
Knowledge-based trust focuses on understanding what the product
delivers, and how: More knowledge can make it harder to lose trust.
51

52. Technological Trust: Knowledge-Based Trust
Knowledge-based technological trust builds in two ways:
Knowledge of the maker (CA)
Knowledge of the product
Strategic narratives provide direct knowledge of the product through the use
of accurate task scenarios.
Well written narratives create the impression that the maker is
knowledgeable and cares about their customers.
52

53. Thank You!
53