SmarTerp: design of an interface for a highly cognitively demanding situation — simultaneous interpretation

I led the product design of SmarTerp, a computer-assisted interpreting (CAI) tool. I ran the user research, the wireframing and the usability testing. Beyond this interface, I helped the Product Owner ground long-term design choices in the business needs. The project was also the subject of my MSc thesis in Human-Computer Interaction, now in the Universidad Politécnica de Madrid’s digital archive.

CAI tools are software made for interpreters: they are the interpreter’s workstation. SmarTerp aims to lessen the cognitive effort of interpreting by giving interpreters automatic speech recognition (ASR) while they work.

To design the platform’s main feature, the interface for oral language interpreters, I followed the steps of user-centred design within the project’s budget and time. I chose which methods suited the project, ran them, synthesised the results and presented them.

The first phase set out the design and business context. From the stakeholder interviews I defined the user work models and the system’s flow model.

The interviews gave me the company’s business goals, the target users, and the roles, duties and actors inside and outside the organisation. What they told me went into the User-Centered Business Canvas below. Four stakeholders came out of them, two primary and two secondary:

A system flow diagram showed the roles, responsibilities and flow of information within and outside the organisation, and where SmarTerp fits in that environment.

I summarised the interviews in a User-Centered Business Canvas. It echoes the Business Model Canvas and adds what user experience planning needs, giving a first view of how business and user problems relate. It helped me draw out what the subject-matter experts knew, across meetings, workshops and design critiques, and see which capabilities the stakeholders believed the platform needed to succeed.

To learn about the users’ problems and their context of work, I ran user interviews and a contextual inquiry, asking interpreters to describe their most recurring problems and watching them work.

I interviewed ten target users, five of them with a visual impairment (three blind, one with retinitis pigmentosa, one with low visual acuity). I used the critical incident technique: each interpreter told the story of a meaningful incident from their past work. This surfaced the problems that disrupt their work the most.

Interviews alone could not capture how complex the working context is, so I ran a contextual inquiry, a mix of observation and interview, at the biennial congress of the Colegio Oficial de Odontólogos y Estomatólogos de la Primera Región (COEM) in Madrid. I watched oral language interpreters working on an online conference: under the COVID-19 protocol each interpreter sat in their own soundproof booth, while the speakers joined by video call.

I analysed the research with affinity diagrams and synthesised it in a persona, an empathy map and a user journey map.

The observed behaviour, the critical incidents and the analysis produced the persona of the oral language interpreter, which every later model used to motivate design decisions.

The journey is “as-is”: its steps and problems are the interpreters’ actual experience, so it shows the critical moments that need intervention. It follows Katy before, during and after a session; each phase has its tasks, pain points and design opportunities, with the pain points mapped to her feelings.

This interface tackles the central part of the journey: starting to interpret, the session, and finishing. That is where the core of the job happens, so its pain points came first.

I built the prototype in ProtoPie and ran the tests with the Wizard-of-Oz procedure. Five target users took part, one of them an accessibility user with retinitis pigmentosa. I synthesised the observations in a rainbow spreadsheet.

After each task, participants answered a Single Ease Question on how hard it felt; after all the tasks, a System Usability Scale (SUS) questionnaire. The results were positive overall: a mean SUS score of 90.5 (SD 6.7) and a mean post-task ease of 6.5 (SD 0.3). The sample is too small to be statistically valid, but the scores agree with the success rate of each task.

The first confusion came from the microcopy of the operator’s voice connection. It was one-way, but the message “The operator is talking to you” led users to think the operator could hear them.

The second was the microphone handover, which did not match some users’ expectations. The post-test interviews showed why: their mental models came from frequent, expert use of the handover procedures in other interpreting platforms.

The usability test showed where the interface needed work: its graphic appearance, and the interaction design of the handover, had to be adjusted.