Visit GooglePlay
Client : Jala
Year : 2018-2019
Jala is an IoT startup in Yogyakarta, Indonesia who provides solutions to help farmers understand the farm condition better in a real-time way for a preventive action towards the risk of farming. Currently, they have 2 products, the device that can detect water condition and a web app that integrated to the device so the farm owner can see their farm condition and eventually will have a better plan to get a successful harvest. This project is about creating the mobile app version of the web app, so farmers can bring and use the app when they’re at ponds while checking the actual ponds.
How the Jala IoT Work
Before getting to the case study i think it’s better to explain a little bit about the device itself. The goal of Jala is to help farmers understand the farm condition better in a real-time way for a preventive action towards the risk of farming. So, they create a device that can measure the water quality, by using 4 parameters. These are the data that farmers take twice a day.
How to use the device? the farmer drop the beacon to the water and then tap the button on the main device, and wait a few seconds, then the device will show those data above. You can watch how it work in this video. Btw, i’m also the one who create this video for them.
The Problem
They came to me and said there is one main problem they want to solve, at least in the first version of the app. So, at that time, the farmers still using a physical notebook to write down all the data of the ponds, at least twice a day on each pond, in the morning and evening. There are some problems with this method:
- The notebook will be damaged over time because the farmers use it every day, and the data on it will be lost. Or the notebook itself can be lost or damaged by accident.
- The farmers need to write the data all over again whenever they need to report it to the farm owner. It would be a time and energy-consuming for the farmers. Imagine, a farmer is typically managing 30-60 ponds, so they have a lot of paperwork to do.
- The farmer can’t compare the data at a specific time on specific days in a glance. They need to compare it manually by looking at the data one by one and flip the pages over and over.
- The farm owner has to analyze the data they get from the farmers manually to define the next step/plan for the farm.
- It takes time for the farm owner to know the condition of their farm because they need to wait for the report from the farmer.
Those are the main objectives of the app in the first version. Now we already moved from the first version, so i will also show the result of the final app. But for this study case, i will focus on discussing this note-taking problem in the first version app.
The User & Audience
The user and audience for this mobile app are the farmers and the farm owners. But the one who will interact with it the most is the farmers because they are the ones who take notes of the pond’s data. The farmer owner will open the app periodically to check their farm condition.
Role & Responsiblity
I am a freelance designer in this team, and I’m the main and only designer for this mobile app, so i do all the design work for this app. From icons, illustration, wireframe, mockup, prototype and i also involved in the user testing, went to the farm and talked to the farmers.
Scope & Constraints
The scope of the first version of the app would be the note-taking part only. Then the 2nd version would be converting almost all the features on the web app into a mobile app version. But in this case study, i will only focus on the first version of the app.
Our mistake at the beginning is we didn’t conduct proper research of the user (farmers) because of a tight deadline. We only assume what they need and how they would use the app. For that reason, we heavily depend on the test result of the first mockup that i make, which i will discuss at the Process part.
The other challenge is the farmers are not tech-savvy. They probably only use their smartphones for calls and texting. But some of them are using WhatsApp and Facebook.
Process
Research & Gathering Requirement
Actually what i did was only interviewing the CEO and the developer of the app. Assuming what the farmer might need. And this was a big mistake because we should do research and interview with the actual farmers. I will talk about how we overcome this mistake in the next section.
The approach that i use to determine the flow is defining how the farmer currently take notes of the pond data manually to their notebook. The flow is:
- Farmer goes to a pond
- Farmer uses Jala device to measure water quality
- Farmer takes note manually on their notebook.
- Notes : farmer take notes mostly twice a day, morning and afternoon.
At least that is the flow that i get from the first meeting. That flow seems too simple, and that leads to our first problem because i can’t see the actual flow from the actual farmer. But i have to work with what I’ve got in that time.
Skipping Wireframe Process
I ended up skipping the wireframe process due to the tight deadline. So i decided to create a very simple mockup to visualize my idea. I know it’s not a good example, but it is what it is.
First Mockup
Like i said at the Scope section, we didn’t conduct proper user research due to the tight deadline. So, i only have the data and requirements from the CEO and the developers. Then i try to create my first simple mockup proposal based on that requirement. Basically it’s only the flow of the note-taking process of the app.
On the Notes screen, it’s a list of individual notes that the farmer created. Every time a farmer added a note, there will be a new card here.
Then there’s a separate screen for Ponds. In this screen, the user can see the latest note on each pond. There’s also information about pond status, giving the farmer warning if the pond’s condition is not right, so the farmer would investigate the cause of the warning and hoping can make the water condition better.
If a Pond card is clicked, the user will navigate to notes inside the pond. There’s all the notes in that pond, the pond information, and filter feature. I know it looks messy 🙁
Usability Testing
When the first mockup above is approved by the team, we conduct the first user testing. I and one of the team Syauqy went to Purworejo (2,5 – 3 hours from Yogyakarta).
The method we use is we print the mockup on small papers in mobile phone size. And then we ask the farmers to examine and interact with the papers just like they use it as an app. We add notes on every screen, which makes them confuse, hard to interact, and can not understand, so we can use it as a not for changes in the next iteration. We did the testing with 3 farmers at that time.
The result is quite heartbreaking for me as the designer of the app because all of them find it hard to understand the flow of the app. But i have to accept it, it means that i as the designer cannot just assume the best flow for the users. This is the importance of user research and user testing.
“You wouldn’t know your product will work until it used by the real user.”
Iteration after Testing
From the first user testing, we got so many valuable feedback. Then we collect all the notes, compile it, and discuss with the whole team about what we should do next. So, we did a total rework of the workflow.
In the first user testing, i just noticed how the farmer actually writes their note. And that’s become my guide to design the next version of the mockup. This is how they write their note, in a table *obviously not in cards like the first version mockup
And this is the mockup, before and after the usability testing.
On the left is the mockup before the testing. On the home screen on the bottom bar, you can see there’s a “Catatan” (Notes) tab active, so this screen shows all of the latest notes, all of it, no categorization, so it can get messy. The user writes a note also from this screen. Then to see a pond, the user need to click the “Kolam” (Pond) tab, and then click on a pond to see the detail. What’s wrong is, that is not how the farmer taking notes and see their notes. From the testing we learned that the flow is:
- Farmer goes to a pond.
- Farmer uses Jala IoT device to measure water quality.
- Farmer takes notes on their notebook, looking the notes based on which pond.
- Farmer goes to the next pond.
The difference between this flow and the first flow above is i know the details on this flow. I know how the farmer use their notebook. I know how the notebook looks like, so the farmer is familiar of the data visualization. Those are the things that i can’t get only from the meeting with the CEO and developers.
Meeting and interviewing the real user is extremely important, so we can see the details of the actual flow.
So the home screen should show the ponds first because the farmer taking notes based on the pond where they at. So we revise the whole flow, as you can see on the right side. Farmer will see list of their ponds in home screen. Then for example, if they want to write a note for Pond A, they tap on Pond A, goes to Pond Detail screen, then add a note in this screen.
User Flow
Note-Taking User Flow
Complete User Flow
Problem Solving
Problem 1
The notebook will be damaged over time because the farmers use it every day, and the data on it will be lost. Or the notebook itself can be lost or damaged by accident.
Solution : Using the app, the farmer doesn’t need to worry about losing their notes because the note will be uploaded to the server.
Problem 2
The farmers need to write the data all over again whenever they need to report it to the farm owner. It would be a time and energy-consuming for the farmers. Imagine, a farmer is typically managing 30-60 ponds, so they have a lot of paperwork to do.
Solution : The farm owner will have their own account on the app, so they can see the report anytime through the app. And the farmer doesn’t need to write the notes all over again.
Problem 3
The farmer can’t compare the data at a specific time on specific days in a glance. They need to compare it manually by looking at the data one by one and flip the pages over and over.
Solution : In the app, we create filter on the pond detail screen, so the farmer can see the notes based on the time a note created.
Problem 4
The farm owner has to analyze the data they get from the farmers manually to define the next step/plan for the farm.
Solution : there is a feature to show a graph version of the data, so the farm owner is able to analyze the data much easier.
Problem 5
It takes time for the farm owner to know the condition of their farm because they need to wait for the report from the farmer.
Solution : if there is stable internet connection, the note-taking process can be realtime, which means the farm owner doesn’t need to wait the report from the farmer to know their farm condition.
Design Decisions
Onboarding
I am making sure that it’s very clear to the user that they can click on the “Lanjut” (Next) button. Even i add arrows symbol and number indicators to me it clearer. Because i was only putting 3 dots indicator in the first usability testing and they didn’t they can’t swipe it.
Home Screen
This screen shows all active ponds on a farm.
- Menu icon, i put it on the right side so it will be easier to reach.
- Top bar, i fill it with blue color so the search field is easy to find. Also as brand identity.
- Farm dropdown, i put it at the top because ponds are inside a farm. It makes sense in a hierarchical way.
- “Tambah Kolam” (Add a Pond), i don’t make it so prominent because it mainly used when the user use the app for the first time. They won’t dig a hole to build a pond so often, right?
- I show the latest note on each pond so the farmer can check the latest condition quickly.
- Side margin, i don’t give a much of side margin, because this app need to show a lot of data, so every horizontal space is valuable.
Pond Detail Screen
This screen shows all the notes in a pond.
- Each pond has its own variables, like the size, the age, etc. And the user can access these variables by clicking on the pond title area, and the information will expand.
- There are 4 categories (tabs) on this screen, and water quality is just one of them.
- “Mode Grafik” (Graph Mode), the user can switch between table mode and graph mode. Graph mode is easier when the user wants to do data analytics.
- The notes separated by date. And on each date, there are 2 notes, note in the morning, and note in the afternoon.
- I put “Edit” text on each right side of the note to make sure that the farmers know how to edit it since they are not tech-savvy people.
- There are 2 buttons at the bottom. A smaller one, Filter, to filter the date and the time (morning &/ afternoon). And a bigger one, Tambah Catatan (Add a Note). I make it bigger because it’s more important than the filter button. I also put it on the right side so it’s easier to reach.
Add a Note Screen
This screen is to add new note.
- Very simple, very straightforward, so the farmer can use it easily.
- The time is automatically filled based on the system time, but it can be edit by the user.
- Clear button to save the note.
Final Result
After the mockup is done, it developed by their in-house developer. The whole design process took more than 1 year because they contacted me again for the 2nd version of the app.
Download the app on Google Play
