Agronota
The team
Before we move on, it is good to understand the team behind the project:
Product manager
Product designer (me)
Front-end developer
Back-end developer (x2)
QA
I and the PM worked very closely, always studying, talking back and forth about mandatory fields, rules regarding invoicing, and business needs.
It all started with an assumption
Smarten, the parent company of Agronota has been providing invoicing systems for more than 15 years, so they are always looking for new opportunities within this market.
We knew that electronic invoicing for farmers would become mandatory within the next few years, so we asked ourselves:
Is there room on the market for a product that helps both farmers and accountants issue those invoices in a simpler way?
In Brazil, the government provides websites to issue electronic invoices. It is free, but it is a complicated and complex system, often scaring farmers and those who are not tech-savvy.
The solution for them? Hire someone to do the hard job.
It was time to talk to users to investigate if there
was a real problem to be solved.
Interviews
We interviewed 8 users. Two of them were farmers and the other six were accountants. All of them need to issue electronic invoices.
Guiding Questions:
How do you issue electronic invoices?
Do you use the website provided by the government or a third-party app?
What are you looking for in a website that issues electronic invoices?
What problems do you face when issuing an electronic invoice?
(Accountants only) When it comes to the farmers: is there any other problem around their finances that you are facing right now?
(Farmers only) Why you do not issue electronic invoices by yourself?
These are only guiding questions. The conversation always changed depending on their answers.
Better results than we expected
We not only discovered we could create one solution, we could also tackle two other problems: a digital cash book and a tax calculator, focusing exclusively on farmers. All in one product.
We also used some key insights as pillars for our planning and development: lots of automation, easy to use, and no more paper, please.
Before planning, examine the players
To create a roadmap, we first decided to examine our competitors to see how they were approaching possible solutions and how we could do better.
Some competitors had all the same features and some were specialized in one of them. We documented all findings and planned based on the discoveries.
Roadmap of deliveries
We broke down our deliveries into three MVPs:
MVP 1: Issue electronic invoice (support for web and mobile)
MVP 2: Automated search for invoices, a way to manage incomes and expenses, digital cashbook, and bank accounts.
MVP 3: Tax calculator
From long forms to a few simple steps
The user flow for invoicing was the most challenging part of the product by far.
As a team, we were challenged to understand every detail, leaving no room for mistakes or misinformation, since any wrong data could lead to problems for the user.
To understand the product we studied the subject and conducted exploratory user research.
Exploratory user research
For the research we used the system provided by the government as a reference, because it includes all possible situations in one place.
Shadowing
Observing the user (accountants) use the system provided by the government. Understand how they use it and see what we can remove to make it simpler.
Record screen and audio
We recorded the accountants using the website. During the activity, we asked them to speak their minds so we could understand their thinking.
A lot of data means a lot
of iteration
Automation and simplicity were our pillars:
Which input can the back-end send automatically?
Which input can start filled by default?
Which preferences can be saved from the last invoice?
How can we simplify even more?"
Desktop - User flow sample
Mobile - User flow sample
We made invoicing easier
Then it was time to add another layer of features and deliver what the users asked during our interviews: no more paper.
We had the first part: The farmer/accountant could issue electronic invoices.
Now we wanted to search for invoices from companies/stores where the farmer spent money, search for expenses, not incomes. With this, we could generate the cashbook, month by month, transaction per transaction.
No paper. Only electronic invoices.
A similar process of iteration as before, but...
This time we could not observe the user interact with the product because the government did not provide any website to generate the cashbook. It is a mandatory document but there is no official website, only third-party apps. So we needed to be fast and be ahead of the competition.
We repeated the process, it worked before so we did it again.
An invoice scout to hunt down expenses
We created a bot to automatically download invoices issued by stores or companies to farmers.
On this screen, the user can filter which invoices he wants to add to his finances (incomes/expenses) and ignore invoices that are not linked with their agricultural work.
Once they choose to add the invoice to their finances, users need to fill in the rest of the information, which is only a few fields since the bot can read the invoice and auto-fill the majority.
Giving control to the farmer
The next step is to enable accountants and farmers to understand their incomes and expenses and choose which invoice will be linked to the cashbook.
We give them the option to manage their finances without actually generating a cashbook if they do not need one.
(The cashbook becomes mandatory when the farmer have a turnover above R$ 4 million, so medium and small farmers will not use this feature in the near future)
Wrapping everything up, the cashbook
All those features can be boiled down to a single document, the cashbook.
As stated above, this document is mandatory for farmers that have a turnover above R$ 4 million. Every year, this number will decrease, meaning that more farmers will be required to generate the cashbook over the years.
Here, our plan is to automate invoicing and to eliminate the use of paper:
Users can issue invoices.
Users can track down invoices issued from stores/companies.
Users can organize their incomes/expenses
Users can generate the cashbook 🥳
And remember the Tax calculator?
We realized during its discovery that it would be easier to develop than expected, so we moved it to MVP 2.
The calculator was placed inside the product as a feature, but it was also used as a tool to generate more leads. We placed it on the main website as a trigger to get emails and contact numbers. More than 500 leads were generated in the first month.
After we understood the big picture of what could be done (thanks to research) the solution became way more complete and valuable for users than when we first imagined.
Lessons learned through
the project
I like to look back at my projects, presentations, or any type of work and investigate what I could have done better. Down below are some lessons I took from this project.
Verifying early my designs decisions and changing accordingly helped me find the right solutions very fast. It doesn't need to be a high-fidelity prototype if you can properly communicate your idea.
Finding a direction and working on it is a better decision than spending time on details at the early stage.
Include everyone early
Rapid iteration was only possible because we discussed ideas with everyone involved.
I and the PM were always checking with devs if the idea was viable and with users if we were on the right track.
Study the subject, a lot
Truly understanding the problem and diving into the subject enabled me to think fast and easily communicate with accountants.
The whole process becomes easier when you comprehend what you are building.
Thank you