May to July '19
A interface design project focused on educating free users about the paid features
A system that encapsulates all the typography, patterns, and design components used across the application.
The idea of previewing a paid feature for our product (and educating users about it) stemmed from an indirect user need passed to our product team from sales. We learned that one of the biggest difficulties in selling the product was users were unaware of some features' functionality. (They weren’t targeting users out of segment — some of our paid features are just unconventional.)
The project initiative provided by our Product Manager detailed a user story that revealed users' desire for a trial of our feature (Crop Health Monitoring) before purchasing it. The user story also functioned as the problem definition because it clarified and contextualized user-reported problems we noticed prior to starting this project.
Next, we spent a couple of days observing users in the app. This was not a direct Contextual Inquiry, but we still viewed recorded sessions of FarmLogs users interacting with our app (our tool:Inspectlet). Viewing these sessions helped us pinpoint the areas that the paid customers were under-utilizing, indicating what was difficult for them to understand.
This is easily one of the best moments in new projects. After listing the overarching goals (derived from the Problem Definition) and agreeing on design principles we would adhere to, we held a “jam” session with our design team and engineers. Inside the room at this point, there's an understanding that everything should be broad and that every idea has the potential to either be great or spark a new, possibly connected idea. Even if it seems crazy, throw it on the board.
When the jam session concluded, we prioritized all of the solutions we came up with (indicated above with red stars) and let the most viable solutions serve as the springboard to our next step.
After kicking around our favorite ideas, we had questions for a few other teams that would help dictate our next steps. Namely, we wanted to know the response time for fetching images, whether we were restricted to use certain content, and what (if any) the business concerns may arise regarding previewing a feature for users.
The reply from the product manager was incredible. Around 110,000 users would have access to the feature (should they activate it), and they could select one free field for a lifetime Crop Health Imagery. The images illustrate the health of crops on a user's field which is measured against a baseline to detect if anything is threatening his yield. The response time for images to load was estimated to be around 2-5 seconds (this was brilliant for our feature).
With a clear direction it was time to begin sketching variations upon variations, upon variations. Pen and paper immediately helped me forgo the aesthetic in order to focus on the user's potential journey.
The sketches underwent further rounds of feedback from fellow designers, engineers, and executives. One can consider this our internal user testing which helped us proceeded to visual design and prototyping.
Though the higher-fidelity visuals were based on the sketches, seeing colors and typography made for a seamless transition as I began creating screens for each platform. A huge takeaway from this step was that changes required a considerable amount of time because altering visuals was time-intensive.
Video walkthrough of the interactions
Interactive prototypes became very helpful in soliciting feedback from other team members. In addition to other designers, it was necessary to loop in engineers.
Design Feedback: Designers mentioned the abstract nature of how the new, proposed screens would fit in conjunction with what was currently in the app, around the information architecture, and ensuring the user would benefit from the additional content/feature.
Engineering Feedback: The engineers wondered how the pieces would fit in with the existing structure of the app and if the design components could be reusable across the app.
The cycle didn’t end there. We made specifications for each individual screen because of the app's nuances and actions we wanted to track to understand the behavior of our customers. The final prototypes landed in Invision, and we then passed it to the developers (along with the specs and assets for each platform).
The biggest setback involved engineering. They estimated it would take two minutes rather than two seconds (as we initially thought) for the backend to fetch the imagery. We erred in not seeking out feedback from our backend engineers at each stage. Continually involving stakeholders who will play a huge role in dictating engineering constraints is monumentally important.
There was another delay in the process. When a member of our product team had a concern, the designers didn’t stand by our design or defend it well. Allocating attention to the criticism caused a delay in the feature release, and we later learned that the "give-a-shit" level was relatively low.
Above, I mentioned that the purpose of the design jam session was to keep all ideas broad. The hope was that as we journeyed through our design process, the "funnel" would become progressively narrower until it became one solid workflow and deliverable.
However, following that design jam and one round of sketching, I immediately began animating. This was a horrible idea and IS a horrible practice. Instead of gradually working through the funnel, I jumped to the end of it. The animations were polished, but the workflow still needed fine-tuning. To show off the animations was to (arrogantly) say I had already arrived at the best solution, which wasn't true. The function of the funnel is to get your ducks in a row before committing to the right solution. That advice that will be permanently tattooed on my mind.