Overview

Workiva’s existing solutions were loved by customers, but our team saw a way to take things even further.

At Workiva, Inc., our customers needed to embed their financial documents with XBRL (a machine-readable finance language based on XML) in order to be compliant with the SEC’s financial reporting requirements. While Workiva’s existing software made this process much easier, it was still long and laborious. There was a lot of guesswork, errors, and reliance on our internal customer support teams. This resulted in inconsistencies in XBRL between customers, which in turn made the data in those financial documents less-than-useful to data aggregators and government bodies downstream.

To address these issues, the XBRL product team leads (myself included) met up with a Subject Matter Expert (SME) on XBRL and SEC financial reporting to create a novel solution.

Problem Statement

How might we further improve the XBRL reporting process for accountants when risk-aversion and process inertia impede significant change?

Users and Audience

At Workiva, our primary users were accountants, who worked at our client companies to track and report their finances. Workiva’s tools have radically transformed the financial reporting process, making things much easier and faster. For this endeavor, we saw an opportunity for a new, potentially disruptive change.

Roles and Responsibilities

I worked alongside the leadership of my team, and experts from the company, to devise a plan for this solution.

In my role at Workiva, I was the UX designer on the XBRL team. I worked alongside our product manager and our tech lead to jointly determine which problems we would solve, and how we would solve them. We also had a large group of software developers on our team, as well as a dedicated UX researcher, a UI designer, and a UX content writer.

For this project, our product triad (meaning myself, the product manager, and the tech lead) and our UX researcher collaborated with the aforementioned XBRL SME, as well as the Director of UX at Workiva. My role was to act as facilitator for the ideation and storymapping exercises we conducted. I also contributed my own XBRL knowledge to the discussion, while keeping the user’s needs in mind as we worked. Down the road, I also created interactive prototypes for testing our ideas, and conducted user testing sessions to validate our hypotheses.

Scope and Constraints

Our solution had to play nice with the existing application, and present a familiar process in a new way (that would hopefully be easier to use).

Our scope of work focused on one XBRL taxonomy (which is a dictionary of definitions and standards specific to a particular regulatory jurisdiction). This initial market was where we would make the greatest impact. As this was updating the solution that customers were already using, these improvements had to integrate into our existing XBRL tooling. This was further compounded by the complexity of Workiva’s flagship application, which our solution had to fit into; minimizing screen real-estate and clutter were top priority.

Challenges

There were two main obstacles for this project. First, we had to streamline and abstract XBRL tagging (a very complicated and esoteric process) into something that any accountant could sit down and wrap their head around. This meant hiding a lot of details and making a lot of changes “behind the scenes”, where the user wouldn’t see them. Second, this was a paradigm shift at a fundamental level. We were uniting two previously unrelated parts of the financial reporting experience. The design work was as much about ensuring users would be comfortable with the new process, as it was about making sure the new process was usable.

Process

User Story Mapping – Problem Space

We created a story map to capture all the aspects of the problem space.

We began with a multi-day story-mapping session, wherein we worked with our SME to better understand the scope of what we were solving. The focus was not just on the user’s experience, but also on understanding the requirements from the SEC. We frequently used story maps at Workiva as a means of creating shared understanding about a complex, multi-layered process. They allowed us to tie specific development/design plans back to elements of a larger story, which aided in prioritization.

Ideation Session

We generated many ideas quickly, writing them on sticky notes.

After that, we had a large ideation session, writing ideas on sticky notes, which we then grouped together using an affinity diagram. This kind of ideation session allows everyone to generate many ideas quickly, regardless of drawing ability. And the affinity diagramming technique is useful to find patterns, which can be good for identifying features or problem spots.

User Story Mapping – Future State

We created a second story map based on our ideas.

We then conducted a second story mapping session, to build out the rough outline of what our proposed solution could look like. This diagram included a horizontal “swim lane” breakdown, wherein various pieces of the story were split into rows. Each row represented a point in the release timeline, so we could prioritize which features to develop for which iteration (e.g. MVP, MVP +1).

Technical Deep-Dive

I met with our SME to discuss more complex usage scenarios.

A few weeks later, I flew out to Washington, DC, to meet up with our SME to discuss the design solution in more detail. We focused on how we might address more specific user scenarios in the design. Those scenarios were fairly complex, so it was well-worth the trip to work with our SME in-person on this.

Interactive Prototype

I created an interactive prototype to use in user testing.

Using the content we gathered from our various story maps, ideation sessions, and technical deep dives, I created an interactive Axure prototype. This solution was complicated enough that a digital prototype was necessary to convey the information. After several iterations of internal feedback and revision (our UX team held periodic critique sessions), it was ready to be tested with customers at Workiva’s annual User Conference.

User Testing

I tested our design with eleven users at our company conference.

Over the course of the conference, I conducted (or helped conduct) eleven testing sessions. We learned about our customer’s current XBRL processes, and then showed them our new ideas. The responses were mixed (as to be expected with any new solution) but we collected a lot of data, which gave us fuel for the next round of design and testing. Testing with so many people was highly valuable; 6-8 participants is what I usually aim for, but we had no shortage of interested parties.

Solution

Our proposed design was a large modification of our existing XBRL tagging system. The design reframed XBRL into terms that accountants were more familiar with, and leveraged processes accountants were already doing in order to embed the XBRL in their documents with minimal thought or effort. (For the sake of respecting Workiva’s NDA, I am unable to provide more specific detail.)

Outcomes and Lessons

Outcomes

I concluded the project by putting the design assets and research findings into an accessible location on our team drive, and explaining the next steps for the work. The project was subsequently handed off to another designer at Workiva, and as of writing this, is currently on hold.

Lessons Learned

Always begin with a clear understanding of the problem. While the project was never implemented during my time at the company, we were able to learn a lot about the problem space, explore several new ideas, and allow the R&D organization to make more informed decisions about our XBRL solution.

Process exists for a reason. More personally, this project was a great opportunity to follow the discovery process from beginning to end. We went from a complicated and esoteric problem space, to a testable solution, and gained valuable insights along the way. I also increased my appreciation for in-person communication of complex ideas.