SAAS . PRODUCT DESIGN . UI DESIGN

Article & journal publishing & management solution (NDA)

My role

Product Designer

Timeline

40 Weeks

Team

Sole Designer & Team of developers

Tool & Skills

NDA Documentation . Adobe XD

My role

Product Designer

Timeline

40 Weeks

Team

Sole Designer & Team of developers

Tool & Skills

NDA Documentation . Adobe XD

Context of the project

iCodex Publishing Solutions is a Pune-based B2B SaaS company working in the academic and scholarly publishing space. I joined as the sole UI/UX Designer, working directly with the CEO. The technical architecture and workflow logic were already defined at the backend; my role was to translate that foundation into real, usable product experiences.

My contribution

I designed both products (I didn’t code these two products that magic was done by the developers. So, cheers to them! 👏), which are now commercially live and form part of the company’s product foundation. This case study focuses on my initial learnings & introduction to a larger ecosystem of products within the system. I was part of the team working on an article publishing & journal management system essentially, a platform that helps organize articles from different publishers, bring related pieces together into structured publications, & make sure those publications end up in the right place. Think of it like a digital library: an article is one piece, a collection of those related articles can become a research paper, journal, or book, & the journal system helps organize where that publication belongs Sports, Health, Food (Gosh, I’m definitely getting hungry while making this portfolio… anyway, let’s continue.), Technology, & so on.

Note: This project is under NDA, so I can’t share the full details publicly. I can tell you what the product does & how it works. but the finer details of how it actually works stay under wraps 🤫. But yes, I really did work on it, I’ve got the project trail (and the Skype meeting history to prove it 😄). If you’re curious about the system, the thinking behind it, ping me up. I’d be happy to talk you through it.

Process

The process followed a clear progression: understand the domain & the workflow, map the information architecture for each product, validate structures through wireframes, build out the full UI, & then refine based on testing and feedback from the CEO & team. Each stage fed into the next, & going back to an earlier stage when something wasn't working was expected

Product #1 : Article publishing platform

Imagine you’re a researcher who has spent years working on something meaningful lets say, the relationship between screen time & eating habits in children. After hundreds of hours of work, you’re ready to publish it in an academic journal to give it credibility & reach. The problem is that the submission process has traditionally been confusing, inconsistent, & poorly designed. Different journals have different requirements, forms are often unclear, & once submitted, authors have little visibility into what’s happening to their work. The Article Publishing Platform was designed to solve this creating a clearer, more structured, & human-centered submission experience.

So, how does it work you ask?

The platform guides authors step by step through the submission process. Authors selects the journal, specify the article type, enter details. Once submitted, the platform tracks the paper across the entire pipeline, providing clear & readable status updates all the way through to publication.

Product #2 : Journal management system

Now look at the problem from the other side beyond the author. Think about a publisher, managing hundreds of journals across disciplines like medicine, psychology, agriculture, engineering, & economics. Each journal carries a large amount of operational complexity ownership details, regional management, article types, layout rules, editorial teams, compensation structures, printing workflows, financial agreements with academic societies, & more.

Before Journal Information & Management System, this information was scattered across spreadsheets, emails, & documents distributed across teams. Access depended on knowing who had the information, & updates relied on manual communication. The system was fragmented, & difficult to manage at scale. JSLD was designed to solve this bringing all journal-related information into a single, structured, & reliable system.

So, how does it work you ask?

The system acts as an internal control panel for publishers, used by management to store, access, & manage journal data in one centralized, role-based system. Each journal record is structured across key categories. Each category contains its own set of sub-sections, fields, & relationships, forming a deeply interconnected system. The challenge was to design for this level of complexity while keeping the experience navigable & efficient not just for technical users, but for managers who need to move quickly through their workflows.

So, whats my honest takeaway & learnings

Both platforms are commercially live and serving real clients in the academic publishing industry. These aren’t portfolio concepts or prototype demos they’re functioning products being used by publishers and their clients. The biggest lesson I took away from iCodex was how closely domain knowledge and design quality are connected. Taking the time to understand the industry’s vocabulary, hierarchy, workflows, and the way people actually work wasn’t optional. The better I understood the domain, the better my design decisions became. Being the sole designer also meant taking full ownership of the decisions I made. There was no one else to pass them on to, which pushed me to make decisions, defend them, & learn from them much faster. Working directly with the CEO gave me an early look into strategic conversations that usually come much later in a designer’s career. Understanding why something needed to be built not just what needed to be designed changed the way I approach stakeholders & client relationships. And perhaps one of the more unexpected things I learnt was how to document work that you can’t fully show. Working within an NDA taught me to separate what could be communicated publicly from what needed to stay confidential, while still telling a meaningful story about the problem, process, contribution, and learnings behind the work. Ultimately, iCodex taught me that good product design isn’t just about making the interface work. It’s about understanding the ecosystem the product lives in, taking ownership of your decisions, & knowing how to communicate the thinking behind them.

Create a free website with Framer, the website builder loved by startups, designers and agencies.