What can the fields of UI/UX teach scientists?

Web developers and programmers have a lot riding on the quality of their product. If it behaves in an unusual manner, it’ll frustrate users. If it’s unattractive, it won’t attract users. If it’s no good, it will lose users. Users are the primary concern. Consequently, there are fields dedicated to this concern: User Interface (UI) and User Experience (UX).

Because web developers and programmers have a much wider potential audience than scientists, they have a better handle on the importance and behaviour of the end user. Scientists could learn a thing or two about UI/UX.

Although, as scientists, we want to produce good, attractive work in a familiar form, we have minimal imperative to do so. A primary goal is to get our work published, which involves getting it vetted by two or three other scientists during peer-review. After that, the work is out into the world. The only real feedback after this point is whether the work is cited, which is hardly a proxy for whether the work is well presented and easy to understand. Sure, peer review is a high bar, but imagine if the testing phase for other products involved only two or three people?

What is UI/UX?

Search ‘UI/UX’ and you’ll find no end of debate on how to define and distinguish the two fields. Such nuance is unnecessary here. It’s enough to remember that both UI and UX include ‘User’. Both fields are a mix of deterministic rules, empirical discoveries from psychology, and subjective recommendations. There’s an experimental ingredient to much of it, though practitioners of UI/UX seem to have an inflated sense of its rigour given how many rules of thumb are termed ‘laws’: Fitt’s Law, Jakob’s Law, Law of Proximity, Law of Similarity, Law of Prägnanz.

Bad UX is memorable. Good UX is hidden. It’s like appreciating a comfortable pair of shoes only after wearing an uncomfortable pair, or forgetting that referees in a sports game are doing their job well until they make a bad call. Ever been tricked by one of those doors that has a handle to pull despite a sign saying to push? That’s bad UX illustrated by one of the simplest of technologies. (Such Norman Doors are named for Don Norman, a key figure in the development of UX principles.)

How to apply UI/UX to scientific papers and talks

Go to lawsofux.com and read their 20 laws. Take particular note of their takeaways. Going through their list will take mere minutes, but covers so many of the basic tenets of good design. For many of the laws, there are obvious parallels between building a user interface and presenting a scientific work. I’ll elaborate on a few below.

An underlying theme from Laws of UX, and one certainly applicable to science, is to develop a simple, intuitive, and accessible experience for the user.

Unfortunately, it is difficult to get in the mindset of your reader or audience. It requires forgetting about the science you’re presenting. Consider how a website developer, for example, can’t rigorously test their own product. They know where to expect all the buttons and menus they’ve placed, how long to expect pages to load or processes to take, and how to navigate between different parts of the site. It would be like illustrator Martin Handford looking for Wally (Waldo to North Americans) after having just drawn the picture himself.

You know each bit of context for each bit of your research, but your audience does not. So you need to continually make this context evident. Instead of just developing figures to display data, ensure they convey insight. Instead of using tables as a place stash trivial details, construct them to enable the reader to infer patterns and relationships. Instead of merely writing figure captions that describe low-level details, include an opening sentence that encapsulates the figure. Instead of writing a paragraph that focuses on a figure, ensure your reader recognises the point of the paragraph.

On a related note is dogfood. Actually, its verb, dogfooding. It’s a term used in UX (and elsewhere) to refer to using your own product as a proxy for real-world testing. In science, this might equate to scrutinising your own manuscript draft. But a post on HackerNoon describes why dogfooding is not enough. It is aptly summarised by the commenter with the fitting username “science”: Dogfooding is enough if you want to be your only customer.

The comment is especially true if you’re eating your own dogfood wrong. Are you simply reading your draft start to finish? That’s not how everyone will be reading it. There are the tired readers only skimming the text. There are the readers who start with the conclusions. And there are people not even reading, but merely glancing at the figures to see if it piques their interest. Think about how your paper appears to these readers.

Reading a scientific paper is a multitude of experiences

Good UX addresses all of the unstated components of an experience. Think about going to a restaurant. Obvious parts of the experience are how good the food was, how friendly the server was, and the total cost. But other little things can undermine an otherwise good experience. Was it hard to find a place to park the car? Were there awkward gaps between different meals arriving? Was it hard to get the bill or the server’s attention?

In a scientific paper, spelling and grammar mistakes should be minor annoyances, yet they undermine our confidence in the rest of the results. We’re all familiar with this point and often go to great lengths to avoid typos. Less appreciated, however, are other minor yet important aspects. Remove redundant labels from multi-panel figures. Use correct characters rather than easy replacements (a hyphen isn’t a minus sign). Take care in whether or not you should be using italics. Just generally pay attention to detail.

Although I’m implying somewhat that each bit of a paper or talk is important, a good ending is even more so. Known in UX as the peak-end rule, people disproportionately judge an experience by how they felt at the end of it. Ever purchased something online expecting to pay a certain price, only to have unreasonable extra fees added at the end? This example of bad UX, also known as a dark pattern, is obviously intended to get the seller the most money. Of course, it runs the risk of losing a repeat customer or the sale itself.

As scientists rather than sellers, we have no such conflicting motives in providing a positive ending. Yet our endings are too often cliche, uncompelling, or they just, like, you know, kind of tail off until it sort of, I guess, becomes apparent that, well, we’re at the end because that’s all there is.

Attractive things work better

“Users often perceive aesthetically pleasing design as design that’s more usable”. That’s the description of the first law at Laws of UX. Applied to science, that could imply that pretty graphs and elegant schematics are indicative of sound science. I’m guessing that’s an unpopular opinion among scientists judging by a question at Academia StackExchange: Do academics look down on well-designed academic websites?

Can something looking pretty really alter its function? Yes, according to Don Norman (the door guy mentioned earlier): Attractive things work better is the subtitle of his post Emotion & Design. Just so we’re clear, this is a guy who cares about function over form. For example, he considered the introduction of colour to computer displays as unnecessary and didn’t initially understand their popularity. Indeed, he recognises that his conclusion about attractive things may be heretical. Nevertheless, he notes that there is evidence that pleasing things work better, are easier to learn, and produce a more harmonious result. And further, that when people are in a relaxed situation, the pleasant, pleasurable aspects of the design will make them more tolerant of difficulties and problems in the interface.

If you’re submitting a paper for review or giving a presentation, the outward appearance of the work can alter, consciously or subconsciously, opinions about the underlying science. If the appearance is rough, it can imply that the science is unfinished or poorly executed. Haphazard slides resembling a kid’s scrapbook, for example, suggest you put together the talk at the last minute. Simple slides, by comparison, imply better preparation despite containing less content.

About complexity: Hick’s Law and Tesler’s Law

Hick’s and Tesler’s Laws both deal with complexity. Hick’s refers to the complexity of choice and tells us that a user with more choices will, not surprisingly, spend longer choosing. Tesler’s refers to who should be burdened by complexity.

Users bombarded with choices have to take time to interpret and decide, giving them work they don’t want. Such a dilemma routinely arises for audience members at a scientific talk. Should they look at one of the elements on the slide? A different element? A third element? The speaker themselves? Faced with this decision, they may well decide to look at their laptop or phone instead.

Tesler’s Law points to the obvious solution to the problem of too many choices: simplify. The law is typically illustrated by noting that, as Larry Tesler did, an engineer should spend an extra week to simplify an application that will save its millions of users an extra minute each. With those numbers, the choice is obvious. But what about a talk with 20 audience members? You’re not going to spend an extra week to simplify one minute of your talk. But let’s say you spend five extra minutes on minor edits to make a slide easier to understand. If it saves 15 seconds of explanation and you multiply that by your 20 audience members, then you’ve recouped your investment.

In a scientific paper, you can’t simplify just by culling the details. They need to be there in perpetuity. Nevertheless, Tesler’s Law still helps. Can you, say, effectively reduce the complexity of a busy figure with judicious labelling? I’m currently writing a paper with a nine-panel figure with 21 lines. One-third of the figure is shown below, and even then it’s still an information-dense figure. Including all of the detail is necessary for completeness, but in the text I discuss only certain aspects. Rather than obligating the reader to locate these aspects, I label them A–D.

Within this same paper, I’m discussing 12 days of oceanographic data. But that’s far too many to compare and contrast, so I build the story around three representative days. In other words, I burden myself with four times the amount of information that I present to the reader.

Science is primarily a one-way interaction, but …

All this talk about the importance of the user misses a key difference between, say, websites and scientific papers. Reading a paper is much more passive. Readers aren’t actively clicking buttons, filling in forms, or purchasing items. It would seem that they’re not interacting with the product. But scientists are still users, and some of the most dedicated at that. We routinely spend hours dissecting and deciphering a single paper. Or 45 minutes listening to a seminar on a single topic outside our primary field. It is easy to take this level of attention for granted and forget that scientists on the receiving end are eager for engaging experiences with attractive interfaces.