Blue Mountain Hay
My on-going work for Blue Mountain Hay has been an interesting experience that has required a deep pool of knowledge and skill-sets. Since I have signed an NDA, I can’t show too much of the work, however I can talk about my experience working with a small team within a remote work-from-home environment, touching on some challenges and wins I have faced along the way.
BACKSTORY
Blue Mountain Hay is a forage products company based in Oregon, with additional locations throughout the Pacific Northwest USA. The company was working with an adequate but out-dated and not ideal administrative web app which was no longer conducive to their needs and complex workflow. They suddenly found themselves in the position of needing an updated and future-proofed web app.
OVERVIEW
Problem: Current internal web app no longer fits the needs of client.
Objective: Dig deeper into the workflows of users to create a new web app from scratch which would allow the company to easily track their bale inventory from farmer to customer (and everywhere in between).
Deliverable: A live shippable product that continues to go through the testing and iteration process.
HIT THE GROUND RUNNING...
When I was brought onto the project, the initial wireframes and flows had already been designed and prototyped, so some groundwork had already been laid. However, my knowledge of farming was admittedly not that deep, relegated to knowing what a tractor was, what bales of hay looked like, and knowing that dairies need hay to feed their animals. This is slightly embarrassing, especially since I grew up in Muskoka, Ontario, surrounded by farmland, but I really had no idea how the product actually gets bought, collected, and sold and how it gets from point A to point B.
Thankfully when I was handed the Sketch file of wireframes by the previous designer, she walked me through what she had done so far and her rationale behind the architecture and flows. It all was very straight forward and made total sense to me. This was a great starting off point for me to start digging deeper and to gain an understanding of the ins and outs of the business.
Since farming was new to me, it was important for me to fully understand the product flows and various needs of the office employees who would be using the new web app. So here I set up various Zoom meetings with the employees. I got them to walk me through their day-to-day tasks as well as to show me how they were using the current system. I recorded the meetings (with their permission, of course) so that I could reference back to them when needed. And reference I did! Many, many times. These recordings proved to be extremely valuable to me early on.
I also had the company owner walk me through the high-level operational process of the entire product flow — who and how the product gets bought from a farmer, who and how it gets baled, who and how it gets shipped, where it gets stored, and finally how it gets into the hands of the customer. There were suddenly a lot of moving parts to this that I initially had not anticipated. What at first glance looked very straightforward, was suddenly very complex.
As a designer, it is extremely important to fully understand how the business works and the users' various pain points. These initial conversations and the copious amounts of notes I took helped guide the rest of the project. Without this knowledge, the end product would not fit the user's needs. You can't solve problems without knowing what they are in the first place.
At this point for me it was helpful to create visual flows which detailed the entire product & workflow processes. These flows became an important tool for me to use to communicate with other members of the team, so that we could make sure we were all on the same page and speaking the same language.
From here, I could take this new knowledge and start revisiting the wireframes that I was given, adding to them and updating the prototype.
USER TESTING
The users who would be working with the final product sit in the Blue Mountain Hay offices in Oregon, however I was in Toronto; so when it came to user testing, it was all done remotely over Zoom.
To prepare for the testing sessions, I would go into the company's old admin system and find comparable and relevant information to what would be inputted into the new system. I did this because working with real-life information and data when testing makes a big difference. In one common workflow, for example, the user has to record the bales of hale they have stacked at a farmer's field, the info that was filled out on a trucker's weight ticket, and then also where the product was delivered. For testing purposes, it would have been easy to just make up bale numbers, farmer names and storage locations, however that would not give a clear indication of a real-life scenario that the users would be dealing with.
Using this info, I would then set up a task list (eg. "Here's a weight ticket from a trucker. Show me how you would enter this information into the new system. Including, farmer, bale weights, etc."). During these sessions, I would just let them click through the process. I would take notes and maybe ask an occasional question throughout, however I tried to save them for the end since I mostly wanted to see how they interacted with the web app. At times I would get them to speak their process out loud, so I'd have a glimpse into their thoughts and get closer as to why they happened to be clicking on the link or button they were clicking on, etc. I recorded these sessions to refer back to when I went "back to the drawing board" and at times to share with the developer as a helpful communication tool.
These sessions proved to be invaluable. I would see the web app work in real-time, see first-hand the user's pain points and wins, and see some of my assumptions blown to smithereens. (LOL).
COMMUNICATION
The team was very small, comprising of only me (in Toronto), a developer (in New Mexico), and the project manager and company owner (in Oregon). Since everyone was working remotely, in different timezones, and we were all occasionally juggling other projects as well, early on we all noticed it was difficult to sync schedules. This was causing some workflow blockage, so we eventually settled on a consistent Monday afternoon meeting where we could catch up about what happened during the week prior and what the plan was for the week ahead. We could also clear up any questions we had as a group and use that information to propel us forward. It became a very helpful quasi “weekly standup.”
As the end product came together and we entered the user testing phase of the web app, the developer and I created an efficient communication technique — using tags on GitHub issues. It worked as follows: Through Zoom user testing, any issues we encountered I would enter on GitHub and add a priority label. If further clarification was needed, the developer would comment on the issue and add a “help wanted” tag or, if all was clear, fix the issue and add a “ready for review” tag. I would then either tend to his comments/questions or test the issues labeled “ready for review”. If all was fixed and working properly, I would then close the issue within GitHub (and feel that oh-so-satisfying feeling of striking something off a to-do list).
Along with informal Slack chats, using these customized GitHub labels became our most consistent communication tool.
BEWARE THE SCOPE CREEP
What was interesting about this project was that we weren’t really building a bare bones MVP that we could release and then continue to build on. The client's previous system was quite robust with a lot of features and the majority of these features were needed in the new system from the first day it went live to make it useful for them. So while we were trying to better their situation and give them a useful and successful product, we also had to keep scope in mind. To keep the project within a specific timeframe, I constantly had to ask myself “What functions really are needed for launch?”
But naturally feature requests would start to come down the pipeline — “Wouldn’t it be great if it could do THIS or THAT?”. And while the answer usually always is, “Yes, it WOULD be great!”, the reality is that the core functionality needs to be sound first and that is where the focus should remain. But it can be quite easy to lose sight of that in the excitement of what could be.
To combat scope creep and to keep us on track, it was important to keep lines of communication open. As someone who has a very rational and logical mind, I became the voice of reason. On GitHub, we created the labels of “bug” or “enhancement”. Bugs got priority and needed to get fixed, but enhancements could potentially be “nice to haves” that aren’t necessarily high on the priority list. Prioritizing “needs” vs “nice to haves” became a constant, but was easily manageable with these simple tools and clear communication.
TAKEAWAYS
The first iteration of the new web app is now live and is being used — and feedback has been positive! Currently we are in the phase of fixing the odd bug and slowly moving on to those “nice to haves”. It’s a good place to be.
Working on freelance projects, I’m continually surprised by the new knowledge you can accumulate as you take on a diverse selection of products. As previously stated, before this I knew next to nothing about farming, but I pulled up my socks and quickly learned. Now I could probably estimate the weight of the truck load of bales that you pass on the highway and if they are 3x4 or 4x4 bales! But for reals, to successfully design a product (no matter how niche or outside of your own personal world), you have to truly step into the shoes of the user and learn how their world works, which never ceases to be being interesting if you’re open to take that ride.
Thanks for reading! In the end, this product was very intensive and robust. While this write-up focussed mainly on communication and the team dynamic, there are lots of design specifics I could expand on. If you would like more info or have any questions, please don't hesitate to get in touch!