There were 3 types of loans available to our users in the marketplace:

- Loans based on guarantees: this type of loan was addressed to bigger corporations;
*Loans based on insurer approval: addressed to small businesses and companies urging for working capital;
-Loans based on prepayment of receivables: this one had a very small business as a target.

Each type of loan had distinguishable persona profiles: from CFOs of big companies to owners of small businesses.

We noticed, that users applying for the prepayment of receivables were not performing as smoothly through our flow as expected. Our purchase funnel attracted a good number of potential customers while the work of our inside sales helped to fill the beginning of the funnel up considerably, however, users were still getting stuck in the middle of the process.

The team then had many assumptions in mind, but only communicating and observing about how  our product is approached by these users led us to better solutions for User Experience.

We tried to be as efficient as we could, so we used the weapons we had to act on:

User recruitment and in loco visits
User test in the real application
Documentation of key findings
Presentation to main stakeholders
Run a Design Sprint
Retest!

At the end of the project we delivered a report presentation with the key findings to our stakeholders (all of them) so they could see the value of interacting with users and the benefits it can bring. We also delivered an interactive prototype after a Design Sprint Session.

The scenarios were projected at the same time the recruitment phase took place. Meanwhile waiting for our users to reply to our e-mails or calls, we ran and planed the tasks and instructions our users would have to follow on the big day. 

Our tests were structured in 4 big tasks that the user would have to accomplish:

Create an account 
Start a loan application
Fill pieces of information out 
Select one loan type 

Companies didn’t have to apply their data to take the test as we prepared false companies‘ profiles instead to choose from. 

As we didn’t have to design any prototype we ran dry tests with internal stakeholders several times before we went on the field, and it allowed us to fix some small details of our script, making sure everything would be working. 

I think most product development teams, in early-stage startups, have the same problem when it comes to recruiting people for user tests: sometimes you don’t have the budget or your persona is not easy to reach out. Recruitment is always a complicating factor in this process and we were not an exception.

So, how did we manage to recruit our participants? We created a simple form on ‘Typeform‘ requesting some basic data about our users such as personal data, location and companies‘ basic information so we could trial them later on. Then, we shared the form with our colleagues and they helped us spread the form on their social media and acquaintances, without it it would have been very hard to find people interested in helping us.
‍
After gathering a good number of applicants, we trialled them and started managing the schedule for the test. During this process, we documented everything on Confluence so anyone from the team could check any information they need.

Most of our participants couldn’t visit our office, so our user testing environments were divided into three:

2 users in our office

2 users in user places

1 user remotely

As there were three types of environments to test our product in it was quite challenging, because we had to be prepared for 3 different scenarios. Nevertheless, the most challenging were the tests at companies. For the tests there we had to have our equipment set ourselves, so we wouldn‘t waste much of our participant‘s time. Sometimes there were difficulties finding a perfect place to run the test, i.e. one of our participants did not have a desk for it, so we had to improvise. In another situation the internet connection was malfunctioning and the network kept going offline many times. However, only this way we were able to see how the product responds to atypical situations.

In the process, users were asked to complete the main task: to select a loan option for a false company. In order to do so they had to create an account, select a loan and fill out the information of their business (from the false information we disposed to them), so the algorithm could match their needs with the best possibilities available. After that, they would have to agree on the billing terms and select a loan proposal.

Before every test the Product Owner and I introduced participants to the false company profiles we had created in order for them to use the data provided and asked to think aloud so we could observe not only their screens, but comments, feelings and behaviour.

While one examiner was supervising the user through the test, the other would take notes and keep our sheets updated with all the user comments. After every session, we would quickly gather together to review the observations and write down additional comments in our debriefing session to make sure we weren’t missing anything.

Despite the obstacles we went through, these visits enriched our work by creating stronger relationships between us and the companies‘ as well as showed how the product is used by the customers in their environment.

After 3 days of hours of hard work running the user tests and debriefing all the notes, similar patterns started to pop out. Here are some of the key findings we discovered during the process

Users performed very well on the signup process:

Choosing a loan option to start the application had very few problems

Participants sometimes didn’t understand the role of F(x) in the application process

Filling up information and understanding our terms of billing was the most critical part of the test.

The last two topics were very critical for us because if those people were not able to understand what our job was, something was very wrong. Also, not understanding how to fill up information and how they are billed is very critical. 

Users were not able to accomplish it by themselves in most of the cases, asking for help or seem very confused with the information on the screen. What happened was that the information about our pricing was being displayed at the step of the flow that confused the users. Also, the way it was written was not clear and some participants had no clue what that meant with many different answers for the same question.

In the end, a report was prepared and presented to all stakeholders, it was important to get them to know what our users were going through so everybody would be on the same page. By this time we were planning how to take action on the problems we found. We had been thinking about applying the Design Sprint process since a long time ago and the occasion seemed the right problem to use this approach.

I had studied the Design Sprint process for a few weeks before we even started this research, and one thing that I found in every single article that time was: people are looking for a way to run Sprints in their companies without spending 5 days with many stakeholders locked in a room. I suppose most of the small-medium sized companies suffer from the same problem, because to stop 5-7 professionals from working for a whole week is always hard.Then, we found the Design Sprint 2.0 developed by AJ&Smart in partnership with Jake Knap.This version consisted of 4 days Design Sprint with specialists allocated in the room only during the first two days. The sprint looked more or less like this:

We could not spend the whole day on these activities so we managed to do it in time-frames of 3-5 hours (depending on the day), but we made sure to reserve the whole day for the prototype and the user test. It was really intense but totally worth.

We sent an email to all participants so they would decide if the schedule was OK for them, and also, to let them better understand why we were doing it. Our main goal in this sprint was to solve our communication problem in the product, more specifically focusing on our persona we used to call Small Business Owners using the same flow as tested before. They also received a few links with content to better understand what was the Design Sprint, so they could get familiar with the process.After our participants bought-in the Design Sprint, we gathered all the 7 participants together, which included our CEO, COO, a Product Owner, a Designer (me), and 3 business specialists. We ran a quick presentation about the process before we started, to make sure everybody gets the idea of the Design Sprint.

Like in the book, we mapped our user journey considering the main touch points the user had with us. As you can see in the picture we did not have a whiteboard as recommended in the book, even though it’s much easier to use a whiteboard we used post-its and paper to make our map.

To help us identify in which part of our journey we would tackle on we started to do our How Might We’s and soon our wall was covered with ideas and possibilities. We asked our business specialists to talk about their daily experiences with our users, what they used to struggle with, their concerns and comments, meanwhile we wrote down everything that came to our minds in the format of HMW and glued on the wall.

With this massive quantity of post-its on the wall, it was time to prioritize them and select which ones would go on our map and which ones would go to the “maybe later” pile. Everything was documented so we did not miss any valuable ideas. The picture shows a clear trend where we should work on, so we decided to focus on the middle of the journey as the map showed it to us.

We did the ideation part on the same day as the map, in the design sprint book it happens on two different days but we needed to optimize our time. I must confess it wasn’t easy since the members had already taken many decisions in the mapping phase, but the results proved to be worth doing it.We followed the 4 steps ideation process as in the book, going from a simple list of ideas to a final sketch for our “museum of ideas”. 

It was a very rich process where everybody could come up with new ideas for the business. In the beginning, the participants felt afraid of sketching on paper because it was quite new for them that the designer was not actually drawing, but business people were doing it instead.

After all sketching process, we jumped into the voting step. Each participant had its own dot stickers so he/she could vote on the best idea, making a heat map of votes so our CEO, the decision maker could decide which of the ideas were most suitable for our goal. 

As we wanted to achieve better communication, the winner ideas were most likely improvements in our screen flow. One of them, was the insertion of videos during or screen flow, to guide users through the form filling. Another one was to change the way we present our pricing, because most of our users from the research didn’t understand our prices and why they should pay for it.

On the second day, we had to join our ideas in one working storyboard that would be the base for our prototype and the test with users. It was a long and tough day with a lot of discussion and decisions to be made, but we manage to finish the day with 15 frames filled with step-by-step storytelling of how our product should be used.

With all the material consolidated, I as the only designer in the group, started off designing our prototype so we could test it on the next day. We also gave a try to Adobe XD, we were used to using Sketch as our main tool and Invision to prototype but in order to gain agility, we decided to use Adobe XD because of its fast prototype feature. It surprised me how well it went with it and I guess it wouldn’t be as fast as if we used Sketch. 

It was really important to have wireframed the storyboard and spent hours and hours doing it because when it came to designing the real flow I already knew most of the details because we had discussed them beforehand. 

Still, I decided to stream my screen to the team so they could comment in real time and help the prototype to get better.We decided not to follow our actual structure and we made room for a new way of going through our product. This allowed us to explore the idea to its fullest and we didn’t stay chained to our old structure and limitations.The results you can see below:

Users could see the whole application process in one screen all together.

Our form was split in small pieces of information at time,  taking the clutter away from the process.

As the users moved forward, more detailed information were asked, the more information filled, the better.

The last form’s step asked for the company’s customers information. Users would have to input only 3 values and our algorithm did the rest of the job.

Here the lender’s proposals are displayed to the user so he/she can choose the best option

Just after the payment all the contact details are revealed. then the business’ owner and lender can get in touch to discuss the final details like contracts, documents and so on.

The big day arrived and we were looking forward to seeing it working with real people. This time we were testing a clickable prototype and sometimes users needed some guidance through it, in order to improve it, I designed some help screens throughout the flow with guidelines for the next task the user would have to perform. The tasks we asked participants to perform were basically the same as before so we could compare before vs after.

People showed a better understanding of what our company do

People liked to have a personal assistant there (even though it was only a fake assistant)

They went on through our screen flow more smoothly than before

The checkout idea worked very well

During our form application, we noticed some points we do need to work on, but nothing critical

Even though the checkout worked well, people still have doubt about the price, finding it expensive (this is a topic for further research).

All in all, we were very happy with our first Design Sprint run in the office, it was a very rich and insightful process that allowed us to think outside the box and test a new idea in a very short period of time.  We ran a feedback survey with the participants and we got very good impressions from them (and of course things to work on for the next time) and all of them are likely to participate again, which is great!