Go on a journey inside Open Journal Systems (OJS) 3.5 user experience (UX) and user interface (UI) developments with PKP’s Devika Goel – Part 2!
In “Inside OJS 3.5 with UX / UI Designer Devika Goel – Part 1”, I interviewed Devika 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.
Now, I invite you to Part 2, where we explored a number of questions and insights that will be fascinating for anyone using or considering OJS, or thinking about upgrading to 3.5. But what is so fascinating about Devika’s journey?
This interview will also be interesting for folks who are curious what goes into, and lessons learned from, designing quality open-source scholarly publishing software driven by values, community, theory, and practice.
What this experience taught me most is that user-friendly doesn’t mean “simple.” It means respected. It means users feel seen in the flow of the design — whether they’re navigating metadata fields or assigning a reviewer. And that’s where PKP’s mission comes through so clearly. We’re not just building tools — we’re supporting the equitable production and sharing of knowledge.
🔄 Iteration and Future Plans
What parts of the design are still evolving or might change based on future feedback?
Many parts of the design are still evolving — and I believe they always should. At PKP, we serve a dynamic and diverse global community, and that means our design needs to remain responsive to how those needs shift over time.
Core areas like the submission dashboard, submission interface, and reviewer experience will continue to adapt as we learn more from the people who use them daily. For example, what works well for an editor today may need to look very different tomorrow as publishing models, peer review standards, and user expectations change.
From a UX perspective, being adaptable is a strength, not a sign of incompleteness. We’re not designing something to be finished — we’re building a living system that grows with the people who rely on it. Feedback isn’t the final step; it’s the fuel that helps us iterate with care and intention.
What grounds this approach is PKP’s core commitment to community-led development. Our design process will remain open and reflective — not just to fix what’s broken, but to continuously explore what could be better. Staying stagnant would be easy, but it wouldn’t serve the community. Evolving with them is not only good design practice — it’s how we honour their trust.
Are there features or improvements users have requested that are on the roadmap?
Yes — several user-requested features and improvements are either already on the roadmap or being actively explored.
One of the most common asks is for more flexible workflows. Users want the freedom to move between submission, review, copyediting, and production stages in ways that reflect their editorial realities — not be locked into a rigid, linear sequence.
We’re working toward adaptive workflows that still provide structure, but with the flexibility to support diverse publishing models and team setups.
Another major area is continuous publishing. Journals are increasingly moving away from issue-based models, and we’re actively exploring how to better support rolling publication workflows — both in terms of interface and backend logic.
Users have also asked for multilingual form fields, especially in submission and metadata screens. For journals working across languages, this isn’t just a preference — it’s essential for inclusion, visibility, and global participation.
We’re also focused on improving notifications — specifically how they’re surfaced, prioritized, and actioned. The goal is to reduce noise while increasing clarity, helping users distinguish what’s urgent, what’s informative, and what can wait. This ties directly into better workflow awareness and decision-making across roles.
Another frequent request has been for improved file history and activity logs. Users want clearer insight into what’s changed, who made updates, and when actions were taken — especially in collaborative editorial environments. A more transparent and human-readable log helps build trust, reduce back-and-forth, and streamline accountability.
Of course, these are just a few highlights. We continue to receive thoughtful requests from the community almost daily — from small usability fixes to more strategic feature proposals.
While we can’t implement everything at once, we have an incredibly dedicated team and a community that doesn’t just use the platform — they help shape it.For us, the roadmap isn’t static. It’s a shared space where community needs, technical feasibility, and thoughtful design come together to build something that’s not only functional, but truly meaningful.
How can the user community continue to give feedback on UX / UI in future versions?
There are several ways the user community can continue giving feedback on UX / UI in future versions — and we truly hope they do. At PKP, we don’t just welcome feedback — we see it as a form of collaboration.
One of the best starting points is by joining the conversation in the Feature Requests channel on the PKP Community Forum. This isn’t just a space to drop ideas — it’s where community needs meet collective imagination. A single idea posted there can spark dialogue, gather support, and evolve into something that benefits thousands of journals around the world.
We also host user testing and feedback opportunities both before and after features are developed. These sessions are incredibly valuable — not just for identifying issues, but for uncovering unexpected insights that help us refine workflows, language, and structure. Participating in these sessions helps ensure the software isn’t just built for the community — it’s shaped with it.
We’re also excited to invite users to virtual co-creation workshops focused on UX and UI. These sessions are about more than critique — they’re about imagining what’s possible together. You don’t have to be a designer to have a design mindset. If you’ve experienced a friction point or dreamed of a better way — you’re already halfway there.
And honestly, if you have an idea, sketch, or even a spreadsheet of feedback — send it. Some of our most meaningful changes have come from people who didn’t wait for a formal feedback window. As a community-led project, the things that are helpful to you, made by you, often become what’s helpful to many.
In the spirit of open infrastructure, we believe feedback isn’t a transaction — it’s a relationship. And the best user experiences are the ones we build together, version by version.
🌍 Broader Reflections
What are the biggest challenges in designing user-friendly software in the academic publishing space?
Designing user-friendly software in the academic publishing space comes with a unique set of challenges — not because the users are difficult, but because the ecosystem itself is incredibly rich, layered, and evolving.
At PKP, we’re not designing for a single workflow or audience. We’re designing for a global community — across 248+ languages, countless disciplines, varying levels of technical access, and often underfunded institutions.
What’s considered intuitive in one context might be confusing in another. So the challenge becomes: how do you create something coherent, flexible, and inclusive — without making it feel fragmented or over-engineered?
We also work within a community-governed model, which means that change can’t be dictated — it must be earned. That pushed me to think beyond usability. I had to understand the values, hesitations, and hopes behind how people work, and then communicate design intent in ways that build trust and alignment.
Add to that the realities of a legacy codebase and a small, mission-driven team, and it became clear that every change had to be thoughtful, high-leverage, and sustainable. There was no room for “nice-to-haves.” Every improvement needed to serve a real, shared need — and do so without creating debt.
But what this experience taught me most is that user-friendly doesn’t mean “simple.” It means respected. It means users feel seen in the flow of the design — whether they’re navigating metadata fields or assigning a reviewer. And that’s where PKP’s mission comes through so clearly. We’re not just building tools — we’re supporting the equitable production and sharing of knowledge.
To me, that’s the real challenge — and privilege — of designing in this space. It’s not about removing complexity. It’s about making space for people to do meaningful work, with less friction and more dignity.
What lessons have you learned from this UX / UI redesign that might apply to other open-source platforms?
This UX / UI redesign taught me lessons that go far beyond design tools — and I think many of them can be helpful for other open-source ecosystems, especially those still growing their teams.
This UX / UI redesign taught me lessons that go far beyond design tools — and I think many of them can be helpful for other open-source ecosystems, especially those still growing their teams.
1. Design is a mindset, not a job title.
At PKP, not every contributor was a designer — but many were designers in spirit. Editors who flagged confusing workflows, developers who built accessibility into every line of code, support staff who shared user pain points — that’s all design work. Open-source platforms thrive when teams think about design as a shared responsibility: anyone can advocate for clarity, consistency, and user wellbeing.
2. Build systems, not just features.
One of the biggest shifts for me was moving from designing screens to designing foundations — flows, components, documentation, and decisions that could grow with the platform. In open-source, turnover is real, and contributors change over time. Future-proofing your work isn’t about perfection — it’s about leaving trails others can follow and build on.
3. Feedback isn’t noise — it’s alignment.
In open ecosystems, feedback can feel overwhelming. But I learned to treat it as directional energy. When people take the time to share what’s broken, unclear, or missing — it’s a sign of care. It also surfaces patterns that can guide both short-term fixes and long-term strategy. Even without a formal UX team, any product group can listen with structure: tag feedback themes, prioritize repeat pain points, and close the loop with your users.
4. Co-creation reduces rework.
We invited users into early testing — sometimes with rough prototypes, sometimes just with sketches. This didn’t just validate ideas; it revealed blind spots early and made our roadmap stronger. You don’t need polished visuals to co-create — you need a culture of showing work early and inviting input. That mindset saves time, builds trust, and makes future adoption easier.
5. Design for the edges, not just the average.
Some of our most meaningful improvements came from people outside the “default user” — folks working in lower-bandwidth regions, using older devices, or navigating OJS in their third language. When we centered their experience, everyone benefited. If your team can learn to ask, “Who might this unintentionally exclude?”, you’re already designing better systems.
6. Trust is the real product.
Whether you’re shipping features, frameworks, or fixes — the real output of an open-source project is trust. Trust that the tool will work. That it will be improved. That feedback is heard. This redesign taught me that every small choice — like clearer navigation or a transparent changelog — is a chance to reinforce that trust.
In short:
You don’t need a dedicated design team to design well. You need curiosity, care, and a willingness to listen deeply and evolve together. That’s how we built something sustainable at PKP — and it’s what I’d hope other open-source projects carry forward too.
How do you balance the needs of users who are tech-savvy with those who are less experienced with digital tools?
Balancing the needs of both tech-savvy and less experienced users isn’t about creating two versions of the same platform — it’s about creating a shared path where people can move at different paces without feeling left behind or boxed in.
At PKP, I didn’t see users as “beginner” vs. “advanced.” I started seeing them in terms of where they are on the learning curve — and how we can design for movement, not just comfort.
That shift changed everything. Instead of thinking about simplicity versus. depth, we focused on progressive empowerment: making sure users could start small, gain confidence quickly, and uncover more control as they grew.
For example, we tried to avoid hiding important functions behind jargon or icons that assumed prior knowledge. Instead, we leaned into transparent language and context-aware actions — so users knew what something did before clicking it. And for more advanced users, we made sure the system didn’t slow them down — adding subtle shortcuts and ways to act faster without sacrificing clarity for others.
Another thing I learned is how important it is to design for graceful failure. A big reason newer users struggle isn’t that the tool is too complex — it’s that the consequences of getting something “wrong” feel high-stakes. So we designed ways to let people explore safely — offering warnings, previews, undo options, and smarter defaults that reduce pressure without taking away control.
What helped most was staying close to both groups. Tech-savvy users showed us where speed and efficiency mattered most. Newer users showed us where assumptions were breaking down. And in between? We found shared patterns — like the need for reassurance, clarity, and flexibility — that shaped how we built flows and framed choices.
So in the end, the goal wasn’t to split the difference. It was to design for confidence, and let the system grow with the person using it. That’s how we honour PKP’s values — not just by being accessible, but by being encouraging.
🎤 Wrap-Up
Is there a particular part of the new design you’re most proud of?
The part of the redesign I’m most proud of is the submission dashboard — not just because of how it looks now, but because of what it represents.
The dashboard is the first thing many editors and journal managers see when they log in. And before the redesign, it often felt like a wall of tasks — cluttered, unclear, and unintentionally overwhelming.
What I wanted to create instead was a space that felt anchoring and empowering — a place where users could immediately understand what’s happening, what’s waiting on them, and what they can move forward.
What made this work meaningful was how many different types of users it had to serve — some managing hundreds of submissions, others just a handful. The challenge was to design a system that could scale in complexity, but still feel intuitive at every level.
That meant thinking not just about UI, but about information design, pacing, and cognitive flow. We reduced unnecessary noise, highlighted next steps, and made it easier to triage and plan so users didn’t have to work to see their work.
But more than that, I’m proud of the shift in feeling. After launching the new version, several users told us the dashboard now felt calmer. That really stuck with me. Because designing for usability is important — but designing for emotional clarity? That’s where we start to make real change.
The submission dashboard redesign reminded me that even small interactions — like a status tag or a timeline indicator — can carry weight. And when we design with intention, those little moments can give people more focus, more confidence, and more time to do what matters.That’s something I hope more teams — inside and outside open-source — carry forward: design isn’t just about getting users through a system. It’s about helping them feel more capable while they’re in it.
What do you hope users feel when they first interact with the updated interface?
What I hope users feel, first and foremost, is relief. A quiet sense of, “Okay, I can do this.”
That feeling matters — because so much of academic publishing is high-stakes, high-pressure, and time-constrained. And when the tools we give people add more confusion instead of clarity, it only makes that work harder. So when someone opens the new interface, I want them to feel a little lighter. Like the system is on their side.
I also hope they feel seen. That the language makes sense to them. That the steps are clear without being controlling. That their role — whether they’re an editor, an author, or a reviewer — has been considered with care. Because what we design isn’t neutral. It either includes people or leaves them out. My hope is that the design signals inclusion at every turn.
And beyond usability, I hope there’s a quiet sense of trust. That the interface helps people feel more in control — not just of the software, but of the publishing process itself. That it gives them enough structure to move forward, and enough flexibility to work the way they need to.
If I had to put it in one line:
I want users to feel like they can breathe a little deeper. That this space — this software — is built not just to function, but to support.
That feeling, to me, is the foundation of good design. And especially in open-source, where we ask users to contribute, adapt, and grow with us — I think how we make people feel is just as important as what we help them do.
_________________
Thank you once again, Devika, for sharing your story along the way! How a scholarly publishing platform is designed impacts (more than) final published outputs, a conversation that deserves much attention.
The platform’s standards, workflow, usability, and interface (and how they are arrived at), are aspects that should be transparent and evolving, in-line with community needs and trust-building, as you’ve highlighted in this interview.
Thank you for bringing this conversation to light.
___________________
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.
Jump to other sections of the newsletter
📌 Sustaining open infrastructure together: A warm thanks to TIB
📌 Advancing open publishing: Feature highlights from three years of CRAFT-OA
📌 PKP update on its open infrastructure accessibility work
📌 Inclusive global publishing: PKP Documentation and Multilingualism Specialist Emma Uhl
📌 Regional feature: Canada’s leadership in diamond open access
📌 Coalition Publica’s Tanja Niemann and Kevin Stranack on Canada’s diamond open access future
