First UX Workshop for Science in the Making

This article was first published on April 24, 2017

We started the project formally on 21 April with a UX workshop run by Diego Lago, Digirati’s head of User Experience.

We’re not starting from scratch. The archival items are already described in the Society’s CALM archive management system, and we have access to metadata that links an archival item with the content that was published in a journal. If we have have some drawings, or a manuscript, or a referee’s letter concerning publication, we know what article or other editorial in a published journal it relates to, so we can link to it.

We also know something of people, and their roles in relation to individual items. We know that Person A was a referee, Person B was an engraver. We have some keywords for each item, and sometimes know a location associated with each item. We want topic-driven navigation for serendipitous discovery, and it is clear that concepts such as Person or Keyword will be expressed as topics (or entities) with a page for every Person, Place or Keyword that we know about. But we don’t know a great deal more about what our topics are yet.

We have seen examples of the archive material we have to work with, and we have a goal that the platform we build should enrich that material, accruing more content and metadata over time from the actions of curators and users. We know that the platform goal is to showcase the archival material associated with journal articles, for a mixed audience.

Everyone brings their existing mental model of what we think we are building. Some of us are not well acquainted with the content, and that model is hazy. Others know the content in great detail. We don’t have a shared understanding of the domain model — or we have different conceptions of it. The first task of the day was to start working on that shared understanding.

Working alone together

The workshop alternated between exercises that we each did on our own, and group discussion.

We started by each writing down all the elements we could think of that would go into making the site. Every scrap of content that could be labelled, or any concept associated with content that might have a bearing on what the site shows and how it shows it. Things that may become pages and links.

The results of this exercise are a mixture of the concrete and the abstract, the class and the instance. Where one of us writes “Person” another writes “Author, Illustrator, Photographer, Witness, Professor, Student”. Common concepts emerge:

Person, Place, Subject, Role, Comment, Manuscript, Marginalia, Correspondence, Image, Archival Unit, Journal Issue, Journal Article, Topic, External web site, Referee’s reports, Date, Institution, Meeting, Front matter, Formula, Letter, Recipient, Sender…

We then spent time talking through the content concepts, to turn them into a first attempt at a model.

We began to discuss the platform’s viewpoint. What takes centre stage in the model? What is the site about? It needs to present the digitised archive material, but in doing that what (if anything) does it reflect of the existing archival hierarchy? You can already search CALM and see results (but no digitised content). We decided that the platform is not an alternative front-end to CALM with added digitised content. The archival hierarchy may not be helpful to users when the archive is only partially digitised, and probably shouldn’t play any significant role in the pilot. Having said that, there may be times when text from the archival description is worth showing in the platform.

“Journal Article” and “Journal” appeared as key concepts in the domain model, but they are not content we will show directly. We link to them on an external site. A link to a journal article from the site doesn’t necessarily guarantee a journey back.

Person emerged strongly as a coordinating concept, more so than other classes. Unlike other topics, people have specific types of relationship to content in the form of Roles that are often different over time. Huxley is the author of one manuscript and the referee of another.

An archival item has relationships to topics. An archival item has one or more images. It also has other content — transcripts, commentary, other annotations, and will invite more from users. The individual image content of an item also has some of these relationships. The entire archival item may be connected to a person by authorship, but one image within it might be connected to a person because it depicts a particular Antarctic explorer. Some items have relationships to other items, especially for correspondence.

Another conversation was around case studies. These are the special “hero” content identified by the Society as important areas for the site to promote in the pilot. But what is a case study? Is it a special kind of content? Or is it just a regular topic page that has been embellished, customised, extended with extra content or functionality? Can any topic page become a case study just by devoting some extra editorial or development attention to it? Is an item page ever a case study?

The conclusion we came to was that (for now at least) any topic page is a potential case study, it’s not a special separate kind of entity. And they are always topic pages, never item pages.

By lunchtime we had reached a model that we felt was a useful starting point for the pilot. We were getting hungry!

After lunch we did another exercise, divided into three parts. We each chose a particular page or aspect of the site from one of:

• The presentation of an archival item
• A topic page
• The platform home page

We then had 20 minutes to write notes on how we would implement a user interface. Diego asked us to consider points such as every landing page is a home page and almost all things are really collections of other things.

Then we had a frenetic interlude in which we each folded a piece of A4 paper three times to make 8 panels. Diego gave us 8 minutes to fill these panels with UI ideas for our chosen area, looking at whole pages, or particular details of the interface. This is a divergent design activity know as Crazy 8s that aims at exploring alternative solutions to a problem in a very short period of time.

Having warmed up our sketching muscles, we then spent a further 30 minutes individually producing a more detailed treatment, the solution sketch:

We then had a review of everyone’s contribution in detail, by each having a good look at all the sketches. Before asking the authors of the sketches to reveal themselves, Diego gave his interpretation of each of the designs, so that the author could hear someone else’s understanding of the presented user interface.

It’s quite tricky to keep your identity secret while someone else is talking about your work, but we mostly succeeded. Once we had done all this for all the designs, we had a further session talking through them all as a group and making sure we understood them.

Then, the voting:

Each of us had 24 stickers that we could allocate to any designs, or particular features of the designs, as often as we felt. It was important to do this after the discussion rather than before.

We can now take the domain model and the expression of that domain model in the most popular UI treatments and create some wireframes. Part 2 of the workshop will be on Thursday, when we will get together again to look at the wireframes and see if they work for everyone.

Next in series: Second UX Workshop