Introduction
Main assumptions
Basing on the project guidelines ("Feasibility Study") we were asked to prepare UX tasks' roadmap, leading to the proper product discovery process. The source document was invented by a group of engineers and researchers. Project lasted 1,5 year. There were around 40 people involved. During the most of the project, i was the only UX Designer in the team.
One of the main assumptions was to base - in the terms of backend and frontend - on the RoHub project, research platform for publishing, sharing and exploring scientific objects.
Problem #1. Source project is incomplete
It quickly turned out that the RoHub was incomplete - it not only had plenty of bugs, but also it didn't cover our needs. The problem was that wrong assumptions were made at the first place, so we joined the project without proper knowledge on the early stage.
User scenario
We came up with a really simple scenario and invited one of our internal researchers (person who really knows how RO should work). Sadly, he didn't manage to finish the process because of the website's bugs and errors. It turned out that there were some issues with the backend, not only with the interface itself.
Service desk
Knowing that, i was pretty suspicious and decided to dig deeper. I talked with the main developer of ROHub and checked their service desk for some hints. I was looking for any features that ROHub was missing in the terms of our future designs. From that service desk, we picked out features that users were asking for, such as:
Then I talked to our developers team and we flagged those featues as "nice to haves" whenever it'd possible.
Analyzing ROHUB platform
To better understand the potential issues with RoHub, I conducted an in-depth analysis of the ROHUB's analytics. My goal was to identify usability problems, user behavior patterns, and areas that required improvement. Here are the key findings based on the gathered data:
Problem #2. Transfering generic user stories into real, useful ones
Simultanusly to the the tasks described earlier, we were tasked with creating user stories based on general guidelines from the "Feasibility Study" document AND on the ROHub. However, the document turned out to be too broad. It provided very low-level descriptions that were not actionable for the backend developers, frontend developers, or even for the UX team. Instead of specific user scenarios, we were faced with vague concepts that didn't help anyone move forward. Our challenge was to transform these general descriptions into clear, actionable user stories that defined specific functionalities.
Speaking the same language
We conducted a series of meetings with stakeholders, backend, and frontend teams. It quickly became apparent that everyone had different interpretations of the terms used in the document. We weren't speaking the same language, which made it impossible to align our work. Seeing this, I started looking for research methods that could help us establish a shared vocabulary and streamline communication across all teams.
Untangling the mystery with OOUX
Introducing the OOUX approach proved to be a great solution. By creating an object map, I was able to visually present my interpretation of the user stories. The map served as a common reference point that everyone could understand and contribute to. It allowed us to break down the high-level descriptions from the feasibility study into tangible objects and attributes, which in turn made it easier to define concrete functionalities for each part of the application. This visual representation became an essential tool for our ongoing discussions.
Explaining
To implement OOUX, I incorporated a legend that helped the team understand and categorize different elements of our application. Here is a breakdown of the legend:
Core Content: These are essential attributes that uniquely define an object.
Metadata: These are supplementary attributes—elements common to multiple objects, used for filtering or sorting (e.g., creation date, edit history, category).
Nested OBJECT [type of relation]: Defines relationships between objects—what other objects are nested within an object and how they connect.
CTA (Call to Action): Defines the actions that can be taken on an object.
Invisible in UI: Elements that are not visible in the user interface.
As you can see below, OOUX map has changed since the very beggining. It was growing and growing - unveiling questions and fields for further talks.
Usability testing. Round one
The first round of user usability tests, conducted from December 16 to 20, revealed several key usability issues in the system:
Users struggled to differentiate clearly between "File" and "Enrichment."
Terms like "Metadata" and "Raw data" caused confusion.
2 types of interface were tested - with tabs and without them. Users opted for the tab version, so we cleaned up the content
Users requested greater prominence for the "Edit display mode" feature.
Based on those insights, the following improvements were developed:
Usability testing. Round two
The second round of research, conducted from December 27, 2024, to February 3, 2025, surfaced further areas for enhancement:
Users needed clearer distinction between "Share" and "Lock" functions to prevent mistakes.
Users wanted OCR/HTR tools highlighted with clear usage feedback.
Users missed clear success or error feedback in the sharing process.
That's why I introduced new decisions like:
