An information architecture exploration in a SaaS product.

The problem

The request history page is an admin-facing page that allows the Verblio internal team to track the history of a customer’s request for content. The page is intended to show all updates made to a request by customers, writers, and admin. Multiple internal teams utilize this page — Ops relies on it heavily to communicate status updates with customers and writers; the engineering team uses this page when bug hunting. The problem, however, was that the page was difficult to understand. A frequent source of confusion and frustration, Verblio admin were often seeking help from teammates in order to decipher the page. This was highly inefficient and cost the whole team valuable time.

Interviews

In order to understand how admin wanted to use the page, what limitations they were facing, and what work-arounds they had created, I interviewed three admin. During the interviews, I had participants share their screens and walk me through typical tasks involving the page.

Findings

1. The most used information on the page was buried at the bottom.

2. The story of the request was difficult to understand. Who performed the action? How did the submissions intermingle with the request? When did these actions take place?

3. Depending on the admin’s screen size, they might not be able to see all of the columns of the table. The table was horizontally scrollable, but this interaction was not obvious.

UI explorations

Finding #1: The most used information on the page was buried at the bottom

During interviews, I learned that the most important information on this page was in the table located at the very bottom. Information in the top sections was needed from time to time, so it was helpful to have it available. However, most of the time users would scroll right past the top two sections and head straight for the table at the bottom of the page.

UI exploration: Cards

UI exploration: New accordion component + reorganization

In this exploration, I moved the table to the top of the page. I further reordered the sections on the page to better reflect the way our admin were using the information. I also played with using our new accordion design pattern; a pattern that was featured in upcoming designs on the customer side of the app. We had not yet used it on the admin side of the app. Though aesthetically and functionally I liked this design, the cost of dev effort was ultimately higher than comparably functional accordion patterns already featured on the admin side of the app.

In this exploration, you can also see the emergence of updates to the table’s information hierarchy. I’ll discuss the table more in section three.

Original table

The changes that made the biggest impact:

• Changed the column headers and reordered them in order to help the story flow.

• Alternate row colors so that at a glance you can discern which time and user the action belongs to.

• Added icons to differentiate the user type (customer, writer, admin, or system).

• Clarified that all times were listed in MST. As a global platform, lacking a clear base for time stamps created a lot of confusion.

• Deleted the ‘Action’ column. With the exception of the creation of a request, this column always displayed ‘updated’. This column was taking up valuable space for a never-changing state.

• Included the email address and user ID number for all users in all places. Admin needed these varying bits of informations for different tasks, so it was crucial to be able to quickly snag it all from the same spot.

• Added hyperlinks to all users so admin could deepen their investigation with a single click.

The submissions section was another section of the page with great opportunity to make the story easier to understand. I added in descriptors so that admin could understand what each bit of information was (writer, request, or client?). I also added in the timestamp so that admin could reference a submission with a row in the table and easily confirm the relationship.

During interviews, I discovered that depending on a user’s screen size, they might not be able to see all of the columns of the table. When the table did not fit onto the screen, it would convert to a horizontal scroll UI pattern. The scroll was not obvious, and was missed entirely by some users. One participant quoted, “The time is usually listed on the right, but then sometimes, like this, it’s just not there.”

I did a round of comparative analysis to see what designers in other industries were doing to address horizontal scroll for information-rich displays of content.

Then I began exploring different patterns in the context of the request history table.

Shadow effect

I decided to use the shadow effect version. When making this decision, two things, in particular, made the choice clear:

1. Sometimes the table was incredibly long. It needed to be obvious to the user that they could scroll even if they were looking at only the top section of the table.

2. The ‘To’ column was one of the juiciest sections of information. It was ideal to show as much of that column as possible.

Sharing the designs with the team

The final phase of this project was sharing my designs with the admin who would be using them to assess usability from the Operations team, and effort to build from the Engineering team.

I created a “mini-fellowship” (Verblio has a strong LOTR community 🧙‍♂️) comprised of three members from Ops to nail down the copy that resonated the most for the column headers. Everyone chimed in with ideas and comments so that we could use the most impactful language on the page. During this process, I also shared the new designs. The Ops members were ecstatic over the new aesthetics, but more importantly, how much easier it would now be to carry out their daily tasks.

To ascertain technical viability, I first met with one dev representative and the project’s PM. We went through the varying design options for different sections of the project and decided which designs best fit not only user needs, but also worked well for the dev team based on technical constraints, component libraries, and time. Finally I joined storygrooming for this feature. Since the dev team is one of the primary user groups of this page, it was extra special to share the new designs with the whole group. Overall they were incredibly excited about the changes to be made and were even happier that the effort lift was on the smaller side.

With sign-off from the team, this project passed to the Dev team for implementation Winter of 2023.