Go on a journey inside Open Journal Systems (OJS) 3.5 user experience (UX) and user interface (UI) developments with PKP’s Devika Goel! In this interview, learn about how communities got involved, how user feedback informed the changes, the diversity of testing, and what went through Devika’s mind as she worked on 3.5. Stay tuned for Part 2!
Ultimately, I hope this redesign feels like an invitation — an invitation to engage more deeply with the platform, to feel more confident in your work, and to see your feedback reflected in meaningful ways. It’s about making sure everyone feels seen, heard, and supported. That’s what good design — and good community — should do.
– Devika Goel
Welcome, Devika! Thanks so much for taking the time to offer this inside journey into your mind, the UX / UI development process for Open Journal Systems (OJS) 3.5, and helping us celebrate how communities shaped these exciting changes!
In this Part 1, we will explore the big picture ideas and goals, design and decision-making process, features and changes, as well as user testing and feedback.
🧠 Big Picture and Goals
What was the driving motivation behind the recent UX / UI redesign of PKP’s software?
The driving motivation behind the recent UX / UI redesign of PKP’s software was rooted in two values I hold deeply: scalability and inclusivity. I wanted to create a space where people — regardless of their background, experience, or role — could easily understand the information in front of them and feel empowered to take action without barriers.
Whether it’s an editor managing submissions, a reviewer giving feedback, or an author trying to navigate their next steps — our design should work with them, not against them.
At its heart, this redesign was about making things clearer, simpler, and more human. Scholarly publishing comes with enough complexities; our tools shouldn’t add to them. I often thought of Don Norman’s words during this process:
“It’s not the user’s job to know what we meant. It’s our job to ensure they understand what we meant.”
That’s been a guiding light for me — how can we help people succeed in their work, without forcing them to decipher the system?
I also wanted this to be a design that could grow alongside our users. Scalability isn’t just about handling more data or more users — it’s about evolving gracefully with the people who rely on us. As their needs change, as technology shifts, our design should flex and adapt, not remain static. I see this as part of being a good steward of both technology and community.
At the core of this work is a commitment to inclusion. Dieter Rams said,
“Good design is as little design as possible.”
To me, that means removing friction, reducing confusion, and opening pathways — so people can focus on their goals, not the hurdles in their way. I wanted this redesign to reflect that simplicity and care.
And of course, this work wasn’t done in isolation. It was shaped by the people who use PKP’s tools every day. Community feedback, testing across different regions, and listening deeply to real experiences shaped every step we took. This is not just software — it’s a living, breathing space we are building together.
Ultimately, I hope this redesign feels like an invitation — an invitation to engage more deeply with the platform, to feel more confident in your work, and to see your feedback reflected in meaningful ways. It’s about making sure everyone feels seen, heard, and supported. That’s what good design — and good community — should do.
Who were the primary users you had in mind during the redesign, and how did their needs shape your decisions?
When redesigning the UX / UI for OJS 3.5, I made a conscious effort to think about everyone who interacts with our platform — editors, reviewers, authors, journal managers, and readers. Each of these groups comes to the software with different needs, expectations, and levels of experience. My goal was to make sure that no matter who you are, you can use OJS with confidence and clarity.
I thought deeply about the editors juggling multiple submissions and trying to keep workflows moving smoothly — for them, clarity, transparency, and better task management were key. I considered reviewers, who generously volunteer their time and deserve a process that is intuitive and respectful of their efforts.
I thought of authors who just want to focus on their research and publishing journey without getting lost in complicated interfaces. And I didn’t forget readers, who ultimately want straightforward, easy access to important scholarship.
But beyond roles, I also thought carefully about geographies and contexts. PKP serves a truly global community, and I was especially mindful of those working in environments that differ from the Global North — places where bandwidth is limited, where English may not be a first language, and where technical infrastructure isn’t always ideal.
I wanted to make sure our design didn’t assume a particular kind of user or environment. Instead, it had to work for everyone, whether you’re at a large, well-funded institution or a small, independent journal in a region where resources are scarce.
Equity in design was a guiding principle. Accessibility isn’t just about screen readers and contrast ratios (though those are vital); it’s also about respecting different workflows, technological constraints, and linguistic diversity.
I asked myself: How can we reduce friction for someone working on an older computer? How can we make it easier for someone new to scholarly publishing? How can we help someone whose first language isn’t English feel confident navigating this space?
In some ways, this project became a personal reflection on empathy in design. How do we design not just for efficiency, but for dignity? For users who may already face systemic barriers, a platform like OJS shouldn’t add to those — it should feel clear, manageable, and supportive.
That’s why this redesign focused on clarity, simplicity, and flexibility. Not just to make tasks easier, but to create an environment where no one feels left behind, no matter where they are in the world, or what their role in publishing might be.
Throughout this process, community feedback shaped our decisions. We heard from journals in Latin America, Asia, Africa, and Europe — voices that helped us understand where we could do better, and how to create a platform that truly supports the global diversity of scholarly publishing.
How does this redesign align with PKP’s broader mission?
This redesign aligns with PKP’s broader mission because it’s not just about meeting today’s needs — it’s about building a foundation that can support the future of open scholarly publishing. Open infrastructure thrives when it’s able to adapt, remain resilient, and continue serving communities as their needs evolve. This redesign was a step towards ensuring that OJS isn’t simply maintained, but is actively made more sustainable, more resilient, and more capable of supporting the next generation of scholars, editors, and readers.
Good infrastructure, like good design, should quietly carry people forward. It should allow communities to focus on their work — sharing knowledge, advancing research, contributing to scholarship — without being distracted by tools that feel outdated, unintuitive, or rigid. This redesign was about ensuring OJS can continue to serve that purpose in a changing world.
By making our platform more flexible, scalable, and easier to build on, we’re reinforcing PKP’s commitment to research, development, and support of open systems that don’t just respond to change — they help shape what’s possible. In this way, UX / UI is not separate from our mission — it’s part of how we make sure that mission remains relevant, impactful, and future-ready.
🎨 Design and Decision-Making Process
What were some of the biggest pain points in the previous version(s) that you aimed to solve?
Some of the biggest pain points I aimed to solve were rooted in the natural complexity that had accumulated over time as OJS evolved to meet many different needs. The system had grown powerful, but with that power came layers of complexity — interfaces that felt overwhelming, processes that took more steps than necessary, and navigation patterns that sometimes made simple tasks feel unnecessarily long or confusing. For users, it could feel like walking kilometers when only a few steps were needed.
Beyond the interface itself, there were broader constraints. PKP operates within a unique context — a lean team supporting a global community, working with a legacy codebase, and upholding a commitment to openness and flexibility. Every design decision had to be intentional and deliver meaningful value without introducing unnecessary complexity or debt. Working closely with engineers, I prioritized solutions that provided clarity and efficiency while respecting these boundaries.
Finally, because PKP is shaped by its community governance model, it was important to build trust and alignment through transparency, clarity, and clear communication about design decisions. This process sharpened my own practice of ensuring that every change, even small ones, could clearly demonstrate its impact on improving usability, reducing friction, and making the platform more welcoming for everyone.
Ultimately, these efforts weren’t just about solving specific UX problems — they were about bringing the platform closer to PKP’s values of accessibility, openness, and community-centered design.
Can you briefly walk us through the design process from research to prototypes to final implementation?
The design process for OJS 3.5 was grounded in research, collaboration, and iteration. We began with user interviews, heuristic evaluations, and analytics to understand real pain points. As Dieter Rams said,
“Good design is making something intelligible and memorable. Great design is making something meaningful.”
This early work helped ensure our direction was both clear and meaningful to our diverse community.
From there, I worked cross-functionally to prioritize solutions that balanced user needs with technical realities. With foundations in place, I entered a conceptualization and prototyping loop — developing lo-fi user flows, wireframes, and concepts, validating them through collaborative reviews and multiple rounds of feedback.
These weren’t just design exercises; they were moments to align diverse voices and build shared understanding. As Don Norman reminds us,
“Design is really an act of communication, which means having a deep understanding of the person with whom the designer is communicating.”
This phase was very much about creating that shared language between design, development, and the community.
Once concepts were refined, we moved to implementation. I worked closely with engineers, maintaining a tight feedback loop to ensure that what we built stayed true to the intent of the designs. This wasn’t a handoff; it was an ongoing conversation about how to translate design into code responsibly and accessibly.
Finally, through quality assurance (QA), rollout, and post-release reviews, we measured success not just by functionality, but by how the changes improved clarity, efficiency, and confidence for our users.
Throughout, I was simultaneously establishing a sustainable design system — building consistency into components, interactions, and patterns to future-proof our work. This wasn’t about a singular launch; it was about creating processes that would help PKP and its community scale with confidence.
In many ways, this process reflected the values of open infrastructure itself: collaborative, iterative, and built to last.
Were there any surprising user behaviors or feedback that changed your initial assumptions?
Absolutely — we encountered several surprising user behaviors that shifted our assumptions:
Aesthetics boosted usability:
We initially set aside visual polish to focus on structure and clarity. But when we introduced cleaner layouts and updated styling, users reported tasks as significantly easier — even before functionality changed. This aligns with the aesthetic–usability effect, where visual appeal increases perceived ease-of-use.
Surface simplicity drives trust:
Users — especially those new to scholarly publishing — preferred consistent, modest defaults over customizable options. They valued a straightforward path they could trust over flexibility that felt overwhelming. This echoed findings in UX Collective and Reincke on designing for dignity and confidence.
Behavior versus self-report discordance:
In interviews, users often said they didn’t mind multi-step processes — but in usability tests, those extra steps significantly increased drop-offs. This distinction between what users say (attitudinal) and what they do (behavioral) is well-documented in UX research. It reinforced our pivot toward reducing clicks and streamlining flows.
Contextual friction:
A user with limited bandwidth in South America reported that our redesigned pages loaded faster — not just visually, but emotionally. Our assumption that layout alone wouldn’t impact global users shifted; lightness of interface directly influenced their experience and confidence.
These insights encouraged us to build with empathy and understanding, honoring both visible and subtle user behaviors. By blending behavioral observation with attitudinal feedback and global context, we uncovered opportunities to reduce friction and deepen trust — often in ways our initial assumptions didn’t predict.
🛠️ Features and Changes
What are the most noticeable UI / UX changes users will see, and why were they prioritized?
The most noticeable changes users will see are in the dashboard, submission pages, navigation, and user invitation process — areas where our users spend the most time and where friction had the biggest impact on their day-to-day work.
The dashboard has been reimagined to surface key information more clearly and reduce cognitive load. Editors and journal managers told us they needed to quickly understand what required their attention without clicking through multiple pages. This redesign prioritizes clarity, efficiency, and better task management, making the system work with users, not against them.
On the submission pages, we focused on simplifying complex workflows. These are high-traffic, high-stakes areas where authors, reviewers, and editors interact most. We streamlined the process to make it feel less fragmented and more intuitive, reducing unnecessary steps while preserving flexibility for different publishing models.
The navigation has also been significantly improved to reduce the feeling of being “lost” within the system. We prioritized better wayfinding because navigating between tasks should feel seamless, not disjointed.
One area we gave special attention to was the user invitation process. Feedback revealed that editors preferred this process to be straightforward and largely hands-off, so they could focus on the editorial decisions that matter most. At the same time, we needed to ensure this flow met General Data Protection Regulation (GDPR) and global privacy standards. We designed a more transparent, compliant, and user-friendly experience, balancing privacy with ease of use.
These changes were prioritized because they have the highest impact on reducing friction, improving efficiency, and building trust, ultimately allowing users to focus more on meaningful work and less on navigating the system.
How have accessibility and inclusivity been addressed in the new interface?
Accessibility and inclusivity have been at the core of the redesign, not treated as features, but as guiding principles from the very beginning. Given PKP’s global reach, with users working across 248+ languages and diverse technical infrastructures, it was essential to design an interface that works for everyone, not just those in well-resourced settings.
We followed Web Content Accessibility Guidelines (WCAG) rigorously, and each component was systematically tested for accessibility, including color contrast, keyboard navigation, screen reader compatibility, and scalability across devices. Accessibility wasn’t left to chance — every detail was reviewed, refined, and validated to ensure it met these standards.
Beyond compliance, we focused on predictability and consistency as key drivers of accessibility. Instead of introducing entirely new components, we emphasized reusing familiar patterns across the platform.
This intentional consistency reduced the learning curve and supported cognitive accessibility, helping users feel more confident and capable as they navigated the system. Predictable interactions allow users to build mental models more easily, reducing friction and enabling them to focus on their work rather than relearning interfaces.
Inclusivity also extended to localization and cultural considerations — we ensured that interfaces remained intuitive and accessible across different languages, reading patterns, and regions.
Can you give us an example of a small UX change that had a big impact on usability?
One small change that ended up having a big impact was the dashboard redesign, specifically making the current status and next steps of a submission explicitly visible. It sounds simple, but it fundamentally changed how editors and journal managers interact with the system.
Through user research and feedback, I noticed that people were often holding too much information in their heads, trying to remember which submissions needed action, which were waiting, and what step came next. That creates unnecessary cognitive load, and in UX psychology, we know that when people have to mentally track too many things, it leads to fatigue and delays in decision-making.
By bringing this information to the surface — clear status indicators, next steps, and health of the submission — we made it easier for users to quickly understand where they are and what’s expected of them.
This ties back to behavioral insights like the goal-gradient effect — when people can clearly see progress, they’re more motivated to complete tasks. It also leans on processing fluency: when information is presented in a way that feels structured and predictable, users trust it more and navigate it more efficiently.
What surprised me was how much users appreciated this small shift. Editors specifically told us,
“Now I don’t have to dig through tabs or rely on memory — I can just see exactly where things stand.”
That one change helped people plan better, make faster decisions, and feel more in control of their workload.
It’s a great example of how small, thoughtful UX improvements, grounded in user psychology, can deliver outsized value, especially when placed in parts of the system where people spend the most time.
🔍 User Testing and Feedback
What kinds of user testing did you conduct during development?
Throughout the development process, I used a combination of user interviews, quick check-ins with key stakeholders, surveys, and feedback sheets shared with the community alongside prototypes. Each method served a specific purpose and brought unique value to the process.
User interviews gave me deep qualitative insights into how people were actually experiencing the platform. These conversations helped uncover not just the friction points but the underlying expectations and mental models users brought to their workflows. This shaped how we approached clarity, hierarchy, and simplification in the redesign.
Quick check-ins with key stakeholders — including editors, support teams, and developers — helped ensure that design decisions stayed grounded in real-world constraints. These sessions allowed us to validate ideas early, align priorities across teams, and foster transparency throughout the process, which is especially important in PKP’s community-led environment.
Surveys offered a way to gather feedback at scale, particularly from regions or user groups we couldn’t reach through interviews alone. They helped confirm patterns we were hearing anecdotally and provided quantitative support for prioritizing changes.
Additionally, I shared feedback sheets with the community alongside prototypes to gather structured input on specific design decisions. This allowed us to involve a wider range of voices and ensure the design wasn’t static — it could evolve and grow with the needs of the people actually using it. This approach not only strengthened trust within the community but also ensured that our solutions were practical, relevant, and adaptable.
Together, these methods created a continuous feedback loop that balanced depth, breadth, and inclusivity, keeping user needs central while supporting the design’s ability to scale and evolve.
How did the feedback from journal managers, editors, and authors influence the design?
Feedback from journal managers, editors, and authors shaped the design in ways that went beyond simply refining screens — it fundamentally reframed how we prioritized what mattered most. One of the key lessons from working with this community was the importance of designing for confidence. It wasn’t just about making things easier; it was about giving people clarity and reassurance so they could focus on their scholarly work, not the tool itself.
Editors and journal managers, in particular, helped us see how much invisible labor existed in the previous workflows, remembering which submissions needed action, manually following up with reviewers, or navigating unclear processes. Their feedback encouraged us to design in a way that actively reduced that burden. This is why the dashboard now surfaces actionable information clearly and workflows are more transparent; it’s about freeing up mental space, not adding to it.
Rather than thinking of feedback as a checklist for fixing problems, we treated it as an ongoing dialogue that shaped how we defined the problems in the first place.
It helped us see that clarity, predictability, and reducing cognitive burden were just as important as accessibility or scalability.
Ultimately, this feedback reinforced the idea that great UX in scholarly publishing isn’t just about efficiency — it’s about restoring time and attention to the things that matter most: quality scholarship, thoughtful editorial work, and meaningful peer review.
Did you involve non-technical users or users from diverse global communities in your testing process?
Yes, I actively involved non-technical users and users from diverse global communities, but what stood out to me is how this helped challenge my assumptions about simplicity and universality. It’s easy to design something that feels intuitive within your own environment or cultural norms. Involving people from varied contexts quickly revealed where those assumptions didn’t hold.
For example, something as small as the language we used in button labels or task cues surfaced unexpected friction — phrases that seemed clear to one group caused hesitation for another. These moments helped me realize that clarity isn’t universal; it has to be co-created across perspectives.
I also saw how different user groups approached time management, attention, and digital trust. Some users wanted systems to disappear into the background; others valued step-by-step confirmation. These nuances shaped how we approached task visibility, progress indicators, and notifications.
What I took away from this wasn’t just validation of the designs — it was a deeper understanding of how involving a broader spectrum of users exposes blind spots early and strengthens the system’s adaptability over time. It helped ensure that OJS isn’t just technically functional — it’s functionally relevant across cultures, infrastructures, and experiences.
In short, involving diverse, non-technical users wasn’t about ticking a box. It was about stress-testing assumptions and future-proofing the design to work well in the unpredictable realities of a global user base.
__
Thank you once again, Devika, for sharing your insights and experiences, as well as giving us fabulous highlights of how communities were at the heart of the changes!
If you’d like to learn more about these exciting changes, you can check out our What’s New in OJS 3.5 recording on YouTube (as well as an entire 3.5 playlist), and our What’s New in 3.5 documentation. You can also access Learning OJS 3.5 documentation at PKP Docs Hub.
