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. But there were many really good reasons uncovered through research, why a feature to help members find the projects they worked on, was a good bet:
1
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, was that even the IT professionals struggle with keeping their portfolios updated.
2
Finding projects you worked on in Feats is a difficult, manual task
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 the effort, many projects in the platform still remained empty.
3
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 project network (people and brands you’ve worked with). The Project Suggester could also look through 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 like an agent of sort, using some filters.
Design
The design of the Project Suggester underwent many iterations, since my initial version failed the tests. I also wanted to use the same design across mobile and desktop, to minimize the development-time and effort needed.
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. It was critical to do testing very early on. 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.
The first version had an unintuitive interface design, but project matching excited the testers
In the first version, project suggestions were part of your home feed, which wasn’t intuitive for testers. The confusion continued 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.
Testers also missed the buttons at the bottom for adding themselves to a project, and also didn’t scroll all the way to the bottom to the details on why a project was suggested.
Once they were explained the concept, testers were excited about being able to easily update their portfolio, and especially being able to tag their coworkers, which they all expressed willingness to do–even 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 a more commonly known design pattern with cards, which 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 to view the project details by clicking “into” a card. The original version 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” section, where members could 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.
I moved the Project Suggester into a flow of its own, knowing it should potentially be accessed from many 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.
And, of course, I also designed the edge case (which in our case wasn’t so much of an edge case) for when a project was empty, and a person could add their role as the first one. This is all controlled by a verification system, in which members could add each other to a project and verify participation.
The verification system was, as we say in Danish, “a very heavy dancing partner” but the most important thing was to make it seem logical and easy to members, so that’s what I focused on, regardless of the logic of the programming itself.
As an additional feature, one which we quickly agreed to slice into a future update for the flow, was being able to add your Work Experience similar to LinkedIn and other portfolio sites, again, in order to feed the suggestions.
Also, I worked with the button designs. A lot.
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.
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 challenged me to try to make very difficult functionality seem intuitive and self-explanatory.
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
I designed the full feature, and then collaborated with my colleague Simon, our 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.
Throughout the process, I’d had calls with developers about the feature in its different stages. This was 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.
I wrote detailed Design Specs for every part of the feature, including suggestions on how to slice it even further down to get a first version out as soon as possible. Any developer, either one from our own team or if needed a freelancer, would be able to pick up the specs and begin the work.
Conclusion
This was a great project because it really challenged me to take an extensive and advanced functionality, and make it seem intuitive and understandable even to someone new to the product. I also think it challenged the rest of the team’s perception of the verification system, because it demonstrated just how simple a design need to be, for people to understand.
I unfortunately wasn’t around to see the Project Suggester become a reality. Sometime after completing the design, which was quite an extensive project, I decided to leave Feats and take a leave of absense for personal reasons. But I greatly enjoyed my time at Feats.