ActiveDisclosure

*Note: I am under an NDA for this project, so I am only sharing information that is public or already implemented.

Case Study By John Lattanzi

Overview / TLDR

• Product: ActiveDisclosure

• Type: Enterprise SaaS, Financial Disclosure Platform

• Timeline: Jan 2022 – Present

• Team: 3 Designers, 6 Product Managers, 13 Engineering Teams

• My Role: Lead Product Designer (Promoted twice during project)

• Tools Used: Figma, Miro, Lucidchart, Azure DevOps

• Outcomes: Helped grow product to 14K+ client sites, 42K filings/year, and contributed to 17% YoY revenue growth

Challenge

Financial reporting professionals (controllers, SEC reporting managers, and legal teams) face pressure to file reports accurately and under tight deadlines. If they fail, they risk being audited, legal penalties, or worse.

The previous version of ActiveDisclosure suffered from poor collaboration workflows, version control confusion, and a rigid editing model that didn’t reflect users’ mental models of how financial documents are prepared.

How might we offer reporting professionals peace of mind during their high-stress peak season?

Goal: Reduce filing stress, build trust for our users, and ensure clarity of the financial documentation.

Business Goal

DFIN aimed to improve customer retention, reduce support burden, and ensure regulatory compliance for its users by modernizing the filing experience.

KPIs:

• # of filings per year

• # of client sites

• # of active users on the platform

• # of annual revenue

With a focused approach, we were able to take the original ActiveDisclosure and modernize it.

Process

Human centered design and design thinking is key for this project - we believe you must:

Design the right thing, then design the thing right.

We work closely with PMs, stakeholders, engineers, and users. We conduct interviews with existing and potential customers, help PMs establish a vision for the product, and design iterations for every story.

We design, iterate, and deliver as one team.

Discovery & Research

To ensure we were solving the right problems, we partnered with PMs to conduct ongoing user interviews with current clients. Over time, we built and maintained a living backlog of user problems, discussions, and hypotheses. These were used to validate our features, prioritize user stories, and shape quarterly roadmaps collaboratively with PM and engineering leads.

• Validate pain points for different user segments

• Prioritize feature opportunities based on urgency, business value, and technical feasibility

• Shape quarterly roadmaps collaboratively with PM and engineering leads

After this process, we’d take the designs back to the engineering team to ensure we met all edge cases. Then, we’d update the user story with the approved designs, add in future ideas into our design debt backlog, and plan our next sprint’s work.

Solution

ActiveDisclosure’s offerings changed significantly through my time on this product - we had 15 major releases in 2024 and that number is set to go up in 2025. Of all the features I’ve designed, there are a few I’m particularly proud of:

• Pagination

• Compare Grid

• Ribbon Redesign

• Design System Rebuild

Pagination

When editing financial documents, there are multiple different forms you need to submit. Some forms require a structured format and some are free-form. We offer multiple editors based on the form you’re editing.

Context: These were the two editors that existed when I joined.

• Section-based editor: The first forms users filled out on our platform were 8-Ks, 10-Qs, and 10-Ks. This required users to upload documents and tables into our sections and use text to describe their documents. This section-based editor was able to be edited by multiple people at the same time, but only one person could edit a section at a time - they could also hide sections if they weren’t ready to be visible yet.

• Form builder: There are plenty of forms that don’t require text or document uploads, so we built forms that can be easily built and optimized over time.

User Goal: Within free-form editing projects, users need to be able to flexibly edit their content, manage content permissions, and understand the total context of the document before filing.

Brief: Optimize the free-form editor to match mental models for document editing, similar to Microsoft Word or Google Docs. Users need to be able to understand where they are in the document, what the final export will look like, what sections are hidden, and where other users are editing.

Process: We began this process by reviewing the insights that led us to the original design.

The editor had users creating new sections for new content. Within each section, you could set permissions to not allow others to see or edit your content in the case it was private or in progress. This editor strived to help users focus on adding the content before worrying about the way the form looks.

“My team just needs to add in our Excel tables and explain them. We can review it as a team at the end, I’d rather worry about how it looks later.” - User Interview quote from 2021

This insight lead to a content-block approach with a print preview feature for them to review as a team at the end of the filing process.

With that in mind, our next step in the process was to do additional user interviews to understand their exact goals. We learned the current flow worked for smaller teams, but larger teams felt this was a disconnected process and wanted it to function more like Google Docs because that was becoming their mental model. We also learned that as more users used print preview, the more they preferred to see the full context of the document in the beginning - seeing it separated made it feel disorganized.

So, we began designing what a paginated editor could look like. Luckily, we already had an editor that could be set to a specific height and width, but content did not go from one content block to another. Our biggest challenge was a technical one - changing the section logic to be embedded within pages and understand how to use a Slate editor to have content flow logically.

A few examples of new hurdles we had to consider for a new editor type:

After multiple rounds of investigation with our engineering teams about all cases we’d need to design for, we built prototypes for every way you could interact with the editor to see if it matched their mental model better. We received ecstatic results and asked us when they’d be able to use it.

It took a full year of technical effort to get an MVP to our users through an alpha and beta release through feature toggles, but we were eventually able to deliver on our promise.

Phase 2: Expand co-editing capabilities and paragraph-level formatting. With our MVP release, only one user could edit one section at a time - now users can edit one content block at a time (line level). Additionally, we now had options for multi-column editing. This further improved our users’ experience and helped them feel more in control of their document.

Phase 3: We’ve expanded this editor into presentations and AI-assisted form building. This sped up our users’ filing process and helped keep all document editing in one platform.

Findings: Now, users can view their document as it is going to be exported and printed, simplifying their review process. They can also feel more in control when editing their document, offering them peace of mind that their form will be ready to file. Seeing the positive reactions to our prototypes during the research process and from our alpha testers when building their first project in the paginated editor made this whole process worth it. It felt great to give them what they wanted.

Compare Grid

Within the iXBRL team, we utilize a grid to see all tags within a pre-defined area at once so you can compare your tags and ensure your document is tagged correctly.

User Goal: Users need to be able to see all of their tags in a document so they can ensure they’re submitting the right information to the SEC or other government agency.

Brief: Accountant users need to be able to see changes in tags based on the tag’s value, the tag’s attributes, and/or the tag’s attributes. They need to see when tags have been added, what tags have been deleted, and when existing tags have modifications; tags also need to be grouped by their preferred label role, date, and dimension (group).

Process: We began this process by interviewing users to determine their biggest pain points. Through discussion, we learned users were either reviewing tags one at a time within ActiveDisclosure or exporting all of their tags and comparing them through Excel documents - both of these were frustrating and time consuming. However, the biggest pain point was not seeing all of your tags at once. One user said they could open a separate version of the document in another browser and compare them there, he just wanted to see them all at once.

So, we began designing the grid. We started by determining the hierarchy of information to build this table based on how they review tags and what matters the most to them. Below are a few initial design concepts for v1:

Afterwards, we tested these with users and their feedback helped us tighten our design. We went through multiple rounds of feedback and iteration before we began building and constantly tested with users as we built the grid. And by a lot, I mean a lot.

However, when the dust settled, we ended with a grid that solved users’ needs and gave us something to build upon for compare.

Our next step was to define every possible change that could occur when comparing versions of a project. We created several hundred use cases of changes and eventually built out documentation to lay out how it should function for each scenario.

Compare also extends past the grid. We needed to track all the states for individual tag details, our facts navigator, and our tag index. Applying all the same style changes was complex, but we utilized Figma's variables and other tools to accomplish this quickly.

Findings: Now, users can view all tags in their document at one time and see what changes have happened since they last saved a version. They can approve changes in bulk and file their documents with confidence. Seeing the validation on users’ faces when we showed it to them was an incredible experience and I had such a great time working with them.

Ribbon Redesign

When I first joined the project, our toolbar was small and concise. However, as we continuously added features and editing capabilities, we needed a way to display more information within it.

User Goal: Users need to be able to see all editing options in the editor without it overtaking the screen.

Brief: Users want to be able to see all editing options for the toolbar while they’re in the document. We had much of the typical paragraph editing fields visible at all times, but much of the functionality was hidden behind a button (shown below):

We wanted to see how we could make all of our functionality visible to users, potentially following mental models set by Microsoft Word and Google Docs.

Process: We began this process by interviewing users to determine their biggest pain points with the current experience. Many users who have used the product for a while were ok with the current experience, but found it annoying always opening menus instead of just clicking their desired button. Users who were newer to the product found it hard to learn what our functionality was because it was hidden behind a menu. Seeing frustration in our users, I wanted to investigate.

I then started looking at other platforms to see how they organize their toolbar.

Google Docs had a toolbar that looked very similar to ours, but hearing the frustration from our users, we wanted to see what a new option could look like. Microsoft Word’s ribbon was very interesting and we wanted to see what that might look like for us.

I started by doing a card sorting exercise to see where we could place all of our functionality if we were to make it more visible. I pulled all functionality out of our menus and our modals to see what was possible.

I started exploring potential designs for how we could improve our toolbar if there were no guardrails. I started by creating new icons, restructured our information architecture, and set up new workflows for our users. Here are a few options we A/B tested:

Through those tests, we got a lot of great feedback and ended up with a ribbon design that we pitched to DFIN to include in their design improvements feature. There were several open stories to add new features into our toolbar, so we displayed the graphic below to offer the option to store all information a bit differently, making adding those features much easier.

They loved the idea and wanted to see it implemented as quick as possible. It took priority over a few of their originally planned features and the engineering team got involved to make it as functional as possible. It was a great process seeing your idea come to life from an insight you found in an interview to production.

Phase 2: We are continuing exploration on ways we could improve the toolbar, including ways to implement tabs for the different forms you may be working on simultaneously, improving search results, and adding more space for additional tabs. This is TBD, but something the product team has expressed interest in continuing.

Findings: Validating user pain points and expanding features to make the engineering process easier was a great hit. It helped the design team have a stronger opinion on future priorities, where our ideas are now included as design debt within sprints.

Design System

When I first joined the project, our design system was a dysfunctional component system. Every design that was shared with engineering had broken components, screenshots overlaying screens, and a very inconsistent feel to the system. Because of that, the platform itself was pretty dysfunctional from a design perspective and I aimed to improve it.

User Goal: Designers need to be able to track all components live on the platform, have a source of truth design folder, and have a shared design language that all designers champion.

Being the user for what we were designing was quite fun. I knew what I wanted to see in a design system and how I would work best. However, I wanted this to be transferable to any other designer onboarding onto the project. So, I spoke with many designers at my company on best practices and ideas. We landed on calling the system Valkyrie because our project has many Thor references within it (long story). Valkyrie is a fierce warrior and built trust with Thor, becoming a key ally to him. That is how we view our partnership with our engineering team and the rest of the designers loved it.

We built out our component system and have turned our design system into a replacement for storybook. The engineers have full access to it, we have built technical data into our designs, and everything matches the current state of our dev environment. Our hope would be that this would be easy to use and actually used by the engineering team.

While there is still work to do, like further documenting our design language, I’m so proud of how far the team has come.

Findings: Now, designers have a shared design system that can be updated easily and context from designs can be shared rapidly. Going from needing to know what Figma file a component was in to replacing storybook was a great experience and made me proud of the design team.

Other features

Ribbon, Certifications, Tie-Outs, Section 16, and Tenant Hierarchy are additional features I’m immensely proud to have been a part of for the last 3.5 years. Happy to share some information on them at request.

Results

42,000+ SEC Filings in 2024

14,000+ Client Sites

DFIN’s goal was to improve customer retention, reduce support burden, and ensure regulatory compliance for its users by modernizing the filing experience.

Over the last 3.5 years, we’ve focused on modernizing ActiveDisclosure to offer customers peace of mind and reduce their stress when they navigate high-stress filing peaks. Through this work, we helped DFIN’s net revenue increase by 17% year-over-year, increased customer retention, and helped customers through our end-to-end solution.

Demos

The client put together demos for their sales team - I do not own any of these videos.

Conclusions and Future Recommendations

In the spirit of Agile, there is always more to do. There are plenty of opportunities to grow this product, especially utilizing AI. I won’t speak specifically to their plans or what we have cooking, but I can’t wait to see how users like it!

Personal Findings

I learned so much through my time on this product. I gained a lot of trust from the product owners through our time working together, which gave me a lot of freedom to try new ideas and experiment with existing solutions. From being overwhelmed by the sheer size of this product to leading the charge for design, I loved working on this so much. I am so proud of this product and I am very excited to see what’s next!