Context and challenge

GetNinjas is a Brazilian startup, and also Latin America's largest online platform when it comes to connecting people to local contractors and service providers. Users can access the platform, navigate through the extensive catalogue and place a request on the service they are looking for. The system, then, looks for professionals who might be interested in executing it and presents them to users for them to decide. More than 1 million service requests are opened every quarter, and the amount of available providers is now more than 4 millions. The company was founded in 2011 and grew to become one of the most promising business in Brazil, according to Forbes Brasil.

The goal of this project was to design a new app for the requesters. The company already had an app for the service providers and a website that would work for both user segments, however the last lacked many desired features for the clients, such as managing their requests and communicating properly with the professionals.

The decision to design a new app, rather than just improving the existing website, was made because internal studies had suggested that it could encourage requesters to use the platform more frequently. GetNinjas' clients rely mostly on mobile devices and expect an experience that fits it. 

The challenge was to design an initial proposal within one month and provide tangible ideas for discussion along with the team and stakeholders. After that, the delivery process was divided into one-month cycles focused on different sections/features of the app. Unfortunately, there was not enough time for further exploratory research at the beginning of the project, which I tried to mitigate by incorporating some evidence from secondary research into the design process.

The process

Before the kick-start of the project, I proposed the process below and discussed it with the PM. Because we were challenged to come up with major definitions in one month, my intention was to spare time by getting everyone on the same page as quickly as possible. Moreover, having constant collaboration with developers helped us identify constraints and check on feasibility timely.

The main steps were:

1. Co-creation sessions and secondary research

2. First propositions of user flows and description of main features

3. Design of main features and usability tests

1. Co-creation sessions and secondary research

Since the challenge was to design quickly and without further research, I relied the most on content from previous research, on desk research, and on my peers. That's why co-creation sessions were scheduled right at the very start of the project.

After exploring through documentation of previous research and external sources, I compiled the data and brought it to our sessions. I chose to run a two-days workshop. 

In the first day, I presented to the team the most relevant pain points we knew our clients had when opening and managing requests and brought some behavioural insights on them. We also had the opportunity to go through and discuss pros&cons of the existing channels (the website, professionals' app, e-mails, customer service and social networks), which were written down. During the second day, we transformed the pain points discussed in opportunities and user goals and created a journey comprising all of them. The last step was to prioritise what we thought was essential and attractive for a 1st release.

Main conclusions

The data and the group work took us to many useful conclusions. The most relevant of them were:

1. The existing feature for opening requests on the website was inadequate because users didn't have a logged area to check their request status. Post-request communication was limited to email, and users lacked essential management options like editing or canceling their requests.

2. Recurring users had a hard time recovering information of concluded requests, since communication was carried out through email. This was frustrating as they couldn't easily access details about the chosen service provider, leading to distrust and a lack of recourse for complaints about bad service

3. Users heavily relied on others' recommendations and scores to select service providers. However, the website's limitations prevented them from easily checking and comparing the profiles of assigned professionals. Users also relied on information about availability, past experience and the certificates the professionals might have obtained. 

4. Initially, users were impressed by GetNinjas' extensive service categories, but they later became frustrated with the mentioned issues. An AB Test was conducted in the past, attempting to prompt sign-ups before showing available service categories, but it failed. Therefore the team concluded that communicating the portfolio's value upfront was essential during users' first interactions.

5. Despite being offered a huge service catalogue, data suggested that GetNinjas' users would most likely request new services related to the ones they opened before. 

6. Users preferred communication with professionals to be carried out through WhatsApp, rather than phone, e-mail, or built-in chat.

2. First propositions of user flows and description of main features

The next step was to propose a first version of the user flow, based on what was discussed during the co-creation sessions and known constraints. To streamline both my reasoning and the product's development process and to keep the new app a bit aligned with the information architecture of the website, I proposed it to be divided into four main features.

1. The home: This would include quick-action components and personalized suggestions based on the user's app activity.

2. Finding and requesting a service: Users would be able to explore the catalogue and select their desired service in this section.

3. User's profile: In this section, users would be able to manage their personal information and physical addresses.

4. Seeing current and past requests: Users could access current and past requests, where they would be provided with management options and access to contractor profiles.

I worked on the user flow and took it to the team for feedback. After a couple of sessions, we reached a consensus on the final version, which is outlined in the picture below. 

During this process, we encountered some constraints that needed attention. One was the inability to implement certain management features like editing and canceling requests in the initial release. Additionally, we faced the challenge of not having an automatic way to determine when requests were considered concluded. However, we recognized the importance of conclusion data for understanding our users and leveraging opportunities for cross-selling and providing more relevant recommendations. Therefore, we decided to address this issue proactively.

Some aspects derived from the co-creation sessions and the constraints mentioned are explicitly tackled by the flow. For example:

- Asking for sign up or login only when necessary and valuable for users — thus allowing for exploration; 

- Features for easily marking requests as concluded and moving them to another section for keep of history;

- Easy access to the profile pages of the service providers with links for messaging on WhatsApp;

- Emphasis on the login and sign up process, separately represented, because that was the aspect developers were challenged by the most.

3. Main features

The four main sections/features served as the foundation for designing and organizing the development process. Each section underwent visual ideation, prototyping, usability testing, and adjustments. To keep things moving efficiently, we scheduled bi-weekly follow-up meetings to promptly propose, align, and get approvals for the progress made.

1. My Requests

Beginning with the "My requests" section, our aim was to simplify how users track the status of their opened requests and provide management options. We knew these features were highly anticipated.

To address this challenge, I decided to display both current and past requests in the same section. This way, users could easily access the details of a specific request and find shortcuts for anticipated actions, such as viewing the contractors recommended by the platform, reviewing data about the request they opened, reporting conclusion, and getting easy access to profile pages of the providers.

Designs for this feature also comprised highlighted indication of the search-for-professionals process, prominent access to information about the provider and the reviews they've received, and focus on rating feature.

To more easily communicate all the possible interactions and states of the interfaces involved in the Requests section, I opted for ProtoPie. Using this tool, I created an interactive prototype with the latest high-fidelity screens. Although the content is in Portuguese, it effectively showcases the essential visual elements.

Moreover, this prototype was utilized as the artifact for usability testing with real users during our sessions. Results of this test were positive.

2. Finding and requesting a service

Another important feature of the app is the requesting services one. Areas in which users are able to navigate through the catalogue and find the service they are looking for at the moment. Besides the main search feature displayed below, these efforts also involved the design of the category and service screens. 

Because GetNinjas have a big number of categories (such as renovations and repairs), we chose to sort them dynamically based on popularity and probability of those being what the user needs.

On this main search page, users can either navigate by checking on the available categories, entering on their page, and selecting the desired service, or by typing in on the search bar and look for the specific service.

Because I was dealing with a huge ecosystem of services, I took opportunities to explicitly reference which categories the services belonged to, and to list and recommend similar ones. The intention was to get users familiar with the organization  and incentivize them to come back by showing we had all they might need.

Once again, I designed a prototype to demonstrate the main actions and pages. Although in Portuguese, it effectively illustrates the entire flow of finding and opening a service request.

As with the previous feature, I used this prototype in usability tests with users, and the feedback was positive.

3. Home

The Home section was one of the last features the company chose to tackle due to its complexity and technical requirements. I spent some months focusing on supporting the implementation of the designed features exposed before, but ended up leaving the company before the efforts on the Home feature began. 

Nevertheless, during the project I had the opportunity to design an overall intention of layout and components for the home page, which is displayed below. The goal was to create a flexible set of modules that could be adjusted not only based on the system's logic but also for marketing campaigns and business objectives.

GetNinjas didn't have a mature channel for recommending services based on usage data, which they intended to accomplish with this new app. The ideal situation is for the home screen to adapt without the need for additional development effort, allowing for highlighting specific categories based on what's most relevant at any given moment.

The Profile section of the app was also not prioritised and neither designed. However, intentions for it are containing features related to user's data management and access to customer support.

Acknowledgements

I supported the implementation of the request management, and finding and requesting services features but left the company before design efforts on the other sections begun. Development was eventually paused due to problems caused by the pandemics and team-restructuring, which was one of the aspects that led me to leave GetNinjas.

Feel free to ask more questions or share your thoughts on this project with me!

Regards,