← Back to portfolio

Translation workflow · Internal product · CoR & EESC

Artemis: ask, translate, review, in one place

UX, UI, user testing & accessibility · Angular
User tests
9 participants, 3 admins
Languages
24 EU + non-EU
Accessibility
Tested, WCAG 2.2 AA
Built with
Design system + Angular

Outcome

One tool where officials request translations of official and legal texts, follow every step, and ask for corrections

Every opinion, legal text and official document at the Committees has to exist in the EU languages. Officials send each text to translation, translators deliver it, and reviewers check it before it is published. If something is wrong, it goes back for correction.

Artemis supports that whole job. Officials create a request, translators and reviewers work on it, and everyone can see where each document is. I designed the interface with the CoR & EESC design system, tested it with users, ran accessibility tests, and the front end was built in Angular.

See the user flow Résumé

BProblem & users

Legal texts can’t be late or wrong, in any language

Translation requests carry deadlines tied to plenaries and meetings. People need to know at a glance what is waiting, what is late, and who is working on it, across hundreds of requests.

Persona

Requesting official

Job to be done
“Get this opinion translated into all languages before the plenary.”
Pain points
Doesn’t know where a request is. Has to email to ask for a change.

Persona

Translator & reviewer

Job to be done
“See my queue by deadline, deliver, and know exactly what to correct.”
Pain points
Dense lists, long forms, unclear correction requests.

Persona

Planning admin

Job to be done
“Plan the work of my unit and spot urgent or late requests early.”
Pain points
Needs filters, exports and saved views, not one fixed table.

CUse cases & user flow

From request to approved translation

Main use cases.
Use caseWhoWhere in Artemis
Request a translation of an official or legal documentRequesting officialRequest: requester, dossier, document, original language, target languages, pages, deadlines, confidentiality, urgent
Follow where a request isOfficials, adminsList with status, dates and a red dot for late items. State, Planning and Activity log in the request
Deliver and review the translationTranslators, reviewersWorkflow, Format checked, Studio checked, Version
Ask for a modificationOfficials, reviewersCorrection, Remarks / Reference, Notebook
Plan the unit’s workAdminsFilters, saved configurations, columns, Excel export, auto refresh

User flow

  1. 1FindFilter the list by institution, unit, status, type and dates.
  2. 2RequestFill in the document, languages, pages and deadlines.
  3. 3TranslateTranslators see the request in their unit’s queue.
  4. 4ReviewWorkflow and quality checks before release.
  5. 5CorrectAsk for changes with a reason; a new version is logged.
  6. 6DeliverSave to the document system; the log shows who did what.

DUsability review

Is it easy to use, and accessible to everyone?

I reviewed the design against the 10 usability rules of Nielsen Norman Group and the WCAG 2.2 AA accessibility standard. Each row shows how the design answers each rule.

Usability review of Artemis.
Usability ruleHow the design answers it
Visibility of system statusRed dot for late items, status column, “Next refresh” counter, Activity log in each request.
Match with the real worldLabels use the Committees’ own words: dossier, referral, adoption date, secretariat.
User control and freedomEdit and Forward always at the bottom of the request; Correction to send work back.
Flexibility and efficiencySaved configurations, choose columns, sort, Excel export for admins.
Aesthetic and minimalist designThe long request is split into tabs on the left, so each screen shows one group of fields.
HelpManual and “Contact HDT” (helpdesk) always in the footer bar.

EUser testing

Tested with 9 participants, 3 of them admins

Moderated, think-aloud sessions with officials, translation staff and admins from both Committees. Each person did the core tasks on the prototype; admins also tested planning and configuration.

Test tasks.
TaskWhoWhat we looked at
“Request a translation of this opinion into French and German.”All 9Finding the fields, choosing languages, marking it urgent.
“Which of your requests are late?”All 9Seeing the red dot and status, filtering by unit.
“Ask for a correction on this translation.”All 9Finding Correction and explaining the change.
“Set up a view for your unit and export it.”3 adminsFilters, columns, saved configuration, Excel.

Design decisions tested

  • The long request form became tabs on the left: Request, Actions, State, Remarks, Notebook, Activity log.
  • Edit and Forward stay in a fixed place at the bottom of the tabs.
  • Late requests have a clear marker in the list.
  • Admins have saved configurations and column choice.

Two kinds of users

Officials and translators need few fields and a clear status. Admins need more control: filters, exports and saved views. The design gives both: a simple default, with power tools in the toolbar and footer.

FAccessibility testing

Checking the same screen through different eyes

Artemis is used all day by people with many kinds of vision. I tested the request screen with vision simulations, checked contrast, and checked the keyboard and screen reader path, against the WCAG 2.2 AA accessibility standard and EN 301 549. Names are hidden in the images.

Request screen seen with blurred vision
Blurred visionLabels and field groups still readable by size and position.
Request screen with low contrast
Low contrastField borders and the active tab stay visible.
Request screen dimmed as in low light
Dim screenText still reads on dark office screens and in low light.
Request screen with shifted colours, buttons appear teal
Colour shiftMeaning never relies on colour alone: checkboxes, icons and text.
Request screen with a yellow tint and faded blues
Yellow tintBlues fade, but the hierarchy holds through weight and layout.
Request screen with visual distortion of text
DistortionShort labels and clear spacing keep fields apart.

Fixes from the audit

  • Active workflow step and success text: #0CA678 (3.1:1) → #0B6E4F (6.3:1).
  • Helper and secondary text: #868E96 (3.3:1) → #5F6670 (5.8:1).
  • Error text and icons: #FA5252 (3.3:1) → #C92A2A (5.5:1).

See the fixes in the design system

Keyboard & screen reader checks

  • Moving through the request tabs and fields by keyboard only.
  • Visible focus ring on every control and grid row.
  • Every field has a real label; icons have names.
  • Late status uses a marker and text, not only red.

GScreens & design system

Built on the CoR & EESC design system, in Angular

Artemis request list with filters for institution, mode, status, type and dates, a dense data grid, and a footer with save, Excel, columns, restore, manual and helpdesk
Request listFilters on top, a dense grid with sortable columns, saved configurations and tools in the footer.
Artemis request dialog with tabs on the left and grouped fields for requester, dossier, document and languages
RequestTabs on the left, fields in three groups: who, what, and the document.

Logo

Artemis icon: two cubes, one yellow with the Greek letter alpha, one blue with an A and a star

Two cubes: blue with an “A” and a star for the source text, yellow with an alpha for the translation. One language turning into another.

Design system → Angular

Blue app header (#2C4390), data grid, filters, tabs, checkboxes, buttons and the request dialog all come from the CoR & EESC design system, so Artemis looks and works like the other internal apps.

App headerFilter barData gridVertical tabsDialogLanguage pickerStatus markerFooter toolbar

See the CoR & EESC design system

HOutcome & next steps

What I delivered, and what comes next

Delivered

  • The full Artemis flow: list, filters, request dialog and workflow tabs.
  • User testing with 9 participants, 3 of them admins.
  • Accessibility testing with vision simulations, contrast fixes and keyboard checks.
  • The Artemis logo, and screens built from the design system for the Angular team.

Next steps

  • Test again with screen reader users.
  • Add a short guide for new requesters.
  • Measure time to create a request before and after.