Soda PDF is a SaaS that enables users to view, create, and edit Portable Document Format files. It was originally developed as a standalone application by LULU Software (now Avanquest) in 2010, Montreal, Canada.

Three months after the release of Soda Online, the team was happy to observe

18%

improvement in user conversion from trial to paid accounts

Soda PDF first started as a one-time purchase, standalone desktop software. Later, the company transitioned to a SaaS model. To offer a convenient way to quickly accomplish popular PDF-related functions, “Service pages” were added to the website, doubling as landers for both organic and paid traffic. A limited online editor was also introduced, with an UI based on the desktop program.

Interface-wise, early versions of Soda PDF mimicked the feel of Microsoft Office at that time. Then, starting with version 12, the software was redesigned to have its own, more distinct style. However, with lack of a fleshed out design system and many new features being added over time, inconsistencies in the UI had started to appear.

I joined the Soda PDF product team at the time when version 14 was being developed. My mandate was to help make the user experience more coherent by tweaking to some of the flows, wording and UI.

After the successful lunch of Soda 14, based on fresh feedback from users, the company developed a clear roadmap for major upcoming features. A plan was formulated to shift Soda PDF from a primarily desktop application to a fully featured online editor that would work seamlessly across devices.

We needed to create a new, online-first vision of Soda PDF. That version would initially be released with only the main, most commonly used features. The reminder of the old functions, as well as the planned new ones, would be prioritized and then deployed as development time allowed. When feature parity was reached with the desktop application, the online variant would be packaged as a replacement for the standalone desktop version of the software.

I had the pleasure and responsibility to take point on the Soda Online design.

• the new version of the app had to seamlessly bridge the the experience across desktop, mobile and web 
• it had to stay sufficiently consistent with the mental model existing users had
• unifying the extensive amount of features in Soda PDF added significant complexity to the project
• due to incomplete in-app tracking, we lacked precise feature-usage statistics
• public perception of Soda PDF needed to be improved, with the Trustpilot score set as the main metric

My first step was to completely immerse myself in the software, using and getting familiar with its every aspect. During that process I quizzed colleagues about some of the more obscure functionality, how and why we came to have it.

I then tested competing offering from Adobe, Wondershare, Nitro, Foxit and others, and looked at the feedback they were receiving online. I spoke with team members about how they saw the differences between us and the competition - what they thought we did better and where we were behind.

My next step was to build an image of how the world perceived our current app. I examined online reviews and rating sites like Trustpilot and G2. I then proceeded with aggregating data from support tickets and interviewing members of our support department about their interactions with our users. AI tools, ChatGPT being premier at the time, helped greatly in parsing and summarizing the information.

To help improve the the information architecture in the app, I conducted a card sort with our internal cross-department test group. In addition to sorting the features into groups according to how they thought the features belonged, I asked participants to also mark which features they used the most, and which, if any, they hadn't realized we offered.

With that knowledge, I could start work on the design. The following are some of the highlights.

Due to its iterative development and lack of a design system at the time, Soda PDF was somewhat inconsistent in its interface. This was most noticeable when it came to where certain features were located and how the menus and dialogues they opened would appeared. Based on the accumulated feedback and the long-term vision for the product, I set to create a coherent layout that better allowed for the product's growth and integration with the rest of the Avanquest ecosystem.

The leftmost side of the screen was reserved for major service categories, helping improve visibility and ease of access.

The "system zone" at the top became home to account, search and other top-level functions that carried across from service to service.

The "tools area" and "side panel" zones housed elements that changed depending on the task the user was preforming.

With the updates to the information architecture, and the airy direction of the UI's redesign that helped turn the user's document into the real hero, we could provide a more consistent and pleasing experience.

The redesign presented a prime opportunity to establish a design system, to help avoid some of the pitfalls the product experienced in the past and speed up work in the future.

Over the years, Soda PDF had steadily accumulated over 120 features, with quite a few being niche functionality requested by specific clients. That had made parts of the interface somewhat unwieldy, resulting in an experience that could feel overwhelming to new users.

Under the argument of expanding our addressable market, I received the green light to give the app’s mobile experience the long overdue attention it deserved.

An important step of the process was to identify the differences in how clients use PDF on desktop and mobile, and then ensure the new interface accommodated for those needs. To succinctly recap the findings, desktop skewed towards authoring, while mobile tended to be more centered on viewing, signing and filling out documents. All the same, the mobile version still needed to provide a well-rounded editing experience. Making sure touch controls were properly utilized was also a big part of that.

In the previous version of Soda, a lot of document organization operations were handled through pop-up windows where users had to manually enter page ranges. Those modals would cover the document view, making it necessary that users memorize which pages they wanted to move, split, extract, etc. To manage this, many users ended up having to write down the necessary page numbers beforehand, or to open another instance of the document in a separate window. This was a considerable inconvenience, especially when working with larger documents. 

To improve that part of the experience, I merged the features for inserting, extracting, and moving pages (as well as for merging and splitting of documents) into a single cohesive interface. The option to manually enter page numbers was still available, but users could now finish the desired task conveniently through a visual representation of their document.