A family of contracts that feels like family
Meta Contract Page Redesign
INTRODUCTION
Rebuilding Meta’s complex contract tool based on forward thinking concepts, refined by user-feedback
I was brought on to Meta's Contracts team to redesign their related contracts system within the broader contracts tool. The primary challenge was to transform complex contract-related information into an intuitive interface that would make a large amount of information across multiple contracts digestible at a glance. The solution needed to seamlessly integrate into both the existing platform and the upcoming beta version for early access users.
TEAM & ROLES
The family that made the contracts family tree
THE PROBLEM
The view of a contract’s connections was unwieldy & unusable
The project aimed to redesign the related contracts panel within the contracts tool. This panel was identified by the contracts team as a significant usability issue. The product team also noted that its clunky implementation caused users to waste hours navigating inefficiently and repeating tasks due to poor design. A Product Requirements Document was drafted to give direction to me before starting on the project.
CURRENT STATE
A related contracts view that lacked context and hierarchy
In the current state of the tool, contracts were nested inside of long, incomprehensible sets of folders. The contracts also only showed their serial number which led to users often clicking in and out of contracts repeatedly trying to find the related or sub contract they were looking for.
TWO STATES OF THE APPLICATION
Building for the live app and the beta
The contracts tool was currently going through a major redesign by one of the other designers on the team. The future state of the app was in beta and was being slow released to a small set of early-access users. Because of this, any new features would have to be adapted to work in both platforms.
THE APPROACH
Adding concept testing to the timeline
Given the significant reliance on the related contracts panel and the importance of a successful redesign, I suggested incorporating a two-week concept testing phase following the creation of initial design drafts. This testing period would not only help us determine the most preferred concept but also gather valuable user feedback, including suggestions and pain points, to inform the development of the best possible v1 of the feature.
THE CONCEPTS
Family tree versus table view
After toying with three early concepts, reviewing them with the design team, and speaking with the key stakeholders, we settled on two concepts to test with our users. We wanted to keep options restricted to two so as not to overwhelm our participants or risk decision paralysis.
THE INTERVIEWS
Hearing directly from the end-user’s mouth
During the script approval process, I collaborated with our Growth Product Manager to define our ideal set of participants. Since engineers were the company's primary target user base, we prioritized participants with an engineering background.
However, I advocated for including one to two non-technical participants to gain valuable perspective on the app from non-technical users. This strategy led us to recruit a group of six participants for our testing sessions.
PARTICIPANTS
SYNTHESIS
Tracking key themes and quantitative feedback
Following the user testing sessions, I spent a week analyzing the data. This included identifying common themes in user feedback and quantifying concept preferences voiced by the user. I also collected metrics around information that users would find helpful in identifying contracts, and actions that they would want to easily take from the related contracts panel.
FINDINGS
Presenting the feedback and design suggestions to product
I then presented all the findings to Product and Engineering, highlighting key insights and sentiments we captured in the sessions.
I formatted the readout, walking product and engineering through what we heard from users (with specific citations) and then ending each section with a design recommendation. The end of the presentation also cataloged one of suggestions that we had from a single user, but seemed to be a good idea. These one-off suggestions held less weight than the broader trends we saw across multiple sessions but if it seemed easy to implement and/or had potential high value to the process still considered it.
We prioritized these recommendations, considering their impact and feasibility, and aligned them with a multi-phase release plan (v1, v2, and v3).
SYNTHESIS
Six sessions, forty-nine insights
Following the user interviews, each session was meticulously documented within our research platform. Key takeaways were highlighted and tagged, facilitating efficient analysis. This process yielded 456 distinct highlights, which were then categorized into 49 key insights. Using these insights as a basis, I wrote out 30 actionable design recommendations for the team to consider.
The insights and their corresponding recommendations were then presented to the co-founders, product team, and key engineering members for discussion and feedback before we discussed next steps.
DESIGN RECOMMENDATIONS
Below is a selection pulled from the 12 design recommendations I collected:
SENTIMENTS
Users were excited to get their hands on the new feature.
“This (both options) is great it looks great I’m very excited, super excited for a new hierarchy view!”
–Kacy Little
“I would say just in terms of the functionality improvements in both cases (both options) I’m a big fan already of what I’m looking at.”
–Jake Johnson
“This is so great, this is great. I’m so glad you guys are doing this. It’s good stuff.”
–Julenny Mayberry
DEV HANDOFF
A three stage release plan to map out the quarter
Since I was going to be moved on to another project following the related contracts panel, I worked with Product and engineering to map out a three-stage release plan for the following quarter. We broke key components from the feature into three releases that were approved by engineering so that the team would have everything they needed to build with minimal support from design.
NEXT STEPS
Looking beyond v3…
In addition to the quarter long release plan. I highlighted some additional improvements that users asked for that were outside the scope of the project. I put together early mocks on these concepts to get started if the team wanted to implement them after the major project was finalized.