Rebuilding Archie

We began to see significant interest in Archie from non-agency industries like hospitality, events, nightlife, and edtech. While they shared similar challenges with agencies, their need for efficient workflows was more urgent. They were more willing to invest in a tool that provides immediate solutions to streamline their operations.

While these industries needed most of our existing features, they required more flexible workflows. Technical decisions made when building Archie limited our ability to unlock certain workflows or implement major feature changes. For instance, Archie requires users to create a project before any other action, and these industries viewed projects as useful but secondary to paying invoices.

The current state of Archie could never meet the needs of these industries.

We explored the options of modifying or rebuilding the app to accommodate these industries and found that starting over would be significantly faster than fixing the current version. After careful deliberation and risk assessment, we chose to rebuild the app from scratch to achieve the flexibility we envisioned. We knew this decision might cost us deals in the short term, but the long-term benefits of unlocking Archie's full potential far outweighed the risks. With that, we began planning the rebuild.

To understand how Archie V2 needed to be structured, we needed to start by conducting user research sessions with prospects and existing customers to thoroughly understand their operational workflows—from onboarding vendors to sending payments. This provided insights into organizational structures, major pain points, areas of opportunity, and workflow patterns.

We then mapped out their workflows in Figjam which provided insights into organizational structures and processes.

We also noted the tools they used for each function at each phase. We identified clear patterns based on client size, which helped us tailor Archie V2 to fit varying client needs.

Each customer had different things to say, but they all mentioned the same features that would 1. Allow prospects to shift their vendor and invoice operations onto Archie and 2. Allow exiting customers to process more invoices in Archie.

The features mentioned were:

•  International payments

•  Artist / agency handling

•  Accounting system integration

•  Complex controls for approving invoices

These features would require a lot of time and additional research, so we knew it was unlikely that they would be built with the release of V2, but we needed to factor them into the rebuild.

I led several brainstorming sessions with the entire team to redefine Archie's mental model. We drew from client feedback, internal challenges, technical constraints, product goals, and business objectives to shape the new framework. Our focus was on these key questions:

• How might we match user workflows of managing invoices and payments in Archie?

• How might we exceed user expectations in Archie?

• How can we build a flexible system that enhances product offerings and adapts to client needs?

• How can we address common user pain points while reducing technical costs?

To get started, I partnered with the Head of Product to outline the business goals and design principles.

I then mapped out the infrastructure of Archie V2. This was bound to evolve as we dived into the implementation of each feature, but it was crucial to create a visual north star to guide the team as we brought our vision to life. This blueprint ensured alignment on the product's architecture and features, serving as a reference point throughout development.

At this stage, we had a clear vision of what Archie V2 needed to offer. While the engineers worked on the infrastructure, I collaborated with the Head of Product to create a master feature list. I made sure to pull from our Client Feature Request database that I had created upon joining, to make sure our plans for V2 aligned with client needs.

We then dumped all features (product and client requests) into Notion, organized by section, and prioritized based on size, technical dependencies, and Sales needs. We then presented this list to the rest of the team for feedback and buy-in.

Throughout the design process, there were multiple instances where I had to pause work on a feature to shift focus to a different feature in order to accommodate engineering needs. This required everyone on the team to remain flexible and open-minded. We ensured open communication channels to facilitate collaboration and address any questions quickly, which was critical to keeping the project on track.

As we finalized each project, we ran the updates by our customers as well as our internal customer success team, since they were closest to our customers. We made the necessary iterations and continued on.

While developing V2, we created Archie's first design system! Collaborating closely with our front-end engineers, we started a "loose" version, recognizing that components would likely evolve, may not be reusable, or could even be discarded entirely. Throughout the process, we emphasized scalability and responsiveness to ensure optimal performance across various screen resolutions.

7 months later, we launched an MVP of Archie V2. There was no loss of key functionality or features — if anything, we built more features. Below were the major changes we made to Archie.

Initially, invoices and payments were built as separate entities within the app, leading to confusion for users who viewed them as a single object. During the rebuild, we prioritized enhancing this experience, recognizing that it was not only a core feature of Archie but also essential for meeting the needs of our new target market. We merged invoices and payments into a unified object called a "payable", introduced detailed status indicators to clearly communicate the invoice's state, and significantly reduced the number of clicks required to find and track invoices.

Invoices and Payments went from this:

To this:

A highly requested feature was the ability to create invoices on behalf of vendors, as well as the ability to edit submitted invoices. We designed for a full page experience to make space for new features that would require additional fields. Additionally, our client interviews and user tracking sessions revealed that many customers didn't have Archie in full-screen mode, with most accessing it on small laptops or tablets. With that in mind, we wanted to ensure a comfortable and efficient user experience across various devices.

Due to the new create/edit invoice experience, we recognized the need to revise the existing invoice quick view. User feedback indicated that the information was difficult to digest. To enhance usability, we transformed the quick view into a more streamlined "view-only" format, organizing information into easily digestible widgets. Additionally, we reduced the width of the sidebar, minimizing the transition between pages and enabling users to check information across multiple invoices more efficiently.

The invoice quick view went from this:

To this:

There were many issues with the Projects feature. First, the drawer view became cluttered when projects had numerous invoices. Second, there was no search functionality to quickly find invoices or vendors. Lastly, invoices were displayed as "Freelancers," which created confusion when a vendor submitted multiple invoices to a project. To address these problems, we revamped the project detail page, making it full-screen, restructured the tabs to separate invoices from freelancers, and added detailed statuses to clearly communicate the state of both vendors and invoices.

The project view went from this:

The project view went from this: