Overview 🔎

Following a user interview sprint of 20+ clients over a 3 week period, we identified a clear gap in our hiring flow. Clients could hire passively through job posting, but there was no proactive approach to hiring. We had a wealth of high-quality users on the platform, but no real way for users to find those profiles organically.

Problem & Solution 🤝

Problem: Clients wanted the ability to browse profiles at their discretion rather than needing to post a fully detailed job to view applications/profiles.

Solution: Leverage our high-quality supply of Independents and allow Clients to browse and filter to find users they were interested in.

Goals

Increase profile visibility and engagement. We measured this by tracking profile clicks and inquiries received

Decrease the time to hire. We measured this by tracking the inquiry created_at time to the paid project created_at time and compared it against that of job postings

Process 🛣

The reason Discover took so long to be prioritized is because it's a massive feature to build, and one that requires extensive planning/designing and a significant amount of engineering resources. That being said, it wasn't a question of IF we should build Discover, but rather WHEN to build Discover. After our user interview sprint, we realized it was time to dedicate resources towards this feature.

Once the decision was made to pursue this feature, we started with competitive research of the Search experience on other platforms. In this research stage, we evaluated competitors, marketplaces in other industries, and any websites we could find with unique search offerings. We took inspiration from those that we admired and made note of features/experiences we wanted to avoid

After this initial research period of user interviews and competitive research, I collaborated with other stakeholders to identify the key features we wanted to support. From here, we knew it would take forever to build everything we wanted in one pass and so we assigned priorities to each feature which helped us to delineate what would be supported in the MVP, v1 and beyond.

With a more focused approach, I drafted out some broad requirements and worked closely with our design team to do some explorations on what the page might look like, how we would structure user information, and where this feature would live within the web app. Here's a look at one of our initial wireframes (courtesy of our founder, Ben Huffman):

After that initial exploration, we had a great starting point on generally what we wanted the experience to look and feel like in its MVP form. From here, we started iterating like crazy on the design side with 1 formal design critique/week and countless async critiques. This helped me to get more concrete feedback from the team on the business requirements and we were able to advance design and adjust requirements in unison.

After a couple of weeks of this, we landed on a design that we all were excited about and I spent a day turning these requirements into stories for our engineering team to begin grooming. A huge positive from this process was including the engineering team in all of our formal design critiques so that they could provide technical feedback on designs and pushback on things that would drastically increase complexity. As a result, by the time we finalized designs, the engineering team already had a firm grasp on how we would build this and there were minimal last minute design changes.

After grooming, we estimated how long this would take for the team to complete, set a target date, and went heads down on making this into a tangible feature on Contra.

As I'm writing this, we are in a beta rollout of this feature although it is available to the majority of our active users. Through initial user testing and feedback there are improvements we would like to make before doing a larger marketing push (one of which is ensuring Independents have their profiles completed and work preferences updated). Stay posted as we continue to iterate and improve on Discover!