The Corona Diaries map includes pandemic story submissions in various languages around the world.

Early morning, about a week into lockdown, I joined a call with teams connecting from Munich, London, Boston, San Francisco, and me in DC. Zoom wasn’t yet a verb, Tiktok hadn’t taken over. Daily television resorted to syndication, news stations had gone mobile. There was no denying the huge technical gap holding many hostage in their own home, forced into remote work, or furloughed until further notice.

The meeting was predicated on a shared Google Doc. It was a first meet for the group. Coordinating efforts was creative director of a tech research department at MIT and her partner at home who was running development. She brought together teams from Harvard’s Nieman Foundation and us at General Assembly.

Each campus sent home their teams. With university programs and staffing suspended, we convened a ghost crew to kick off Corona Diaries, an open voice journaling platform amidst the pandemic. We did some killer work.

The world transitioned to remote load-tested every internet system.

The MIT team previously built a web-based voice recording tool. They wanted to capture the story of people during the pandemic. Neilsen wanted to connect independent reporters, and democratize journalism. Humanity was battling unprecedented isolation and the world was lacking a platform to document the impact.

Wireframes include a profile page for a affiliate user, including associated organization, playlist, and record UI.

Nobody knew what we were facing, or for how long. In response, we hoped to give access to anyone who wanted to be heard.

The open database was made as a story archive. Publications like NPR and the Boston Globe joined to promote the initiative. Papers like the Miami Herald ran campaigns with groups of diarists. BBC/PRI’s the World and USA featured the work. We had a number of potential use cases to document and track voice entries. Global associations of nurses and workers were testing the tool as part of advocacy campaigns.

Like any eager product team, our initial goals were lofty and ambitious. We found opportunities wherever we looked. Organizations and media of all sizes were crippled by the pandemic restraints, and we had a solution for them.

The biggest challenge was production capacity. We had feature requests but two engineers. One had created the technology we were using, but neither had any experience working with front-end languages. Any time dedicated toward customizing for partners was time away from our core product. If we were to build out an embed feature, we needed to think how the work could be reused. Recognizing our limited ability to make bigger updates, the scope of our work focused on optimizing input.

Proposed site organization to account for planned product features.

Recording UI, permissions, and UX writing to help put contributors more at ease

I had conducted an initial heuristics assessment and testing, to be validated. With General Assembly still in session, we gave our students the opportunity to contribute to the work. The site was used to demonstrate usability testing, product design, and an ongoing study on voice data.

Before voice platforms like Twitter rooms and Clubhouse took off, our students found how difficult voice is to work with. Text is simple and doesnt come with the same sense of identity. Voice represents a person, their character and attitude, but has a number of qualities that influence how its recieved. The design conventions around audio were familiar, but varied.

Early tests validated what our reviews found. When the site opened, visitors were put off by the browser requests. The content wasn’t clear, and the recording UI and quality wasn’t optimal. Visitors had more questions about purpose and use, when our goal was submission.

The tool was deployed as a web application to eliminate barriers to access. Without native support though, hardware performance can be throttled. We saw issues come in about recording quality. On older phones, recording added audio artifacts. At worst, voice data was lost, but at best it was muddled. We couldn’t put out a data product that was losing data. Adjusting flow of streaming output solved the loss issue.

More problematic was the flow of permissions.

The initial permission modals were displayed on page load, and often got in the way of site exploration.

Before the site loaded, the browser was flooded by permission requests: load page, press record, request mic, request location, show legal disclaimer. Usability studies confirmed users were alarmed by the prompts. Most were concerned by the amount, and we heard worries about privacy, security and convenience. The permission modals were preventing visitors from considering the site’s use or purpose, distracting from the content. Multiple prototypes testing various orders and modals helped reduce friction in loading. When we integrated optimized flows, visitors contributed more and bounce reduced markedly.

Updated flow of permission waits for user interaction before modals are displayed.

Iterations later, the updated tool waited for user interaction to prompt for permission. Pulling from my past experience with location-based tools, we could leverage browser IP to offset browser requests. Now the site automatically pulls IP data and confirms but provides an option to change location. Updated UI and UX writing now guides recording and answers questions about use. We cleared superfluous content to ensure language is consistent. The site’s map UI is easier to listen, shows meta data, and accommodates for sharing.

Wires for embeddable playlist UI to be used on an affiliate site.

Visions for the product before the pivot to education

Early conversations about the product included a vision of galleries. The map was already built out, but we wanted to expand on functionality. We ideated use cases for possible tools. We considered ways open voice data could be used in art, history, or research. We dreamed of virtual spaces for meetups, generative voice trading cards, and character animation to improve comfort.

Early drafts of potential product brand mark, exploring global, diaristic and pandemic themes.

As our work would later show, the biggest hurdle was the lack of human connection. Though incredibly moving, voice content alone wasn’t enough to generate interest. We brainstormed ways to humanize voice without compromising privacy. Marketing and product plans, visual identity and UI systems were drafted. A landing page was created to promote the tool.

The Corona Diaries landing page was a example project used to teach visual design and front-end.

Instead of owning the product and pursuing it further, we offered the case to students, to design freely with the medium.

For nearly two years, since our kickoff, students have researched voice data. They’ve prototyped zines, and pitched spin-off platforms. They’ve demonstrated the vast potential of voice and the many concerns that accompany.

Though our work of managing the product has concluded, we’ve continued to learn some things about working with voice:

• Perception is a design constraint. In the time of deepfakes, people are precious about their voice. Without some sort of login or ID, open data sources are viewed as suspect. Asked to contribute, people can be skeptical, not sure what to believe, and will look for evidence of concern.
• When feeling disconnected, voice is a powerful, humanizing media. For as many that shared concern, many participants reported voice as more empathetic and compelling content. Users who knew more about the person felt more connected.
• The applications of voice are far-reaching, but users need facilitation. We heard ample feedback validating our work, people liked the idea, but most did not know where to start. Prompts and campaigns can be helpful in encouraging engagement.
• Flow matters, especially when asking for permission. Voice should be as easy as a “good old fashioned phone call.” If there’s any ask, request or explanation, assume it interrupts flow.
• Lost data that can’t be restored, contributions should be treated as sacred. Though the issue was limited, our value diminished if we disenfranchised segments of our users. It’s always important to consider access as part of the problem to be solved. We considered recording offline and delayed uploading, if we couldn’t fix the software.
• Automated editing tools may encourage use. Noise reduction and trimming can be done automatically, like in Keezy, and can lessen concerns in recording of quality. Using ML tools can also extract meta data and content to be shown or used in product features or for accessibility.