generated from jhudsl/OTTR_Template
-
Notifications
You must be signed in to change notification settings - Fork 0
/
03-lessons_from_user_designers.Rmd
158 lines (105 loc) · 10.8 KB
/
03-lessons_from_user_designers.Rmd
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
---
title: "Lessons from User Designers"
output: html_document
---
```{r, include = FALSE, echo = FALSE}
ottrpal::set_knitr_image_path()
```
# Lessons we should borrow from user designers
```{r, fig.alt="Learning objectives This chapter will demonstrate how to: Understand good documentation increases the impact and usability of software tools. Understand good documentation is helpful for both tool developers and users.", echo = FALSE}
ottrpal::include_slide("https://docs.google.com/presentation/d/1PH9_KlLVggYpNJI0fgvcIcft2vDtGA_mlCqKFA8gnAg/edit#slide=id.gd422c5de97_0_24")
```
## Thinking about user-centered development
Creating tools that are easy to use starts with thinking about your user's perspective.
In other words, user-centered design is an exercise in applied empathy [@deMatos2013].
This is why a common saying in user-centered design is "You are not your user" [@Alexakis2017]. Although it may be true that you may have a lot in common with your user, this saying is based in the idea that you should not assume your user knows what you know or thinks like you do. For example, a warning message that may seem perfectly clear to you as a developer, may be a foreign language to your user.
```{r, fig.alt="Tina the Tool Developer and Uri the Tool User both are looking at Tina’s tool that has error written all over it with a warning sign. Tina says These error messages tell me exactly what I need to know and everything is working as I intended! But Uri the Tool User says I don’t understand what I’m doing wrong these errors are unintelligible to me!", echo = FALSE}
ottrpal::include_slide("https://docs.google.com/presentation/d/1PH9_KlLVggYpNJI0fgvcIcft2vDtGA_mlCqKFA8gnAg/edit#slide=id.gcd0e3791ab_0_0")
```
^[For all cartoons:
Avataars by https://getavataaars.com/.
Icons by https://thenounproject.com/ License CC BY-NC-ND 2.0.
Emojis by OpenMoji License: CC BY-SA 4.0.]
As compared to yourself, your typical user may likely have a different:
- Educational background.
- Programming experience level.
- Set of motivations for using your tool.
And most importantly _your user does not know your tool like you do_! You have spent many, many hours developing this tool and its unrealistic and impractical for them to spend the same number of hours with your tool that you have.
```{r, fig.alt="Your user does not know your tool like you do!", echo = FALSE}
ottrpal::include_slide("https://docs.google.com/presentation/d/1PH9_KlLVggYpNJI0fgvcIcft2vDtGA_mlCqKFA8gnAg/edit#slide=id.gd228cc29d1_0_146")
```
Also keep in mind users are humans in a context. Humans have demands in their life, have been working long days, and are tired/frustrated/distracted/etc. Making your tool as easy as possible to use increases the likelihood of your user continuing to stick with your tool and even becoming an advocate for your tool to their colleagues!
### Generalities about bioinformatics tool users
On a general level, there are some characteristics we know about bioinformatic tool user communities.
The typical user of bioinformatics tools are generally:
- Highly educated in their specific research topic.
- Skilled at picking up new information.
- Unlikely to have extensive experience in programming; may be uncomfortable with using command line.
- If they do have experience programming, it's likely been from informal and self-taught learning.
- Like many professionals, likely to feel time pressure from deadlines.
However, the bioinformatics user community also includes a variety of individuals with different roles and experiences.
@Mulder2018 described 10 user personas for bioinformatics software, all with their own skills and competencies:
- Physician
- Lab technician
- Ethicist
- Biocurator
- Discovery biologist/academic life science researcher
- Molecular life science educator
- Academic bioinformatics researcher
- Core facility scientist
- Bioinformatician in an academic or research infrastructure support role
- Bioinformatics software developer/software engineer
Additionally, users may be at various stages in their education (undergraduates, graduates, postdocs, etc) and may have varying experience and time constraints.
## Exercise: Think about the user community for your tool
Write down what you know (or think you know) and try to identify any knowledge gaps you might have about your user community.
- Who is your user community?
- What need of theirs is addressed by your tool?
- What kinds of skills does your tool assume your user has (does your user community have those skills)?
Keep the questions about your user community in mind and in a [later chapter](https://jhudatascience.org/Documentation_and_Usability/obtaining-user-feedback.html), we'll go into more detail about conducting user research to address any knowledge gaps you may have about your user community.
## General principles about user-friendliness
While finding out about your user community is critical, there's also principles we can discuss that are common to all users/humans.
#### Humans like visuals
Humans are drawn to intuitive visuals. Visuals are efficient means of communication and help users absorb information better than long-winded paragraphs (though visuals need an accompanying explanation too).
Sometimes this is particularly helpful for complicated concepts. For example, BEDtools (@Quinlan2010) allows for the manipulation of genomic sequences in BED files. Some of these principles can be complicated to visualize, but the authors of BEDtools do a great job of using visuals to explain each function:
```{r, fig.alt="BEDtools has nice visuals with their documentation that help explain complicated subject matter. In this figure they’re showing how ranges are merged together. ", echo = FALSE}
ottrpal::include_slide("https://docs.google.com/presentation/d/1PH9_KlLVggYpNJI0fgvcIcft2vDtGA_mlCqKFA8gnAg/edit#slide=id.gcd0e3791ab_0_44")
```
Here, this figure explains how the merge function works given a particular set of ranges.
#### Stay away from jargon
What someone considers jargon is a very relative to their own experiences. Terms that may seem like common knowledge to you may be foreign to your user.
For example, something seemingly commonplace to you like `TSV` may be something a user does not understands what it means. To help smooth over jargon-related barriers, spell out abbreviations the first time you mention them (e.g. 'tab separated values (TSV)'). This doesn't mean you have to have long winded explanations of every term, instead you can quickly link out to an article or website with information about a term you've used (e.g. [tab separated values file (TSV)](https://en.wikipedia.org/wiki/Tab-separated_values)). This has the benefit of saving you and your user's time without making your explanations too long winded.
#### Navigability: Make help easy to find
When your user has a question in mind, it can make their experience a lot more stress-free if they can find their answer with ease. Its not always obvious to a user where you have put an answer to something, particularly if user is already frustrated; deep in the troubleshooting trenches! For these reasons, navigability is important for your tool and documentation.
_Quick tips for increasing your tools' navigability_:
- Minimize the number of clicks for finding help!
- The more important a piece of information is to a users' ability to use your tool, the more it should be in the forefront of your tool!
- Patterns are super helpful! Be consistent about where to find things. Once a user has caught on to your pattern of how you store things in your tool, don't switch it.
- Use visual cues where possible!
##### Use reading patterns to your advantage:
Even if you try to make your text succinct and lean on visuals where possible, there will still be instances where you may inevitably require large chunks of text.
Large chunks of texts are hard on your user, especially if they are trying to scan the information for something in particular.
To help these chunks of text be less cumbersome, utilize reading patterns:
Described in this [useful article @Soegaard2020](https://www.interaction-design.org/literature/article/visual-hierarchy-organizing-content-to-follow-natural-eye-movement-patterns), humans' eyes are drawn to items based on:
>
- Size: Larger elements will dominate and catch eyes first.
- Color: Bright colors catch eyes ahead of muted, drab ones.
- Contrast: Stark differences between elements draw eyes to the brighter one.
- Alignment: Users expect to find certain elements in the same place.
- Repetition: A repeated quality (e.g.,colored parts of text) draws the user’s eye.
- Proximity: Putting related elements (e.g., header with associated text) close together means these are related.
- Whitespace: Including whitespace around elements singles them out as separate groups of information.
- Texture and Style: Using distinct textures/styles (e.g., chunky, military-style buttons) draws the eye while setting the theme.
Based on this, human eyes will scan a website's page in Z or F pattern [@Soegaard2020].
> The Z Pattern — In designs without much text, our eye starts scanning from top left to top right, then diagonally down to bottom left, stopping at the bottom right.
> The F Pattern — In designs with more text, we scan across the top, from left to right, then down the left, searching for clues to what we want to know. On finding one, we’ll scan across to the right.
For more details on these patterns and how to implement them with your own content, read more:
- [About natural eye movements](https://www.interaction-design.org/literature/article/visual-hierarchy-organizing-content-to-follow-natural-eye-movement-patterns) by @Soegaard2020.
- [About "F" patterns](https://uxplanet.org/f-shaped-pattern-for-reading-content-80af79cd3394) @Babich2017.
More about user-friendly principles in general:
- [Principles of User Interface Design](http://bokardo.com/principles-of-user-interface-design/) by @Porter.
- [Golden Rules of UI Design](https://xd.adobe.com/ideas/process/ui-design/4-golden-rules-ui-design/) by @Babich.
- [About intuitive layouts](https://www.oreilly.com/library/view/designing-interfaces/0596008031/ch04.html) by @Tidwell.
#### Provide a method for users to file concerns
No matter how much you have perfected your tool, it will never be perfect, especially since software deprecates over time. Because of this or other [unknown unknowns](https://uxdesign.cc/the-knowns-and-unknowns-framework-for-design-thinking-6537787de2c5), a usable tool still has a way for a user to let the developers know when something isn't working. This might be a direct and obvious break like a bug or broken link, but it could also be something more subtle that also requires your attention.
We'll discuss this in more detail in a [later chapter](#obtaining-user-feedback).
Now that we've discussed some major principles about users and design, let's dive in to talking about how documentation can help!