Introduction

After successfully building a web application in record-breaking time (see original study case here), the client expressed satisfaction, leading us to continue our collaboration. The new request was to develop a second system that shares data with the original one.

This system needed to introduce new functionalities, such as an updated dashboard, a complex reward system as well as synchronization with a custom webshop. Additionally, the system had to feel familiar to the existing user base while at the same time being distinguishable from the original one.

This case study will detail how we approached these challenges and showcase the results. Let’s begin by jumping into the design phase.

Design

The goal in this phase was to maintain the familiarity of our system for the existing user base while simultaneously ensuring a sense of freshness and familiarity. Achieving this delicate balance presented a considerable challenge, but fortunately, our designer possessed the experience and skills necessary to tackle it. Collaborating with developers, the client, and myself, we swiftly finalized the look and feel, proceeding to design each individual screen used in the application, which was then approved by the client.

‍

‍

Typically on projects like these, you have limited resources (and time) so we needed to focus on what’s really additional value, so alongside the color scheme update we ended up designing a couple of new components, but at the same time we reused as much as possible, to maintain familiarity as well as reduce complexity, thus being able to stay within the delivery timeframe.

‍

Updated reward system

In the previous system, a commissions and pools-based structure was in place. However, in the new system, the rewards (and rules) became more intricate.

Essentially, users and those in their referral tree were rewarded for their purchases of plants. In a sense, you can think of this as a cashback system, but instead of direct discounts users received commissions from the bonuses for which they were eligible. The bonuses were the following:

1. Sales bonus —Basic Bonus rewarding users for bulk purchases.
2. Special bonus — An upgraded reward system from a special bonus, targeting medium-sized buyers.
3. Super bonus — A reward system for power buyers who order large Volumes.
4. Residual bonus — Reward for users who brought lots of smaller buyers, but that don’t buy in large quantities.
5. Pool bonus —a special pool in which, 1% of every purchase went. The sum was then equally distributed between the eligible users.

The initial and crucial step was to clearly understand and afterward define the logic. To achieve this, we used a FigJam board, where we manually documented calculations and provided examples for each computation. Every single computation was then checked (and confirmed) by the client.
When doing a calculation, we wrote the thinking logic in whole sentences, why something happens. This helped us quickly jump back to it when reviewing the logic at a later date.

‍

‍

As you can see each type of bonus addressed and tackled a certain type of user, and ultimately rewarded (motivated) the users to make as many purchases as possible. Coding the logic here was certainly a challenge here, but after roughly 3 weeks of work we got it working exactly as we wanted.

Alongside the backend logic, other part of the team worked on displaying the bonuses on the dashboard, so let’s have a look at this next.

‍

Dashboard

Same as in the first system, the dashboard serves as the central hub where users access all vital and relevant data within the system. We faced the challenge of designing a new interface to present a substantial amount of data in a user-friendly manner. Our solution involved re-using tabs, incorporating a pie chart, and integrating progress bars to motivate users and visually represent their progress toward goals. Additionally, dedicated tabs were implemented to provide users with detailed information on their performance and progress toward earning rewards.

‍

‍

Naturally, the views varied for each user role. Admin is interested in general statistics and datasets, while users needed information on their progress toward bonuses and the performance of their team.

‍

‍

Synchronization with webshop

Another significant new feature involved the synchronization with a webshop, where purchases were made and subsequently synced back to the system to count towards “sales” and rewards. The synchronization process had to be robust, as accurate numbers and bonuses depended on retrieving the correct information. We implemented a two-way sync, ensuring data such as commission balance, user information, and order information were synchronized.

Communicating expectations and functional specifications to the developers was crucial in ensuring a smooth operation. Once the functional specifications were written down, it was essential to prepare well-written technical documentation. This documentation serves not only to debug potential issues but also to facilitate smoother project onboarding for new developers joining the team.

‍

‍

As the project manager, my role involved ensuring frequent communication between developers on this topic and monitoring progress. This was achieved by addressing the matter during daily standup meetings. If any blockers or uncertainties arose, immediate action was taken to resolve the impediments.

We are also in the process of preparing a case study detailing the development of the webshop, which you can find here.

‍

Bonus: Automation testing

‍

‍

There is one more aspect I would like to address that wasn’t mentioned before. Throughout the project, in an effort to save time, minimize bugs, and enhance quality, the development team collectively decided to initiate automation testing using Cypress. This proved to be a prudent decision, with noticeable improvements evident in the sprint following this choice. Here is what Amadej, our QA lead, had to say on this topic:

At the beginning of the project, testing was all about manual labor. Meaning clicking endlessly, testing every function, every step, and every screen by hand.

In our quest to enhance our QA process, I implemented Cypress, building on my existing testing expertise. Leveraging my prior experience, I seamlessly integrated Cypress, overcoming the initial challenges with ease. My understanding of Cypress’s capabilities significantly elevated our testing efficiency which not only streamlined our testing processes, but also complemented my JS programming skills.

Why Cypress? Because it’s challenging, funny, and rewarding software that is always a “work in progress”. Every day you write and execute tests, you find some new challenges that keep motivating you to know more, to learn more, and to work better every day.

Cypres provides us with more sufficient, effortless, and effective testing sessions. Once you know how to use it correctly, it helps the whole team that is working on a project with more effective bug and error detection, thus greatly benefiting our project team’s performance.

Amadej, Cloud9devs QA engineer

‍

Evolved client communication strategy

The client expressed high satisfaction with our services, highlighting the quick delivery, effective collaboration and communication, and our comprehensive guidance throughout the project.

As our partnership with the client grew stronger, I refined our communication methods. Establishing regular weekly overview meetings was a key step that helped us effectively tackle issues and challenges. In addition, we reached a consensus that phone calls should be used for urgent matters. For everyday, non-urgent communications, we chose to use Telegram, ensuring that we stayed on track with our project timelines.

A notable success was the on-time delivery of the product, which stemmed from our familiarity with the client’s expectations and our ability to leverage our strengths. This wasn’t mere luck, but a result of our previous experiences with this client.

Our team’s growing expertise and in-depth understanding of the project allowed us to provide a precise project timeline estimate of 11–13 weeks. This efficiency resulted in delivering higher value within a shorter timeframe. Additionally, our increased knowledge of the user base’s needs and behaviors informed our recommendations to the client on the optimal design strategies for each feature in the planning stage.

The most significant outcome of this collaboration was the profound understanding we developed of the client’s business needs over time. This deep insight enabled us to offer customized and effective support tailored to their specific requirements.

‍

Conclusion

After roughly of 11 weeks of development, we were finally ready to release the product to the customers, therefore the product goal was successfully achieved. Here are some of the key factors that contributed to our success:

1. Value Prioritisation — discover what your customers love about your product. Write everything down, then put it on a list and order it by priority. This will help you maintain focus and reach the goal.
2. Write everything down — Just as stated, write everything down. Furthermore, when working on something complex write down even the thought process.
3. Prepare functional specification —The product owner (or project manager) should write down the functional specification of how a portion of the system should behave. Then ask the developers to write technical documentation on this feature.
4. Facilitate retrospective meetings — by having retrospective meetings, you facilitate the discussion and collaboration among team members, which may lead to process improvements. In our case, this led to cypress testing among other things.

In conclusion: it’s important all stakeholders (our team and client’s team) clearly understand what we’re trying to achieve, and what challenges we’re working on. Once the goal is set it’s just a matter of time before you and your team can reach it.

‍

Written by Peter Artenjak, PSM I Project Manager @ Cloud9devs.com

‍