How do we maximize client satisfaction? Testing 1,2,3.
In our last post, we discussed the general product development strategy employed by our team, and so this time around thought it would be helpful to follow up with some specifics on how we work closely with clients to ensure our digital services accurately meet their needs. We figured the best way to illustrate this would be to sit down with one of our Product Designers and have them share their recent experiences doing just that. So, let’s meet Ruben van den Hout, responsible for both our Plantonomy and Crop Cycle Management applications.
To start us off, as you've recently been conducting some testing with our clients on the Crop Cycle Management product… for those who are as yet unfamiliar with it, can you give us a few details on what it’s all about?
Ruben: So Crop Cycle Management (CCM) is a basically a way for growers to automate what they are doing already. So imagine you’re a grower, and you’re growing a flower crop. A flower crop has several stages of development, and within those growth stages a grower generally uses different settings for his climate, irrigation and all the other aspects that are relevant to enable the growth in that specific phase. So what Crop Cycle Management does is allow you to save all those different settings, connected to those grow phases, in what’s called a ‘recipe’. That recipe is a collection of settings for the whole growth cycle of your crop, which then can be reused when you start a new batch.
This has several benefits. One of the most important ones is that the growers for which this is interesting have to manage a lot of batches — so for cannabis it can be from between 50 and 120 at the same time which are active for example. So you can imagine if you have that many batches that are active, you have to keep track of each individual phase of each batch. Every day there will be some batches that change phases, or get harvested, so it’s difficult sometimes to maintain an overview, and often growers may forget to change settings when crops enter a new grow phase.
So CCM reduces the number of mistakes that growers may make, and also creates a knowledge base where growers can use the recipes to improve the next generation. So for example you can say these settings delivered me this result, and you can improve the recipe based on what that result is.
So in advance of us releasing a beta for CCM, you did some usability testing for the product. What was your goal for that initiative?
Ruben: Well even before we did usability testing, we did an interview where we spoke to 5 cannabis customers and explained the general idea for the product that I’ve just described. We showed them some basic wireframes of a really broad [product] proposition, because back then it was also about labour, climate… anything related to the grow phases of the crop. Based on their feedback we found out that steering the climate with those recipes was actually the core benefit where they saw the most value. So we said, ok, let’s take that part and start with that. We refined our model and built a new prototype based on the findings.
So the goal for the usability test that we did a few weeks ago was to validate again with the growers, whether the functionality would be useful to them, match their current way of working, and did they still see the value that they thought they saw when we first presented the idea.
Read more now
So how did you go about conducting the test? Was it done remotely?
Ruben: Yes, we conducted the tests remotely. We started by pre-screening the candidates with a short questionnaire, to get some details on their position, experience, and their knowledge of the climate computer to ensure we had the right participants. The test itself consisted of working with the prototype through a Microsoft Teams meeting, where we provided a link to the software which they could run on their own device, and then we recorded the whole session. I then asked them to perform tasks to guide them through the prototype.
Ok, so what were the initial reactions? How was the prototype received?
Ruben: In general, quite well in terms of functionality and usefulness. So based on the simple execution of the prototype, they really saw the value of what we’re trying to achieve. Of course there were comments about extending the capabilities by adding other features, but that was not the core goal of the prototype.
We also found out that the batch level was actually a pretty low level to work with in terms of grow phases and recipes. So you can imagine if you start a few new batches every day and you need to enter the same grow phases again, and connect the recipe, that’s too much work to be operationally efficient. So we found out that we should take one step back and look at the cultivar, or the strain that you’re actually growing, as the grow phases are mostly fixed at that level. So now per batch they only make tweaks, and for cultivar, that’s where the general planning and value is.
So you start at a higher level and basically use that as a template that you can make minor tweaks to…
Ruben: Yeah. So that’s a major change we made based on feedback from our testing.
So was there anything else in the results that surprised you?
Ruben: Not so much actually! What surprised me was that it matched so well with what they were expecting. We were actually 80-90% on the mark.
Well that’s great, and obviously validates your model.
Ruben: Yes. We also gathered some data afterwards in two main categories: usefulness and ease of use. We noticed because the workflow was a lot different than what they were used to, it took a little time for them to wrap their minds around the structure of the application. So usefulness was rated higher than ease of use, but in general averaged pretty positively.