Designing a complex Leasing software
We will discuss about Keshavarzi’s leasing system designing process here. What were challenges and what we achieved.
Where does the story begin?
The whole target was creating a integrated online leasing software for Keshavarzi Bank. Means that from choosing to delivering the product would be completely online. This was the second integrated leasing system of the whole country and that’s where our troubles began.
How did we start?
As you can see, we had most parts of the actual business model which was so helpful. This picture exactly shows what is happening in a standard leasing process and how data transfers between different panels. We knew what was our exact target but our real problems were something different.
- We only had one product in country which was similar to ours’s so we didn’t have many examples to do deep research and competitive analysis
- This system was new for us. We didn’t have any experience with leasing process in real world and now we have to design it!
- The whole system was considered to have multiple users and panels. By saying multiple users, I mean every single request of users should transfer between different panels with different admins and that’s hard! (You can easily understand what I mean using the picture above)
- Leasing process was happening in traditional way in the country. For every step, there were many paper works and different difficulties. We didn’t know the exact concerns of this world and also how to make an online clone of it.
What we needed
We needed to understand the exact mindset of user. But also we had some experts in cour company which we could ask several questions about process during the design process. To reduce the time of training our team about every part of leasing (I mean every input box and other parts had different functions and meaning, which could effect and change the whole process to other direction and requests.), we needed a quick way to learn and use them at the same time.
As I mentioned, due to market situation, we didn’t have many options for research and other related steps. So it was important to consider every aspects of the product to reduce our weakness in research steps.
Time to start
We started by gathering all the business models of product. We have checked them several times and started asking our questions from experts about what each step or any part of the process means. In other word, our first approach was to train ourselves good enough about whole process, but we didn’t have much time.
Process of work
We have decided to do interviewing and learning from the beginning to the end of designing process. Main reason of doing this was simple. Leasing system is so huge so there are lots of things to learn about and we didn’t have enough time to learn everything and then design. Of course there would be conflicts during this way of designing, but we’ve managed to reduce our speed just to make sure everything was going well. Most of our questions were answering by experts so we were much aware of each step.
Beside of interviewing experts, we did several interviews with different users of system to understand their mindset and producing our personas for project. We needed to know what is exactly happening in real world!
One of the most challenging parts were the main users. Let me be more specific. Our main users would be some trained experts. They were involved in every step in each leasing steps for checking and changing the state of a single transferred data between different panels. It was totally fine but we needed to know how they wanna train them to understand how to design better. It’s true that they would be trained for working with this, but we can’t skip applying user experience to their panels! So we tried keep that balance by creating the whole system without considering that users are trained for it. After that we started slightly changing some parts based on our hypothetical persona for this specific users.
Our product backlog for each sprint was upside down. Each main panel was for a single company so our main user which I mentioned before was a trained employee of that company and every panel needed a setup process like windows. For creating a setup based system, it would be much easier to start from the beginning or the root. For some reason, managers decided to start from the end to beginning which was so challenging. It was common to change a designed part just because we were getting closer to the root of the system and also all business models weren’t ready.
It was a total chaos but we’ve managed that situation with huge documentation. We documented every action and decision we made for each screen and each field. Speaking of documentation, It’s worth to mention that each step of leasing process has made of different subsets and each subset had it’s own components. That’s where we decided to do everything specially our documentation process in atomic way. Because as I mentioned, everything was so complex and huge. By doing this way of documentation and design, now changing every part or any further actions was much easier and simple. We were almost faster this way!
As I mentioned, we were learning during designing process about leasing. So we’ve decided to put anything that we learn about each part in it’s document so we made it impossible to forget about them and also everything would be clear for other designers and other teams.
Another matter was the system’s integration. Each panel had it’s own rules and functions but overall they were making a single product together. It was important to keep everything integrated. We didn’t have much time to create some general rules for our design structure and that’s why we’ve decided to design everything and then redesign everything again once we got to the end. It was much faster and also accurate; because we had experienced the whole process once and we knew about similar parameters. Now we were able to create some great general rules based on real data and experience to refactor everything.
Let’s do some test
Leasing is complex (I’m saying this for 100th time). Each process is so long and for accurate results, we needed to test all the process at the same time but it was impossible. So we detected which parts are available for tiny usability test and we tested only on those parts. For the most of the flow, we’ve decided to test on real world and get real feedbacks. We started collecting user logs and events and combined them to understand the final result for each user in real world. After doing that, we found some problems. Some of there were because of business models and rest of them were on our side. We fixed our side step by step and kept analyzing all logs.
What we learned?
As we all believe, we all need to know everything to do something specially when it comes to product world. But that’s not true. We learned that it’s possible to adopt and develop our knowledge about something we want to make at the same time we are building it and that’s how you grow up with your product.
