Designing a feature to help members of Feats find the projects they worked on

What is Feats?

Feats.co is a platform, now aiming at freelancers mainly in creative and tech industries, where members can create an online portfolio, connect with past collaborators, and get hired for future projects.

While this may sound like your average freelance- or portfolio platform, there’s a twist. A dedicated team at Feats, as well as the members themselves, help each other by collecting and adding projects, and inviting as well as verifying the people who worked on them. This gives members, and the people looking to hire them, a reliable track-record of their work.

I worked as the Design Lead for Feats for two years, and it was especially this value of project transparency, showing everyone who worked on a project, as well as helping people get hired based on their work, that convinced me to join.

Strategy

When you’re working in a start-up especially, the decision where to invest time, effort and resources needs to be pretty well considered. Luckily, there were many really good reasons why a feature to help members find the projects they worked on, was a good bet.

Our target group struggled with keeping their portfolios updated

Having just completed an extensive research project, we were very familiar with the issues digital agency employees in creative and tech struggle with. Number two on that list was, probably not very surprising, that even the IT professionals struggle with keeping their portfolios updated.

Yet finding the projects they worked on in Feats was a difficult, manual task

But while there were hundreds of projects added monthly in Feats, members didn’t have a way to find their own projects easily, apart from doing a manual search. The community team at Feats spent a lot of time suggesting members projects they may have worked on, and with good effect, too. But despite this great effort, many projects in the platform still remained empty.

Empty projects and profiles diminishes Feats’ overall value

Giving members strong profiles with verified track-records of their work was a main selling point of Feats. And knowing who worked on what was also Feats’ most important and most valuable asset data-wise.

Functionality

The “Project Suggester” as the feature became known as, would primarily suggest projects based on your network, consisting of people you’ve worked with, and brands you’ve worked with, from your projects.

The Project Suggester could also potentially look through project descriptions for your name, and projects where someone else added your email.

The issue with this however was, that new or empty profiles potentially wouldn’t get any suggestions at all, because existing data is a prerequisite. Because of this, we also toyed with ideas for adding work experience onto your profile similar to LinkedIn, or let people search for projects in the project suggester.

Design

As you can see below, the design of the Project Suggester underwent many different iterations, since my initial version failed the user testings. I also wanted to use the same design across mobile and desktop, to minimize the development-time and effort needed.

The “project suggester” underwent many iterations, but only a few key designs were tested.

Getting suggested projects isn’t really a common feature or pattern that people are used to. I had to design a feature very few people, if anyone at all, had ever tried before. This is why it’s great to do testing early on in the design phase.

The first version had an unintuitive interface design, but project matching and tagging others, excited the testers

I had quickly designed the first version as part of a larger project to redesign and reposition the product, with the intention of matching IT professionals with companies. This was before freelancers became the focus of Feats.

In the first version, project suggestions were part of your “updates” feed. This wasn’t intuitive for any of the testers as they mistook it for a feed or article.

The confusion continued well into the project suggestion flow and indicated that the entire context, or lack thereof, in the feature was losing the testers. It needed to be much more clear what they were even looking at in the first place.

It also seemed like they missed the buttons at the bottom for adding themselves to a project. They also didn’t scroll all the way to the bottom of the project, to the details on why a project was suggested.

However, once they were explained the concept, they were excited about being able to easily update their portfolio and also especially that it is a shared effort in particular. All testers showed willingness to tag other people they worked with on the project as well, without any incentive system.

The final version was a lot more intuitive, and testers finally seemed to understand the concept

In the final design I used the more commonly known “Tinder card swiping” design pattern. This seemed to be more intuitive, although there were different opinions about whether it was the best design for this purpose.

I chose to stick with it, since it also made it easier for people to view the project details.

In the original version, I showed the full project with the “did you work on this” buttons on top in the bottom, and people missed them.

In both versions, and from the very beginning, I had included a “Why was this suggested” link, where members can investigate the rules behind the feature. This was also due to Feats’ (and my own) principle of full data transparency. As an added bonus, it helped testers to understand the feature better, when they knew how it was done. And many of them asked, how it was even possible to suggest projects like this. Magic! 🔮🧙‍♀️

All of the rules for the suggester

I moved the Project Suggester into a flow of its own, knowing it should potentially be accessed from different places, the profile, an onboarding, even an email. Initially, the idea was that the Project Suggester should have been a “page” all on its own, but it didn’t make sense.

I also added a small onboarding flow to explain the feature for the first time people use it.

Finally, I worked with the button designs. Alot.

I focused most of my time and attention on the mobile version, since checking your project suggestions should be something easily done while you’re on the go. Adding your projects and writing case studies is something people are more likely to do on a computer.

And, speaking of people.

User testing

For testing, we primarily created click-through prototypes with follow-up questions and ratings using Maze. I was especially interested in finding out if adding other people on a project was intuitive, and if people understood how they could add others (searching for a name, adding an email, etc.)

Because when members added themselves on a project that didn’t yet have anyone else who could confirm their participation, it was critical that they could add other people successfully, so they could get into the project.

This way of verifying roles, through a whole verification system, was extremely difficult to work with, because it heavily constrained the design. It also challenged me to try to make a very difficult thing to understand, seem intuitive and self-explanatory. I didn’t always entirely succeed. But it the verification is the way that Feats ensures, that people who are on a project, actually worked on that project, because the people verify each others participation.

As part of the larger research project to redesign and reposition the product, we did online prototype tests of a prototype of the entire platform, and this included the first version of the Project Suggester.

Development

The way I worked with this design solution was designing the full feature, and then collaborating with my colleague the Product Lead on chopping it up into nice little bite-sized versions. This way, we would be able to release small, incremental improvements rather than have extremely large and long development projects. The true value of my designs isn’t realised until it’s released into the product, and is being used by the people its designed for.

Throughout the process, I’d had calls with developers about the feature in its different stages. This is to make sure I don’t run down a road design-wise that there is no way in hell we could build. But for the final design handoff to development, I held a kick-off meeting and presented the final feature.

In ,