16 User-centered content design
As a [person in a particular role]
I want to [perform an action or find something out]
So that [I can achieve my goal of …]
This framework can help us be more specific in getting started. Placing the concept into one of our working examples, Citi Bike, one user story could look like this:
As a [marketing executive]
I want to [explore associations between subscriber attributes and contextual preferences]
So that [I can improve upon our segmentation and targeting]
Or another of our working examples, the Los Angeles Dodgers:
As a [marketing executive]
I want to [understand variation in game attendence conditional on expected outcome and contextual factors like day of week, opposing team, starting pitchers, and cumulative win percentages]
So that [I can increase game attendence within constraints]
For these user stories to be valid, we would need to first research relevant marketing executives, if possible, at Citi Bike or the Dodgers, respectively. The value of this approach increases as we develop multiple actions and goals for a given user, or multiple users, each needing a tailored communication.
Similarly, and alternatively, we may find that framing our communication purposes in terms of jobs work better to help us become specific. Richards provides a template here too:
When [there’s a particular situation]
I want to [perform an action or find something out]
So I can [achieve my goal of …]
Framing our research into these forms can help us to be specific in defining our purpose and audience for communicating.
16.1 Creativity
Effective communication, too, requires creativity. But how? Nobel-prize winner Linus Pauling, foreshadows the how, when he explained,
The best way to have a good idea is to have a lot of ideas.
Indeed, we find a something idea from Bayles and Orland (1993), in an experiment conducted on students to learn about creativity:
The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality. His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the “quantity” group: fifty pounds of pots rated an “A”, forty pounds a “B”, and so on. Those being graded on “quality”, however, needed to produce only one pot —albeit a perfect one —to get an “A”.
Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the “quantity” group was busily churning out piles of work—and learning from their mistakes —the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.
Creator of the ubiquitous javascript library d3.js and former graphics editor at the New York Times, Bostock (2014) applied similar advice, explaining that “design is a search problem.” In that keynote, Bostock led us behind-the-scenes in the creation of several data-driven articles at the New York Times. He showed us hundreds of snapshots of prior versions of what became the final, published articles. The flip-book style presentation of these snapshots show hundreds of ideas tried before the graphics and narrative became final. He advised that early in the search for a communication solution, use methods that allow fast prototyping so that we can, one, try many things, and two, not become too attached to any particular design.
Let’s look at ways to prototype the communication next.
16.2 Prototyping
Prototypes are not the communication. It isn’t polished. It isn’t generally pretty. Its purpose, as Ko (2020) explains, is merely to give you, as a creator, knowledge and then be discarded:
This means that every prototype has a single reason for being: to help you make decisions. You don’t make a prototype in the hopes that you’ll turn it into the final implemented solution. You make it to acquire knowledge, and then discard it, using that knowledge to make another better prototype.
Because the purpose of a prototype is to acquire knowledge, before you make a prototype, you need to be very clear on what knowledge you want from the prototype and how you’re going to get it. That way, you can focus your prototype on specifying only the details that help you get that knowledge, leaving all of the other details to be figured out later.
With just text, we might call a prototype an outline.1 As we bring in data graphics — and especially when we layer in audience interactivity with both data graphics and its containing documents — the creation of those interactions can become more complex, take longer to implement. To save time, it can help to sketch out the layout and organization of the information and interactivity. And sometimes the fastest way to iterate though ideas is to set aside the technology, for a bit, in favor of pencil and paper (or, perhaps, any electronic equivalent like sketching software based on touch screens). Information designers Nadieh Bremer and Shirley Wu provide enlightening examples of early pencil sketches in their recent book, Bremer and Wu (2021).
Of note, with sketches, we can sometimes find use in linking them together through storyboards, commonly organized as a grid with visual and narrative elements,
as a way to communicate a larger, graphics-heavy narrative.
At some point, we shift from low-fidelity, hand-drawn prototypes to those of higher-fidelity, using some kind of layout or drawing software. Anything that would allow us to quickly draw things. Apple Keynote, perhaps. Or more specific drawing, illustration, or prototyping software like Illustrator, Sketch, Affinity Designer, Inkscape, or Figma. There is no best tool, and better tools depend on its user’s skill and speed with it, and the purpose it furthers. Of note, what serves as faster is also relative. Bremer and Wu frequently use ggplot2 and Vega-Lite to prototype interactive data graphics that are ultimately coded in the javascript library d3.js.
16.3 Evaluating
In the last segment of our circular loop of iterating, we evaluate the communication. We have several approaches, which may be combined. These include critique and empirical research.
16.4 Critique
Visualization criticism is critical thinking about data visualization. The same is true, more generally, about communication. A critique is a two-way discussion. Stated differently, there’s a human on both sides of the communication. As Richards (2017) recognizes, “it’s not easy to let other people tear your work to shreds. It’s not easy listening to them tell you what’s wrong with [your draft work].” She provides rules to help. First, “be respectful: everyone did the best job possible with the knowledge they had at the time.” Second, “only discuss the content, not the person who created it.” Third, “only give constructive criticism: ‘that’s crap’ is unhelpful and unacceptable.” Fourth, “no one has to defend a decision.” The focus of a criticism is only in making the content better.
Keep these ideas, and Richard’s rules, in mind. First, establish the purpose of the critique. When reviewing someone else’s document, center yourself on the purpose that was agreed upon, such as clarity, accuracy, or correctness. Should this purpose be multiple, review one aspect at a time, focusing on content first.
Secondly, be objective and well-reasoned. Typos are usually more conspicuous than reasoning flaws, but also less important. Each statement should be objective, delivered in neutral language, and backed up by theoretical reasoning or empirical evidence.
Third, offer alternative solutions. In your comments—help, don’t judge. A critique must serve the goal. Simply pointing to problems is not enough. The critic must state an alternative solution in a way that is clear and complete enough to provide a basis for improvement.
Fourth, structure the review. Begin by providing a global assessment, to place further comments in proper perspective. As a rule, point out the weaknesses, to prompt improvements, but also the strengths, to increase the authors’ willingness to revise the document and to learn.
And a note for the content creator: you don’t have to apply suggestions by the critic, but you should think critically about the advice.
Brath and Banissi (2016) and Kosara et al. (2008) provide a framework for critiques in the context of data visualizations. More broadly, Ko (2020) and Richards (2017) guide us with critiques in the context of design. And in the context of communication, consult Doumont (2009).
16.5 Empirical research
The value of critiques depend largely upon the expertise of the critic. Another, approach, used often in industry, is to conduct experiments — industry commonly calls them A/B tests — where one group receives a base design or communication (the control group) and another group receives the same communication but with one modification (the treatment group). This is, in effect, observing the effect of that portion of the communication: how did the change in communication affect the response?
With interactivity, we may wish to include observation or user testing. We can provide the communication to a user, let the communication stand alone (i.e., don’t guide them, verbally or otherwise, outside the communication or interactivity being tested, and ask them to verbalize what they are thinking and how they are interacting. If they become silent, prompt them again to verbalize. This approach can help us understand when and how a communication breaks down in some way. Finally, have them reflect on their interaction with the communication.
Lee et al. (2015) provide another view into the process of telling data-driven stories, in the context of a team effort. The authors diagram steps, components, and responsibilities:
But whether we are part of a team or creating alone, we integrate numerous concepts to effectively communicate data-driven, visual narratives. The goal of this text was to introduce many of the main components shown above while providing an entry point for further discovery in whatever rabbit hole you’d like to explore within.
In closing, to paraphrase Richards (2017), storytelling with data “isn’t just a technique,” or set of techniques, “it’s a way of thinking. You’ll question everything, gather data and make informed decisions. You’ll put your audience first.”
An outline is actually a great place to begin even for data graphics and interactions.↩︎