Overview
Formplus is a cloud-based, enterprise-focused data collection SaaS
It helps users gather data from multiple channels, storing this data in any endpoint they choose. Formplus was founded in 2014 and headquartered in Leeds, United Kingdom.
We conducted user research with about 20+ users to redesign the User Experience of Formplus. With the new design, we were able to improv e customer retention, and the company secured a google grant in the same year.
Brief
Although Formplus has a significant amount of users and a stable acquisition rate, there was a need to improve customer retention.
The company began to notice that although customers were signing up and finding the product useful, it was a little difficult to get these customers to either become paying customers or to get them to use the service for the long term, thereby improving the company’s revenue.
This goal would later encompass a series of projects, features and changes to the platform. Some of which would be detailed below.
Objectives of project
1. Retain ease of use
2. Make interface relatively simple to use
3. Rethink key features by understanding user needs
My Role
For the period of time I worked at Formplus, I was the sole product designer on the project. I majorly worked with the product team on the product discovery, research and ideation phase, And then subsequently with the entire team to bring the project to life.
I was responsible for;
1. Conducting one on one user interviews with existing users
2. Re-designing, prototyping and shipping all mockups
3. Conducting usability tests
Process
My Design Process
My process for each project might differ slightly based on varying factors. However during my time at formplus, my process remained relatively the same.
Usually, I’ll start with defining the problem, understanding the limitations of our present solutions, do a little competitive research, to see how our competitors solved the same problems and how they falter. Then, I’ll ask team members for their ideas on the problem, present my findings and gather all my insights.
After making my notes, I sometimes brainstorm with the project manager and some members of the frontend team to understand the boundaries that the existing codebase provides before I start designing.
However, some tasks are different and may require more extensive research, gathering user data, conducting an AB test and etc., An example is the redesign of the reports page where we had to seek feedback from the users. We sent surveys and got a couple of responses which guided our design.
Finally, I start with the lo-fi, then we do multiple reviews, and iterations to fine-tune the design and then it’s ready for production.
Conducting Research
Uncovering UX Issues
1. UX Audit
Breaking down the brief, I had to understand the problem and the reason why customers acted the way they did.
I started with a personal audit of the product. I went through the entire product and took notes on how the UX functioned.
The objective of this step was to identify key issues, and possible friction points from my personal use of the product.
Key UX Issues Identified from UX Audit
The issues I identified are as follows;
1. Building a form using the builder proved to be cumbersome because adding a field and opening the settings gives users too much information at once which can increase cognitive load. This settings also overlaps the fields awkwardly.
2. Advanced features pertaining to the form fields were located outside the builder environment so it could cause a lot of back and forth
3. The reports feature was not performing optimally as they could only be viewed and not exported.
These were the most important among the others I noticed. When I was done with this, I moved on to qualitative research to understand the users pain points and compare the issues i noticed with the reports from the users.
2. Involving the users
The research objective was to identify the key issues and the reasons why some may be dropping off the platform.
I worked on this with my teammates, two product managers, one focused on growth and the other focused on product.
We achieved this by;
1. Speaking to existing clients through one on one UX calls. We did this with about 15 users.
2. Sent out a user feedback survey and another user satisfaction survey to different user segments to gather as much data as we could.
Gathering the results
The results from both the interviews proved to be very insightful as a number of pain points were discovered. A few of which were not related to the user experience of the platform. But for the purpose of this case study, only the issues pertaining to the user experience of the platform would be highlighted.
From the interview sessions, users highlighted the following issues;
1. Overwhelming and confusing interface
2. Difficulty in finding the needed advertised functionality
3. Certain key features not working as they expected it to eg Reports
However, there were some positive we noted to maintain in the redesign and they include;
1. Intuitive drag and drop builder
2. Numerous field options
3. Being able to work with teams and collaborate on forms
Analysis of Findings
Creating User Personas
Apart from bringing out the problems, conducting the user interviews helped us to understand our target users more. What they typically use it for, and how they typically use the software.
With this I created a user persona to aid the design process.
Prioritising Problem Areas
Although the entire platform was redesigned, the initial research exercise we carried out not only highlighted user pain points, it also helped to prioritise what areas to start with in the redesign.
The following were decided as the topmost priority;
1. Builder environment: This is because a lot of users found this a little clunky to navigate and it is where users carry out the bulk of interaction with the platform. Luckily this coincided with a compulsory backend rewrite of the application.
2. Rethinking the reports page: This is because the reports page is also what users use to make sense of the data collected. It is one of the most important parts of the platform, from research we see that the way we designed it function was not the way the users wanted to use it.
Design Decisions from User Persona
The design decisions highlighted below were put into consideration to cater for a more mature audience. We noticed that although we have users from a variety of age groups, the majority of our users are between the ages 28 – 48. We also noticed about 68% of our users are in the educational sector.
The decisions include;
1. Using muted colours:
2. Maintaining a minimal approach
3. Attention to the accessibility of the platform
The Builder Enviroment
Redesigning the builder
Streamlining the Interface
Right from my first interaction with the Formplus builder as a user, I had already identified major areas that could be improved. On joining the team, I pitched the idea to the necessary authorities, and after a lot of back and forth and iterations on the design. We agreed to go with my suggestion.
I carried out a small user testing session using a maze (a user testing platform) and a few people that had some experience with form builders. I realised that about 80% of the testers found the new solution to be a lot more intuitive than the first. The new design has been implemented presently and we have received about 50+ positive reviews on the intuitiveness of the builder. We have also gotten more positive user feedback from our users.
Before
1. The grey background and dull blues used in the builder environment made the interface look generally dull.
2. Adding a form field required an extra button to be clicked for the users to edit the form.
3. At every little edit, the user was presented with too many settings for each field which ends up feeling confusing if users were to make multiple edits on large forms.
After
1. Although I had to retain the blues as they are the brand colours, I made them less prominent in the builder and used white as the background colour to make the interface appear clean
2. I added an edit state to appear whenever a user added a form field. This prevents an extra click and the user can easily edit the form without feeling overwhelmed
3. The edit state prevents users from encountering too many confusing settings when making little changes. This makes building forms simpler and faster.
Simplifying the logic flow
Before
The logic flow, used for setting conditional rules to form fields. An example of a rule is; “If ‘option a’ is selected, go to page 2”.
1. Initially the logic flow was located on the settings page, which implies users should finish building the form before attempting to add logic rules. This made it hard to use because it involved a lot of back and forth between the settings and the builder.
2. The way the logic flow is displayed when created looked very confusing especially in cases where a lot of rules are present.
After
1. I moved the logic function to the builder for easy access. This way a user can always add logic rules to their fields seamlessly.
2. I edited and streamlined the display of the logic so it’s easily understandable.
Testing with users
When testing with users, majority of the users attested to a faster build time. Although it took a few users a little while to get used to the new platform, the majority of our users were happy with the experience.
Reports
Rethinking the Reports
Process
The reports and analytics pages are one of the most important features of the software. These pages allow users view detailed statistical data of responses. We got a few support cases regarding this page and had to do something to improve the user’s experience.
We started by sending out feedback emails for our users to give us detailed feedback and describe their pain points.
Then I and the product team analysed the responses and also did some hallway research of our own.
How it was
The reports page allowed users to view the users’ responses as various types of charts and graphs, pertaining to the individual field.
How it needs to be
At the end of the brainstorming session with the product team, we came up with the following action points to improve the user experience of the reports page;
1. Make the reports page have the same mental model as a buildable form, just like the regular form is. We also added the ability to add text and headers to the reports, thereby giving them more control to actually present data. So they can create reports right from the app and download it as a pdf for use.
2. Isolate the responses as against the question fields – Because users wanted to see specific responses according to the responses not necessarily by the field as we had thought.
3. Allow users to choose which data is relevant to the analytics page – Because a user complained that the static data we show wasn’t relevant to him.
4. We also made some improvements to the code to allow for faster load speed, and better graph alternatives to improve the experience of the users.
Analytics
Business Outcomes
Was our aim achieved?
Although there are various factors that work together to aid customer retention, some of which have nothing to do with the user experince of the software. I would say we achieved our aim. We were able to increase revenue and retain about 20% more users in the next quarter of deployment.
In addition, our user feedbacks suggests that users have a better experience building forms now in comparison to the previous builder.
Outcomes and takeaways
On being a team player
I have enjoyed working with the team, and most importantly I learned a lot about being a team player. Sometimes my suggestions on ways to improve the user experience was met with hesitation and for good reason. But with time I learnt how to utilise user testing and feedback gathering to convince the team, and it has always yielded a good result.
Final words
I love every project and task I worked on at Formplus and i am grateful for the opportunity to contribute to something that is helping thousands of people daily. I have learned a lot during my time there and most of all, i learnt the importance of good leadership, teamwork, research, feedback gathering and user testing.
