How we designed Galassia Ariosto

Giulio Andreini
UX Collective
Published in
10 min readJan 9, 2018

--

Fig.1 — The homepage of the digital archive Galassia Ariosto

Context

At the end of 2013 I was involved into the Galassia Ariosto project as project manager and user experience designer. The project was commissioned by the Centro di Elaborazione Informatica Testi e Immagini (CTL), a research laboratory of the Scuola Normale Superiore di Pisa. The CTL is a long-time client of Net7 (where I work) and I’ve been personally working with their research team since more than 10 years.

The Project

The CTL team has always been interested in studying the relation between text and illustrations, mostly focusing on the first chivalric poems that were printed in Venice starting in the 16th century. The project Galassia Ariosto is a in-depth study of the relations between the text of Orlando furioso (and other chivalric poems like La Gerusalemme Liberata, Orlando Innamorato, Tredici canti del Floridoro) and the illustrations sets that were produced to enrich the text.

Fig.2 — This is how books with images looked like in the 16th century: example of a page with illustration (Orlando furioso, edition Valvassori 1553, Venice).

Net7 was involved to design and build the digital archive where all this data are stored and made accessible on the web:

  1. A back-end system that allows the team to perform their research, inserting images, texts, comments, entities and building relations between all those elements, including portions of images and texts.
  2. A front-end user interface to make all this work public and accessible to the world.

The main challenges of the project: make all this complex data and relations easy to browse and understand, create an attractive UI that involves the user, create different ways to access the content of the archive targeted to different groups of users (personas).

Autopilot disabled!

I’ve worked many times on short term projects where the design process is made on autopilot and there’s no chance to do some qualitative or quantitave research.

Galassia Ariosto was to last three and a half years and I saw a good opportunity to disable autopilot and adopt a user centered design approach to apply some user experience design methodologies. Here’s the description of the methodologies adopted.

Kickstart user experience with a retrospective

Since the research team has a very long term experience in the production of digital archives, we decided to start by analysing the previous projects. I’ve been working with the CTL team for years so I also have the same experience but from the UI/UX design and management perspective.

If you’ve been doing something many times the best way to start the next iteration is by asking “What did we do wrong?” and “What did we do right?”. And try to improve it.

The retrospective was run focusing on two main aspects:

  1. The previously published archives (namely: L’Orlando Furioso e la sua traduzione in immagini, L’officina scrittoria di Anton Francesco Doni, Memorie).
  2. The work methodologies and workflows applied during the design and development activities.

For each of these two aspects each member of the research team was asked to highlight things she liked and didn’t like. After a group discussion and a review of all the answers, we created a list of things to keep doing and things to avoid during the design and development of Galassia Ariosto.

The results of the retrospective were a good foundation for all the following activities.

Proto personas

Personas are profiles of persons that will use the archive. The scope is to identify a few profiles of common target users of the archive and for each persona define some informations that range from age to a short bio, from digital expertise to personality. All this information are summarised in personas profile cards that are used as a reference during all the project: it’s a very important methodology because it impacts all the following activities, from user stories to user testing.

While personas are the result of expensive and time consuming activities, proto-personas are 100% fictional characters that are created by invention. More info about proto-personas here.

The long term experience of the research team was very useful and exploited to define the personas profiles: in fact the CTL team members know very well the categories of people using their archives and this was useful to create effective profiles without running expensive interviews and research activities.

Fig.3 — Profile of persona Maria Grazia, “old-school researcher”

The results of this activity were 8 personas profiles.

Benchmarking with stakeholders

Before starting designing Galassia Ariosto I proposed to do some benchmarking and take an in-depth look at similar archives or projects belonging to different domains. With this methodology we are looking for interesting user experience patterns or user interface details that might be relevant for our project.

Each member both of the research and design teams was given the task to discover websites or digital archives and for each one to take screenshots, write a brief description and list which aspects were a good inspiration for Galassia Ariosto: all the benchmarks were reviewed during a workshop that involved the whole team.

User stories

User stories define what users (personas) want to accomplish while using a product and are defined with a simple sentence where we detail what a user can do and the scope of each action. We defined user stories during a couple of workshops and each story was described by:

  1. The main sentence.
  2. A short description.
  3. A list of fine grained details.

In some cases we also started drawing some hand-sketch wireframes.

User stories relate personas to their tasks and thus shape the design of a product and user interface. At a later stage they are useful to select the tasks we will submit to users during the user testing sessions.

Information architecture

Before defining the information architecture of the archive we studied the logical structure of the various entities and the relations among them. As you can see in Fig. 4 we dealt with many different types of entities and a complex logical architecture.

Fig.4 — The logical structure of the entities of the archive

Luckily we understood that the information architecture could be much more simple and reflect the hierarchical structure of each edition. We focused on a main user journey that leads the user from the homepage to the most fine-grained element (the Scene) following this path:

Homepage > Works and Editions > Edition > Canto > Episode > Scene

The information architecture was designed around this main user journey and this allowed us to keep the overall navigation very simple.

Wireframe

Once we completed the user stories and the information architecture we designed the wireframes of all the pages of the archive.

Hierarchy is something important here: the tendency is usually to say that everything is “very “important and the result is to have pages full of information that goes far beyond the cognitive load limit of the user. I insisted a lot on this topic and we managed to define a clear information hierarchy for each page that we used to design the wireframes.

The next step was to use the wireframes produced to create an interactive prototype in the Invision app: this allowed us to simulate the navigation through the archive and to submit it to real users for testing.

Portable Lab User Testing

User testing is one of the most important methodologies in user experience design and allows us to evaluate our design with real users to get some qualitative feedbacks. Showing our wireframes and interactions to real users can be enlightening and we often discover UX problems we didn’t notice: this happens because when you work for months on the same project you get used to your own decisions and you give for granted things that are not easy to understand for real users.

We decided to run two user testing batches in two different phases of the project:

  1. A first session on the Invision prototypes (before starting developing the front-end).
  2. A second session on a work-in-progress version of the archive, between the two main front-end development sprints.

The user testing was conducted applying a testing methodology designed at Net7 called Portable Lab User Testing that lies between the classic lab testing and the “guerrilla” testing: it’s a lightweight testing methodology that we run with a laptop, recording what users do and say with a screen recording application (Screenflow). This type of testing is fast to set up and can be performed at any location, which is an added value because it doesn’t require recruited users to reach a lab.

Fig.5 — During a Portable Lab User Testing session

Here are the details of how we ran the user testing:

  1. Recruitment: the CTL team identified 5 participants for each user testing batch corresponding to the most relevant personas profiles. This was quite easy since they have a lot of connections with colleagues and students within the university. We contacted the selected users and planned the testing sessions (where and when).
  2. Tasks: I reviewed the user stories, the information architecture and the wireframes and identified the tasks to be submitted to the users. Task are usually short navigation journeys or interactions with your product and shouldn’t take more than a few minutes each. The strict relation between the user story and the task is very important because you are validating all your work from your original assumptions to the final product. I usually prepare a limited number of tasks (between 10 and 15). I want each user testing session to last 1 hour maximum.
  3. User testing sessions: the sessions where made in the CTL’s office or directly in the office of the recruited users. I set up my laptop with a standard mouse and mousepad: it’s very important to provide the user a very standard setup so they don’t focus on disturbing elements like a weird mouse. I adopt the think-aloud protocol so what the user is thinking is recorded in the screencast video. It’s also very important to make clear to the users that they are not under examination and that they can’t go wrong and I usually give them a bit of context explaining what we are doing and why they’ve been invited. Then I launch the screen recording application and start with the tasks. At the end of the last task I thank the user and I ask if they have some general comments and close the session thanking them for their time.
  4. Video review and spreadsheet: when all the user testing were completed (5 users per testing batch) it was time to review the recorded videos. I started by creating a Google Spreadsheet document where I inserted the name of the users (rows) and the tasks (columns). Next to each task column I also added a column for my own comments. Then I viewed each video and inserted in each corresponding cell YES if the task was completed and NO if the user didn’t make it. Next to these cells I added comments if there were important insights I got from what the user was saying or doing. After reviewing all the videos I created a new row in the spreadsheet that I called “results” and I calculated the percentage of success of each task (100%: all users completed the task, 0%: no user made it). This kind of quantitative data (derived from qualitative research) is very useful because if you got 0% you can be sure that something is wrong and if you got 100% you probably made a good design: for all the other percentages in the middle you need to review your comments and understand what was wrong for users who didn’t complete the task. Then I added another row called “actions” where I wrote a list of things we had to do to improve the user experience (even for tasks that have a 100% result there can be some space for improvement).
  5. Final presentation: the last step was to insert the results from the spreadsheet into a Slides presentation and present the outcomes to the CTL and Net7 teams.
Fig.6 — Slide of the presentation of the results of the Portable Lab User Testing

What happened next? After we had these results from the user testing is was time to start a new design iteration to improve the user experience: a lot of work to be done after the first user testing batch… a lot less after the second.

Conclusions

These are the methodologies we adopted to design the user experience of the digital archive Galassia Ariosto. Did we do a good job? Decide yourself just visiting the published archive here!

There are many other methodologies out there and it’s up to the UX designer to decide which ones to adopt depending on time availability, budget and type of project.

In this case the choice was proven to be right since during the last user testing iteration (January 2017) we got very good feedbacks and the tests didn’t highlight major problems with the required tasks.

A big thank to the CTL and Net7 teams for the amazing work done (detailed list of people here). A special thank to Eleonora Borelli and Francesca Di Donato for reviewing this article.

If you are interested in applying some UX design methodologies to your project or for any other info feel free to contact me at: info@giulioandreini.it.

The poster presented at DH2019 — Digital Humanities conference 2019 — in Utrecht, depicting the whole process.

--

--