UX Case Study—User Interviews 👀

“The difference between ‘Shared with me’ and ‘Team project’ is not clear to me”

“I’d love to be able to search for projects.”

“Is there a way to have more control over projects I’m seeing? I don’t usually need to see my completed projects for instance.”

☝️ This is just a taste of the recent customer feedback from User Interviews—a user research platform aiming to help teams make better, faster product decisions.

My Challenge

🎯 Provide better discovery and organization tools for users to navigate their projects.

Problem #1: Users have mentioned that they need their list of projects to be better organized and more discoverable. Basically, as Researchers and teams use the platform more and more, their list of projects becomes unwieldy.

🎯 Explore improving the visual hierarchy for project cards and the data we decide to display.

Problem #2: The ‘Project Cards’ are not doing the best job surfacing helpful data about the project in an easy to consume and scan way. We should explore improving the visual hierarchy and the data we decide to display.

Before we dive in, let’s provide some context…

Let’s look at the existing platform

This is the existing ‘Projects’ tab for User Interviews. A ‘Project’ is essentially a user interview study where a company decides which types of people they want to target, and schedules interviews with qualified participants. All projects fall into one of three ownership categories: 1. My Projects (full edit access) 2. Shared with me (either view or edit access) 3. Team Projects (view access). Projects also have a ‘Status’ (live, draft, or completed).

How they wanted to improve the UI/UX

My task was to:

1. Provide additional functionality to help users navigate within their ‘Projects’ tab
2. Improve the project cards themselves by revisiting the data User Interviews displays as well as the overall information hierarchy.

Technical Feasibility

User Interviews informed me that, technically, they had the ability to easily implement the following solution types:

• Filtering by status
• Filtering by project ownership (my projects, shared with me, team projects)
• Search on a project name

Grouping projects within folders or applying a tagging system would present more technically complex solutions, and should only be pursued if absolutely necessary.

My Approach 🧐

1. Figure out a way to use card space more efficiently → Using the current layout, I’m able to see 4+ cards at a time each including a lot of unused space. Whereas if we shrank the project cards, I would be able to see 8+ at a time. So my initial intuition was to explore more compact cards to allow users to quickly scan through their ‘Projects’ tab.
2. Explore using icons to more clearly indicate project ownership → One of the popular areas of customer feedback was not understanding the difference between ‘Shared with me’ and ‘Team Projects’ and also not being able to easily identify the ownership of a given ‘Project.’ Admittedly, this was the #1 area of confusion for me as well. The especially tricky ownership type is “Shared with me” because you can either a) have permission to manage, or b) only be able to view (similar to Google Drive). So the concept I explored was using the icon color + matching button color to indicate whether or not you have been granted edit access or only read access
3. Using button color to indicate ‘Project’ access → Given the current UI, the only way to decipher my access level for a given project was to see the button text change from “view” to “manage.” This wasn’t 100% clear at a glance, so I decided to use grey button colors to indicate ‘view only’ access and colored buttons to indicate ‘manage access.’
4. Break all available data points into 3 buckets given prior customer feedback (in order to understand updated information hierarchy)

a) Top Priority data points that are needed to see at a glance to know if you want to click into the expanded project detail view.

• Internal Project Name + Project Status + Project Owner + Project Ownership (shared/owned/team) + Requested/Scheduled/Completed

b) Lower Priority data points that only need to be viewed once a user has drilled down into the expanded project detail view.

• Creation date + external project title + length + audience type + qualified applicants + no-show applicants

c) Data points that could potentially fall into bucket a) or bucket b) and as a result need to be incorporated into multiple iterations and testing environments.

• Interview type

Initial Concepts

Improving the ‘Project’ card layout

From there, I began simply pen and paper sketches to get to the point where I could take a stab at some initial layout concepts to review with the team which you can see below 👇

👀 Key Takeaways

• You can see that I am actively exploring different concepts that either include or hide the interview type (ex: “1–on-1 interview”). This data point was listed as somewhat important (and was placed in data bucket c.) in our initial deep dive so I wanted to be sure to account for both options so that we can effectively test.
• I went with the more compact approach in order to help users understand key project information quickly, and also more easily skim through all of their existing projects.
• Projects have sub-actions depending on project ownership that a user can take (mainly, “delete”, “duplicate” and “share”). I explored two different concepts for these buttons. First, is including them in a dropdown on the edge of the primary button. The second was placing them in a sub-menu opened by the 3 circles button in the top right of concept #4. In the off chance that these buttons should be displayed on the expanded view only, I opted to leave the sub-menu off of concept #3, but this is definitely not what I advise.
• I added icons to indicate project ownership (the mockups above are focusing on the “shared with me” ownership because it is the only one where you can have either ‘read’ or ‘edit’ access depending on the permissions that have been granted to you. Green icon + green button = edit access. Grey icon + grey button = view access.

Creating more advanced navigation functionality

Challenge #2 was to add additional navigation features so that users can more quickly find the right projects. Given the technical limitations, the proposed feature set was relatively straight forward. It is important to note that I updated the existing toggles to include the ownership icons to help cement them into users’ minds and allow for more clear UI on the project cards.

Taking things to high fidelity 🚀

Once I uploaded the different card variations into Zeplin, I wanted to go in-depth to understand all of the different card states using solution #2 as well as implementing the proposed navigational improvements.

Card states can be determined by the following criteria:

1. Project ownership (My Project, Shared with me, Team Project)
2. Project Permissions (View access or Edit access)
3. Project Status (Live, Draft, Complete)

👀 Key Takeaways

• Users can now see 8+ projects at a time(instead of 4) given the more compact design of the cards
• Users can easily search for projects, use project ownership toggles, or filter by project status
• Project ownership is more clearly displayed by using icons. These icons along with the buttons also indicate edit vs. view access by using green vs. grey fills.
• Project status no longer looks the same as the button and is supported by button color.

Final Improvement

My goal is never to stop at improving the user experience. I also want to make things easier for engineering and heighten the flexibility/adaptability of the platform as a whole.

I would consider the initial layout to be far more rigid, as any additional information would break the current CSS rules and require updates to the frontend code 👇

Now let’s look at the updated card layouts☝️ As you can see, if I want to add something like “Interview Type” in the example on the right, none of the spacing rules require changing. The height of the card simply adjusts…easy as that! This way, User Interviews can easily examine data points in bucket c) that require a bit more feedback in order to determine whether or not they are needed for the project card preview. In the improved card layout, running A/B tests require 0 additional frontend layout updates.

One final look 👀

Thanks for reading 🙏