Ux Case Study: Qompro, saving money on Saas with group buying
Every company out there has their own tools to carry on with their projects. From pencils to excel, all of them are required in their daily work and some of them are essential. With each passing day, more and more technologies develop new software tools that make our job easier in exchange for subscriptions: those are known as Saas, Software as Services. Saas are essential to many companies, but also require time and money to manage due to the plethora of choices there are in the market nowadays.
Our client in this project, Qompro, is a Spanish company that aims to use group buying to help young startups save up money when buying those Saas subscriptions. By gathering several companies that require a subscription in that particular software, and presenting the Saas providers with those leads, Qompro aims to reduce the costs and make those young startups focus on their own products, instead of worrying about the financial pressure those Saas provoke.
In this particular project I have worked with Adrián Fernández and Juan Diego Ruiz, two teammates from Ironhack. Our goal was to provide Qompro with the tools to start the development of their project: a thorough research about those potential users, the definition of an MVP (minimum viable product), the visual design and flow of those basic functionalities and a UI kit that allows them to be able to work in new features in the future. We had two weeks to finish this product, and we dedicated a first week on interviews and analysis and a second week on the creation of the UI and prototypes.
Step 1: UX Research
Before we started researching information about our clients, we needed to do some initial investigation about some of the terms we were facing for the first time in this project: Saas, group buying and B2B.
We have already covered what Saas are, but we wanted to see a few examples and how their subscriptions worked. Most Saas had several packages varying in the features they provided and with different price tags, that adapted to the necessities of both users or companies.
B2B, also known as business to business, was the exchange of services between two companies, opposed to B2C, business to customer, that focused on providing products from companies to individual users. In this case, Qompro was aiming to provide those products to young startups, the group that most widely suffered the high price tags of some of those Saas subscriptions.
Lastly, we investigated the group buying feature. We were familiar with the concept thanks to platforms that allowed you to share subscriptions with family members or friends, like Netflix sharing plans or Nintendo with their online family plans. It was more popular in a B2C environment, but Qompro wanted to aim this concept to companies at the moment.
Competitive Analysis
Once we achieved a basic understanding of the environment surrounding our project, we started narrowing our scope to the companies that worked in this sector. We researched the products of several companies that provided companies with Saas management solutions.
With this examples we created an axis, dividing the companies between those who offered a wider range of functionalities (like reports, credentials management, invoices, budget per teams, cashback, etc.) and those who focused on providing more specific functionalities (like simply provide audits for companies, or procuring new Saas).
Aside from this distinction, we also wanted to make sure to differentiate between those who focused on smaller companies and those who clearly were aiming to provide their services to bigger companies. Of course, there would always be exceptions, and we didn’t have access to private data from those companies, but based on the language and the display of the features, we were able to gain insights into which kind of products they offered and to who.
After putting them all in the axis, we were able to see where Qompro fitted in this canvas. At the moment, Qompro was solely focusing on startups, and their product aimed to have less functionalities at the start, and slowly implement more features in the future. Focusing on a smaller product at the start wasn’t necessarily a bad thing: being able to provide a specialized solution for companies that had less time meant that they would be able to finish tasks faster and achieve their goals with less effort.
Interviews
To attain knowledge of our users, we conducted several interviews, all of them of startups from Spain: Qoala, Gretel, Nominis, Nester, Niubo and Capboard. Our goal with this interview was to have data about the needs of different companies, since none of them were placed in the same sector, all had different creation dates and varied in the size of their companies.
After the interviews we realized that even though companies were very different between each other, they all agreed on several problems and needs that affected them on the daily, that we were able to analyze in next steps.
Empathy map
To better understand the way this startups interacted with this environment, the problems and needs they were facing and their objectives, we created an empathy map. We first focused on what they see, say, hear and do, and tried to extract the pains and gains of these situations.
Regarding their environment, we gained several insights from the interviews:
- These startups were faced with many alternatives for different Saas in the market, with various packages and prices, and no way of comparing them before making a decision.
- They also didn’t know how to save up money in those subscriptions, nor did they had a specific control of budgets, most of them relying on spreadsheets or simply looking at invoices one by one.
- The only way they had to save up money was to go for the free subscription, even though they could use some of the better features in more expensive plans.
- Some companies used automatization features for their receipts, like Holded and Revolut, but it wasn’t common among them.
- Google Spreadsheets and excel were the most common management tool to organize invoices and prices, but sometimes it was chaotic or not useful at all.
- After the first year, most companies lose access to financial aid to cover for those Saas subscriptions, and they try to anticipate those expenses in advance.
- All of them knew about group buying, with initiatives like Buo, but none have heard of group buying in Saas.
Aside from these insights, we also took note of some of the quotes regarding their pains:
“I don’t want to have unnecessary expenses: If I can combine two Saas functionalities in one, I prefer that”
“I wish my teammates could manage their own Saas subscriptions, or at least suggest them in an organized way instead of coming to me and wasting time”
“I need to have complete control over my receipts, licenses, users, passwords, etc.”
“Having to manage the subscriptions takes a lot of time, specially if you want to stop or cancel a subscription”
We also took note even though all of these companies knew about the Qompro initiative, most of them believed that group sharing would make them share their licenses with other companies, and were worried about privacy issues. This was not the case, and we had to make sure to make those features clearer for our users.
Our interviewees also shared with us some things that they would love to have in a product like ours, and we took note so we would be able to fulfill their needs:
“I wish we could have suggestions to combine Saas and save up money”
“I want to have all my data about Saas (licenses, users, receipts) in the same place and be able to search for them”
“I wish we could just press a button and pause or cancel subscription: like an ON and OFF button”
“I want to participate in group buying anonymously and receive the benefits of working in a group but retaining all my information and control about my company”
User Persona and User Journey
Now that we had the point of view of our users, we were able to sum up those characteristics that were common to all of them, and make an User Persona and User Journey, to imagine what an ideal customer would look like.
We created the profile of Finances Francis, a young man working in an imaginary company called Compra+, with 4 other colleagues. He’s in charge of managing finances in his job position, and he aims to be efficient with his tasks, but sadly, being in a company that small he has to multitask most of the time to cover for the needs that arise. He aims to be wise in his time management, finish all of his duties as soon as possible and having everything organized so he can check it out at any moment.
We also devised an ideal scenario where we can see all the problems that our persona, Francis, may find. Our scenario is as follows:
It is the end of the first year for their company, and Francis has to generate a report of the spendings by the end of the day. He anticipates it’s going to be a hard task to finish, but he had prepared spreadsheets in advance. As well as a report, he also has to think on ways of solving possible financial issues. Will he be able to finish everything on time?
With this scenario in mind, we start going through his journey: first thing in the morning he checks what he has to do. He has to deliver a report of the spendings of that year, and to do so, he opens up his spreadsheets. A year full of spreadsheets can be a big document, and even though he tried to be organized, it’s difficult for him to check all the different values without spending a lot of time. Moreso, after the first year of the company, they are going to lose financial aid from their government, so they have to make sure that everything is under control by using all the invoices and data from the past.
Finding those invoices take him a lot of time, since they’re mixed between mails. After he has gathered all the information, several hours have passed, and he realized by looking at the numbers that Saas subscriptions take a good chunk of their budget. He wants to save up money on those, but he believes all the software they have is essential for their work, so he’s not sure about what to do. He tries to find a solution online, but most web pages have so many features that he gets overwhelmed, when the only thing he wanted was for a way to save up money.
While he’s thinking about this, a teammate asks him about a new Saas they could add to the list, and he gets even more anxious: having to research abou that new Saas and adding it to their database takes time, and he needs to finish his report. In the end, he gets to make the report, and meets with his boss. Suddenly, his boss realizes that in one of the subscriptions the price has doubled and they weren’t notified, and the charge was already made to their bank account, making them go out of budget that month.
As you can see, Francis has many troubles during this journey, but that gives us opportunities to help him fix those. We thought of several ways to do so:
- Allowing him to get all the information about spendings at a glance, and having invoices organized.
- Give him recommendations about Saas that could be combined or changed to save up money.
- Creating a solution that focuses on Saving up money instead of having too many features.
- Provide a way for employees to ask for specific Saas so they can open requests instead of going directly to a manager.
- Getting notifications about the status of subscriptions, especially when prices go up.
These are only some of the ideas that came up thanks to the user journey, but we will see later that some of them had to be prioritized over the others.
HMW and Problem Statement
We now know all those problems our persona found in its journey, so now we can make pertinent questions about what we can do, as designers, to help them fix those problems.
How might we help those users save up money in Saas subscriptions?
We can as well define in a single line everything that encompases our current challenge:
Small and young Spanish startups need to find a way to save up money and improve their management of Saas subscriptions because they don’t have the luxury of wasting money at the start or spending much time on management.
With these two in mind, we can proceed to the ideation of the solution.
Brainstorming functionalities
While working on the previous steps, we were full of ideas on what to do with the different problems we were facing, but instead of focusing on solutions early, we needed to have all the facts to start ideating. To be able to have all of those ideas on paper, we started sketching (my teammates preferred good old paper and pen, while myself preferred the ipad because I’m used to working with it), and we designed several features that Qompro’s desktop app could have.
We used the crazy 8 methods, and devised a series of features, and surprisingly, even though we didn’t agree on it, we designed the same ideas in several points. In the end, we designed 8 fundamentals features:
- an onboarding,
- a search for a new group screen,
- a gallery with all the groups you were in,
- the possibility to create a new group,
- the details of that particular Saas group,
- a notifications section,
- the profile
- the Saas management screen with data about what you’re saving and what you can improve.
We checked them out with our stakeholder, and decided to keep all of them at the moment, as they would be prioritized later on with the MOSCOW method.
Information architecture: Sitemap and User Flow
Before adding features, the muscle of our product, we needed to add the skeleton, the fundamental base of the navigation: the sitemap. We devised 4 screens for the onboarding, in which we would make an introduction, ask for data, ask for Saas and other interests and confirm all the input. After that, we would divide our product in: a home, join a group section, create a group section, my groups section and the profile. There would also be an updates section in the home, instead of having in real time notifications, but that was a change we did later on. As any design project, our decisions weren’t static: we needed to make changes in order to adapt to new insights while we worked. The sitemap I show you is the final one, but we did many changes throughout the process.
With the user flow we tried to represent the ideal path a user could do in our application. They would go through the onboarding, they would join a group, try to search for a saas, and when they don’t find it, create their own, checking later in the my groups section to see their progress. For the sake of displaying how the information would look, we did the onboarding as if it was the first time the user reached our platform, but we would show the my groups section as if they would have joined several, so we could see how the page would look like having more information on screen. In this particular project we didn’t have much time to focus on empty states, but that would definitely have been something we would have liked to work on more.
Prioritization and MVP
As of now, we had several features planned for the app. However, due to time limitations, we needed to be able to deliver a product that could be functional even with the minimum requirements: that is an MVP.
To do so, we got all of the features we had designed and added a few more that were ideas that our stakeholder had suggested or our clients had asked for and organized them in a Moscow Method table, a tool that would help us categorize them in the ones required for our project, and those which had less priority in our sprint. The result was as follows:
- An easy to follow onboarding with information about how Qompro works
- A group buying feature based on goals, the main feature of our product.
- The possibility to create new groups if Saas are not displayed
- An overview of the groups joined
- A profile with the information from the company
- Updates about the status of the groups
Again, updates was something that we added later on, since we needed clients to receive feedback on the status of their groups. Originally we didn’t consider notifications to be essential, because in real time ones weren’t useful for an applications designed to spend the less amount possible time on it. But then again, if clients didn’t know how to check the status, they would be forced to go through all their groups if the status of the group changed. Combining these two insights, we agreed that having an ‘updates screen’ instead of a notification panel was more useful, but we will see that later in the prototypes.
With these features from the MVP in mind, now we had a realistic goal on what we could work on, and later on, Qompro would be able to add more features for their product.
Low fidelity prototype & testing
In this step of the process we didn’t spend much time on details and we focused more on the way screens were organized, and the flow of the site. We split the task of creating individual elements in paper and combined them in a frankenstein-like prototype in figma, showing our clients how the application would work in a basic way. We don’t clean up the design in this step because the idea is not to have anything written in stone, but to be able to move things around and not spend much time on it.
The prototype with the basic functionalities worked as expected, and we tested it with a few users, to see if we had achieved an intuitive flow, even for those who weren’t familiar with this kind of website.
The feedback was positive in general, and the flow was clear as we intended, but some users asked for tooltips in parts where the information was scarce and the app throwed new concepts, like all the categories provided in the onboarding so you could add more Saas. We also had a screen after our onboarding with the possibility of joining all the Saas you were already subscribed to by getting the information you provided in the onboarding, but since that screen appeared just after the onboarding it was a bit disruptive to the flow. Our stakeholder also asked for a field in the data input screen where companies could state their number of employees, a data that would help them analyze the profiles and provide better solutions catered to their clients.
Mid fidelity prototype & testing
After making the changes necessary to improve the flow from the previous prototype, we translated our design to a full-digital version, added some text instead of lorem ipsum in some sections to make the flow easier to read to testers. Now, the onboarding displayed the number of steps, as well as more information about each section.
After a first pass of the tests, our users insisted that it was weird that a website like that didn’t had a homepage with a summary, so we used the opportunity to link that section with the ‘Updates’ page we mentioned earlier, as well as displaying some highlighted groups (for examples, the last one created on the page, or one that would be featured by Qompro itself). We also added four buttons that connected with the my groups section, based on the different status a group could go through:
- Open: there were the groups that still hadn’t got all the clients required to start negotiations. Our groups had a limit of 5 members, and when the spots were filled, the group was closed and a new one would automatically open. This was made this way so Qompro would be able to make the process of negotiating faster, instead of having many groups to manage or having clients wait for a long time for a group to be filled.
- Negotiation: Groups that were closed and were just awaiting the process in which Qompro took the leads to the providers, agreeing on a discount and then coming back with results.
- To be approved: when a group is created, Qompro needs to add information like the logo, screenshots, plans and all the information about features. As the process takes some time, those groups created by clients are displayed on this page, awaiting approval.
- Successfully closed: as clients should have an historic record of all the discounts provided by Qompro, we created this category so they have access to them. As of now, it only consists of a page displaying the name and the percentage obtained, because all the contact is going to be done via email in a personalized way until Qompro automatizes this process or adds the feature of a live chat with their clients.
Aside from this feature, users also asked for a search bar to be able to search for specific Saas in the onboarding and the join a group, instead of having to scroll until finding it.
Step 2: UI Development
Now that we had a first ‘beta’ version of our design, the next steps would be to start making decisions not only on the flow and content of our design, but the visual aspect as well.
Visual competitive analysis
We took the same companies we analyzed in our competitive analysis, and started taking notes on the color palette, elements and designs they had. We realized there was a trend on minimalistic designs in all of them, having bright colors against white backgrounds, with high contrast, being able to display big amounts of data without worrying about accessibility issues. Some had more pastel tones, like Welii, while others like Sastrify and Cledara had teal as their main color.
Brand attributes & Moodboard
Qompro already had already gone through an initial design with the creation of their landing page, but still hadn’t defined their brand attributes nor a specific color palette. Based on their description of their company, and the values that the users were expecting, we created both a moodboard that conveyed the energy we wanted to showcase in our product and a list of the core values we wanted with those pictures.
Instead of going against the flow, we agreed that minimalistic designs were needed to display information in a clean way, so we went with that style as well. We agreed that the design had to be modern, organized, clean and efficient, to make users able to focus on the content, not the container itself. As spreadsheets where chaotic, even with the organizational elements, we wanted to provide a feeling of calmness as well, with the use of neumorphism, a new take on skeuomorphic design that made elements pop from the background in an organic way, combining shadows and lights, imitating real life elements. This has been a trend in UX for a while, but we needed to make sure not to overdo it, because accessibility in this case was more important to have a very innovative and original design.
Colors and typography
We did several versions of the search for a group screen, one that had the most amount of information, to be able to clearly see how everything lined up. We started by designing one single card, and copied and pasted it through all the pages, displaying the search bar and a side navigation. We chose together 6 of the ones that seemed more clean and we made a test with users to see which one was the most pleasant visually for them. Most users went with the designs that had a white background and higher contrast, as we had anticipated. In the end, the most voted design was the one with purple and lilac tones, the blue one being a candidate close behind. As we liked some ideas that we tested in both designs, we combined them to create a final color palette and visual aspect, that we will see later.
For the fonts, we kept the ones that Qompro had already chosen: Plus Jakarta Sans and Nunito, since we agreed that it featured strong titles and easy to read paragraphs throughout the page.
Style tile
To be able to work at the same time in several parts of the high-fidelity prototype, we created a style tyle to help us remember the design choices we had made, and also provide Qompro with a visual way to show future developers the aesthetic of their brand. The main colors were purple and lilac tones, with non-pure black and white to be easy on the eyes. We went with big solid buttons, only having lines in tertiary ones, and using flat illustrations from Storyset to decorate the webpage, keeping it minimal while being inviting to our users.
UI Kit — Atomic Design
One of the most important approaches for us in this project was to use the atomic design organization to create our components. Since we needed to reuse most of them in most sections, we broke down each element to its minimum aspect in figma, and after creating components we combined them to make bigger ones. For example, we created tags and combined them to have the tag bar in the search section; we also created avatars, icons and buttons, and then created the cards, one of the central elements for our page. This made the project faster, and allowed us to make many variations with ease in a project that didn’t allow us to spend much time in creating this prototype.
High fidelity
After carefully creating all the components, we started building the prototype. We kept all the animations to a minimum, since we didn’t have much time to spare on it, but focused on the display of the information. Still, we emulated the motion of the cards in some carousels, as well as the functionalities of joining and leaving groups. After all the changes, we had a light application that was fast in the display of its features, but didn’t confuse the client with unnecessary information. We added many tooltips in case the user wanted to need more, but kept the information out of the way to not overload the visual weight of the screens, that were already filled with information about the Saas, cards, and tags.
You can check our finished prototype here:
When we finished it, we showed this prototype to several users and tested it with them. We wanted to highlight some of the quotes received in this test:
“The design is subtle but clean, it’s easy to read and I can find everything easily, I love it”
“I like that I have all the information that I require on each screen. If I feel lost I just need to hover the tooltip and I have the explanation there”
“I like that the animations are not too over the top, so they don’t distract, but are flowy and make the site dynamic without being too much”
We also received some suggestions to improve the homescreen, like adding a missing tooltip there to explain what those categories meant, or adding some message to our “need help” section and the categories in the profile that still weren’t developed. Of course, we translated those insights to Qompro, since it would mean that developers should add a popup explaining that some parts of the website weren’t developed, but definitely those were also a priority for the page.
Desirability Testing
To make sure that all of our design choices were on the right track, we sent a survey using Google Forms with our designs against those of the competitors, and we were glad to see that 100% of the testers chose our design over the others. These are some of the quote they sent us in that survey:
- “The cards presented in the middle of the screen are visually appealing.”
- “It looks professional and straight-forward, which is what i’d like as a company.”
- “It’s sleek, modern and has a clear contrast.”
We also used the Microsoft desirability toolkit cards to make users choose 5 adjectives that they associated with our brand, and most of our users agreed that our product was comprehensive, responsive, inviting and trustworthy, positive attributes we wanted Qompro’s brand to have.
Future steps
We finished all the deliverables required for Qompro to start developing their product, but that didn’t mean that improvements couldn’t be made in the future, the web app was far from finished. One of the things that we wanted to add that we didn’t have time to finish was the recommendations on Saas, as well as the display of how much each company is saving in those particular groups. As of now we didn’t have the data to back up the information displayed, but as soon as the project starts running, Qompro will be able to add that information to their site.
We also didn’t forget about the problem Finances Francis had about managing credentials and passwords. That feature would be very nice to be implemented in the future, as well as a record of invoices and earnings.
The chat-like platform to keep a record of all the process of negotiation, the documents needed and everything related to the discounts would also be a feature that should be implemented in the website, but as we mentioned before, that requires more work on the developers part. This, next to the Saas Management section where the user could turn on and off their subscriptions would be very interesting to have and would fulfill user needs we found in our investigation.
Conclusion
This project was the first one we did with a real company after our Ironhack Bootcamp, and it was really challenging in different ways. This project has required organization down to the smallest detail, but also adaptability, because time constraints were pressing, but most startups’ interviews were moved from their initial schedules, since most companies don’t have the luxury to spend time on them. We really wanted to thank both those companies that took the time to answer our questions, as well as Qompro, for giving us the opportunity to work on this interesting project, putting our recently acquired skills to use! We have also learned a lot about the world of Saas and b2b business, and how startup works, and I think that’s valuable knowledge for the future. And finally, I would also love to thank my teammates, that gave their all in this project, having to cut sleep and free time to be able to finish this work. Without them this would have been impossible!
If you liked our project, feel free to check the linkedins of my teammates and I and connect with us! We like constructive criticism, so if you would have taken different decisions, please share your thoughts in the comments or send us a message. See you on the next Medium post!
