I lead the design and branding for farmr. I conducted user research using a systematic UX/UI design process that is user-centered. The following is the story of how I worked the through problem farmr was trying to solve, and how I met the user goals and business goals.
The average supermarket apple is 14-months old, potatoes are up to a year old, and carrots are up to 9-months old! farmr wants to change that and connect farmers with customers who genuinely want fresh produce.
Are you the kind of person who cares about the safety and freshness of your food?
You buy fresh food from a high-end grocer known to sell organic food, but have you ever wondered how "fresh" your food is? Most produce is months if not up to a year and a half old. That is crazy. How many of us know how ethically the produce that we eat have been grown, or under what circumstances the chickens were raised to get that organic label?
Local farmers depend on selling or renting booths to sell their produce and proteins at farmers markets, but because of ease of use, more people shop at large grocers. farmr wants to change this.
This phase in my systematic UX/UI process is about understanding what the business hopes to achieve to solve the problem.
farmr had two solutions they wanted to offer to customers.
Give customers an easy way to buy produce directly from farmers.
Give customers the ability to rent land from farmers called pods. The user could virtually take care of their pod while the farmer professionally cares for the pod of that customer.
I then broke down those business goals into a way a user was going to accomplish them. The client, development and I had many conversations to build the requirements document using Google Drive so we could easily collaborate back and forth.
Give customers an easy way to buy produce directly from farmers by allowing the customer to choose from various farms to buy produce in an e-commerce style cart.
Give customers the ability to rent land from farmers called pods so the user could virtually take care of their pod by giving the customers the ability to rent via subscriptions through farmr for a season (3 months) or an entire year.
We then scoped these out further for requirements. Here are some examples of our requirements in our scope document we created.
Allow a user to save credit card information.
Allow a user to favorite a farm so they could quickly buy from that farm again.
After talking with farmers and distributing surveys, we found the most popular pieces of land for an individual pod would be either 8' by 8' or 8' by 16'.
This allowed the business to offer two choices of pods and charge more money each month for the subscription of the larger pod.
Only allow the user to select produce from a farm that was available.
This would mean we would have to have a database of produce and proteins. We would also have to allow the farmer to create a profile so they can enter in what produce or proteins they offered at their location.
Thinking up solutions
Starting with wire-framing by first sketching in my notebook, I am able to think up multiple solutions quickly and get an idea to start cleaning it up to move forward with a hypothesis.
I then moved the idea, that I hypothesized solved the solution into a flow chart to understand where all of my pieces were going to come together. How a user navigates through the app is very important. This allows you to think of the journey the user goes through your app instead of individual screens. A user-centered approach is empathizing with your users. You will find shorter ways to accomplish a task, how to combine tasks, or what tasks you need to remove. 💯
I then moved the idea, that I hypothesized that solved the solution, into Sketch. This allowed me to create a cleaner wireframe that we could then build a prototype for. This is so we can do some user testing before moving into hi-fi designs and a hi-fi prototype. Allowing us to fail and learn without spending a lot of time on the UI and branding.
Here is a video of the prototype I built from the wireframes. We took this prototype to test the farmer side and user side at local farmers markets. This is what is commonly refereed to as guerrilla testing. This is because guerrilla testing is not in a controlled environment, and you are out in the wild. I find this type of user testing the most effective, but I do controlled environment testing as well on most projects.
Taking what I learned from wireframes, I was able to implement those changes in the hi-fi design. We also added in fun iconography and bold beautiful images to give the app a wanting or craving from the user to buy produce from a select farm.
The designs needed to be scoped out for the farmer flow, the user who wants to rent pods, and the user who wants to buy produce from an individual farm. We needed to show alerts, sign, payment and everything in between so we could put that in a prototype but ultimately give that to the development team so they knew how each piece was going to work.
We involved the development team through the wireframe, hi-fi, and all user feedback processes. This kept them in the loop so they knew what we were ultimately going to build. While we were testing and finalizing the design they were building the architecture and constructing the database to house all of the data.
We then wired up all of the hi-fi designs back into MarvelApp so we can then do a second round of user testing.
The following shows a video of the hi-fi prototype built in MarvelApp. I usually build them in Invision, but I know different teams use different tools. I want to make sure that I am at least somewhat familiar with various tools in case I have to work within constraints.
We found it tough to test farmers with a wireframe prototype.
It was easier it seemed, to test them with a hi-fi prototype. Our conclusion was they would rather create a profile, upload information, and manage orders and pods from their desktop. That is what sparked us to remove the flow of the farmer from the app and build a web app for the farmer to upload their information.
That story will come in a different case study soon.
After removing the farmer flow we then created another hi-fi prototype to test users. With the tweaks I made from the feedback from the wireframe prototype, I found a more successful run through will all users. There were some final things to tweak but it was good to go after that to start writing user stories for development. The project is still being developed. You can view more information about farmr at localfarmr.com.